Wednesday, October 31, 2001

Yaygın İnternet Teknolojileri

İnternet servis tarafı için hangi teknolojiyi seçmeliyiz?

Doğru çözümü bulmak için birkaç seviyede düşünmek lazım:


* Hangi işletim sistemi en güçlüsü?
* Hangi işletim sistemi en rahat kontrol edilebilir?
* Hangi programlama dili İnternet servis paketleri içinde en yaygındır?
* Hangi programlama dili en rahat kullanılır?
* Hangi programlama dili için programcı daha rahat bulunur?

İşletim sistemi gücünden bahsederken önemli olan, hangisinin daha uzun süre ayakta kalacağıdır. Microsoft NT ve 2000 hala dayanıklı bir sistem değildir. Amerika'da büyük müşterilere ne zaman gitsek, eğer Microsoft ile site kurmuşlar ise, ondan başka bir sey arıyorlar idi (örnek Best Buy, Martha Stewart ). Genelde Microsoft İnternet tarihinin başlangıcında, reklam yapabilmek için, büyük müşterilere "size bedava site yapacağım" demiştir. Böylece etrafta hava atabiliyordu, mesela müşteri XYZ'nin sitesinde Microsoft programlarının olduğunu söyleyebiliyordu. Fakat bilinmeyen, bu sitelerin sırf reklam için Microsoft tarafından bedava kurulmuş olduğudur.

Fakat müşterinin site trafiği artmaya başlayınca site çökmeye başladı. Sebepleri: Microsoft işletim sistemleri dayanıklı sistemler değildir. O yüzden büyük siteler için (hatta küçükler için bile) Microsoft'tan vazgeçin. Microsoft çözüm ortağı bir şirkette danışmanlık yapmış biri olarak bunu üstüne basarak söylüyorum. Unix sistemleri, özellikle "çekirdek" işletim sistemi yaşlı olanlar daha iyidir. Solaris, HPUX bu tür sistemlerdir. Linux yaşlı olmasa bile o kadar cok test yapan kullanıcısı vardır ki, hataları daha hızlı yamanmıştır. FreeBSD içinde iyi seyler duyuyoruz. Fakat serbest Unix'ler arasında pazar ivmesi şu anda Linux arkasındadır.

Kontrol: Hangi sistem daha rahat kontrol edilir? Yani, sitenizin bakımını yapan insan, hangi sistem ile daha rahat eder? Bu arada hemen "rahat" kavramını tanımlayalım. Rahat ne demek? Eğer rahat, güzel pencerelerden ikon'lu programların üzerine tıklayarak sistem idaresi demekse, o zaman MS'in üstüne yoktur(!).

Yok eğer kontrol, hangi sistem daha iyi "otomotik kontrole alınabiliyor" ise, o zaman Unix çeşitlerini tavsiyeden baska çaremiz yok. Unix sistemleri genelde betik/script edilebilir sistemlerdir. Yani, her türlü işi, kayıtlı ufak programlar ile yapabilirsiniz. Görsel tıklamalar kayıt edilemezler. Fakat komut satırından yazdığınız kelime komutları kayıt edilebilir. Sistem idarecileri icin bu vazgeçilmez bir şeydir. İdarecilerin genelde aynı işi tekrar tekrar yapmaları gerektiği için, kayıtlı komutları geri sisteme işletebiliyorlar ise, bu çok iyidir.

Windows ile de nispeten kayıtlı komutlar işletmek mümkün ama, bu komutlar işletim sisteminin her yerine erişiyor. Çoğu önemli idare "muslukları" görsel şekilde yapılır Microsoft ile. Unix'de bütün güç yazılı komuttadır. Yazı kaydedilebilir. O yüzden sistem idarecileri Unix'i çok sever. Sevmeyenler Unix'i bilmez. Microsoft ile bir şey öğrenmek basittir, "Unix ile çok zor" diyorsa birisi, hemen dönün başka birini bulun.

İşletim sistemini seçtiniz. Peki hangi programlama dilini kullanacaksınız? Şu anda Java en iyisi. C++, kullanması ve öğrenmesi zor bir dildir, ve çok kolay hata yapmanıza izin verir. İşletim sistemi yazmak için uygundur, çünkü makina seviyesine inmek rahattır. Fakat şirketler için yazılan programlar bu seviyede calışmazlar, şirket programlarında çabuk ve yanlışsız programlamak daha önemlidir. Özetle, C++ dili ile çok müşterimize program yazdık, güçlü bir dildir ama vefasızdır. :)

Basitliği ve okunulabilirliği sayesinde Java cok kullanıcı toplamıştır. Şu anda dünya çapında Java programcıları Visual Basic programcılarından daha fazladır. Bunu unutmayın. Yaygın olduğu için, ve ayrıca Sun Microsystems şirketi arkasında olduğu için, servis paketleri tarafından çok tutulmuştur bu dil. ATG Dynamo, WebLogic, IMB WebSphere gibi paketler Java programlarını doğrudan çalıştırabilirler.

Programcı bulma rahatlığını da galiba aynı anda cevapladık.

Thread'ler

Program yazarken, kodunuza aynı anda, iki değişik işlemi yaptırma ihtiyacı hissettiniz mi?

Mesela, programınızın bir bölümü örütbağ üzerinden gelen bilgiyi depolarken, öteki tarafı aynı anda ekranda şekiller çizsin, kullanıcı girişi ile meşgul olsun.

Programlamaya başladığımızdan itibâren yarattığımız programlar, dizisel yöntemle çalışacak türdendir. Bu programların başlangıcı sonu belli, bilgisayar tarafından nasıl işletileceği hangi sırada işleyeceği bilinen programlardır. Birden fazla programı işleten işletim sistemidir, tek programın içinde bunu yaptırmak genelde lazım olmaz.

Fakat eğer, eşzamanlı çalışacak kod parçaları aynı program içinde lazım oluyorsa, ve kullandığımız dil Java ise, bize lazım olan İş Kolu denen kavramdır.

İş Parçacığı Nasıl Kullanılır

Java dili içinde İş Kolu kullanmak çok rahat. Ilk önce, eşzamanlı işleyecek kod için bir nesne yaratmak gerekiyor.

