Friday, October 31, 2003

Yapay Zeka ile Problem Çözümü

Baglanti

Oracle ve İşlem İdaresi

Veri tabanlarını kullanırken anlamamız gereken çok önemli bir kavram işlem (transaction) kavramıdır. Veri tabanı nedzinde işlemler, zamana bağlı olarak gelişirler, ve bu konuda işlemler, veri tabanına direk bağlı olan programların veriyi 'hangi zamanda, nasıl' göreceğini kontrol ederler.

Yani, dış dünyadan veri tabanının içine bakmamız bir işlem çerçevesinde gerçekleşir.


Üstteki resim ile işlemlerin nasıl kullanıldığını görüyoruz. Benzetme ile anlatmak gerekirse, bir işleme başlamak şuna benzer: Mesela veri tabanı bir apartman dairesi olsun, o zaman işleme başlamak, kişinin (kullanıcı) evin bütün odalarına (veriye) bakıp, akılda tutup, sonra bir odaya girmesidir. Bu odaya girince, kişi aklında olan bilgileri işleyip hakkında kararlar verebilir, vs.

O sırada, öteki odalarda ve de evin içinde yapılan kalıcı değişiklikleri göremez.

İşlem bitimi, Oracle COMMIT kelimesi ile olur, ve benzetmemizdeki kişinin odanın dışına çıkıp yaptığı değişiklikleri evin içine kalıcı olarak koymasına ya da, dısarıda yapılmış olanları görmesi demektir.

Buna işlemlerin kendilerini birbirlerinden 'izole' edebilme özelliği denir.

Kilit Sistemi ve İşlem Sınırları

Ayrıca, işlemlerin veri izolesi için kullanılmasına ek olarak, Oracle kilit sisteminin de işlem kavramında direk bağlandığını göreceksiniz. Yani,

SELECT * FROM CIZELGE1 WHERE DIZEY1 = '111' FOR UPDATE;

komutu sonucunda, DIZEY1 değeri 111 olan veri satırı (row) kitlenecektir. Bu satır, aynı bağlantı üzerinde COMMIT komutu verilene kadar kitli kalacaktır.

Aynı işlem sırasında kitli satıra erişmek isteyen öteki kullanıcılar, eğer yukarıdaki komutun AYNISINI işletirlerse, beklemede kalacaklardır.

Beklemeden geri dönmek istiyorlar ise, FOR UPDATE kelimesinden sonra NOWAIT (hiç bekleme) kelimesini eklemeleri gerekir.

İslem Ne Zaman Başlar?

Bir işlem, zaten bir işlem içinde bulunmuyorsanız, herhangi bir SQL komutuna kullandığınızda otomatik olarak başlayacaktır. Yani BEGIN TRANSACTION (işleme başla) gibi bir komuta gerek yoktur. Bir önceki işlemi COMMIT ile bitirdiyseniz, aynı bağlantı üzerindeki ilk SQL komutu otomatik olarak sonraki işlemi başlatır.

Gereğinden Fazla Calculus