public class BizimNesne implements Runnable
{
public void run()
{
for (int i = 0; i<100; ilk_kol =" new" ikinci_kol =" new">

Yukarıdaki örnekte gördüğümüz Thread adlı nesne, kendi başına çalişabilen İş Kolu nesnesinin Java'daki halidir. Yani, Iş Parçacığı kullanmak için Java dilinde Thread nesnesini kullanmak gerekiyor.

Ayrıca, nesnesel programcılık içinde İş Kolu kullanımı ve akılda canlandırmak daha rahat, çünkü eşzamanlı programınız içinde işbölümü yaparken tek bir nesneye tek bir İş Kolu bağlarsak, hatirlamak ve kodlamak rahat oluyor.

İş Kolu kullanmanın en zor tarafı, değişik parçaların, aynı kodu (ya da nesneyi) aynı anda kullanması gerektiği durumlardadır. Bu gibi durumlarda, aynı nesnenin 'işlem ortasında' iki taraftan aynı anda değiştirilmesi hatalı kod çikaracağından, ortak kullanılması muhtemel nesnelerdeki işlemleri 'kitlemek' gerekir.

Kitlemek

Kitlenmesi gereken programları anlamak için şöyle düşünelim. Programınızı sabit varsayın ve programınızın aynı satırları üzerinden geçen değişik işlemciler olsun.

Aynı handan geçen değişik yolcular.

Bu yolcuların sadece bir tanesinin handa kalabileceğini varsayarsak, kitleme kavramını anlamaya başlayabiliriz. Java dilinde bu işi basaran 'synchronized' kelimesidir.

Kitleme yapmak, iş kolu tarafindan 'kullanılan' işlemler için gerekir. O yüzden, yukarıdaki örnekte kitleme yapmamıza gerek yok, çünkü programın kendisi zaten bir iş koludur. Fakat başka bir nesne gerektigini varsayalım.

public class BankaHesabi
{
protected int miktar;

public void paraEkle(int yatir)
{
miktar = miktar + yatir;
}

public void paraCek(int cek)
{
miktar = miktar - cek;
}
}

Bu program dahilinde mesela müşteri hesabına bağlanmış, ve para ekliyor olabilir, aynı anda banka da, faizden gelecek parayı hesaba ekliyor olsun. Eğer BankaHesabi nesnesi kendi kendini korumazsa, iki değişik işlemin aynı 'miktar' sayısına bakarak işlem yapması mümkün olabilir! Bu da programın doğru işlerliğı bakımından facia olacaktır. Müşteri hesabı yanliş çıkacak.

Bu hatayı engellemek için, programı şu şekilde değiştirmek gerekir.

public class BankaHesabi
{
protected int miktar;

public synchronized void paraEkle(int yatir)
{
miktar = miktar + yatir;
}

public synchronized void paraCel(int cek)
{
miktar = miktar - cek;
}
}

Synchronized kelimesi Java dilinde kitleme yapmak için kullanılır. Eğer bir iş kolu syncronized kelimesi içeren bir işlemi işletiyorsa, Java sanal makinesi şunları yapar.


* Işlemi kitle
* Öteki işlem kolları (varsa) onları bekleme kuyruğuna al.
* Bu gelen iş parçacığı için kodları işleme koy

Ilk gelen kolunun işi bitince, öteki parçacıklara teker teker izin verilecektir.

Ne zaman kullanılmalı

Internet ve sunucu üzerinde çalışan programların %99'unda işlem kolu kullanmak gerekmiyor. Bu tip programlar uygulama sunucusu denen öteki kodlar üzerinde işlediği için, eşzamanlı kodlama bu alt seviye program tarafından halledilmiştir.

Eşzamanlı kodlama yapmak hakkaten çetrefilli bir iştir, ve Internet sayfası sunan programlar için çok temel bir ihtiyaç olduğu için en alt kademede bu iş zaten yapilmiştir.

Mesela her kullanıcıya, aynı anda sunulan sayfa değişik Iş Kolları tarafından sunulmaktadır. Biz sayfayı tek bir kullanıcı farzederek yazarız, işin öteki tarafını uygulama sunucusu halleder (Tomcat gibi).

İş Kolunu özellikle kullanmamız gerektiği durumlar, kendi başına çalışan Java programları olabilir, eğer eşzamanlı işlemesi gereken yerler için bu programın kullanbileceği bir kutuphane erafta yok ise, o zaman bu tür kodlamayı kendimizin yapması gerekebilir.

Hız kazanımı

Ayrıca, ikinci bir Iş Parçacığı ekleyerek programımızın 2 kat hızlı çalışmasını beklemek de yanlış olur. Donanım seviyesinde düşünürsek, eğer birden fazla mikroişlemci mevcut değil ise (iki tane Pentium işlemcisi gibi) o zaman işletim sistemi mikroislemciyi iki parçacık arasında paylastıracaktır; böylece iki parçacık yarım hızda çalısır ve hiç bir kazanç olmaz.

O zaman, tek mikroislemci üzerinde parçacık kullanmak niye gerekiyor diye sorabilirsiniz ve haklısınız. Su kıstası kullanın: Eğer programınızda 'bir seyi bekleyen' ya da dıs dünyada bir seye takılıp kalan' bir kısım yoksa, birden fazla parçacık kullanmanın yararı olmayacaktır.

Programcılık genel kültürü açısından, Is Parçacığı kavramını bilmemiz ilerde ise yarayabilir.

Takım Oluşturma Asamaları

Günümüz is dünyasinda organizasyonlar çalisanlarinin takim oyuncusu olmalarini beklemektedir.Organizasyonlarin gücü ,güçlü takimlarla artmakta ve kisisel dinamiklerin yerini takim dinamikleri almaktadir.Özellikle yazilim sektöründe çalisan insanlar içe dönük ve bireysel degil; iletisimi güçlü ve takim içinde aktif olmak zorundadir.Bireylerin takimdan beklentileri farklidir.Bir kismi aynen futbolda oldugu gibi teknik direktör yani proje lideri yönetiminde çalismak ister.Bu kisiler proje lideri tarafindan tanimlanmis görevleri basari ile gerçeklestirirler.Bir kisim ise daha serbest çalisabilecekleri,görevlerinin takim dinamikleri içinde belirlendigi takimlarda çalismak isterler.Farkli egitim,kültür ve görüse sahip insanlarin takim olusturmalari hiç kolay degildir.Yapilan arastirmalar sonucunda takim olusturma asamalari asagidaki gibi tanimlanmistir.


* Takimin ilk kez biraraya getirilmesi
* Takim içinde çatismalarin ortaya çikmasi
* Takimin normlarinin olusmasi
* Takimin performansinin ortaya çikmasi

TAKIMIN ILK KEZ BIRARAYA GETIRILMESI : Bu asamada bireyler takim içindeki diger bireylere karsi pozitif yaklasmaktadir.Bireyler birbirlerini tanimaya ve anlamaya çalisirlar. Bireyler takim içindeki pozisyonlarini ayarlamaya çalisirlar.

TAKIM IÇINDE ÇATISMALARIN ORTAYA ÇIKMASI : Bu asamada takim içinde çatismalar ortaya çikar.Bireyler arasindaki çatismalar takimin dagilmasina ya da bir sonraki asamaya geçmesini saglar.Ilk asamadaki pozitif yaklasimin tam tersine,bireyler negatif yaklasim içindedir.

TAKIM NORMLARININ OLUSMASI : Ilk iki asamayi basari ile geçen bireyler takim normlarini,kurallarini,çalisma biçimlerini belirginlestirirler.Bireylerin takim içindeki pozisyonlari bellidir .Bireyler birbirleri tanimistir.

TAKIM PERFORMANSININ ORTAYA ÇIKMASI : En son asamada takim; performansini organizasyon içindeki problemlerin çözümü için kullanir.Bireyler çözüme odaklanirlar. Takimin gücü,takim içindeki bireylerin gücünün toplamindan daha fazladir.Bireylerin basarisi,takimin basarisi ile birlikte artmaktadir.Böyle takimlara 'kaynasmis takimlar' denir.Kaynasmis takimlarin belirgin özellikleri :


* Takim üretkendir.
* Takimin performansi,kisisel performanslarin toplamindan daha fazladir.
* Takim elemanlari yaptiklari islerden memnunlardir.
* Takimin ortak bir hedefi vardir ve takim bu hedefe ulasmak için çalismaktadir.
* Takimin fiziksel anlamda biraraya geldikleri ortak bir mekan vardir.
* Takim içindeki bireyler kendilerini essiz hissederler.
* Takim içindeki bireyler yaptiklari islerden kendilerini sorumlu tutarlar.

Takim olusturken yapilmamasi gerekenler :


* Takima güvenilmemesi , takimin hata yapma sansina sahip olmamasi ve takima müdahale edilmesi
* Bürokrasi
* Takim içindeki bireylerin fiziksel olarak farkli ortamlarda bulunmasi
* Takim içindeki bireylerin birkaç takimda görev almasi
* Projenin basinda belirlenen kalitenin projenin ortalarina dogru azaltilmasi
* Yanlis belirlenmis proje bitisleri

Kurumlar takim olusturmak için bilinçli olarak bu noktalara dikkat etmelidirler.

SQL Nasıl Kullanılmalı

Kume kavrami (ilkokuldan hatirladiniz mi?)

Veri tabani programlari, buyuk miktarda veriyi islemek icin yazilmistir. Yaptiklari butun islem, kaybedilmez turden veriyi saklamak, hizli sekilde geri getirmek ve gerigi oldugu zaman filterden gecirip sadece bir bolumunu kullaniciya sunmaktir.

Mesela asagidaki komut,
INSERT INTO MUSTERI VALUES ('Murat', 'Bilisim', 'Adres', 111);
veri tabaniniza VALUES kismindan sonra gelen bolumu, MUSTERI kayitina yazmanizi saglar. Elektrik kesilse de, ekraniniz patlasa da, bu veri bir yere gitmeyecektir. (Hard diskiniz bozulmadigi surece tabii). Eger bu veriyi geri istese idiniz,
SELECT * from MUSTERI WHERE ISIM = 'Murat';
komutunu uygulardiniz.

Simdi size ilginc bir sey aciklayacagim. SQL Veri tabanlari ilkokulda ogrendiginiz kume kavrami ile calisirlar. Hani kesisen kumeler, ek kumeler, vs.. hatirlarsiniz.

Sonucta veri bulmanin en rahat yolu, veriyi bir kume gibi gormek, ve istediginiz elemanlari istenen kume icinde, otekileri disinda gormek uygun olur.

Ve en can alici yere geliyoruz. Veri tabanlari, kume teorisi ile en hizli halde calisirlar. Bundan baska yol varmi ki? diyebilirsiniz. Elbette var. SQL diline sonradan eklenen bu uzatmalar, bazen gerekli olsa bile, genelde kacinilmasi gereken kullanim bicimleri. Bu alternatif metoda 'tekerleme metodu' diyecegiz, otekine kume metodu.

Tekerleme Metodu

Elinizde 1 milyon musteri kayidinin oldugunu dusunun. Diyelim ki, bir program yazmaniz istendi, bu programa gore, her musterinin size masrafi, getirdigi parayi birbirinden cikarip, musterinin size net maliyetini bulup, ayni musteri kayidi uzerinde 'net maliyet' adli yere geri yazmaniz istendi. Bu programi iki sekilde yazabilirsiniz.
   --- Tarif kod yaziyoruz
BASLA;
HER KAYIT ICIN
EGER MUSTERI SEHIR = 'ANKARA' ISE
KAYIDI AC;
NET_MALIYET = MASRAF - MUSTERI_KAR;
MUSTERI.NET_MASRAF = NET_MALIYET.
EGER SON;
SONRAKI KAYIDA GEC;


Yukaridaki koda gore, her kayidi teker teker acip, isleyip, tekrar geri yazmaniz gerekecek. Yani her islemi, teker teker yapacaksiniz, teker teker nasil isleyecegini dusuneceksiniz demektir. Yani veri tabanina, isini 'nasil' yapacagini ogretmeye ugrasacaksiniz demektir.

Fakat veri tabanlari, buyuk veri kumeleri uzerinde calismaya alisik degiller mi? Niye nasil yapacagimizi tarif edelim? Ne istedigimizi istesek, gerisini veri tabani yapsa olmaz mi? Iste alternatif yontem:

Kume Metodu

UPDATE MUSTERI SET NET_MASRAF = MASRAF - MUSTERI_KAR WHERE SEHIR = 'ANKARA';

Vay canina, bu daha kisa oldu. Hem de sonucta daha hizli isleyecektir goreceksiniz. Bunun sebebi nedir? Cunku kume teorisini kullandik. Veri tabanlari kumeler ile calismayi severler. Biz yukarida, bir kume tanimladik, 'ne' istedigimizi soyledik, ama nasil yapilacagini soylemedik. Kumemiz, Ankara sehrinde calisan musteriler idi. Bunu yaptiktan sonra, veri tabani arkasina donup veriye bakti, en hizli erisim ve degistirme algoritmasini kendi hesapladi, ve uygun olan en hizli metodu kullanima koydu. Biz veri tabaninin onune engel koymadigimiz icin, bu metod en hizlisi oldu.

Her teknolojinin kullanilmayi sevdigi bir sekil vardir. Bu sekli bulun, boylece teknolojinin cevapladigi sorun tiplerini de bulacaksiniz. Boylece cekic gereken yerde testere kullanmazsiniz, daha tecrubeli, gereken yerde gereken malzemeyi kullanan usta muhendis haline gelirsiniz.

Tuesday, October 30, 2001

SQL veri analizi nasıl hızlandırılır

Veri inclemek icin SQL dilini kullanan programcilar icin yaziyoruz. Ozellikle CRM, yani veri ambari olan programlarda, SQL dilini cok kullanacaksiniz. Servis programlarinda genelde SQL veri analizi 30,000 satirlik veriyi gecmez.

Veri ambarlari daha cok veri isler, o yuzden daha degisik tekniklere ihtiyac duyarlar.

Eger ambar SQL kodunu, internet sitelerinde kullanilan SQL kodu gibi yazarsaniz, saatlerce ekran basinda beklersiniz, SQL kodu katiyen isini bitirip geri gelmez.

Bu yuzden, SQL kodunuzu hizlandirmanin yolunu bulmaniz lazim. Kullanilan metodlar arasinda


* Tablo uzerinde dizin yaratma
* SQL koduna 'dizin' kullandirtma
* 'Gecici' tablo olurturma

Dizin nedir, acele isleyelim. Bildiginiz gibi veri tabani kayit tutar. Bu kayitlar tablolar icinde tutulur. Tablo ne oldugunu anlamak icin, diger yazilarimiza bakabilirsiniz. Hemen ornek bir veri tabani tablosu gosterelim.
MUSTERI
(
ISIM VARCHAR2(100),
SOYAD VARCHAR2(100),
EMAIL VARCHAR2(100)
)

Tablo veri turudur. Yani veri tabanina diyorsunuzki "Bu sekilde verileri bu tablo adi altinda girecegim, hazir ol". Bundan sonra veri tabanina SQL dilini kullanarak veri girebilirsiniz. Mesela
INSERT INTO MUSTERI ('Burak', 'Bayramli', 'burakbayramli@sk.com');

Eger veriye erismek istiyorsaniz, (mesela butun verileri ekranda gosterelim), o zaman tekrar SQL dilinde
SELECT * from MUSTERI;
.. diye bir kod isletmeniz yeterlidir.

Fakat, sadece belli kayitlara erismek istiyorsaniz, o zaman 'secici' SQL kodu kullanmaniz lazim. Mesela sadece ismi 'burak' olan kayitlari bulalim.
SELECT * from MUSTERI WHERE ISIM = 'Burak';

Iste dizinler, bu gibi SQL kodu hizlandirmak icin isinize yarar. dizinler kutuphanelerde olan kitap kartlari gibidir, hani bir kitabi bulmak icin once o kartlara bakip, nerede oldugunu ogrenirsiniz, ve direk o bolume gidersiniz. Veri tabani dizinleri ayni sekilde isler. Her tablo uzerinde dizin yaratabilirsiniz. Bir tabloda birden fazla dizin olabilir. Dizin yaratmak icin bir ornek verelim.
CREATE INDEX MUSTERI_DIZIN ON MUSTERI(ISIM)

Bu komutu isleterek veri tabanina dedinizki "Eger isim hanesini kullanara musteri tablosuna erisenler olursa, islemi dizin kullanarak yap". Dizin kullanan SQL kodu daha cabuk isler. Genelde dizinler otomatik olarak bulunur ve kullanilir veri tabani tarafindan. SQL programinizin degismesi gerekmez.

Not: Veri tabanlarinda tabii ki hicbir sey bir baska sey kaybetmeden kazanilmaz. Dizinlerin surekli guncel tutulmasi gereklidir, buda zaman alir. O yuzden her INSERT kodu artik daha yavas olacaktir. Alin size muazzam bir muhendislik problemi: "Programiniz daha cok analizmi yapiyor, yoksa verimi ekliyor". Eger analiz yapiyorsaniz, cok dizin eklemenin pek zarari olmaz. Ekleme yapiyorsa, dizinleri azaltin.

Gelelim ikinci metoda: Dizin kullandirma. Biraz once bahsettik, dizinlerin kullanilmasi otomatik olarak veri tabani tarafindan yapilir. Fakat bazen Oracle gibi gelismis veri tabanlari bile, hangi dizini kullancagini karistirabilir. Bu aslinda cok normal, sonucta milyonlarca kodluk programlar olsada, SQL programcilarinin beynini okuyacak seviyede degiller. Bazen Oracle cok kotu analiz karari alabilir.

Iste bu gibi vahim zamanlarda, SQL kodunuza "tiyo" vermeniz gerekir. Yani diyeceksinizki "Sayin oracle, biraz kafan karisti galiba, hangi dizin kullanacagini unuttun, al bunu kullan". Bunun kod olarak sekli:
SELECT /*+ INDEX (MUSTERI_DIZIN) */ ISIM FROM MUSTERI WHERE ISIM = 'burak';

Boylece Oracle, dogru dizini bularak veriye hizli sekilde erisebilir.

Ucuncu teknik, gecici tablo olusturma. Gecici tablolari, cok zor gorunuslu SQL kodunu parcalamak icin kullanin. Unutmayin, eger 3~4 sayfalik SQL kodu yazmissaniz, Oracle perde arkasinda komik seyler yapabilir. Veri tabanini belli sekilde isleme 'zorlamak' icin, SQL kodunuz parcalara ayirin, ve gecici tablolar olusturun, o tablolari alip sonraki tabloya koyun, vs. Unutmayin, eger gecici tabloyu siz olusturduysaniz kontrol sizde, eger Oracle olusturursa, sistemin vefasina kaldiniz demektir. Kontrolun elde olmasi her zaman daha iyidir.

Oracle Veri Erişim nasıl hızlandırılır

Eger cok buyuk veri tabani uzerinde, veri islemi yapiyorsaniz, bu yazimiz isinize yarayabilir. Genelde CRM sistemleri icin veriler ambara alinmadan once, bir on-temizlikten gecirilir. Mesela eger "butun isim" hanesi, ilk isim, soyisim diye ayrilmamissa, bir ufak program bu isi ambardan once yapabilir. Fakat bu islemi 4 milyon kayit uzerinde yapiyorsaniz, uzun zaman bekleyeceksiniz! Buradaki teknikler size yardimci olabilir.

Oracle veri erisim, daha once dedigimiz gibi, SQL kodu ile yapilir. Oracle bu dil uzerinde bazi uzatmalar yapmistir; Eger gerekirse, SQL veri erisim komutlari 'ayni anda birden-fazla' (paralel) sekilde isletilebilir. Bu ozellik icin tabii ki programci bu ozel SQL komutlarini bir sekilde Oracle veri tabanina iletmeli.

Genelde en cok kullanilan metod, bu paralel degisikligini 'cizelge bazinda' belirtmektir. Mesela MUSTERI cizelgesini paralel seviye = 4 diye tanimladiysaniz, bu kayida erisen her kod, 4 kopya halinde isletilir, ve bu kopyalar ayni anda isletilirler.
 CREATE TABLE MUSTER PARALLEL DEGREE 4
(
HANE1 VARCHAR2(10),
HANE2 VARCHAR2(30)
)

SELECT * from MUSTERI; -- iste bu erisim, 4 kopya ile, daha hizli geri doner.

Bunun isletim sistemi seviyesindeki etkilerini gormek icin Unix seviyesinde
ps -eaf 
komutunu isletin. Sonuclari mesela suradaki gibi olsun.
oraclesi 18578     1  0   Feb 06 ?        0:01 ora_p001_ESIPROD
oraclepi 18667 1 0 Feb 06 ? 158:59 ora_dbw0_ESIPROD
oraclesi 18578 1 0 Feb 06 ? 0:01 ora_p002_ESIPROD
oraclesi 18578 1 0 Feb 06 ? 0:01 ora_p003_ESIPROD
oraclesi 18578 1 0 Feb 06 ? 0:01 ora_p004_ESIPROD
oraclepi 18683 1 0 Feb 06 ? 9:47 ora_snp0_EPIPROD

Yukaridaki listede gordugunuz gibi, parelel komutunun isletim sistemi seviyesinde etkisi oldu. Isletim sistemi 4 tane 'islem' (process) gosteriyor.

Simdi butun cizelgelerinizin paralel seviyesini ikiye katlamadan once iyi dusunun. Paralel islemin en buyuk yararlari gunluk programlar icindir. Servis programlarinin arkasinda olan veri tabanini degistirmeden once tartmak lazim; 30, 40 bin kayit isleyen kod icin, bu degisiklik bir yarar saglarmi?

Oracle Kullanmak

Oracle, belli başlı veri tabanlarından biri. Veri tabanlarının nasıl çalıştığını öğrenmek için Oracle biçilmiş kaftan. Geliştirme ortamında Oracle kullanmak için para odemeye gerek yok. Oracle sitesinden programı indirmeniz mümkün. Uzun zaman sürecek, buna hazır olun. 1 Gigabayt civarı bir program.

Programı indirdikten sonra, nasıl kontrol edeceğimize gelelim.

Veri tabanı yaratmak, kullanıcı yaratmak, tabii ilk önce Oracle'a bağlanmak yapmamız gereken işler arasında.

Veri bakıcısı olarak bağlanmak için şunu yapın.

sqlplus /nologin

Arkasindan, Oracle sistem idarecisi olarak bağlanmak için sunu isletin

SQLPLUS> CONNECT INTERNAL;

Sifre girmeniz gerekebilir.

Artik Oracle'i indirip kaldirma islemleri yapabilirsiniz.

SQLPLUS> startup;

Yukaridaki komut, Oracle baslatmak için kullanilir.

SQLPLUS> shutdown;

Yukaridaki komut, Oracle'i (normal sartlarda) indirmek için.

SQLPLUS> shutdown abort;

Yukarıdaki komuta çok dikkat edin. Mecbur olmadıkça katiyen kullanmayın. Bu komut Oracle isler kodunda geri dönülmez bir hata olduğunda işletilir. Bazen Oracle'in temizlik yaptığı sıralarda, veya Unix sistem idarecilerinin yanlışlıkla Oracle'ın kullandığı dosyaları silmesi sebebi ile program donabiliyor. Bu gibi hallerde, shutdown komutu işe yaramayabilir. Gene de shutdown'a 2-3 dakika süre verin. Eğer hala işlemiyor ise, shutdown abort yapmanız gerekecek.

Kullanıcı Yaratmak

Kullanıcılar, şematik ile aynı kavram sayılırlar, ve yaratmak için 2 bilgi gerekir.


* Kullanıcı için ayrılmış parola
* Kullanıcı olağan bölgesi

Parola'nin ne işe yaradığını biliyoruz. Olağan bölge şu ise yarar: Eğer kullanıcı Oracle nesneleri yaratırken, hangi çizelge alanında yaratılacağını belirtmedi ise, varsayılan çizelge alanına olağan çizelge alanı diyoruz. Sonucta her nesnenin bir yerde muhafaza edilmesi gerekir, degil mi?

CREATE USER hasan IDENTIFIED BY hasan_slx DEFAULT TABLESPACE alan_1;

Veri Tabani Yaratmak

Veri tabani yaratmak için komut satırını kullanabilirsiniz. Fakat, veri tabanı yaratma işi Oracle'da oldukca karışıktır. Eğer elinizde daha önce işlemiş bir programcık yok ise, en iyisi dbassist adlı görsel programı kullanmak. Sitemizde genelde görsel tıklanan türden programları pek tasvip etmiyoruz, fakat dbassist programi bir çok seyi arka planda otomatik olarak yaptığından yeni baslayanlar için tercih sebebi olabilir. dbassist, ayrıca, veri tabani çıkartmak yerine, "veri tabanini yaratabilen" programcık da üretebilir. Bu programcığı örnek alarak kendi sürümünüzü yaratabilir, ve komut satırından birçok defa çalıştırabilirsiniz.

Oracle'ı Hızlandırmak ve İndisler

Coğunlukla tipik bilgi işlem (OLTP) performans sorunlarının altında, veri tabanı indislerinin yanlış kurulmuş olması yatar. Bu yazıda düzgün indis kullanımı için bazı kurallar vereceğiz.

Düzgün İndis Kullanımı

Performans eniyileştirme kararlarının çoğu, hangi indisi nerede kullanalım sorusu etrafında geçer. Bilgi işlem tarihinde, indisler bazen gereğinden az, bazen de gereğinden fazla kullanılmıştır. Benim tecrübeme göre, iki şekilde VTİ (veri tabanı idarecisi) çok gördüm. Ekteki liste, indisleri düzgün kullanmak için bir tavsiye listesidir.


* WHERE ifadelerinde sık kullanılan kolonları indisleyin.
* İki tabloyu birbirine zincirlemek (JOIN) için kullanılan kolonları indisleyin.
* Seçiciliği yüksek olan kolonları indisleyin.
* Seçiciliği en az olan kolonları BİTMAP indisi ile indisleyin.

Not: Seçicilik (selectivity), herhangi bir kolon X için, her satırın ne kadar değişik değer taşıdığına verilen isimdir. Eğer seçicilik bir kolon için yüksek ise, o kolondaki değerler her satırda daha sık değişir.

Üstteki tavsiyelere ek olarak, birkaç ek indis kullanımı daha tavsiye edebiliriz.

1'e yakın seçiciliği (yüksek) olan, ve nokta sorgu (point query) bağlamında kullanılan kolonlar için, Oracle hash indisi kullanın. Nokta sorgu, kesin uyuşan, tek bir satıra hedefli bir sogru demektir. Mesela bir kimlik kütüğünde bir şahsı getirmek için sosyal sigorta numarası üzerinden yapılan bir sorgu, nokta sorgusuna bir örnektir.

Öteki tür kolonlar için normal (B*tree) indisleri kullanabilirsiniz; bu tür kolonlar genelde bir yelpaze türünden bir pencere içine düşen birden fazla satırı geri getirmek için kullanılacaklardır. Bu sorgular WHERE ibaresinden sonra, ya büyüktür işareti ya küçüktür işaretini kullanan, ya da LIKE % gibi kolon içine bakarak satır tarayan sorgulardır.

Sık olarak güncelleştirilen, yani 'üzerine yazılan' kolonlar için indis kullanmakta dikkatli olun. Ayrıca, üzerinde çok silme ve ekleme işlemi yapılan 'tabloların' da kolonlarını genelde indislemeMEk için özen gösterin. Bu bahsedilen iki işlem de Oracle'ın indisleri izlemek için içinde tuttuğu B*tree veri yapısında çok sık değişimlere yol açacağı için, performans acısından pahalı seçenekler olacaktır, ve bu sürekli değişim indis iç yapısının bozulmasına, istikrarının dağılmasına (fragmentation) yol açacaktır. Asal anahtarlar ve göstergeç anahtarları bu kural için istisnadır.

Asal ve göstergeç anahtarlarını kesinlikle indislemeniz gerekir. Oracle, asal anahtar kolonları üzerinde kendiliğinden zaten bir tekil indis (unique index) yaratacaktır, ama göstergeç kolonlar üzerinde hiçbir indis yaratılmaz. Bu indisi CREATE ve ya ALTER ile sizin yapmanız gerekecektir.

İndislerinizi, gerektiğinde birden fazla kolonun oluşturduğu birleşik indis haline getirebilirsiniz. Böyle yapmak ile Oracle'ın eniyileştirici (optimizer) alt-programına yardımcı olur. Fakat dikkat: Oracle, Sybase'den ayrılan bir şekilde daha sıkı bir indis kapsayıcılığı kuralını takip eder. Bu kurala göre, bir sorgu sırasında indisin devreye sokulması sadece ve sadece eğer o kolon birleşik indisin başından başlayarak aynı sırada bir şekilde uyum bulunmuş ise devreye sokulacaktır. Mesela, bir tablonun a, b ve c kolonları üzerinde bir a+b+c birleşik indisi var ise, eniyileştirici bu indisi sadece WHERE ibaresinde a, a+b, ya da a+b+c kolonlarını aynı sırada bulduğu durumda kullanacaktır. B, c, b+c, ya da a+c kolonlarının WHERE'de bulunması, Oracle için indisi devreye sokmaz.

Üzerinde sorgu içinde fonksiyon işletilen kolonları (MIN ve MAX haricinde) hiç indislemeyin. Oracle eniyileştirici böyle kolonlar için indis kullanmaz.

Alternatif olarak, bir türetilmiş kolon yaratabilirsiniz, ya da tiyo ya da numaralar kullanarak sorgunuzu silbaştan tasarlayabilirsiniz. EXPLAIN PLAN komutunu kullanarak sonuçlarınızı kontrol edin.

Genelde üzerinde NULL ya da eşitsizlik karşılaştırılması yapılan kolonları indisleyeMEyin. Aşağıdaki operatörler eğer bir kolon üzerinde kullanılıyorsa Oracle eniyileştirici indis kullanmaz.


* IS NULL
* IS NOT NULL
* !=

Eşitsizlikten kurtulmak için, eğer mümkünse sorguyu = a da IN kullanacak şekilde tekrar yazabilirsiniz.

İçinde görüntüye (view), ya da alt-sorguya (subquery) referans yapan sorgularda indis kullanımı için dikkatli olun. Bu tür sorgular üzerinde EXPLAIN PLAN'i tekrar tekrar işleterek indislerinizin hakikaten kullanılıp kullanılmadığını ortaya çıkarın. Eğer kullanılmıyorlar ise, alt-sorguyu onu kullanan üst sorguya daha sıkı katarak indis kullanımını tetiklemeye uğraşın, ya da alt-sorguyu, ufak birbirinden ayrı sorgular halinde parçalayın. Aynı şekilde, görüntülerden tamamıyle vazgeçmeye hazır olun, ya da bu görüntüleri somutlaşmış görüntü (materialized views) haline getirmeyi tasarlayın.

Sonuç olarak, indis kullanımını uygun olduğu zaman yapın. İndislemiş olmak için indislemeyin. İş hayatımızda üzerinde 'hiç' indis olmayan veri tabanı da gördük, 'her kolon' üzeinde indis koyulmuş veri tabanı da...Üzerinde hiç indis olmayan veri tabanının kötü olduğu kesindir, cünkü en azından, asal anahtarlar üzerinde indis olması en tecrübesiz VTİ'ın bile bildiği bir şeydir. Her kolon üzerinde indis olması ise ya gereksinim belgesinde, ya veri tabanı tasarımında ya da uygulama tasarlanmasında olan eksikliklerin bir işaretidir.

Oracle Bağlantılarını Listeleyin

Son projemizde, toptan işlem yapan bir programdan şöyle bir hata aldık.

SQLException: ORA-01000: maximum open cursors  exceeded

Hataların hangi SQL'den geldiğini anlamak için Oracle'da aşağıdaki sorguyu kullanabilirsiniz.

SQL> select sql_text, count(*) from v$open_cursor group by sql_text;

Sonuç olarak aşağıdaki gibi bir çıktı gelecektir.

SELECT SYSDATE FROM DUAL                                              109
SELECT flag_1, flag_2 FROM TABLO 150
SELECT rowid, "KULLANICI"."ACCOUNT".* FROM "KULLANICI"."HESAP" Wher 1
Select /*+ CHOOSE */ cols.column_name as Name, nullable, da 1

Bu komut o anki açık/işlemde olan sorguları gösterir. 2. satırdaki sorgunun 150 açık cursor'u olduğunu görüyoruz. Bu tabii iyi değil. Tamir için, bu sorguları kullanan PreparedStatement'lara (.close()) cağrısını eklemek gerekir. Bu eklemeden sonra sorun düzelecektir.

Müşteri Çizelgeleri

Musteri kayıtları CRM için cok mühimdir. Sonuçta, bütün kayıtlar dönüp dolaşıp müşteriye bağlanır. CRM için böyle olması gerekir, çünkü raporlar hep müşteri etrafında dönüp dolaşır.


Mesela müşteri 123 örnek alınsın... Satış, ve Web site uğrak kayıdı olsun. Eğer bu iki değişik kayıdı, müşteri 123 üzerinden bağlanmazsanız, aşağıdaki rapordan doğru sonuç alamazsınız.

"Bana saat 12:00 den sonra web siteme uğramış, ve benim dükkanlarımdan 3 kere alışveriş yapmış müşterilerimin listesini ver".

O yüzden, çizelgeler (table) aşağıdaki gibi gösterilmiştir.

WEB (
SAAT DATE,
MUSTERI_NO,
WEB_SAYFA_NO
)

SATIM (
MAL_NO,
MUSTERI_NO
)

Gördüğünüz gibi MUSTERI_NO iki çizelge üzerinde bulunuyor.

Diyeceksiniz ki: "Ben veri tasarım'ı biliyorum. Bundan kolay ne var? Bir çizelgenin anahtarını, ötekinin içine koyarsınız, olur biter".

İşin mekaniği gelince haklı olursunuz, evet. Fakat hatirlatmak istedigimiz çözüm yolu değil, çözüm sebepleri. Veri tasarım sırasında, sadece arasında bir bağlantı olan kayıtlar birbirine bağlanır. Bir CRM sisteminde kaydedilmiş her 'olay' müşteriye bağlıdır. O yüzden, bu olaylar müşteri kayıdına bağlanmalıdır. Eğer CRM sisteminiz, web sitesi analizi yapıyorsa, 'sepete atma' 'ödeme' gibi kayıtlar, müşteri no'sunu içermelidir. Eğer veri transferi sırasında bu bilgi elinizde yoksa, bir şekilde bunu bulmalısınız.

Müşteri anahtarı yaratma metodu burada işinize yarar. Müşterileri birbirine bağlamak için bâzen elinizde ortak anahtar olmayabilir. Bir şirketin değişik paket programları (satış, depolama) birbirinden ayrı kisiler ve zamanlarda yazılmış olabilirler. Böyle ortamlarda müşteri kayıtlarında bir bağlantı yoktur. Eğer şirket özellikle uğraşmamış ise, ikisi tamamen değişik kayıt ortamlarında, veri tabanlarında olacaklardır.

CRM raporları için bu kayıtları birleştirmek esastır. Anahtar yoksa, "yaratacaksınız". Yâni, müşteri ilk ismin ilk 3 hârfi, adresin ilk 2 hârfi ve posta kodun tamâmı ile bir anahtar yapabilirsiniz. Bu sayede birbirine uyan anahtarlar size aynı müşterileri verecektir.

Genelde veri ambarınıza müşteri veri transferini en son yapın. Sebep: Mesela satış kayıtlarını ambara aldınız. Satış kayıtları üzerinde müşteri anahtarı olacaktır. Bu sayede sadece gerekli olan müşterileri ambara alabilirsiniz. Eğer müşteri için bir satış yoksa, o müşteri kaydını transfer etmek gerekmeyebilir.

Mimari

Mimari kurmak, mimariye karar vermek gibi terimleri bir yazılım projesi sırasında, ya da yazılım mühendisliği hakkındaki makalelerde çok görüyoruz. İlk bakışta uyanan intiba, "mimarinin teknik lider seviyesinde, ya da her programcının yapamayacağı türden birşey" olduğudur. Bu intiba, bir ölçüde doğru olabilir, çünkü etkili mimari yapı tecrübe gerektirir. Birçok diğer türden mimariyi başarısı ve hataları ile görmeden, mimariler arasında seçim yapmak zordur.

Öncelikle mimarinin ne olduğunu tanımlayarak başlayalım. "Mimari, bir projenin oyunu oynama kuralları + teknoloji seçimi ve kullanacağı tüm tasarım kalıplarının toplamıdır" diye bir tanım yaratabiliriz.

Aslında ikinci ve üçüncü noktalar, dönüp dolaşıp oyun kurallarına bağlanır. Yani ikinci nokta olan teknoloji seçimi, oyun kurallarını değiştirdiği ölçüde mimariye dahildir, mimariyi etkiler.

Daha detaya inersek, şimdi oyun kurallarının ne olduğunu tanımlamamız gerekir. Oyun kuralları, bir genel soruna verilmiş olan genel bir cevaptır. Mesela, bütün Java nesnelerimiz veri tabanına şu şekilde yazılsın şeklinde yaptığımız bir beyân, mimari bir seçimdir. Diyelim ki, her kalıcı Java nesnesi

public interface KalıcıNesne {
public void setBaglanti(Connection conn);
public Resultset oku();
public void yaz();
public void sil();
}

.. gibi bir arayüzü gerçekleştirmeli (implement) diye bir kural koyabiliriz. Bunu yaparken bir mimari seçim yapmış oluruz, eksiği ve fazlası ile bu secimi, bu genelleme ile tartışabiliriz. Mesela, üstteki mimari seçim yerine, "artık JDO ya da Hibernate adlı kütüphaneler var, bu oku(), yaz(), sil() gibi gereksiz kodlamaları yapmamıza gerek yok" gibi bir tartışma başlayabilir. Bütün bunlar mimari tartışmalardır. Gördüğünüz gibi, belli bir işlevin "algoritmasını" tartışmıyoruz. Birçok nesnenin arayüzünü nasıl kurulacağını belirleyecek genel kurallar saptamaya uğraşıyoruz.

Mimarilere gereksinimimiz, aslında, insanların belleğinin sınırlı olması sebebiyledir. Eğer beynimizde, proje sırasında karşımıza çıkan her soruna değişik bir türden bulduğumuz bir cözümü tutabilecek kadar geniş olsa idi, ve bu çözüm demetini anında başka bir insana insanüstu bir iletişim yeteneği ile aktarmamız mümkün olsa idi, mimariye ihtiyacımız olmazdı.

Fakat durum böyle değildir. Bu yüzden, bütün proje kodunu rahat bir şekilde tasvir (genellemeler ile) ve kendimiz açısından hatırlayabilmemiz için mimari kurarız. Ayrıca, kodlama hızı bakımından sürekli tekrarlanan problemlere sürekli aynı cevabı vermek, kodlama hızımızı arttıracak, projeye verim artışı sağlayacaktır.

Bir diğer fayda da, yazılım takımındaki her programcının, yazılımın her tarafı üzerinde rahatça çalışabilmesine imkan vermesidir. Eğer bütün programcılar, mesela görsel bir Swing tablosunu veri tabanına bağlarken aynı kaideleri takip etmişseler, birbirlerinin tablo kodları üzerinde değişik zamanlarda birbirlerinden habersiz çalışabilirler. Yani, "sandalye değiştirmek" denilen birbirinin yazdığı kod üzerinde çalışmak ve bakım yapmak, mimari üzerine kurulmuş olan bir kod bazı üzerinde çok daha rahat olacaktır. Bunun da verimlilik olarak takıma getirisi çok önemlidir.

Extreme Programcılık ve Mimari

Şimdi gelelim XP projeleri için mimarinin önemine..

XP tarihi yazısında Extreme programcılığın aylarca hiç kod yazmadan sürekli mimari/tasarım kurmaya uğraşan, ve dolu belge sıfır kod üreten rojelere/tekniklere karşı oluşturulduğunu söylemiştik.

Tabii bu tavsiyeleri okuyarak, hiç mimari yapmadan direk kodlamaya da atlamak yanlış olur. "Peki karar noktası nerededir? Ne kadar mimariyi, ne zaman, ne kadar süre ile tasarlamak gerekir?" gibi bir soru cevaplamamız gerekiyor.

Teknik liderlere: Aklınızda aşağı yukarı bir mimari sürekli olsun. Bu mimarinin kağıt üzerinde olması gerekmez. Eğer müşteri illa ki görmek istiyorsa, ballandırarak ve teknolojik bilginizi konuşturarar bu aklınızdaki mimariyi "genel hatları ile, arayüz seviyesine fazla inmeden" anlatabilirsiniz. Fakat yazılımı geliştirmek için bunun pek bir faydası yoktur, sadece iyi bir gösteri olur.

Yazılım sırasında aklınızdaki bu genel mimariyi kullanarak, programcılarınız sizden tavsiye istediğinde, genel hatlı bu mimari ışığında tavsiyelerde bulunabilirsiniz. Zaten, takım iletişimi iyi ise ve günlük toplantılarda teknik bilgi alışverişi yapıyorsanız, bilgi ve yöntemler kendiliğinden takıma yayılacaktır. Takım lideri olarak arada sırada koda bakarak, istediğiniz kalıpların kullanılıp kullanılmadığına bakabilirsiniz. Eğer kullanılmamış ise direk baskı ile programcının değiştirmesini istemeyin; yeniden düzenleme tekniği ile birim testlerin koruması altında programcılar kodun bu bölümüne tekrar geldiğinde gerekli değişikliği kendiliğinden yapacaklardır.

Programcılara: Arayüz seviyesindeki (çok önemli) tasarımı tanımlamak sizin göreviniz. Bunu yaparken, öncelikle elinizdeki özelliği kodlayacak kadar bir tasarım oluşturun. Kodlamayı tecrübenizin elverdiğince okunur, ve az satır kod ile yapmaya gayret edin, nesne tasarımı anlaşılır olsun. Fakat kırk hafta sonrasını görmeye uğraşmayın. Unutmayın, kırk hafta sonra kodlanacağını zannettiğiniz bir özellik, müşteri tarafından projeye dahil bile edilmeyebilir. Bu yüzden bu gün için, bu güne yetecek kadar tasarım yapın. Bu tasarımı yaparken tabii ki gerekli takım arkadaşınız ile konuşabilir, eş programcınız ile tartışabilir, arayüzünü kullandığınız programcılara soru sorabilirsiniz.

Bu ilk problemi kodlayıp, işi bitirdikten sonra, aynı çözümü kullanabilecek yeni bir özellik ile karşılaşabilirsiniz. O zaman mevcut olan kodunuzu bu yeni özellik için kullanıp kullanamacağınıza bakın. Eğer çok ufak değişiklikler ile çözüm halâ geçerli ise (düşük bir ihtimal) hemen eski kalıbı yeni özellik için hemen kullanabilir, ve ufak bazda bu mimari seçimi koda dahil edebilirsiniz.

Eğer önceki çözümün yeni özelliğe göre değişmesi gerektiriyorsa, bu değişimi yapın, ve eski/yeni kodu bu yeni ortak koda göre tekrar yazın.

Şimdi dikkat: Bu yaptığınız seçim, ufak seviyede bir tasarım, ya da geniş anlamda herkesin kodunu etkileyecek şekilde bir mimari seçim olabilir. Bunu takıma tanıtın, hatta daha da önce, genel kurallara yansıyacak türde bir seçimi teknik lider tarafından anlaşılmasına ve fikrinin alınmasa gayret edin. Eğer bu konu hakkında daha önce kural konulmamış ise, teknik lideriniz ya bu konuya daha eğilmemiş, ya da daha öncesi için önemsiz bulmuş olabilir.

Eğer bu doğru ise, düzgün iletişim ile yeni mimari kuralları tartışın ve uygulamaya koymaya başlayın.

Debugger İyi mi, Kötü mü

Asağıdaki konuşma, bir İnternet tartışma forum'undan alınmıştır.

TIGRAN

....Bütün bu bilgiler icin teşekkürler. Acaba Linus (Torvalds) bu konu hakkında ne düşünüyor? Bir süre önceki fikrini hatırlıyorum, ama belki değişmiştir. Yani, fikir değistirmek normal, ve kdb programı artık bayağı iyi durumda, acaba Linus bunlara bakınca, kdb programını Linux ana dağıtımına dahil edemez mi?

LINUS

Debugger yazılımlarını sevmem. Hiç bir zaman hoşuma gitmedi, herhalde böyle devam edecek. GDB programını kullanırım, debugger olarak değil ama, disassembler olarak.

Çekirdek (kernel) debugger'larını savunmak icin söylenenler beni az bile olsun etkilemedi. Emin olun, savunmaların çoğunu da duydum. Sonuçta söylenenleri şu kelimeye indirgeyebiliriz.

Debugger varsa, geliştirme yapmak rahatlar, ve yeni özellikler eklemek kolaylaşır.

Açık olayım, umrumda değil. Çekirdek kod yazmak "kolay" bir şey olmamalı. Satırları teker teker takip edip, program çalışmasını anında izleyerek hata bulma işlemini desteklemiyorum. Çekirdek içini en ince detayda görebilmemiz (debugger sayesinde) bence o kadar da iyi bir şey değil.

Güya, karşı destekçilere göre, eğer debugger yazılımı yoksa başımıza şunlar gelecekmiş.


* Bir hata olunca her sey çöküyor, fsck programını kullanıyorsunuz ve cok uzun zaman alıyor, bu da programcının moralini bozuyor.
* Debugger olmayınca, programcılar Linux çekirdek projesinden vageçiyorlar, çünkü işleri zorlaşıyor ve zaman alıyor.
* Yeni özellikler eklemek zaman alıyor.

Fakat bütün bunların nesi kötü?

Bana göre, durum hata değil, istenen özellik. Hem belgelenmiş, hem de boyle olması iyi, o zaman duruma hata diyemeyiz.

Özellikle, "yeni özellik eklemek zaman alıyor" düşüncesi, debugger kullanmak için hiç geçerli değil. Sanki özellik azalsa, bu Linux icin (ya da bütün yazılım sektörü için) bir problem olacak. Tam tersi. Benim en büyük işlerimden biri Linux icin yazılan yeni özelliklere 'hayır' demek, arayıpda bulmak değil.

Oh tabii, "ama her şey çöktü ve fsck komutunu kullandım, ve sonuç olarak hic yardım edecek bir ipucu vermedi, moralim bozuldu". Ne yapayım? Bu olana iki turlu karşılık verirsin. Ya daha dikkatli olmaya başlarsın, ya da çekirdek debugger programı istiyorum diye ağlarsın.

Açıkcası, dikkatli olmayanları bu şekilde önceden elemek bence iyi. Bu kulağa hissiz gelebilir, ne yazık ki öyle. Ve hani, 'Eğer sıcağa gelemiyorsan mutfaktan çıkarsın' seviyesinde bile değil. Daha da derin. Yazılım dünyasinda Darwin Kanunu'ndan bahsediyorum.

"Dünyada iki türlü programcı var" demek cok soğuk ve hissiz. Ama öyle ve ben ikinci tür ile çalışmayı tercih ederim. Alışın.

Ben kötü bir adamım. Linux dünyasi niye bazen tersini düşünüyor anlamıyorum. İnsanlar beni iyi zannediyor, fakat ben, sinsi ve plancı bir adamım; Eğer bana göre daha güzel bir Linux ortaya çıkacaksa, kaybedilen ve kırılmış kalpler beni zerre kadar ilgilendirmiyor.

Bunu öylesine de soylemiyorum. Hakikaten iyi bir adam değilim. İçimden gelerek ve yüzümü bozmadan "umrumda degil" diyebilirim.

Benim düşünceme göre, çekirdek debugger olmaması, programcıları otomatik olarak sorunlar hakkında değişik "seviyede" görmeye sevkedecek. Debugger yoksa, "nasıl çalıştığını anlayım, sonra tamir etmeye baslarım" düşüncesine girmezsiniz. Daha değisik şekilde düşünmelisiniz. Herşeyi daha başka seviyede görmek isteyeceksiniz.

Bir bakıma "kaynak kod, işler kod" ayırımı bu, daha bile fazlası... Kaynak koda bakmak değil, (tabii ki arada bakacaksınız, bütün en basit debugger bunu sağlardı zaten), ama kaynak kodun üst seviyesine bakacaksınız. Kavramların "anlamına" geleceksiniz. Yani, debugger olmazsa, üst seviyeye atlayıp programin genel olarak ne yapmaya uğraştığını anlamak isteyeceksiniz, tek bir satırın ne yaptığını değil.

Zaten 'önemli' hataların coğunda debugger programlarının faydası olması çok zor. Önemsiz aptalca hatalar da var tabii, geçende olan truncate() hatası gibi mesela... Beni ilgilendiren 'önemli' hatalar. Gerisi detay. Eninde sonunda tamir olurlar nasıl olsa.

Başkalarının aynı fikirde olmadığının farkındayım. Ben kimsenin annesi değilim, eğer debugger kullanmak isterseniz kullanırsınız, "lekelendiniz" diye düşünüp size arkamı dönecek falan değilim. Sadece, bu programları kullanmak konusunda benden yardım beklemeyin. Tercihim, programcıların debugger kullanmayı azaltması. O yüzden, bu yazılımlar Linux ana dağıtımın parcası olmayacak. Ayrıca revaçta olan programlar ismen bilinmiyorsa, ya da yokolurlar ise arkasından ağlayacağımı zannetmiyorum.

Linus Torvalds

Liderlik

Liderlik aslında "zıtlıklar" üzerine kurulmuştur. Burada anlatacağımız teknikler, iyi kullanılırsa çok yararlı, yanlış kullanılırsa çok zararlı olacak türden. Zıtlıklar dengesi böyledir.

Liderlik, gurup içine dahil olan insanları yetiştirir. Bu kişiler bir kişi olabilir, ya da dünyanın her tarafına dağılmış 1000 kişi. Bilindiği üzere, herhangi bir şeyi yapmak, yani icraat, zaten zor şeydir. "İcraata doğru" liderlik yapmak daha da zordur. Fakat esas zor olan liderlik kavramı içindeki zıtlıklardır - Takıma yardım et, ama bağımlılık yaratma. Takımı oluştur ona güç ver, ama katılma. İşin bitiminden sorumlu ol, ama işin yapımından direk olarak sorumlu olama.

İyi liderlik için size bir kaç ilginc öneri daha:


* Mümkün olduğu kadar sessiz olarak yönetin.
* Oyunculuk yeteneğini kullanıp iletişimi kalitesini arttırın.
* Liderliğini 'gereksiz' hale getirmek icin sürekli uğraşın.
* Liderlik stilini ölçeklenebilen, yani ufak bir takımdan büyüğüne işleyecek türden kurun. Başarı ölçünüz kazandığınız para, masanınızın büyüklüğü değil, yarattığınız "etki" olsun.

İnsani Noktalar

Liderlik ve akıl çelme arasındaki fark nedir? Liderlik yapmaya başladığımdan beri hep bu soruyu kendime sormuşumdur. Asağıda belirttiklerim seçme ölçeği olarak bana bu konuda yardimci olur. Liderlik:


* Doğruyu saklayıp, açıklamamak
* Korku

.. üzerine kurulamaz. Kurulsa bile tam randıman veren bir liderlik olmaz.

İktidar ve Sorumluluk

Liderliğin zorluğu, sorumluluğun 'tam' olması, ama icraattaki etkinizin 'dolaylı' olmasıdır. Takımınızın üzerindeki otorite ve size düşen sorumluluk arasındaki uyuşmazlıktan bahsediyorum. Biraz daha açıklayayım.

Sorumluluk demek, eğer takımın yanlışı olursa, "ben" ceza alırım demek. Otorite demek, bir işin bitirilmesi için gerekli kararları ben veriyorum demek.

Eğer "kontrol kimde olmalı" diye sorarsak, ilk başta cevabı bulmak kolaydır. Otorite ve sorumluluk sanki birbirleri için yaratılmışlar değil mi? Kontrolu elime alıyorsam, o zaman sorumlulukda bana düşer. Kontrol ben de ise, otorite de bende demektir.

Bir tek problem var. Kontrol güçlüdür, ama hassastır. Kırılgandır. Karakterinizin müsaade ettiği ölcüde etkili olur. Ölçeklenez, yani 10 kişiye, 20 kisiye aynı şekilde uygulanamaz. Sonuçta, tek bir insanin yapabileceği şeyler sınırlıdır.

Liderlik, kontrol demek değildir. Eger lider olmayı kabul ettiyseniz, sorumluk alıyorsunuz demektir. Sorumluluk tam olacaktır; iş bitmediyse suçlu sizsiniz. Ama bu sorumluluğu yerine getirebilmek icin kulandığınız otorite 'dolaylı' olacaktir. Bütün programları siz yazmayacaksınız. Eğer liderlikte iyiyseniz, hiç program yazmayacaksınız. Program yazmak yerine, sizin altınızda çalışan programcılara daha iyi program yazmasına 'yardımcı' olacaksınız. Kontrol/Sorumluluk dengesini kurabilmek, birbiri ile nasıl götüreleceğini anlayabilmak liderligin en zor tarafıdır. Bu dengeyi kuramayan liderleri farkedersiniz: Calışanına bağırır, sinirlenir, her yaptığını kontrol etmeye kalkar, ya da hic bir seyi iplemez, saklanır. Dolaylı otorite ve sorumluluk altında değisim yaratmak cesaret, bir gelecek planı ve kendini tanıyan insan (lider) ister.

Stephen Covey adlı yazarın, "Başarılı İnsanlarin 7 Alışkanlığı" adlı kitabında, şu kavramları öğrenmiştim. Etki alanı ve endişe alanı. Etki alanı şahsen değisim yaratabileceğiniz alandır. Endişe alanı sizin başınızı ağrıtacak, ve problemler çıkarabilecek olayların/insanların olduğu alandır. Ne zaman bu iki birbirine uymazsa, aradaki farktan stres doğar.

Mesela yarın bir pikniğe gidecekseniz, fakat eğer hava nasıl olacak diye endişe ediyorsanız, etkiniz altında olmayan bir şey hakkında endişe ediyorsunuz demektir. En iyisi, endişe alanınızı etki alanınıza indirmek, mesela çıkış planı hazırlamaktır. Yanınıza şemsiye almak gibi. Bu örnekte endişe alanı, etki alanından büyüktü.

Terside olabilir. Etki alanı, endişe alanından büyükse: Mesela lider ileri geri konuşuyor, ve etrafındakileri kırıyor, moralini bozuyor. Yani lider, ne hakkında endise edeceğini bile bilmiyor. Böyle durumlarda yapabileceğiniz sey, ya gözlem yeteneğini geliştirip, yaptıklarınızın neleri etkiledini görmek, ya da Kemal Sunal taklidi yapip, söylediklerinizin kötü etkilerini hafifletmek.

Bu iki örnekteki alan uyumsuzlugu bir çoğu liderde kronik olarak mevcuttur. Proje başarısı size bağlı. Fakat atlayıp bütün kodu tek başınıza yazamazsınız. İradenizi kullanıp otoritenizi etkileyebildiğiniz insanlara indirgemeniz gerekir. Liderlik yapmaya başladıktan sonra, söylediğiniz şeyler takım tarafından yanlış anlaşılabilir, o yüzden hergün, sorumluluk duygunuzu geliştirip, dediklerinizi, hareketleriniz ile uyum haline getirin.

Liderlik Niye Gerekli?

Lidersiz bir gurup insan düşünün. Eger düzenleri kurulmuş ve iyi halde zaten calışıyorlarsa, böyle calışmaya devam edeceklerdir. Fakat, değisim kapıya geldiğinde işler durum değişir. İnsanları bu yeni şartlara gore kendi kendini değiştirmesinin ne kadar zor oldugunu o zaman göreceksiniz.

Değisim bir kaç şekilde gelebilir.


* Teknik: Kulandığınız teknolojiyi değiştirdiniz, ya da teknolojiyi 'nasıl' kullandığınızı değiştirdiniz.
* Müşteri: Firma ürününüz için yeni bir pazar arıyorsunuz
* Düzen: Çalıştığınız düzende işlem değişimleri yapmanız gerekiyor.

Liderlik Değişim Yaratır

Böyle durumlarda kapıdan girişinizi yapıp (gürültülü olarak ya da sessizce, ama her zaman farkedilecek şekilde) ve takımınızı kurun. İletişim kalitesini yüksek tutarak, takımınızı kendi kendine yetecek duruma getirin.

Kalıplar

"General Patton büyük bir taarruz başlamadan 10 gün önce görev başına alınmıştı. Birliğine etki yaratması için elindeki zaman çok azdı. Patton, kitaptaki bütün moral verme, yönlendirme ve heyecanlandırma yollarını kullandı, ve ordusuna, savaşı kazanmanın MÜMKÜN olduğuna inandırdı. Patton sanki aynı anda, her yerdeydi. 34 yıllık askeri tecrübesinin her gramını kullanmıştı.... "

Beni liderlik kalıplarını aramaya iten işte bu satırlardır. Eğer, "Patton kitaptaki bütün yolları kullandıysa" nerede bu kitap? Liderliği anlatacak bu önemli eseri bulabilirmiyim?

Elinizde tuttuğunuz bu kitap, bu konuda benim denememdir. Liderlik konusunda öğrendigimiz herseyi, 'kalıplar' halinde paylasmaya uğrastık. Her kalıp için, kullanıldığı ortamı belirtmeye uğrastık, çünkü, kalıpları anlatmanın en iyi yolu kullanıldığı ortamı tanımlamaktır.

Tekrar belirtmeden geçemeyeceğim. Burada ugrastığımız maddeler patlayıcı türden, yani tehlikeli. Yanlış yapılan liderliğin etrafına olan kötü etkisi büyüktür. Şimdi kalıplara gelelim.

Kalıp 1: İlk Zafer

Yazılım takımının morali düşük durumda. Bitiş çizgisi yaklaşıyor, fakat yazılım hala bitecek durumda değil. "Bu takımı nasıl kendine inanır hale getirirsiniz?"

Bahsettiğimiz takımda çoktan değistirilmesi gereken şeyler olabilir. Eğer bu değisiklikler yapılmamış ise, bu durumun tarihinde, genelde, arka arkaya gelmiş ve takımın direncini kırmış kayıplar vardır. Sürekli kaybeden insanlar, otomatik olarak değisimi düşünmekte zorlanırlar. Bu gibi durumlarda en önemli sey, takıma yeniden kendine güven aşılamaktır. Güveni yaratacak en rahat sey, ufak bile olsa, bir 'başarıdır'.

Bu işin kötü tarafı denebilir. İşte önünüzde bir takım, sürekli kaybediyorlar. İyi açıdan bakarsak, ne kadar kaybederlerse ve dibe inerlerse, yeni gelen birinin işe yarayacak bir şey bulması o kadar kolaydır.

Bu kalıp için: Takımın beraber yapabileceği bir şey bul. Eğer takım tam anlamıyla felç olmuş ise, kolları sıvayıp kendin yap. Bu yapılan şeyin, yani başarının ufak olması önemli değildir. Takımın durumuna yardım eden, başarı olarak kaydedilecek herhangi bir şey olması yeterlidir. Eğer takım beraber yapmış ise, çok daha iyi.

Kalip 2: Kutuplayıcı Soru

Bir anlaşmazlığı nasıl ortaya çıkarırsınız? Anlaşmazlıklar kendini saklamaya bayılırlar. İki insan yıllarca birbiri ile uyum halinde olduğunu söyleyebilirler, fakat birden bire bir gün, birbirinin boğazına yapışmış olabilirler. Teyzem onlarca yıl amcam için özel yemek olarak kuşkonmaz yapardı, en sonunda bir gün, amcam hic kuşkonmaz sevmediğini söyleyebildi. Teyzem çok şaşırmıştı.

Saklanan anlaşmazlıklar başınıza dert açarlar. Bunları ortaya çıkarmak, değişim için en önemli şeydir. Lider olarak sizin, anlaşmazlıkları, daha fikir sahibi olan kişiler katılmadan görmeniz mümkündür. Görünce ne yapacağınız daha da önemli. Mesela, kuşkonmaz vâkasında gidip teyzeme diyebilirdim: "Teyze, amcama kuşkonmaz yapma, vallahi hic sevmiyor". Bu genelde ise yaramaz. Teyzem uzulur. Amcam gizledigi seyin aciga ciktigini gorunce kizabilir.

Daha iyi bir yöntem şu olabilir. "Gündemdeki anlaşmazlık hakkında öyle bir cümle ve fikir bulun ki, bir taraf katılsın, öteki taraf katılmasın.

Mesela, amcam ile teyzemi bir odaya alıp, sebzeler hakkında konuşmaya başlayabilirim. Bir ara, "Kuşkonmaz dunyanın en iyi sebzesi değil mi?" diye bir laf atabilirim. Amcam diyecektir, "Hiçde değil, ben yeşil fasulyeyi daha çok severim". Iste şimdi uzlasmaya doğru bir adım atmış olduk.

Kalıp 3: Endişeleri Aktarma, Tercüme Et

Takım lideri olarak göreviniz, hem kendi, hem de takımın görev/sorumluluk çizgisini birbirine uydurmak. Mesela, eğer müşterinize belli bir bitiş tarihi verdiniz, ve o tarihte hata sayısı belli bir düzeye düşmemiş ise, müşteriniz başınıza dert açacak. Bu durumda takımınıza dönüp, 'eğer hata sayısı düşmezse, müşteri başımıza dert açacak' demeyin. Müşterinin dert acması, takımın direk olarak gördüğü hissettiği bir sey değildir, ayrıca ellerinde yapacak birşeyleri olmayabilir. Hâtta takım icraat seviyesi düşebilir bile; çünkü stres seviyesini arttırdınız.

Daha iyi bir yöntem, şu olabilir. Takıma dönüp şöyle deyin: "Müşterinin benim başıma dert açması beni kaygılandırıyor. Sizin bu duruma yardım etmek için üstünüze düşen bölüm hata sayısını düşürmek. Daha hızlı hata düzeltmeniz için size nasıl yardım edebilirim?"

Böylece size düşen etki/endişe alanınızı doğru saptadınız. Takımın etki/endişe alanı da doğru bir düzene girmiş oldu.

Site Kullanım Ölçümü

Bir e-ticaret ya da içerik sağlayan bir site kullanıma açıldıktan belli bir süre sonra kullanıcılarınızın yeni ürünlere, yeni yazılara nasıl tepki verdiğini ölçmek isteyeceksiniz. İnternet'in en büyük avantajlarından biri, bu ölçümü yapma yöntemi, aynen yaptığınız yayınlar gibi Java kodu ile hallolacak!

Tabii Apaçe gibi internet sunucu programları her sayfaya erişim olduğunda dosya kütüğü üzerine bir satır yazabilirler. Erişilen sayfa ismi, isteğin nereden geldiği, çerez içeriği, vs. gibi şeyler olabilir. Fakat bu tür internet sunucu bazlı tutulan kütükler, istediğiniz kadar zengin bilgi içermecektir. Bunun sebeplerine gelelim.

Artık İnternet yayıncılığı ve uygulama sunucuları oldukça ilerlediği için, değişken içerikli türden sayfalar, "bir tek sayfa" kodu kullanarak "birçok" sayfa içeriğini gösterebiliyor. Mesela sitemizden örnek verirsek, article.jsp sayfası her yazıya tekabül eden XML'den üretilen HTML'i dinamik olarak bulup, otomatik olarak cevap nesnesine diğer içerik ile beraber birleştirip/ekleyip tarayıcınıza gönderiyor.

Fakat internet sunucusu takip için dosya isminden başka bir şey anlamadıgı için kütüğunde görünen erişim izi sürekli article.jsp oluyor! Fakat article.jsp sayfasını kullanarak 10 çeşit yazı servis etmiştik. İnternet sunucu programı ne yazıkki bu türden önemli bir detayı kaçırdı.

Çözüm olarak erişim izlemeyi, içerik kodlamasının yapıldığı aynı yere koyacağız, JSP sayfasının içine.

Tasarım

İz bırakma işlemini iki şekilde yapabiliriz. Ya veri tabanına, ya da dosyaya yazacağız. Dosyaya yazmanın bir zararı yok. Fakat, uygulama sunucusundan (Tomcat gibi) çıkan daha zengin kullanıcı izleme bilgisini, sonradan sorgulama yöntemi kullanarak en rahat veri tabanında analiz edebilirsiniz.

Fakat bir uyarı vermeden geçemeyeceğim. Eğer, mesela her sayfaya erişimde veri tabanına bir satır yazacaksak, bu işlem sayfa yüklenmesini yavaşlatacak. Çünkü tecrübeye dayanarak söylemek gerekir ki, bilgi işlem dünyasında veri tabanına erişmek "pahalı" bir işlem diye bilinir, bir sorgu işletip cevabını almak öteki işlemlere oranla her zaman daha yavaştır.

Yani, şöyle düşünün; sitenizi ölçeklemek için 2 tane daha sunucu eklediniz, sayfaları değişik bilgisayarlara paylaştırdınız, umudunuz site trafiğini bölerek her bilgisayara düşen yükü biraz olsun hafifletmek. Fakat eğer her sayfaya erişimi içinde veri taban erişimi var ise, bütün paylaştırma bir işe yaramadı, çünkü hala tek merkezi noktaya odaklanmış muazzam bir yük sözkonusu, yani veri tabanı üzerinde.

Tabii veri tabını ölçekleyerek, bazı bilgileri önbelleğe alarak tekrar hızlandırma yapmanız mümkün. Fakat, bahsettiğimiz türden kullanıcı izleme kodları, bir çizelge üzerine sürekli EKLE (INSERT) işlemi yapıyor olacak. Bu türden bir işlem sitenizin diğer dinamik kısımlarının gerektirdiğinden ayrı bir SQL kodlaması ve ölçekleme planı gerektirebilir. Aklınızda olsun.

Bu işe en rahat çözüm, aslında, JSP ile EKLE sorgusu arasına bir ileti kuyruğu koymak. Mesela Java JMS standard arayüzünü kullanarak, bir ileti kuyruğu üzerine izleme bilgisini sürekli olarak atabiliriz. JMS ortamı salla-gitsin (fire and forget) tipi çağırım kullandığından, sayfa yüklenmesi veri tabanına bağlanmamış olur. Bir taraf kuyruğa ekler, öteki tarafta kuyruktan bilgiyi boşaltıp veri tabanına yazabiliriz.

Bu da aklınızda bulunsun.

Hangi Bilgileri Kütükleyelim

Sitenizin hangi kullanımını ölçmek istiyorsanız, o bilgiyi izleyin ve kaydedin. Mesela, bir elektronik gazete için hangi makalenin, saat kaçta, hangi makaleden sonra okunduğu önemli bir bilgi olabilir. Veri tasarımı olarak şöyle yapabiliriz.

  ..
public static final String YAZI_OKUNDU = "1" ;
public static final String KATEGORI_LISTE = "2" ;

protected String olcumTipi;
protected String oturumNo;
protected String yaziIsim;
protected Date zaman;
protected String kategoriIsim;
protected String referans;
protected String uzakMakinaIp;
protected String uzakMakinaIsim;
..

Veri yapısıni Java nesnesi olarak gösterdik, çünkü sitemizde JDO kullandığımız için .class dosyasından geri-işlem yaparak veri tabanı çizelgesi yaratmamız mümkün oluyor. EKLE, SEÇ gibi veri taban işlemlerini JDO otomatik olarak çıkartabiliyor, programcı sadece bir Java bean verip, üzerinde JDO komut satırından bir program işletip SQL, JDBC kodlarını .class dosyasına eklettirebiliyor. JDO ile veri taban bağlaşımı yapmak çok rahat.

İzleme konusuna dönelim: Bean'imiz birden fazla izleme 'çeşidini' temsil edebilecek. Yani, kategori listesine tıklamak ile yazı detayına tıklamak aynı bean üzerinde olacak, bu yüzden mesela yazı izlerken kategori kolon değerleri boş kalabilir. Bu o kadar önemli değil.

Java tasarımı olarak, JSP sayfalarının içinde ikidebir bean'ler ile uğraşmamak için, ikinci bir arayüz yaratıp, bu (daha geniş) arayüze bean yaratma, yazma gibi görevleri verecebiliriz. Bu daha geniş arayüz şöyle olabilir.

  public static void sayfaZiyaretKaydet(
String oturumNo,
String yaziIsim,
String referans,
String uzakMakinaIp)
{
Olcum olc = new Olcum();
olc.setOturumNo(oturumNo);
olc.setYaziIsim(yaziIsim);
olc.setZaman(new Date());
..
..

..ve JSP içinde kodu şöyle olacak.

<%
OlcumKapisi.sayfaZiyaretKaydet(request.getSession().getId(), file, request.getHeader("Referrer"), request.getRemoteAddr());
%>


Analiz

Bu yazıda, izleme bilgisinin nasıl toplanacağını işledik. Alınan bilginin işlenmesi çok daha geniş bir konu. Sık erişilen bir siteden çıkacak bilgilerin hacmi tartışılmaz. Bu bilgileri analiz etmek için istatistiki, olasılıksal yöntemler kullanılıyor, hatta yapay zeka yaklaşımlarını kullananlar bile var. Veri madenciliği denen, "veriden bilgi" çıkartmak başlı başına ayrı bir dal, bu konularda ileride değişik yazılarımız olacak. Bu konularda lazım olan Java bilgisi değil, SQL, bir metin-yazar ve bol bol zaman olacak.