(MİT üniversitesi Matematik hocası Gilbert Strang'in MİT üniversitesine hitaben bir yazısından alınmıştır)

Calculus I, Calculus II, Calculus III - öğretim sistemimizde ne kadar büyük bir dengesizlik! Matematiğin geri kalan kısmı Calculus tarafından boğuldu denebilir. Bu kadar Calculus dersinden sonra takip eden ders herhalde Türevsel Denklemler (gene Calculus), Calculus'tan önceki ders'te herhalde Calculus'a Giriş dersi idi. Arkadaşlar, bu dengesizliği düzeltmek bizim görevimiz, bunu başkasından bekleyemeyiz. Lineer cebir'in ne kadar önemli bir ders olduğunu biliyoruz. Bu ders seçmeli/rasgele alınan bir ders değil, uygulama olarak birçok öğrenciye Calculus'dan daha faydalı olacak bir ders. Artık sayısal bir dünyada yaşıyoruz.

Bu konu hakkında dünyadaki hocalara öncü ve örnek olmamızı istediğim için, Lineer Cebir'in faydalarından bahsetmek istiyorum. Özetle şöyle düşünüyorum: Eğer şu ankinden daha fazla öğrenci Lineer Cebir öğreniyor ise, matematik bölümü bir şeyleri doğru yapıyor demektir. İstatistik ve Ayrıksal Matematik te lazım. Umarım bölüm başkanı ve rektör onaylar. İnanıyorum ki bu sayede öğrencilerimi için doğru şeyi yapmış olacağız.

İzin verirseniz, lineer cebir ders basamaklarından bahsedeyim. Mesela dersin her aşaması belli denklemlerin çözümüne, ya da o denklemleri çözmeye temel olan fikirlere ve algoritmalara göre ayırılabilir. Bu safhalar birbirini tamamlamalıdır. Mesela 4 denklemi merkez olarak alabiliriz.
En önemli nokta, herhangi bir uygulama için (gerçek dünyada) bir doğrusal 'sistemi' görebilmek. Şu bizim ünlü A matrisimizi bulabilmek, tanımlayabilmek ne kadar önemli değil mi? Bunun sonrasında tabii ki o matris üzerinde işlem yapmamıza yardımcı olacak fikirler takip edecek.

* Alt-uzaylar ve bazlar, izdüşümler ve dikgenlik, özvektörler ve özdeğerler
* Algoritmalar da çok önemli (matris çarpımı da buna dahil)
* Ax = kolonların katışımı, A = LU ile yokedilmesi, sonra Gram-Schmidt işlemi

En mühim konu da 'doğrusal dönüşüm'. Eğer bir problem içinde matrisin bazına ne olduğunu biliyorsak, her şeyi biliyoruz demektir. Ben örneklere odaklanabilirim, siz ispatlara odaklanabilirsiniz, ama sınıfın ne beklediğine her zaman kulağımızı açık tutalım.

Tekrar ana konuya döneyim, çünkü hepimizin yardımını ve eylemini gerektiriyor. Lineer cebir hakkında çoğunlukla destek görüyoruz, ya da aldırmazlık görüyoruz. Öteki hocaların da kendi yapacak işleri var, hattâ ve hattâ üst düzey mühendisler bile lineer cebiri istenmeyen bir şey olarak görebiliyorlar. Belki de bilgisayarların işleri nasıl değiştirdiğinin farkında değiller. Fakat sonuçta öğrencileri önde tutarak doğru seçimi yapacaklardır. Öğrenciler durumu anladığında hocalarımız da doğru seçimi yaptıklarını inanacaklarına eminim.

Calculus I, II ve III derslerinin kendisinin reform edilmesi bu sunumun dışında. Bu dersler de önemli, ama hayat-memat seviyesinde değil. Öğrencilerin çoğuna 'yararlı' olacak türden matematik öğretmek bizim görevimiz.

Gilbert Strang

JDBC ile Tablo Karşılaştırmak

Bazen müşterimiz, bilgi işlem sisteminde çok önemli olarak görülen bazı bilgilerin 'değiştirilmesi' halinde bu olaydan haberdar olmak isteyebilir.

Genelde bu tip erişim problemleri için klasik çözüm, neyin değiştiğini raporlamak yerine, kullanıcı erişim haklarını kısıtlayan bir sistem getirmektir.

Fakat bazen sistem kullanıcıları özellikle erişim kısıtlamayı değil, neyin değiştiğini bilmek isteyebilirler. Müşteriniz, "bazı bilgilere erişmeye normal olarak hakkı olan kişilerin bile yaptığı değişikliklerden haberdar olmak istiyorum" diyebilir. Bu pek normal olmayan bir istek olsa da, mümkündür.

Bu teknik probleme, şu şekilde bir çözüm getirebilirsiniz.

Ya, değişimi görsel bazlı olarak görsel kod üzerinde yakalarsınız, ya da, değişimin nihai adresi olan veri tabanına inerek çıkartabilirsiniz.

Veri tabanına inerek yapabileceğiniz kontrollerin bir iyi tarafı şudur: JDBC genel veri bilgileri (meta data) denilen, bilgiyi tasvir eden bilgi sayesinde, bir veri tabanı içindeki tabloları ve onların kolon isimlerini genelci bir şekilde şekilde (metin bazlı) olarak toplamamız mümkün oluyor. Bu bilgileri kullanarak, veri tabloları içindeki veriye bile aynı genelci şekilde erişebilirsiniz. Yani, veri erişmek için yazdığınız kod, bir tablodan ötekine değiştirilmeden işleyebilir!

Özellikle değişim yakalamak gibi nerede bulunacağı bilinmeyen bir veri değişim arayışı, genelci bir yaklasımla çok daha yararlı olacaktır.

Ekte verilen TabloKarşılaştırıcı kodunda gördüğünüz gibi, herhangi bir tablonun 'öncesi' ve 'sonrası' karşılaştırmasının yapılması, bu tür bir yaklaşım ile çok kolay oluyor.

TabloKarşılaştırıcı

JSTL Yaratıcısı İle Mülakat

(JSL yaratıcısı Shawn Bayer ile mülâkattan alınmıştır).

Bize kendinizden ve şu anda uğraşmakta olduğunuz projeden bahsedermisiniz?

Yale üniversitesinde araştırmacı programcı olarak çalışıyorum. Bir şekilde Apaçe Yazılım Vakfı ve Java Birlik Süreci'ne dahil oldum. Şu anda JSP standart etiketleri (JSTL) teknolojisinin referans yazılım lideriyim. Bu yazılımı Java Birlik Süreci altında gerçekleştiriyoruz. Manning kitabevi altında 2 kitap yazdım; biri Web Development with JavaServer Pages, öteki JSP Standard Tag Library adlı kitap, yani JSTL.


JSTL Nedir?

JSTL, standart etiket kütüphanesidir. Bildiğiniz gibi, JSP altında anlık değişen türden içerik konabiliyor. Mesela programcık (scriplets) kullanabilirsiniz, ama herkesin bildiği gibi programcık ile sayfa yazdığımız zaman, içeriği işlem mantığından ayırmak zor oluyor. Sayfaya bakıyoruz, bir metin, bir Java kodu, tekrar HTML, tekrar Java, yani tam bir keşmekeş. Alternatif yöntem etiket kütüphaneleri, yani ihtiyaca özel (custom) etiketler idi. Etiket kütüphaneleri uzun süredir aramızdalar, değişik şirketler değişik kütüphaneler çıkardılar, Apaçe'den de bazı kütüphaneler geldi. JSTL atılımı bu bütün dağınık olan kütüphanelerin ortak bir temsilini çıkartıp standart bir etiket dilini ortaya koymak idi. Böylece, mesela içerik yazan görsel tasarımcılar tek bir etiket dili öğrenebilirler, ve her J2EE uyumlu servis ortamında kullanabilirler. Dil standart olunca, standarta uyan Uygulama Servisleri arasında bir rekabet çıkabilir, bunun sonucunda daha etkin yazılımlar ortaya çıkacaktır. Ya da, benim yazdığım gibi genel etiket konularında artık bir kitap yazılabilir, çünkü üzerinde mutabakat kurulmuş olan tek bir dil vardır.

JSTL JSR (Java Tarifname İsteği) ile Apaçe arasındaki ilişkiyi anlatabilir misiniz?

JSR süreci Java Birlik Süreci altındadır. Bütün öteki JSR'lar gibi (mesela J2ME, J2EE) birlik altındaki şirketler, uzmanlardan aldığı yorumlar ile ilerler. Benim yönettiğim Referans Yazılımı, Apaçe altında sürmekte. Yani JSTL tarifnamesinin 'gerçekleştirimi' Apaçe altında yapılıyor, aynen JSP/Servlet tarifnamesinin kodlamasının Apaçe altında Tomcat ile yapıldığı gibi. Yani ortada herkesin kodlama yapabileceği bir standart var, biz bu kodlamalardan sadece biriyiz. Ama referans olarak ilkiyiz. Standart kavramının güzel tarafı burada: Yazılımın gerçekleştirme safhası değişik şirketler tarafından yapılabileceği için, rekabet sayesinde daha çok iyi ürünler ortaya çıkabiliyor.

Apaçe'nin Sun ile özel bir ilişkisi var gibi gözüküyor... Bu ilişkiden biraz daha bahsedebilir misiniz?

Evet, hakikaten prensip olarak düşünürseniz Sun'ın JSTL için niye IBM ya da BEA gibi büyük 'ticari' şirketleri seçmediği biraz garip gelebilir. Fakat Apaçe'nin şimdiye kadar gerçekleştirmiş olduğu serbest yazılımlara bakarsanız, Apaçe Web Sunucusu ya da Tomcat gibi büyük, ve çok başarılı olmuş olan projeler görürsünüz, normal olarak bu yazılımlar etrafında büyük bir kullanıcı gurubu oluşuyor. Böyle bir kullanıcı gurubu, JSTL için uygun bir ortamdı zannediyorum. Ben bu kararın yapıldığı seviyede olmadığı için sadece tahmin edebiliyorum, fakat Apaçe etrafındaki kullanıcı gurubuna bir örnek vermem gerekirse; Şahsen Apaçe etiket kütüphanesi daha beta seviyesinde iken, etrafında birçok kullanıcı vardı. Ben de bu ilk kullanıcıların sorularını İnternet üzerinde cevaplıyordum, vs.. Tabii bu ileride yazacağım kitap için birçok soru/cevap topladım, yani böyle bir şeyi yapabilmem bile Apaçe etrafında nasıl büyük bir topluluk olduğunu gösteriyor.

JSTL amacı nedir, ve hangi problemleri çözmek için ortaya çıkmıştır?

Ee evet, daha önce belirttiğim gibi JSTL etiketlere bir standart getirmek görevini güdüyor, yani oluşum olarak şu an JSP teknolojisi ile alâkadar olan şirketlerin ve kullanıcıların ortak mutabakatını temsil ediyor. JSTL'in hedef gurubu sayfa içerik yaratıcısı, arka plan Java kodlayıcısi değil. İçerik yaratıcısı derken, belki de program yazmayı bilmeyen, ya da sayfa yaratırken program yazması gerekmemesi gereken kişilerden bahsediyorum. Ayrıca içerik yaratıcısı derken bir projede oynanan bir rolden bahsediyorum, özel bir kişiden değil. Genel hatları ile belirtmek gerekirse, JSTL, JSP'yi yepyeni bir guruba tanıştırıyor. Kitabımda örneklerini tekrar tekrar gösterdiğim gibi, aslında 'tamamen' JSTL kullanarak bütün bir uygulamayı baştan sona yazabilirsiniz. Tabii büyük bir yazılım ile uğraşıyorsanız bu kod bakımı açısından iyi bir mimari seçim olmayabilir, herhalde bu şekilde yazılım mimarları JSP içinde fazla işlem mantığı istemezler. Fakat teknolojinin bunu mümkün kılacak silahları 'sağladığını' belirtmek için bunu söyledim. Mesela kitabımda örnek olarak verdiğim bir portal uygulaması var. Ayrıca bir ileti sistemi, takvim, gibi örnekler var. JSTL çok esnek bir teknoloji, ve programcı olmayanlar için de yararlı. Programcı olanlar için bile yararlı bazı soyut temsiller bulunuyor. Hala arada sırada, bana içinde çalıştığım üniversiteden sayfa yazmam için istekler geliyor, o yüzden JSTL içindeki bu özellikler benim çok işime yarıyor.

JSTL'in ilginç bazı özellikleri nelerdir?

Tipik bir JSP uygulaması için lazım olan sorunların cevabı JSTL'de bulunabilir. Mesela, şartsal mantık için etiketler var. Ya da bir liste üzerinde döngü ile elemanları ziyaret edebilen sözdizim mevcut. JSTL, Java Collection arayüzünün sağladığı her nesne ile konuşup, elemanlarını ziyaret edebilir. JSTL'i metin formatlama için, ya da milletlerarası kişiselleştirme için kullanabilirsiniz. Veri tabanına direk erişebilen etiketler bile var; tabii bu özellik bazı ortamlarda tepki yarattı (sayfanın veri tabanına erişmesi kötü olarak bilindiğinden) fakat ufak ve orta ölçekli mimarilerde, ya da, içerik için gereken bazı bilgilerin bazen veri tabanında olması sebebiyle bu özelliğin olması bana göre iyi oldu. Mesela kullanıcının sayfasını kişiselleştirmesi sonucunda, ne bileyim, renk tercihi mesela veri tabanında olabilir. Bu gibi bir bilgiyi almak için bazıları koskoca bir katmandan geçmeden bu bilgiyi almayı tercih edebilirler.

Ayrıca JSTL, XML işlememiz için bile bazı etiketler içeriyor. Bu açıdan XSLT'ye rakip bile sayılabilir. Tabii JSTL, XSLT ile birbirini destekler halde de çalışabiliyor, mesela JSTL sayfası içinden XSLT değişimlerini tetiklemek gibi. Fakat buna ek olarak, XML içinden aranan metni çekip çıkartabilecek ve içerik üzerinde kullanabilecek JSTL etiketleri var. Böyle olunca, JSTL ile bir şablon oluşturuyorsunuz, sonra işte şuraya XML'den gelen bilgi döngü ile açılarak yazılabilir diyebiliyorsunuz, vs. JSTL üzerinde bütün bunları yapmamızı sağlayan bir deyim dili var. Kıyasla, JSP'yi programcı olmayanların kullanması çok zordu. Birazcık Java bilmeyenlerin JSP kullanması imkansıza yakındı. Mesela, oturum sınırı nedir, ya da istek nesnesi üzerinden bilgiyi nasıl alabilirim gibi.. JSTL deyim dili ile, Java bilmeden, sayfaya gelen bilgiye erişmeniz mümkün olabiliyor. İstek nesnesine erişmek için basit bir sözdizim yaterli oluyor. Deyim dili bütün etiketleri birarada tutan tutkaldır: Mesela bir etiket ile bir numarayı tarayıp, sonucu sınırsal değişken üzerine koyabilirsiniz, sonra başka bir yerde bu değere erişip başka bir işlem yapabilirsiniz.

XSLT'nin problemleri sizce nedir?

Şimdi belirteceğim görüş herkes tarafından ne kadar benimseniyor bilmiyorum ama, hafiften benim 'ufak' bir isyan çığlığım haline dönüştü. Çoğu kullanıcı için XSLT'nin kabul edilmez durumda. Zaten genelde işlevsel dilleri sevdiğimi söyleyemem, (XSLT bir işlevsel dildir). Akademik ortamda olmam yüzünden bu garip gelebilir, çünkü LISP ya da Scheme yerine gördüğünüz gibi Java'yı tercih ediyorum. Ama Java'nın başarısını bakacak olursak öteki insanlarda bu tercihi paylaşıyor demektir. Eğer bilgisayar dillerinin mimarisini biliyorsanız, şöyle bir tanım yapılabilir. Java ve JSP mecburi işlemsel bir dildir. "Şu, şurada, şu şekilde olacak" gibi tanımlar yapar. Işlevsel diller der ki "şu ve şu gibi kalıplar için, şöyle davran". Fakat problem şurada: İçerik üreten kullanıcılara bu kavramlar çok yabancı geliyor. Ayrıca, döngüler, koşulsal ibareler kullanamamak veriyi göstermemizi zorlaştırıyor.

Deyim dilinden biraz bahsedebilir misiniz?

Deyim dili, Java kullanmadan veriye ulaşmanın bir yoludur. İçerik üreticisi, Java'dan daha basit olan bu dili kullanarak sayfa yaratabiliyor. Javascript'ten ve alternatiflerinden bile daha basit. Her ortamın değişik bir deyim dili gerektirebileceğinden hareketle, bize bu deyim dilini nasıl seçtiğimizi soruyorlar. Bu soruya cevap, JSP'nin zaten kullanıldığı ortama en çok lazım olan deyim dilini bulduğumuz olacaktır. Yani, şu anda veriyi içerik olarak göstermesi gereken, ama Java programlamayı bilmesi gerekmeyen kimseler... Her lazım olan şey için yeni etiket deyim diline eklemedik, yeterli derecede bir alt sözdizim ile yetindik. Daha fazlası için zaten Servlet/JavaBean üzerinde birçok şey yapmak mümkün. Ya da özel etiket yazılabilir. Burada anahtar, mesela başkalarının yazdığı sayfaya bakım yapmak için çağırılabileceğiniz, böyle bir durumda herhangi bir dilin %20'sini bilmeniz yetmezdi. JSTL'in tamamı, bazı dillerin %20'sinden azdır. Mesela, oturum üzerinde olan kullanıcı nesnesinin adres değerine şöyle erişebilirsiniz: session.kullanici.adres ve etrafına $ işareti koyarsınız olur biter. Java ile session.getAttribute diyecektik, vs, tabii yanlış yapma ihtimali var, ve bir Java hatası olsa, içerikçinin hatayı düzeltecek Java'sı yok.

Ama sonuçta bir dili, başkası ile değiştirmiyor musunuz? Fark nerede?

Evet, sonuçta bütün diller ortak kavramları paylaşır. Fakat deyim dillerinin avantajı, işlem çağırma, Java tipleri, istisna hallerini bilmemize gerek bırakmaması. Örnek olarak, bütün istek (request) bildirgeçleri JSTL sayfasına String (metin) olarak gelir, eğer bu bilginin üst sınırlarını falan gösterecek olsak, bir sayı gerekir, vs, bütün bu dönüşümleri JSTL otomatik olarak yapar.

Bir şirket yazılımı içinde JSTL, genel mimari içinde nasıl yeralır?

JSTL, Java Collection arayüzlerini kullanmak için yazıldığı için, arka planda ne olduğu farketmez. Arkada Servlet, Bean'ler, ya da EJB olabilir, JSTL için bunlar önemli değildir. Model 2 MVC'ye bile JSTL rahatça uyabilir; Struts yakında JSTL'i içine dahil edecek. Herhangi ölçekte bir uygulama için JSTL kullanılabilir. Fakat belirteyim: JSTL'in özellikle küçük ve orta ölçek için kabul edilir olması için de özen gösterdik, bence Web uygulamalarında kronik gördüğüm bir sorun, üzerlerinde 'aşırı mühendislik' yapılmış olması.. Yani basit şeyler için muazzam çetrefilli tasarımların getirilmiş olması..



J2EE projelerinin en çok yaptığı hata nedir?

Benim özel görüşüm aşırı mühendislik büyük bir sorun. Çoğu internet ve şirket yazılımları, insanların anlaması için çok zor bir halde, ve bu büyük bir problem. Aşırı mühendisliğin en bariz kaynağı, vaktinden önce yapılmış eniyileştirme, yani, daha bir problem ortaya bile çıkmamışken o probleme göre tasarımlar yapmış olmak. Nesne havuzları (object pool) harika bir örnek. Her nasılsa, herhalde çok kötü olan örneklere bakarak, insanlar çok fazla nesne yaratıldığını görmüşler ve güya çöp toplama (garbage collecting) dayanılmaz bir problem. Ve bu sözde soruna çözüm olarak öteki metodlara bakmışlar, mesela veri tabanı bağlantısının havuzlanması gibi. Fakat bu öteki alanlardaki özkaynak gerçekten değerli, yani, veri tabanının az bir sayıda olan tavan bâglantı sayısı var canım! Bu nesne havuzcuları, gittiler nesneleri havuzladılar, bilmiyorlardı ki Sun'ın anında derleme teknolojisi yeni nesne yaratmakta çok hızlı. Sonuçta ne oldu, elimizde 'olmayan bir sorun' için eniyileştirilmiş bir kod var. Belki normalden 'azıcık' daha iyi performans gösteriyor, ama işte o kadar. O arada, kaynak kodun anlaşılması muazzam zorlaşmış, ve tabii ki bakımı bir o kadar zorlaşmış.

JSTL bir proje içinde işbölümü için nasıl faydalar getiriyor?

Genelde etiket kütüpleri, ve özellikle JSTL'in getirdiği fayda soyut kavramlarla oynayabilmektir. JSTL'in programcıklara olan üstünlüğü budur. Tabii bizim sektörün en önemli özelliği, soyutluk seviyesini kaldırarak işimizi azaltmak! (İdareciler de işi başkasının üzerine yıkarlar :) ). Sonuçta JSTL detayları, bu detayları görmesi gerekmeyen içerikçilerden saklayarak işlerini kolaylaştırır. Soyutlamanın ana fikri budur. Böylece proje içinde bazıları iş mantığı yazabilir, başka birisi bu mantığı nesne modeli üzerine koyabilir, ve bu model üzerinden gerekli bilgiyi Iterator nesnesi ile JSTL sayfasına afişe edebilir.

Servlet Teknikleri

Servlet nesnelerini JSP sayfalarının Javalaşmış hali olarak düşünebiliriz. Bir JSP sayfasının <% %> işaretleri arasında Java kodu yazmak yerine, aynı Java kodunu gerçek bir Java nesnesi olan Servlet üzerinde yaratıp, aynen orada çalıştırmak mümkündür. Zaten JSP sayfaları da derlenip, arka planda Servlet'e dönüşüyorlar!

Peki o zaman, ne için JSP kullanıyoruz? Nerede Servlet nerede JSP kullanalım?

Bu soruya cevap şöyle olacaktır: "Görsel kodları JSP içine, işlemsel kodları Servlet içine koymak gerekir".

İşlemsel kodlara örnek, veri tabanına erişen işlevler, hesap yapan, karar veren tanımlar, ya da, kullanıcının girdiği veriyi işleyip kontrolden geçiren türden işlemler olabilir. Servlet, bütün bu arka plan işleri yaptıktan sonra gerekli 'veri nesnelerini' yaratıp, kontrolü JSP'ye bırakabilir. JSP bundan sonra veri nesnelerine bakarak ekranda sayfayı göstermeye başlayacaktır.

Servlet, kullanıcı hareketlerinin (bağlantı tıklama, dügmeye basma) gittiği adres olmalıdır. Yani, bir url bağlantısı sayfaya koymuş isek, hedef olarak bu bağlantı, Servlet nesnesini gösterebilir. Bunu yapmak için şöyle bir ibare yeterlidir.

<a suraya="/IslemciServlet?bildirgec1=deger1&bildirgec2=deger2">Buraya Tiklayin</a>


Ya da, kullanıcının girdiği bilgileri işlemek için, HTML/JSP başında şöyle bir tanım yapabiliriz:

<form type=POST action="/IslemciServlet">
<input type...
....
<input type="submit"...
</form>


Yukarıdaki tıklamayı işlemek için, şöyle bir Servlet kodlanabilir.

public final class IslemciServlet extends HttpServlet {

// buraya, sinif icinde gerekli olan degiskenleri
// tanimlayabilirsiniz.

// tiklama islemi, bizi direk bu doGet islemine getirir
public void doGet(HttpServletRequest request,
HttpServletResponse response)

throws IOException, ServletException {

String bildirgec1 = request.getParameter("bildirgec1")
String bildirgec2 = request.getParameter("bildirgec2")

//
// bu degerler ile islem yap..
//

response.sendRedirect("sonuc_goster.jsp");

} catch (Exception e) {
throw new ServletException(e);
}



Sonuc_goster.jsp nesnesinin ekranda birseyler gösterebilmesi için, oturum nesnesi üzerine bazı cevap nesneleri koymak mümkün. Dikkat edin, Servlet, doGet işleminden return ile geri değer vermiyor. Servlet ile JSP'ler arasındaki iletişim bu yüzden, request.getSession() ile erişilen "oturum" (session) nesnesi üzerinden yapılıyor. Bu nesneye değer koymak için, şöyle bir ibare yeterli olur.

..
request.getSession().setAttribute("geriBildirgec1", new String("filan"));
..

Servlet Derlemek ve Yerleştirmek

Bağlantıların Servlet'lere erişebileceğini gösterdik. Peki Tomcat, ya da başka J2EE uyumlu Uygulama Servisi bu tanımı nasıl biliyorlar? Hangi Servlet'e nasıl erişileceğini bilgisayarda nasıl söylüyoruz?

Bunu yapmak için, site_ismi/WEB-INF/web.xml adlı dosyaya Servlet hakkında bilgi vermemiz gerekiyor. web.xml dosyası, Tomcat başlarken her seferinde "bakılan" bir dosyadır, Internet uygulamanız hakkında tanımlar burada yapılır.

<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
<servlet>
<servlet-name>IslemciServlet</servlet-name>
<servlet-class>IslemciServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>IslemciServlet</servlet-name>
<url-pattern>/IslemciServlet</url-pattern>
</servlet-mapping>

</web-app>




Uygulamanız için bir WAR dosyası paketlerken, yukarıdaki web.xml dosyasının WEB-INF/ dizini altında olması beklenir. J2EE standartına göre bu böyledir.

WAR dosyasının şöyle bir yararı var; İnternet uygulamanız için bütün gereken kodları bir paket içinde tutar. WAR dosyası yaratmak için JAR komutunu kullanabilirsiniz, sadece sonuç dosyasının sonu .jar ile değil, .war ile bitecek. Bütün fark burada.

Tabii WAR'ın 'formatı' bir yana, esas dikkat edilmesi gereken tarafı WAR'ın paketlediği 'dizin düzeninin' standarta göre olması gerektiğidir. Bu düzen şöyle olmalı:

site_ismi/WEB-INF/web.xml - Ayartanım dosyası
site_ismi/WEB-INF/classes - Derlenmiş Java nesneleri
site_ismi/WEB-INF/lib - Paketlenmiş serbest yazılım, ya da ticari dış
Java paketleri

Böyle bir düzeni paketleyip Tomcat'a verdiğinizde (webapps altına bırakarak mesela), hiç CLASSPATH ile uğraşmanız gerekmeyeceğini belirtelim. Bu yöntemin rahatlığı budur: J2EE standartına göre yazılmış bütün Uygulama Servisleri, classes/ ve lib/ altında gördükleri Java nesnelerini CLASSPATH'e otomatik olarak dahil ederler.

Servlet'e Dönelim

Web.xml, Tomcat'a Servlet'in nerede olduğunu gösterdi. Bunun haricinde, Tomcat'in içinde (server.xml üzerinde), her Servlet'i gösterecek şekilde yapılmış bir ayar da vardır. Bu ayar sayesinde sonu "Servlet" ile biten bütün Java dosyalarına, http://localhost:portno/siteismi/servlet/xxxServlet gibi bir ibare ile erişilebilirsiniz.

Yani, programcı dilerse, yukarıda servlet-mapping olarak gösterilen ibareyi hiç kullanmayabilir, Servlet'in öteki kullanım şekli ile halâ erişilmesi mümkündür. Seçim programcıya kalmış. Sistem idaresi bakımından Servlet'lerin direk adresini özellikle belirtmek size daha uygun gelebilir.

Evet, şimdi Tomcat'i başlatın, ve tarayıcınızdan önce HTML sayfasına, oradanda tıklayarak Servlet'i işlettirip, JSP sayfasına gidebilirsiniz.

Unutmayın, Servlet içinden HTML üretmeyin, çünkü kod bakımı açısından zorluklar yaşayabilirsiniz. Başkasının yazdığı bir program üzerinde Metin (String) nesnesi kullanılıp Java içinde HTML üretildiğini görünce kaçmak isteyen çok programcı gördüm! Aynı şekilde, JSP içinde görsel olmayan işlem yapmak uygun değildir. Sonuç itibari ile JSP içinde daha limitli bir ortama "hapis durumdayız", bir Java sınıfında olduğumuz kadar serbest olamayız. Bu yüzden dişli bütün kodların JSP içinden çıkartılması isabetli olur.

Özel örnek vermek gerekirse, birim testlerinin erişimi bakımından Servlet üzerinde işlem mantığı işinizi kolaylaştıracaktır. Ayrıca, kodunuz Servlet üzerinde ise, sözdizim hatalarını derleme sırasında bulabilirsiniz, JSP örneğinde sayfayı ayreten ziyaret ederek derleme işlemini 'tetiklemek' gerekecekti. Servlet ile bu dertlerden kurtuluyoruz.

Yardımcı Programlar


* Java J2SE Geliştirme Seti (JDK) - Temel Java kütüphaneleri ve derleyici programı
* Java J2EE Geliştirme Seti (JDK) - Servlet kodlarını derlemek için gereken kütüphaneler
* Tomcat Uygulama Servis programı

Unix Rsync - Makineler Arası Dosya Kopyalamanın Hızlı Yolu

Sitemiz için kullandığımız tekniklerden bir tanesi, geliştirme ortamında yaratılan içerik .xml, .class, .jpg, .gif kayıtlarından "sadece değişmiş olanların" sonuç ortamına kopyalanmasıdır. Kabul edersiniz ki, üst üste yapılan ve çok sayıda dosya içeren bu şekilde kopyalamalar için, sadece ve sadece yeni ve değişmiş dosyaların kopyalanması zaman bakımından en verimli seçenektir.

Sitemizin ilk başlangıç yıllarında kullandığımız Unix scp programı, her kayıtı sürekli sonuç ortamına kopyalıyordu. Örnek bir scp komutu aşağıda gösteriliyor.

 scp *.jsp kullanici@bizim.isp.makinasi.com:/usr/local/site/dizin/

Rsync

SSH ve CVS ilgili makalede, ssh (ve dolaylı olarak scp) komutu ile, güvenli bir şekilde nasıl uzak herhangi bir makinada Unix komutu işletebildiğimizi görmüştük. SSH'in öngördüğü anahtar dosyalar doğru yerlere koyulduktan sonra,

ssh uzakmakina.com -l kullanici ls /usr/local/herhangibirdizin

..gibi bir komut, uzakmakina.com üzerindeki bir dizinin içeriğini dökebiliyordu! Hemde bunu yaparken, bildiğimiz Unix komutlarını uzaktaki bir makine üzerinde kullanabiliyorduk. Bu çok güçlü bir yöntemdir. Rsync programı da, arka planda kopyalamayı gerçekleştirmek için SSH'i kullanabiliyor. Güvenlik bakımından bu yöntemi seçmeniz tavsiye olunur.

SSH bağlantısı, rsync programına -e ssh ibaresini ile yapılıyor.

Aşağıda örnek bir rsync komutu görüyoruz.

rsync -av -e ssh /usr/local/dizin kullanici123@uzakmakina.com:/usr/local/filan/dizin

Bu komut, /usr/local/dizin dizini ile uzakmakina.com makinasındaki /usr/local/filan/dizin dizinini kullanıcı123 adlı kullanıcı üzerinden eşitliyor.

Not: Bu rsync komutunu ilk işlettiğinizde, bütün dosyaların bir kere kopyalandığını göreceksiniz (eğer sonuç dizini tamamen boş ise). Fakat ikinci sefer aynı rsync komutunu işletince, hiçbir kopyalanmanın olmadığını görmeniz mümkün olacak. Çünkü ikinci sefer rsync, akıllı bir şekilde hangi dosyaların değiştiğini ve eklendiğini anlamaya çalıştı, ve sadece farkları göndermeye çalıştı.

Kaynaklar

üzerinde kurmak için, rsync tar dosyasını cygwin dizininize (mesela c:/cygwin) bırakıp, tar xvf komutu ile açın.

Lokal Kopyalar İçin

Rsync'i iki diskiniz arasında yedekleme yapmak için de kullanabilirsiniz. Bu gibi durumlarda -e seçeneğine ihtiyacınız yoktur. Sadece -av ile rsync kullanmanız yeterli, mesela:

rsync -av  /cygdrive/c/Arsiv /cygdrive/f/Arsiv

Bu komut c: disk üzerindeki Arsiv dizinini f: adlı diske taşıyacaktır. Tabii, tekrar söyleyelim, rsync'in cp komutuna göre yararları şunlar; Aynen makinalararası durumda olduğu gibi, ilk kopyalama tamamlandıktan sonra "ikinci rsync" işlemi sadece farkları (birinci kopyalamadan sonra yeni olan dosyaları) gönderecektir. Bir diğer seçenek --delete ile de "hedef dizininde olup, kaynak dizininde olmayan dosyaları" bile otomatik olarak hedeften sildirebilirsiniz! Rsync mükemmel bir eşitleme aracıdır (synchronization tool).

Gördüğümüz gibi bu tür güçlü bir araç için tıklama ile "güzel gözüken" arayüzlü bir programı aramamıza hiç gerek yok. Unutmayın: Tıklamalar, tekrar işletilemez, bu yüzden admin'lerin korkulu rüyasıdırlar.

Eger cetrefil bir ssh kullaniyorsaniz, mesela ssh'e -P ile port vermeye mecbur kalmissaniz, vs

rsync --recursive -ve 'ssh -p [port]' /yerel/dizin kullanici@1.1.2.13:/uzak/dizin


Karesel Denklem Çözümünü Türetmek

Baglanti

Thursday, October 30, 2003

Oracle Kavramları

Oracle kurmak ve bakımını yapması gereken Veri Tabanı Sorumluları için, işe yarayabilecek bazı kavramlardan bahsetmemiz gerekiyor. Programcılar için de yararlı olacağını zannediyorum. Yazdığınız programın sonuç ortamında nasıl çalışacağı detaylı Oracle bilgisini gerektirebilir.

İyi bilmemiz gereken 3 kavram var. Şematik (schema), Çizelge alanı (tablespace), SID ve bu kavramların birbiri olan ilişkisi.

SID

'Veri tabanı' kelimesini kullandığımızda genelde birçok şeyden aynı anda bahsediyoruz. Oracle paket programının tamamına, içinde bilgi depolayan kayıtları, kullanıcı isimlerinin toplamina aynı anda veri tabani deniyor. Fakat, Oracle dunyasinda, bu kavramlari daha da berraklaştırmamız gerekecek. SID = Veri tabanı diyeceğiz, ve, veri tabanı Oracle paket programı değildir gibi bir tanım yapacağız.

Peki o zaman, veri tabanı nedir?

Oracle'a göre veri tabanı, hakkında konuşabileceğimiz en büyük kayıt birimidir. İçinde çizelgeler, onların yazıldığı dosyalar, bu çizelgelere erişecek kullanıcı isimleri, ve paraloların toplamına veri tabanı diyoruz. Bir proje icinde şu kelimeleri duyabilirsiniz.


* Hangi veri tabanına bağlandın, çizelge bilmemneyi bu tabanda bulamıyorum...
* Benim kullanıcı ismimi bu veri tabanında da yaratır mısın? Kullanıcı şifrem kabul edilmiyor
* Fazla veri tabanı yaratmaya gerek yok, bir tane üzerinde çalışsak olmaz mı?
* Hayır olmaz, çünkü veri tabanı idarecileri iki veri tabanı olursa idaresi kolaylaşır diyorlar.

Bunları tanımladıktan sonra, SID'e dönelim. SID, veri tabanına erişmemizi saylayacak bir isimden ibarettir. Örnek olarak SATIS, BORDRO, MUSTERI gibi veri tabanı isimleri olabilir.

Çizelge Alanı

Çizelge alanı, çizelgelerin üzerinde depolanacağı 'dosya' ismidir. Buna çok dikkat edelim. Dosya derken /usr/dizin1/dizin2/cizelge_alan_1.dbf gibi bir gerçek Unix dosyasından bahsediyorum. Yani, Oracle veri tabanının, gerçek dünya ile (işletim sistemi) buluştuğu yere çizelge alanı diyoruz.

Çizelge ile çizelge alanlarının bağlantısı, alan yaratılırken sâdece bir kere yapılır. Ondan sonra ne zaman bu çizelgeye erişseniz, önceden tanımlanmış olan dosyadan oku/yaz otomatik olarak yapıyorsunuz demektir.

Çizelge alanı yaratmak için, şöyle bir komut işletebilirsiniz.

CREATE TABLESPACE cizelge_alan_1 DATAFILE '/usr/local/dizin1/oracle/cizelge_alan_1.dbf' SIZE 200M;

Şematik

Şematik = kullanıcı diyelim, fakat Oracle dünyasında şematik biraz daha güçlü bir kavramdır. Eğer daha basit veri tabanlarına alışık iseniz, herhalde her kullanıcının, her çizelgeyi görmesine alışıksınız. Oracle için çizelgelerin erişilip erişilmeyeceği hem şematik bazında yapılmıştır, hem de, sahiplenme mekanizması yani, hangi çizelgenin kime 'ait' olduğu da şematik bazında yapılır. Bir veri tabanına (SID=ORNEK1) bağlandığınız zaman, tabanda bazı çizelgeleri göremeyebilirsiniz. Görmek için, belli bir şematik kullanarak bağlanmanız gerekecektir. Hattâ ve hattâ, aynı isimdeki iki çizelgeyi değişik şematiklerde yaratabilirsiniz; Oracle bundan yakınmaz. Yani, SID'den sonra Oracle'ı paylaştırmanın/bölmenin ikinci bir yolu şematik'tir.

Oracle idarecileri (yukarıdaki proje konuşmalarına o kadar aldırmayın) az miktarda SID ve paylaştırmak için çok miktarda şematik yaratmayı tercih ederler.

Şematik yaratmak için kullanıcı yaratmamız yeterlidir.

CREATE USER hasan IDENTIFIED BY hasanslx DEFAULT TABLESPACE alan1;

Ek Bilgiler

Kullanıcı MEHMET olarak SID'e bağlandıysanız, ve CREATE TABLE komutunu işletip bir çizelge yarattıysanız, bu çizelge MEHMET şematiğine ait olacaktır.

Bu çizelgeyi başkaları göremez. Görmesi için özel izin 'vermeniz' gerekir.

Eğer MEHMET kullanıcısı olarak bir çizelge yarattıysanız ve detay belirtmediyseniz, bu çizelge DEFAULT TABLESPACE diye yukarıda belirttiğimiz yokluk değeri (default) alan1 altında yaratılır.

Oracle ve Autoincrement Kolonlar

Bazı veri şemalarında ID kolonu atanan bir değer değil, üretilmesi gereken bir sayıdır. Bu sayı, en basit hâliyle 1'den başlayarak her yeni veri satırı için birer farkla artması gereken bir sayıdır.

O zaman her satırı yazarken bu ID'nin üretilmesi gerekmektedir. Bu üretimi, ya uygulama içinde yapacağız, ya da veri tabanın otomatik olarak yapmasını sağlayacağız.

Otomatik attırım bazı veri tabanlarında bir kolon tipi olarak bile karşınıza çıkabilir. Oracle'da bu işi yapmak için bir sequence ve bir trigger kullanmamız gerekiyor. Oracle, bu tekil sayının üretimini ve tabloya atanması işini birbirinden ayırmıştır. Bu da sanıyorum isabet olmuştur, auto-increment kolon tipi hakikaten çok basitleyici bir çözümdür.

Oracle'da otomatik ID üretimi için iki şey gerekir; Bir sequence, bir de trigger. Meselâ, şöyle bir tablomuz olduğunu düşünelim.

   create table test (
id number,
veri varchar2(20),
...
);

Bu tablo için bir sequence ve bir trigger yaratalım.

   create sequence test_seq
start with 1
increment by 1
nomaxvalue
;

create trigger test_trigger
before insert on test
for each row
begin
select test_seq.nextval into :new.id from dual;
end;

Artık,

INSERT into test (veri) values ('blablabla');

.. gibi bir INSERT kullandığımızda, hiç ID'ye dokunmamıza gerek kalmadan, bir sonraki ID sayısı hesaplanacak ve kolona koyulacaktır.

Matlab Yerine Octave

Not: 2010 itibariyle tavsiyemiz matematiksel bilimsel hesaplar, grafikleme isleri icin Python dili uzerinden ve Numpy, Scipy paketlerinin kullanilmasidir.

Matlab programı, matematik formüllerini otomatik olarak çözmek için şahane bir program. Artık çoğu üniversitede matematik dersleri için öğrencilere Matlab veriliyor. İstatistik, olasılık, sembolik formül çözümü, grafikleme, doğrusal cebir gibi işlemleriniz için Matlab'i kullanabilirsiniz.

Matlab'in en güçlü tarafı doğrusal cebir hesaplamalarıdır. Bunda tabii ki Matlab'in tarihi önem kazanıyor, programın ilk kullanıldığı alan doğrusal cebir problemleri idi.
>> A = [2 3 4; 5 6 7]

A =

2 3 4
5 6 7

>> A'

ans =

2 5
3 6
4 7

>> A'*A

ans =

29 36 43
36 45 54
43 54 65

>> A'*A
Burada A adında bir matris yarattık, devriğin aldık, ve devriğini matrisin kendigi ile çarptık.
>> x = sym('x');
>> f = x^2 + 4
>> diff(f)

ans =

2*x

Yukarıda x adlı bir sembol tanımladık, f fonksiyonu girdik, ve türevini aldık. Fonsiyonu ezplot(f) komutu ile fonksiyonu grafik olarak gösterebiliriz.
>> ezplot(f)





Ya Matlab Yoksa?

Fakat Matlab para ödemeniz gereken bir program. Bulamayanlar için Octave Matlab yerine geçebilecek bir program. Serbest yazılım olduğu için herkese açık.

Octave'ın yaratıcıları, programı Matlab ile birebir uyumlu yapmak için yola çıkmışlar. Hakikaten de, çok yaklaşmışlar. Matlab script programları, .m dosyaları üzerinde durur. Bu dosyalardan çoğunu işlettiğimizde Octave ile aynen işlediğini gördük.

Grafik için, Octave gnuplot adlı programa dısardan çağrı yapıyor, fakat bu da hiç problem değil, çünkü gnuplot programı da bedava.

Octave'i Ubuntu uzerinde kurmak cok kolay: sudo apt-get install octave3.2 octave-optim octave-image. En son iki paket imaj isleyebilmek ve optimizasyon yapabilmek icin.

kaynak kodlarından derlenerek kurulabilir. Windows üzerinde Cygwin (Unix komut satırını Windows'a getiren) kullanilabilir. Windows için en basiti, zaten derlenmiş işler kodlardan kurmak. Bu halde bile cygwin programına ihtiyaç var, unutmayın. Octave'ı şuradan indirebilirsiniz.

Winzip programı kullanarak, tar.gz dosyayına tıklayın ve cygwin üzerine açın. Açmak derken ters-sıkıştırma yapmak anlamında söylüyorum.

Bu işlem bittikten sonra, gnuplot ile bağlantı kurabilmek için, pipe-gnuplot adlı işler kod lazım. Bu işler dosyayı c:\cygwin\usr\local\bin altına koyun.

Şimdi, c:\cygwin\usr\local\share\octave\site\m\startup\octaverc ayar dosyasına girip, aşağıdaki şekilde değiştirin.

...
gnuplot_binary = "pipe-gnuplot c:/gp373w32/wgnupl32"
..


Tabii bunun işlemesi için, gnuplot programının, c:/gp373w32 altında olması lazım.

Tipik Problem

Başıma gelen ilk hata, cygwin kurulurken, less adlı komutun kurulmamış olmadı idi. Cygwin kurucu programını tekrar başlatarak bu yardımcı kodu ekledim, ve Octave çalışmaya başladı.

$ octave-2.1.40.exe
GNU Octave, version 2.1.40 (i686-pc-cygwin).
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002 John W. Eaton.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html

Report bugs to .

gnuplot_binary = pipe-gnuplot c:/gp373w32/wgnupl32
gnuplot_has_multiplot = 1
page_output_immediately = 1
ans = :/usr/local/share/octave/2.1.40/m/statistics//:/usr/local/share/octave/2.1.40/m/control//


octave-2.1.40:1> a = [3 4 4; 5 6 6]
octave-2.1.40:2> a'

ans =

3 5
4 6
4 6

MySql ve Performans

Aşağıda MySql üzerinde çalışan Java uygulamaları için bazı performans tavsiyeleri.

JVM'den ölçüm değerleri almak için aşağıdaki seçeneği java komutunuza ekleyebilirsiniz.

-verbose:gc -XX:+PrintGCTimeStamps

JVM yığıt belleğin olağan değeri 64 MB'tır, ve bu değer çoğu web uygulaması için küçük kalmaktadır.

-Xms128m -Xmx256m

DB bağlantı havuzu (connection pool) için 15-20 bağlantı çoğu uygulama için yeterli olmaktadır, elinizdeki Thread'lerin sayısından daha fazla bağlantı açmamaya özen gösterin.

ConnectionJ 3.0, ConnectionJ 2.0.14'ten 40%-400% daha hızlı! En son sürücü kodlarını kullanmaya özen gösterin.

JDBC URL üzerinden tanımlanıp fayda sağlayacak parametreler şunlar.


* Yavaş işleyen sorguları kayıtlara geçirmek için logSlowQueries=true ve slowQueryThresholdMillis=n (2000 olağan değer)
* Performans ölçümlerini toplamak: gatherPerfMetrics=true ve reportMetricsIntervalMillis=n (30 saniyede bir olağan değer)
* Kullanım danışmanı (usage advisor), kullanılmayan nesneler, SELECT sorgularında kullanılmayan kolonlar, yarıda kesilmiş Resultset döngülerini raporlamak için: useUsageAdvisor=true

Bir Theserverside yazısından alınmıştır.

Geliştirme, Deneme, Sonuç

Projemizin kodlama safhasını dönemlere böldüğümüzü farzedersek, her dönemin sonucunda yapabileceğimiz iki şey vardır. Ya elimizdeki kodları sonuç ortamına göndeririz (sürüm) ve böylece kullanıcıların kullanımına açarız, ya da müşteri rolünü oynayan kimse o dönem için beklenen özellikleri test eder ama sürüm yapılmaz.

Aşağıdaki şekillerin neyi kapsadıklarına gelelim: Tümleştirme ortamı, kabul testlerinin çalıştığı, yani kullanıcıların uygulamayı test ettiği ortam değildir. Kullanıcı testleri, en iyi şartlarda sonuç ortam kopyası üzerinde, olmadıgı zamanlarda ise tümleştirme makinasında ayrı bir servis şeklinde kurulabilir. Tümleştirme otomatik olarak çalışan, derleme, birim testleri, "otomatik" kabul testlerini işleten bir kurulumdur. Teknik lider tarafından betikler ile kurulmuş ve zamanlı (scheduled) işleyen ortamdır.

(Aşağıdaki şekle bakarak) tümleştirme ortamı, otomatik ve periyodik olarak (mesela her 30 dakikada bir) en son kodları kaynak kontrol idare programından çeker, derler, ve otomatik testlere tâbi tutar.

Geliştirme sırasında kodlanan nesneleri, tümleştirme ve sonuç ortam kopyasına test edilmek üzere göndermemizin iyi olacağını belirtmek gerekir. Bazı takımlar sonuç ortam kopyasına gönderme yapmayı, gerçek sürüm yapılmadan hemen önce yapmayı seçebilir, fakat sonuç ortam kopyasına sürüm yapmak, her dönem sonunda (ya da daha sık olarak) iyi bir seçim olacaktır. Sebeplerine geleceğiz.


Eklemek gerekir ki, bazı projelerde sonuç ortam kopyası bile olmayabiliyor, özellikle Internet yazılımlarında, bu çok tehlikeli bir durumdur. Özellikle sonuç ortamı işletim sistemi geliştirmeden değişik ise, işletim sistemi farklarından ortaya çıkabilecek bazı hataların en son ana kadar ortaya çıkmaması mümkündür. Diğer sebeplerde vardır.

Sonuç Ortam Kopyası

Bir İnternet yazılımı, ya da herhangi bir bilgi işlem mimarisi muhakkak birden fazla katman içerir. En azından elde olan ikinci bir entite olarak veri tabanı vardır. Bu veri tabanının nerede olduğu, nasıl bağlanılacağı gibi bilgileri içeren ayartanım dosyaları kaynak kod ağacınızın bir parçası olabilir.

Ya da, uygulamanızın ihtiyacı olan bazı bilgiler XML dosyalarında tutuluyor olabilir. Bu XML dosyalarının durmakta olduğu dizin, uygulamanıza nasıl bildirilecektir? Dizin yeri, bir .java dosyası (yani kod) içinde tutuluyorsa, bu kötü bir programcılık adeti olarak bilinir; çünkü bu şekilde yazılmış olan kodu alıp başka bir ortama koyduğumuz zaman kod çalışmayacaktır. Ortam değiştirirken değişmesi "gerekmeyen" kod yazmak, ulaşmamız gereken amaçlardan biridir.

Kodumuz nasıl yazılmış olursa olsun, yukarıda bahsedilen türden hataları sonuç ortamına gelmeden önce yakalamak, projemiz için yararlı olacaktır. İşte sonuç ortam kopyası (staging) yararı budur.

Bu hataların çıkmasının sebebi, geliştirme ortamının kuruluş itibarı ile sonuç ortamından her zaman değişik olmasıdır. Bu değişim, sonuç ortamında belki de birden fazla makina olması, veri tabanının muhtemelen birden fazla makina üzerinde yer alabilmesi, veri tabanı kullanıcı isim/şifresinin sonuç ortamında değişik olması, bazi işletim sistemi dizinlerinin erişim izinlerinin değişik olması gibi olasılıklardır.

Tabii geliştirme ortamının bile, sonuç ortamına olabildiği kadar benzetirseniz, kod aktaran betikleriniz daha basit olacaktır. Ama arada muhakkak bir fark olacaktır, işte bu farklardan gelecek olan potansiyel hataları önceden yakalamak için, sonuç ortamına benzeyen bir ortam üzerine bol bol kod göndermesi yaparak testten geçirmek yararlı olur.

Sonuç kopyasını, isminin belirttiği gibi sonuç ortamına çok benzeyecek şekilde kurmalıyız. Sonuç ortamını mesela Oracle veri tabanı sürüm 9.1.0 (atıyorum) ile kurulmuş ise, kopyanın da aynı sürümü en son ufak numarasına kadar taşıması gerekir. Eğer sonuç Tomcat kurumu /usr/local/tomcat altında, ve kodlarımız /usr/projeler/proje123 olarak koyulmuş ise, kopyada aynı şekilde dizin yapısını kurmalıyız. Eğer sürüm ortamı veri tabanı (büyük bir ihtimalle) ayrı bir makina üzerinden erişiyor ise, kopyanında aynı şeyleri yapması isabetli olur.

Süreç

Proje dahilinde, bir dönemin nasıl geçebileceğini özetleyelim.


* (Her gün) Programcılar kod yazar, test ederler, ve KKİ'a eklerler
* (Her gün) Tümleştirme makinasında işleyen bir Rubi ya da Perl betiği, her yarım saatte bir en son kodu çıkartır, kendi ortamında derler, test eder, sonuçları bildirir.
* (Özellik bitince) Bir programcı takımı, özelliklerinin kodlaması bittiğinde (dönem sonunu beklemeden) müşteriye haber verir, test edilmesini istedikleri özelliğin olduğunu söylerler. Bu anda, müşteri ya kendisi, ya da bir programcı yardımı ile, sonuç ortam kopyasına en son kodu gönderilmesini sağlar. Özellik burada test edilir.
* (Son) Dönem sonuna gelince, bir gün öncesinden, sonuç kopyasına gönderme betikleri tekrar işletilir.
* (Son) Müşteri beklediği özelliklerin hepsini bu ortamda bir daha test eder
* (Son) Sürüm yapmaya karar verildi ise, kopyaya gönderen betiklerin benzeri (ya da aynısı) kullanılarak sonuç ortamına sürüm yapılır.

Betik Neye Benzer?

Sonuç kopyasına kod gönderen betiğin ne yapması lazım? Tabii ki .java, .xml, .jar dosyalarını rsynch veya scp ile makineler arasında kopyalaması gerekir. Bu bir.

Ayrıca, veri taban şematiğini sıfırdan kurmamıza yarayan, .sql dosyaları içindeki bulunan DDL dilindeki CREATE TABLE, ALTER TABLE, vs. içeren komutları da kopyada) işletmemiz gerekir. Bunu yapmamızın sebebi herhalde açıktır. Veri taban şematiği proje süresince değişen, gelişen bir şeydir, ve bildiğimiz gibi kod, bir bakıma şematiğe birebir bağımlıdır. O yüzden en son kodun, en son şematik üzerinde çalışması gerekmektedir. Bütün betiklerinizin, bu yüzden, DDL komutlarını boş bir veri tabanı üzerinde sıfırdan tekrar işletmesi isabetli olur. Bu sayede DDL içinde yapılması mümkün hataları da önceden yakalayacaksınız.

Eğer sonuç ortamı kullanılmaya başlandı ise, bu sistemin güncellenmesi özel bir sistem bakıcısı tarafından yapılacaktır, çünkü bu durumda DROP ve CREATE komutlarını veri tabanında kullanamayız. Sistem kullanılmakta olduğu için verileri kaybetmemiz mümkün değildir, sistem bakıcı bu gibi durumlarda yeni şematiğin öncesi ile farklarını otomatik olarak bulur (TOAD programı buna izin veriyor) ve bu farkları ALTER komutları olarak üreterek sonuç ortamı üzerinde işletir.

Yazılım Patentleri Hakkında - Donald Knuth

(Donald Knuth, bilgisayar bilimin önde gelen profosörlerinden biridir. Bilgisayar bilimin önemli bir dalı olan Hesapsal Yük Teorisinin kurucusudur. Algoritma hakkındaki kitapları, akedemide en temel referans olarak kabul edilir).

...

Patentler ve Tescilli Markalar Komisyon Başkanına, Box 4, Patent and Trademark Office, Washington, DC 20231

Sayın Komisyon Başkanı,

Diğer bilgisayar bilim uzmanları arkadaşlarımın bir süre önce yaptığı gibi, sizden ve ofisinizden bir ricada bulunmak istiyorum. Lütfen hesapsal işlem/fikir/yazılımlara patent verme kararınızı bir daha gözden geçirin. Bugünlerde tüm yazılım dünyasında, özellikle şu anda aktif olarak çalışan bilgisayar bilimciler arasında büyük bir endişe ve rahatsızlık hissetmekteyim, çünkü Patent Mahkemelerinin ve Patent/Tescil Ofisinin kararlarının hayatlarını zorlaştırdığını söylüyorlar.

1945-1980 arasında genel inanış (ve uygulama), patent kanunlarının yazılım ürünleri ile ilgisinin olmadığı yönünde idi. Fakat son zamanlarda görüyoruz ki bazı kimseler pratik faydası ve önemli olan bazı algoritmalar için patent almışlar -mesela Lempel-Ziv sıkıştırması, RSA açık anahtar şifrelemesi- ve bu kimseler şimdi kanuni yaptırım kullanarak diğer programcıların bu algoritmaları kullanmalarını engellemeye uğraşıyorlar.

Bu durum, şimdiye kadar yaşadığımız bilgisayar devrimini mümkün kılan politikalardan ciddi bir sapmadır, ve bu sapmanın toplum için çok zararlı olacağını düşünüyorum. Eğer bu durum daha önce kullanımda olsaydı, benim kendi çalışmalarıma zarar verecek bir gelişme olacağını belirtmek isterim. Mesela ben, tüm dünyadaki matematik ve fizik makale ve kitaplarının %90'ını yazmak için kullanılan TeX adlı bir yazılım geliştirdim. Eğer bugünkü yazılım patentleri 1980'de aktif olsaydı, böyle bir sistem kurmam mümkün olmazdı, kurmayı düşünmek aklımdan bile geçmezdi, ve başka birinin de bunu düşüneceğini zannetmiyorum.

Bana söylendiğine göre, şu anda mahkemeler matematiksel algoritmalar ile matematiksel olmayan algoritmalar arasında bir ayrım yapmaya uğraşıyorlarmış. Bir bilgisayar bilimci bu arayışın ne kadar boş olduğunu size söyleyebilir. Evrende Bir algoritmadan daha matematiksel bir şey zâten yoktur. Algoritma, doğanın fiziksel kanunlarından ayrı duran soyut bir kavramdır.

Dahası, sayısal ve sayısal olmayan algoritmalar arasında bir ayrım bulmak da mümkün değildir. Sanki sayısal değerler, diğer kesin bilgilerden değişik bir şeylermiş gibi. Bütün sayılar veridir, butün veriler sayıdır. Zaten matematikçilerde sayılardan çok harfler ile çalışmaktadırlar.

İşte bu yüzden, algoritmaları "bu matematikseldir, bu değildir" gibisinden bir ayrıma tâbi tutmaya uğraşmak, bence, 19. yüzyılda Indiana eyalet meclisinin "bir çemberin çevresinin çapına olan oranının yaklaşık 3.14116 değil, tamı tamına 3 olduğunu" söyleyen bir kanunu geçirmeye uğraşması kadar saçma geliyor. Bu da aynen ortaçağ kilisesinin "güneşin dünyanın etrafında döndüğünü" beyan etmesi gibi birşey.

Amerikan kongresi bir süre önce, çok akıllıca bir kararla, matematiksel şeylerin patentlenemeyeceğine karar verdi. Zaten başka türlü matematik yapmak mümkün olmazdı; Pitagoras teorimini her kullandığımızda birine telif hakkı mı ödeyecektik?! Bu bağlamda belirtmek gerekiyor ki, bugünlerde insanların büyük bir aceleyle patentlemeye çalıştığı temel algoritmik fikirler bu kadar temel ve herşeye lazım olacak türdendir. Eğer şu anki gidişata izin verilirse, sonuç, yazarlara kelimeler için patent almaya izin vermek gibi olacaktır. Yazarlar ve gazete muhabirleri, her kelimenin sahibine telif hakkı ödemedikçe yazı yazamaz hâle geleceklerdir. Algoritmalar yazılım için aynen kelimeler bir hikaye için neyse, o kadar temel bir gerekliliktir, çünkü algoritmalar her ilginç yazılım ürününü üretmek için gerekli olan en temel yapı taşıdırlar. Eğer her avukat başarı ile kullandığı bir savunma yöntemini, ya da anayasa mahkemesi, önceden verilmiş kararlarını patentlese halimiz nice olurdu?

Patent mahkemelerinin bir patent kanunu formalize ederken topluma hizmet etmek istediklerini biliyorum. Patent ofisinin, şimdiye kadarki soyut düşünceye değil, somut fiziksel kanunlara dayanan teknolojik yaklaşımları etrafındaki misyonunu başarı ile yerine getirdiğini söyleyebilirim. Benim kendi şahsımın da bazı donanım araçları hakkında patentlerim var. Fakat şu anki tüm yazılımları patentlemeye doğru giden trend, görüşümce ufak bir avukat ve mucit haricinde kimseye yararlı olmayacak, ve aynı zamanda bilgisayarlar yararlı işler yapmaya uğraşan insanların ezici çoğunluğu için zararlı olacaktır.

Bütün gün boyunca işimi yapabilmek için kullandığım programları şöyle bir aklımdan geçirince, hemen belli oluyor ki bu programlardan hiçbiri, eğer yazılım patentleri 60'larda ve 70'lerde aktif olsaydı bugün mevcut olmazlardı.

Eğer bugün kuralları değiştirirsek, yazılım dünyasındaki tüm gelişimi şu anki seviyesinde dondurmuş olacağız. Bugünkü trend devam ederse, Amerika'nın değerli yazılımcıları için tek çare olarak ya yazılımı bırakmak, ya da ülkelerinden göç etmek zorunda kalacaklardır. Her halükarda ABD yazılım dünyasındaki lider konumunu kaybedecektir.

Lütfen bu tehlikeli trendi tersine çevirmek için elinizden geleni yapın. Yazılımcıların entellektüel haklarını korumak için "ellerinden en temel yapı taşlarını almaktan" çok daha verimli yöntemler var.

Saygılar,

Donald E. Knuth, Emeritus Profosör, Stanford Üniversitesi

Bilgi İşlem Tasarım Kalıpları

Tasarım kalıpları adı verilen akım, Batı'da özellikle bilgi işlem yazılımcıları tarafından son yıllarda çok ilgi görmüştür. Bir tasarım kalıbı basit bir açıklama ile bir nevi reçetedir. Bu reçete, sürekli karşımıza çıkan bir sorun tipine karşı bulunmuş, gene sürekli verilmiş olan ve işe yarar bulunmuş bir çözümdür.


Bir yazılım kalıbını tasvir için, önce, hangi soruna ilaç olduğunu saptamak gerekir. Bu şartlar tanımlandıktan sonra, çözüm de bu bağlamda verilir, ve örneklerle süslenek kalıp dağarcığına katılır.

Bir yazılım kalıbı, hem çözüm getirmesi açısından, hem de bu çözüme bir isim vermesi açısından çok yararlıdır. Çünkü, artık bu verdiğimiz isim ile "hakkında konuşabildiğimiz" bu kalıbı daha rahat tartışabilmeye başlarız, ve iletişimimiz daha berraklaşır.

Site J2EE kodları da bu tür kalıplar ile doludur. Her ne kadar bu kalıpları yazı yazı paylaşmaya uğraşmış olsakta, bu kalıpların tamamını veren, ve ilgili özel yazılara bir referans içeren bir "ana katalog" çalışması daha yapılmamıştı. Okumakta olduğunuz bu yazı, bu eksiği kapatmaya uğraşacak. İdealimizde, bu yazının, önünüzde çözmek zorunda olduğunuz problem ile karşılaşır karşılaşmaz bakacağı bir başlangıç noktası olmasıdır.

Bu açıştan sonra kalıplara başlayalım.

Kalıp: İstek -> Sonuç


İhtiyaç

İnternet/J2EE bazlı yazılımımız içinde, kullanıcı bir bağlantıya tıkladıktan sonra, veri tabanından bilgi toplayıp ekranda göstermemiz gerek.

Çözüm


* Tıklanan bağlantı ya bir Servlet'i gösterir, ya da, FORM POST'un hedefi Servlet'tir. Her hâlükarda, Servlet'e kontrol geçtiğinde, bu servlet'e gönderilen bilgiler istek.getParameter("parametre") gibi bir kullanım ile okunurlar.
* Parametreler ile sorgu işletilir (JDO, JDBC, vs)
* Veri tabanından gelen sonuç, bir döngü içerisinde okunur, ve aynı anda bir ArrayList listesine bu sonuçlar eklenir.
* Okuma bitince eldeki ArrayList, oturum (session) üzerine eklenir.
* Kontrol, redirect (yönlendir) komutu ile sonucu listeleyecek JSP sayfasına gönderilir.
* Sonuç JSP sayfası, ArrayList'i oturumdan alır, ve JSTL etiketleri kullanarak döngü içerisinde gösterir.

İlgili Yazılar


* JSP'nin Geleceği - JSTL

Kalıp: Dosya/Metin Taraması


İhtiyaç

Bir dosya, ya da, bir String metni içinde özel bir kelime bulunması lazım. Bulununca bu kelime ya değiştirilecek, ya da bulunduğu rapor edilecek.

Çözüm

Jakarta ORO paketini kullanarak düzenli ifade kullanın, ve Perl'e benzer bir stilde aradığınız kelimeyi bulun. StringTokenizer ile vakit kaybetmeyin. Düzenli ifadeler aradığınız metin formunu çok esnek bir şekilde tanımlayabilmenizi sâglar.

İlgili Yazılar


* ORO

Kalıp: Tomcat Ölçeklemek


İhtiyaç

Sitemiz bir tek Tomcat servisi ile çalışıyor, ve kullanıcı sayımız artmaya başladı. Site ölçeklenmesi lazım.

Çözüm

Birden fazla Tomcat servisi kullanarak ziyaretçi yükünü dağıtın. Bunun için hem Apaçe, hem de Tomcat sevisinde bazı eklemeler yapmanız lazım.

İlgili Yazılar


* Tomcat ile Dağıtık (Distributed) Sistem İnşâsı

Kalıp: Bilgisayarlararası Dosya Gönderimi


İhtiyaç

Bilgisayar A'dan bilgisayar B'ye kayıt göndermemiz gerekiyor. scp (ya da rcp) komutu aynı kayıtları tekrar tekrar gönderiyor. Sadece farkları gönderebilen bir teknoloji yok mu?

Çözüm

Rsync kullanarak, ilk sefer her şeyi gönderdikten sonra ikinci ve ya üçüncü sefer sadece farkları göndermeniz mümkündür. Rsync, ssh üzerinden de çalışabildiği için güvenli bir çözümdür.

İlgili Yazılar


* Rsync

Kalıp: XML dosyasına değer eklemek


İhtiyaç

Elimizde XML dosyasındaki herhangi bir etiket altına yeni bir değer eklememiz gerekiyor. Bunun en basit yolu nedir?

Çözüm

Java dünyasında XML çözümleri tam bir çorbadır. Süzerek seçebildiğimiz kadarı ile, ekleme yapmak için en rahat cözüm Jaxen'dır.

İlgili Yazılar


* Jaxen = XPath + JDOM

Kalıp: Java İçinde Sabit Değerler (Constants)

İhtiyaç


Java programına lazım olan bazı sabitler (constants) var. Bu sabitleri nerede saklayalım?

Çözüm

Sabit değerleri, yani servis programınız başladıktan çökünceye kadar hep aynı olacak değerleri, muhafa etmek için Java properties dosyalarını kullanabilirsiniz. Properties dosyaları metin bazlı, metinyazar (editör) ile değiştirilebilen dosyalardır. Java ile bu dosyaları okumak için, ResourceBundle nesnesini kullanın. Bu nesne properties dosyasını bulmak için WEB-INF/classes altına bakacaktır. Properties dosyalarınızı bu dizin altına bırakın. J2EE dısındaki mimariler (mesela Swing), properties dosyasını CLASSPATH'e dahil olan herhangi başka bir dizin altına bırakabilirler.

İlgili Yazılar


* Properties Dosyaları - Java İçin Ayar Yapmak

Kalıp: XML İçinde Değer Bulmak

İhtiyaç


XML dosyasında değişiklik değil, sadece okumak amacı ile işlememiz lazım. Hangi arayüzü kullanalım?

Çözüm

XPATH arayüzü bu iş için biçilmiş kaftandır. Unix dizin sözdizimine benzer bir şekli (/enust/biralt/enalt/dosya gibi) kullanarak etiket değerlerine erişebilirsiniz.

İlgili Yazılar


* DOM ve XPATH kullarak XML işlemek
* Basit XPath Örneği
* XPath İle Çocuk Düğümleri Toplamak

Kalıp: Metin (Text) Bazlı Veriyi Oracle'e Yüklemek


İhtiyaç

Metin olarak virgül ayrıklı bir dosyadaki bilgileri, Oracle şemetiğinde bulunan bir tabloya yüklememiz lazım.

Çözüm

SQL*Loader teknolojisi tam bu işe göre.

İlgili Yazılar


* Oracle SQL*Loader

Kalıp: Java Nesneleri İle Veri Tabanına Erişmek


İhtiyaç

Veri tabanına SQL sorguları kullanarak erişmek istemiyoruz. Sadece Java nesneleri kullanarak veri tabanına erişmek mümkün değil mi?

Çözüm

JDO ile bu mümkün. Rakip olarak revaçta bulunan Hibernate'de, standart olmamasına rağmen, fena bir cözüm değil. Fakat standartları daha çok savunan bir site olarak, site kodlarinda JDO kullanıyor(duk). Ayrıca gelecek (bu teknolojiyi kullanan iş bulmanız) açısından, JDO'nun geleceği daha parlak.

İlgili Yazılar


* İnternet Yazılımları İçin Örnek Mimari
* Mevcut Şemetik Üzerinde JDO
* Bağlaşım: Nesneler, Veri Tabanları

Kalıp: Java İle E-posta Yollamak



İhtiyaç

Java kodumuzdan e-posta göndermemiz gerekiyor.

Çözüm

JavaMail bu sorununuzu çözecektir.

İlgili Yazılar


* Java İle Eposta (JavaMail)