Tuesday, October 31, 2000

Yeni Metod

Yakın zamanda "çevik metod" kategorisi altında yeni dizayn ve kodlama tekniklerine ilgi artmaya başladı. Bazıları tarafından bürokrasi-karşıtı, ya da dağınık kodlama olarak görülse de, bu yeni metod yazılım dünyasında büyük hareket yarattı. Bu yazıda hafif metodları uygulamanın sebeplerini sayacağım ve özellikle "değişebilir" özelliginden ve insanları ön plana almasına değineceğim. Ayrıca, eğer bu dar ve dikenli yoldan geçmek istiyorsanız, size hangi niyet ile yola çıkmanız daha iyidir, onu göstermeye uğraşacağım.

Yokluktan Cokluk, Sonra Hafiflik

Genelde yazılım, bir kargaşa durumudur. Kargaşa halinde yapılan bu yazılım şekline "önce kodla, sonra tamir edersin" derler. Böyle yazılımlar genelde plansız yapılır. Sistem dizaynı genelde kısa vadeli kararlar ile yapılmıştır. Bu şekilde yapılan geliştirme her ne kadar ufak sistem icin idare eder ise, sistem büyümeye başladıkça yeni özellikler eklemek çok zor hale gelir. Bu tür sistemlerin kokusunu uzaktan almak mümkündür: Ne zaman yazılıma özellik eklemesi bittikten sonra, test süreci, gereğinden fazla zaman alıyorsa bilin ki bu sistemin içinde yanlış çok, ve bilâhere dağınık bir şekilde kodlaması yapılmış.

Yazılım hayatımız boyunca uzun bir zaman, bu tip projeleri çok gördük ve hatta yaşadık. Alternatifimiz de yok değildi: Kontrollu Metodlar denen metodlar yazılım isine disiplin getirmeye uğraştılar bir süredir. Amaçları yazılım projelerini daha "tahmin edilir" ve "iyi işler" hale getirmek oldu. Bunu yapmak için yazılım projesine sıkı bir düzen takip ettirmeye uğraştılar, ve en büyük önemi de planlama safhasına takdim ettiler. Aslında gizli gizli öteki mühendislik alanlarına özendiler, mimarlık, inşaatçılık gibi.

Bu kontrollü metodlar bayağı uzun süredir aramızda. Başarılı oldukları söylenemez ve seveni de fazla yoktur. Bu metodlar hakkında en çok duydugumuz şikayet "bürokrasi fazlalığıdır", çünkü izlemek için o kadar çok ekstra faaliyet gerekiyor ki, proje birdenbire kağnı hızına düşüveriyor. O yüzden bu metodlara "ağır" metodlar adı takılmıştır, ve ya Jim Highsmith arkadaşımızın dedigi gibi, "Dev Metodlar".

Fakat yakın bir zaman önce, kontrollu metodlara karşı olarak yeni bir alternatif çıktı. önce "hafif" diye bilinen bu metodlar, şimdi "çevik" metodlar diye biliniyor. Çevik metodları sevenler büyük bir ölçüde ağır metodların bürokrasisinden bıkmış insanlar. Çevik metodlar, yokluk ile çokluk arasında çok güzel bir denge buluyorlar bizce, tam kararında ve en çok getiri verecek bir şekilde bir düzen takip ediyorlar.

Sonuç olarak çevik metodlar, ağır metodlara kıyasla büyük işletim değişiklikleri getiriyorlar karşımıza. Mesela çevik projeler ötekilere kıyasla kod belgelemeye, yani döküman yazma işlemine daha az önem verirler. Çevik metodlarin merkezi kaynak koddur, çeviklere göre bir kod parçasını belgeleyen en iyi yer, o kodun kendisidir. Bu örnek tabii ki esas farkları göstermek için yetmez. Belgeleme fikrinin altında yatan iki büyük fikir vardır.


* Projeler için uyum sağlayabilmek, geleceği görmekten daha faydalı olmalı: Ağır metodlar, yazılım işlemini ince detaylı ve uzun vadede planlamaya uğraşırlar. İşler yolunda gider bir süre, ta ki değişim kapı onune gelinceye kadar. Ağır metodlar bu yüzden değişimi sevmez ve hatta durdurmaya uğraşırlar, teknoloji bakımından olsun, müşterinin istediği özellikler listesi bakımından olsun. Çevik metodlar değişimi bekler, ve hatta hatta 'ister'. Uyum sağlayabilen metod olarak, kendilerini değiştirmek bile anlamına gelse, değişime ayak uydururlar.
* Çevik metodlar "insan" merkezlidir, "düzen" merkezli değil: Yani takip edilen düzen insanların doğasına uygun olarak, onların en rahat ve severek calışıcağı bir ortam yaratmak için uğraşır.

İlerideki bölümlerde yukarıdaki kelimelerin anlamını daha detaylı olarak işleyeceğiz, bu sayede uyum sağlayan, insan merkezli düzen nasıl oluyor anlayabileceksiniz. Böylece bu şekildeki işlem düzeninin yararlarını, eksiklerini göreceksiniz, "kullansak mı kullanmasak mı?" sorusuna cevabı burada bulacaksınız.

Tahmin Edilir mi Olsun, Yoksa Uyum Sağlayan mı

Dizayn ve kodlamayı ayırmak

Genelde bugünün yazılım metodlari, ilham için öteki mühendislik alanlarına dönmüşlerdir, inşaatçılık ya da makina mühendisliği gibi. Bu tür "öteki" mühendislik alanlarında, yapımdan önce planlamak çok önemlidir. Öteki alandaki mühendis arkadaşlarımız, çok detaylı çizimler ile neyin, nasıl, ne kadar, ne ölçüde yapılacağını belgelemek için calışırlar, ve bu parçalarin nasıl birbirine bağlanacağını önceden gösterirler. Önemli dizayn kararlari (mesela bir köpru kuruyorsanız, köprü ağırlığı nasıl taşınacak) bu çizimler sırasında verilir. Çizimler bittikten sonra planlar yapım için başka bir gruba veya şirkete verilir. Yapım sırasında dizayn planının sıkı şekilde takip edileceği bilinir, hatasız bina yapmanın başka yolu yoktur. Yapım grubu dizaynı takip ederken bazı zorluklar ile karşılasabilir, fakat bu durumlar genelde az meydana çıkar.

Bütün ölçümler ve detaylar ilk dökümanda olduğu için, 'yapım planı' denen plan ilk dizayn planını çok kullanır. Yapım planı işbölümü düzeni kurar, yani, yapılacak işler arasında bağlantıları önceden düzenler. Bu sayede yapım bütçesi ve süresi tahmin edilebilir. Yapım planı, işçilerin neyi, ne zaman yapacağını sıkı şekilde tarif ettiği için, inşaatı kurma zamanı geldiğinde planı takip edenlerin fazla kafa calıştırması gerekmez. Bu safhâda el becerisi zihin cimnastiğinden daha önemlidir.

Gördüğünüz gibi, inşaatçılıkta dizayn ve inşaat iki türlü, birbirinden değişik eylemler. Bir tarafta dizayn, tahmin edilmesi zor, yaratıcı ve daha pahalı insanlar gerektiriyor, öteki tarafta yapım, daha rahat tahmin edilebiliyor. Eğer elimizde bir plan varsa, yapımı planlayabiliyoruz. Elimizde bir yapım planı varsa, düzenli bir şekilde yapmaya, kurmaya başlayabiliyoruz. Ayrıca önemli bir nokta: İnşaatçılıkta yapıyı kurmak, planlamaktan her zaman daha pahalıdır ve daha uzun zaman ister.

Alın size bugüne kadar izlenen yazılım metodlarinin temeli. Bugünün yazılım projeleri de, yanlış olarak tahmin edilir bir is düzeni, ve kodlama zamanı için ucuz programcı kullanabilsinler diye, dizaynı, kodlamadan ayırmaya uğraşmışlardır. Ve işte o yüzden dizayn için bir metod bulmaları gerekmiştir ki, sonradan plana bakıp kodu yazmak mümkün olsun, aynen inşaatta olduğu gibi..

Yazılım sektörü için bu planlar ne şekilde çıkar karşımıza? Genelde bugünün yazılımcıları planlama için dizayn demek, UML gibi ok-ve-kutu çizdirebilen bir metod kullanmaktır; Akıllarınca, eğer bütün önemli dizayn kararları UML ile alınabilirse, bu planı alıp kodlama planına çevirilebilir, ve oradan yazılımcı bölüm bu planı alıp, programı yazar.

Şimdi biraz daha zor sorular soralım: Kendini koda çevirecek bir dizayn şekli mümkün mü, ve eğer mümkünse, hangi projenin "yapım" kısmı plandan daha pahalı ki, böyle bir metod takip etmek finansal bize açıdan faydalı olsun?

UML şemalarını programlara verilip kodlattırmak kolay bir iş midir? Ne yazık ki hayır. UML şemaları kağıt üzerinde çok güzel gözükse bile, kodlamaya gelince büyük boşluklar cikar karşımıza. İnşaat mühendislerinin kullandığı şema şekilleri yılların verdiği birikime dayanır, kullandıkları kodlar ona göre anlamlı ve doğruluğu matematiksel olarak ispatlanır türdendir. UML şemalarının doğruluğunu ispatlamak için tek yapabileceğimiz şey bir arkadaşa göz atmasını rica etmektir. En tecrübeli dizayncılar bazen yaptıkları dizayn kodlama sırasında başaşağı dönünce şaşkın kalıyorlar.

İkinci sorun fiyat meselesi. Bir köprü inşa ettiğiniz zaman, planlama safhâsı genel masrafın %10'u kadardır. Geri kalanı inşaata masrafıdır. Yazılım mesleğinde kodlama safhâsı için harcadığımız zaman bunun tam tersidir, yani dizayna göre çok daha azdır. McConnell'a göre büyük bir proje için, zamanımızın %15 kadarı kodlama ve test etmek ile geçer, yani yüzdeler köprü kurma senaryosu ile tamamen ters bir haldedir. Test etme süresini bile kodlama ile aynı yere koysanız, dizayn hala %50 kadar zaman alır. Bu gibi bilgiler ışığında, dizayn işinin yazılımdaki yerinin, öteki mühendislik alanlarındaki yerine göre değişikliği iyice ortaya çıkar.

Bu tip sorunlar, Jack Reeves arkadaşımızı şunu söylemeye itti: "Yeni Metodlarda dizayn dokumanı/şeması aslında kaynak kodunun ta kendisidir. Ve yazılım için inşaat evresi, aslında derleme ve bağlantı programları tarafından otomatik olarak zaten yapılmaktadır". Bu düşünceye göre otomatik yapılan her şey, yazılımın inşaat evresine tekabül eder.

Su ana kadar gördüklerimizi özetlemek gerekirse:


* Yazılımda kodlama evresi ucuzdur.
* Yazılım sektörunde büyük efor dizayn için harcanır, o yüzden akıllı ve yaratıcı insanlar gerektirir.
* Yaratıcı işler, planlaması zor olan şeylerdir, o yüzden tahmin edilebilir planlar bir hayal olabilir.
* Yazılım mühendisligi için, diger mühendislik alanlarından kavram kullanmak yanlıştır. Öteki mühendislik alanları değişik sorunlarla uğraşilar, o yüzden değişik bir metoda ihtiyaçları vardır.

Yazılım Kapsamı Değişimi

Projelerde bazen garip şeyler duyuyorum. Programcılar bana gelip diyorlar ki "bu projenin problemi sürekli değişen özellik listesi (yazılım kapsamı, müşteri kontraktı yani)". Beni en cok şaşırtan ise, insanların bu değişikliğe şaşırması. Şirketler için yazılan yazılımlarda, değişim tek sabittir. Esas sorun bu değil, bu değişime nasıl ayak uyduracağınız.

Bu değişim ortaya çıkınca karşı bir reaksiyon cesidi, "müşteri ihtiyaçları kapsam grubu tarafindan yanlış toplanmış" olabilir. Bu yanlış düşünceye göre kapsam grubu (programcılar yada idarecilerden oluşabilir bu grup) özellik listesini toplar, müşteri tarafından bu listeye imza attırır, yani kabul ettirip döndürür ve sabitleştirir. Böylece düzeni bu sabit merkez üzerine kurup yazılım sırasında değişimi en aza indirgemeye uğraşılır. Eğer değişiklik gerekmişse, bu demek ki kapsam grubunun yanlışıdır.

Bu yaklaşımın açık noktası şurada: İlkinden başlayalım. Bırakın ihtiyaç/kapsam listesinin tamamlanmasına, listesindeki birimlerin değişik variyasyonlarını bile anlamak proje başında çok zor bir şeydir. Diğer bir zorluk, ihtiyaç listesindeki birimlere fiyat biçme zorluğudur: Yani, öyle bir durum düşünün ki, müşteri şirketi mesela arabasına yeni bir cant istiyor, ama araba satış görevlisi (sizin şirketiniz) cant için $10 mi yoksa $10,000 mi isteyeceğini söyleyemiyor. Fiyatı bilmeden müşteri cantı isteyip istemediğini nereden bilecek?

Yazılım zaman takvimini yapmanın zor taraflarından biri işte budur: Yazılım işlemi aslında tamamen bir dizayn eylemi olduğundan, takvime konması zor bir eylemdir. İkinci bir sebep de: Yazılımın "ham maddesi" insanlardır. İnsanlar her zaman tahmin edilmesi zor birimler olmuslardir. Bilâhere insanların hakkındaki planlama işleminin beklenmez olması sürpriz olmamalıdır.

Yazılımın elle tutulamayan özelliği de bir etken: herhangi bir yazılımı kullanmadan, işinize yarayıp yaramayacağını anlayamazsınız. Anlamak için hiç değilse projenin ilk sürümlerinden birini kullanıp şöyle bir tartmanız gerekir, ancak o zaman ne özellikler lazım hangisi daha az lâzım, fikir sahibi olabilirsiniz.

Bütün bunları bir araya getirseniz görürsünüz ki, yazılım hakkındaki genel düşünce, rahat değiştirilebilir bir şey olduğudur. Yazılım, 'yazılan' bir şeydir, yazılan silinir de, tekrar yazılabilir de. O yüzden, proje kapsamının değişmebilmesi de "normal" bir şey olmalı. Müşterileriniz de bunu biliyor zaten, hele hele kendileride bir kaç satır kod yazmışlarsa...

Daha bitmedi: Hadi diyelim, program kapsamını değişmeyecek bir şekilde belgeleyebildiniz (bir mucize sonucu). Bu halde bile, şirketin kendisinin düzen değiştirmeyecegi ne malum? Bugün iyi olan bir kapsam, 6 ay sonraki sektörde müşteriniz için iyi olmayabilir. Bütün iş dünyasi durup onları bekleyecek değil ya! iş dünyasının çoğu değişikligi de böyledir, aksini söyleyen ya yalan söylüyordur, ya da borsada çoktan milyarder olmuştur.

Tahmin Edilebilirlik İmkansiz mi?

Genel de hayır. Bazen yazılım dünyasinda tahmin edilebilirlik mümkündür. Mesela NASA'nın uzay mekiğinin yazılım planı tahmin edilebilir bir plandır. Bir sürü insan, şa-şa lı başlangıçlar, uzun zaman alan plan/geliştirme yaparak o işe koyulurlar... NASA benzeri projeler, başka yerlerde de vardır. Fakat 'işyerleri' için yazılan programlar bu kategoriye girmez. İşyeri programları için değişik bir düzen izlemeniz gerekir.

Esas önemli olan, ne tür durum içinde olduğunu bilmek. En kötüsü, tahmin edilemeyecek bir durumdayken, ettiğini zannetmek. Klasik metodçu arkadaşlarımız genelde bu tür 'dış iş planı hatlarını' çizmekte pek iyi değillerdir. Hani metodların uygunluktan geçip uygunsuzluğa girmeye başladığı o gri alandan bahsediyoruz. Bunun suçu biraz da, metod mucidi olan arkadaşlarımızda. Metodlarının 'herkes' tarafından kullanılabilmesini istedikleri için, etrafına sınır koymaktan genelde kaçınırlar. Bu yüzden takipçileri olan bazı zavallılar, metodu yanlış yerde kullanma hatası yaparlar, beklenmez durumlar için 'beklenir olanı seven' metodlar kullanmak gibi.

Böyle yanlışları yapanı aslında anlıyoruz. Sonuçta bir şeyi tahmin edebilmek, planlayabilmek arzulanan bir özellik. Fakat tahmin edemeyecegin şeyleri planlayabilirim sanmak, proje sırasında geri dönülmez yanlışlara yol açıyor. Böyle durumlarda plan işlevini kaybedince, bu durum yeterince kollanamıyor. Yavaş yavaş plan elinizden kaysa bile, belli bir süre hala bildigim yolu takip ederim gibi işi 'kıvırıyorsunuz', fakat en sonunda gerçek ile plan arasındaki uçurum o kadar çok büyüyor ki, film mecburen bitiyor. Acı sonla.

Bu söylediklerimiz bazılarına ağır gelebilir. O kadar dikkatle kurduğunuz müşteri idare yöntemleri, proje planları demek doğru değilmis. Fakat tahmin edebilmek ne kadar güzeldi! Katılıyoruz. Eski alışkanlıkları bırakmak kolay değildir. Fakat ortada bir problem var. Bu problemin varlığını kabul etmek, çözmeden önce en gerekli aşama. Merak etmeyin: Alternatif, kontrolsuz, anarşik planlama/kodlama metodu değil. Alternatif, bilinmezi kontrol edebilen bir metod. Uyum sağlamanın önemi işte burada.

Bilinmezi Kontrol Etmek

Bilinmez dünyada, kendimizin nasıl müfettişliğini yapabiliriz? En önemlisi, projenin yolda yürüyüp yürümediğini nasil anlarız? Bize lazım olan, bir kendini denetleme mekanizması. Öyle bir mekanizma ki, gerçekçi, ve kendimizi aldatmamıza yer bırakmayan bir mekanizma.

İste anahtar cevap: Sık sürüm yaparak geliştirme metodu. Bu aslında pek yeni bir fikir değil, daha önce başka adlar altında duymuş olabilirsiniz: Azar azar geliştirme, devrim usulü, basamaklı stil, spiral metodu, vs..vs. Önemli olan, sık sürüm metodu ile, çok kısa aralar ile proje özellik listesinden bir kaçı kodlanır kodlanmaz herşeyi paketleyip, bir sürüm yapmak. Tabii ki bu ara sürümler bütün kapsamı içermiyor, ama en son planladığınız sistemin özelliklerinden bir kaçını içeriyor. Unutmayalım, aklımızda sürekli bitiş çizgisi var. Ona göre kısım kısım sürüm yapıyoruz, öyle kafamıza esen özellikleri koymuyoruz program içine. Ve, bu ara sürümü, az özellik içerse bile, sanki son sürümmüş gibi otomatik testlere tabii tutuyoruz (yazabildiğimiz kadarına), ve iç bağlantılarını doğru şekilde kuruyoruz. Burası çok önemli.

Çünkü bir proje için, gerçeklerle yüzyüze gelmenin en iyi yolu, test edilmiş ve "baglanmış" bir sistem ortaya çıkarmaktır. Güzel güzel yazılan o proje dokumanları ve belgeleri bir sürü yanlışı saklayabilir. Calışır program bile, test edilmemişse, yanlışlarını saklayabilir. Fakat bir programın önüne oturup şöyle bir kullanınca, programcılık hataları, ya da müşteri yanlış anlamak yüzünden çıkan hatalar hemen ortaya çıkarlar.

Sık sürüm metodu, klasik planli projeler için bile yararlıdır. Fakat "çevik" metodlar için vazgeçilmez bir durumdur, çünkü proje kapsam değişikliği ile boğuşmak için başka yol yoktur. Sık sürüm metodunu takip edince anlayacaksınız ki, uzun süreli planlar bayağı gevşek, ve bütün dikkatli ve detaylı planlar hemen bir sonra gelen sürüm için yapılıyor. Böylece temeli yavaş yavaş büyütüyorsunuz, ve yeri geldikçe üzerine eklemeler yapıyorsunuz.

Aklınıza bir soru geliyordur, her sürüm ne kadar aralıklar ile yapılmalı? Değişik çevik metodlarden değişik cevaplar alabilirsiniz. XP metodu 1 hafta ile 3 hafta arasında değişen bir süre verir. SCRUM metodu 1 ay der, Crystal metodu daha da uzatabilir. Fakat genel bizce, her sürümü yapabildiginiz kadar sık yapmak. Böylece sonuç sistemin bir parçasını daha sık görerek, nerede olduğunuz anlamak daha rahat olacak.

Uyum Sağlayabilen Müşteri

Uyum sağlayabilen metodlar kullarken müşteri ile ilişkilerin de değişmesi gerekiyor biraz, özellikle program müşteri şirketinin dışında yazılıyor ise. Bugünlerde müşteriler ayrı bir programcı şirkete proje verince, fiyat kontrollu proje vermek istiyorlar. Bu eski sisteme göre ihale başlatılıyor, fiyatlar toplanıyor, bir fiyata göre programcı şirket seçilip, proje veriliyor, ve yazılımın bitirme sorumluluğu bu şirketin üzerinde oluyor.

Tahmin edebileceğiniz gibi, fiyat kontrollü projeler için bilinen kapsam gerekir, ve klasik metod gerektirir. Uyum sağlayabilen metod kullanmak demek, kapsam bilinmiyor demektir, ve fiyat kontrolü bu projeler için anlamsızdır. Bu tür projelere fiyat kontrolü getirmek projeye acı sonuçlar getirebilir. En sonda olacak depremden hem siz, hem de müşteriniz etkilenecektir. Sonuçta müşterinizin bir şekilde bir yazılıma ihtiyacı var ki bunu sizden istemiş. Bu yazılım eline geçmezse, şirket geleceği kötü şekilde etkilenecektir. Yani yazılımı şirkete verdikleri para bir yana, onlara lâzım olan programı alamamaktan ifade bulan bir zarar ile karşı karşıya gelirler.

Demek ki iki taraf için de fiyat kontrollu bir kontrakt imza etmek zararlı. Bu demektir ki, müşteri de, siz de değişik bir ilişki halinde olacaksınız.

Çevik metodlar altında müşterinizin yazılım projeniz üzerinde daha fazla etkisi olmalı. Her sürüm sonunda, hem durum kontrolü için, hem de projenin yonunu değiştirebilmek için katilmalari gerekiyor. Böylece yazılım takımınız ile müşteri arasında daha sıkı bir ilişki doğuyor, tam bir takım oluyorsunuz yani. Kabul edilyoruz: böyle bir yazılım geliştirme yöntemi her müşteri ve her yazılım şirketi için uygun olmayabilir. Fakat böyle olması uyum sağlayabilen metodlar için şarttır.

Böyle bir sistemin müşteriniz için en önemli yararı şudur: Az özellikli olsa bile kullanilabilir bir yazılım, kullanima cok önceden açılabiliyor. Ve yeri geldikçe, ve iş düzeni değiştikçe, kendileri de ne istediklerini daha iyi anladıkça, sistemi değiştirme şansları ellerine geçiyor.

İnsanların, Körü Körüne Metoddan Önce Gelmesi

Uyum sağlayabilen bir metodu kullanmak kolay değil. öncelikle cok kaliteli programcılara ihtiyaç var. Hem kişilerin kaliteli olmasi lazım, hem de yazılım takımının birbiri ile uyum halinde olması lazım. Ve ilginç bir gözlem yapmak gerekirse, uyum sağlayan metod için iyi programcı gerekir, iyi programcılar da, aslında bu tür metodlar ile en rahat çalışırlar.

Programcılar Lego Parçası mi?

Klasik metodlarin asıl istedikleri lego parçası gibi istenen yere konabilen programcı birimleridir. Böyle metodlara göre lazım olan, değişik tipte ve özellikte programcı "parçalarıdır". Bir tarafta analizciler, öteki tarafta testçiler, başka bir tarafta idareciler. İnsanlar, kişi olarak önemli değiller, ne rol üstlendikleri önemli yani. Yani, projeye hangi "kişi" aldığın önemli değil, belli rollerde belli sayıda "parçalar" aldığın önemli.

Fakat gerçek hayat hakikaten böyle mi? Çevik metodların getirdiği en büyük değişiklik iste burada. Bu tür fikirleri bir tarafa atmamız gerekecek.

Bu gözlemi en iyi ispatlayan bence Alistair Cockburn. Bu konu hakkındaki bir yazısında, klasik, başı-sonu belli metodların, sıkıcı ve ne yapacağı belli insanlar gerektirdiğinden bahsediyor. Fakat insanlar tahmin edilir ve planlabilir birimler değil. Cockburn'un yaptığı araştırmalara göre, vardığı sonuç, insanların yazılım projesinin en önemli parçaları olduğudur.

Bu arkadaşımızdan bir paragraf: "Biraz önceki yazımın başlığında, klasik metodlara atıf yaparak, insanlar lego parçası gibi kullanılıyor demiştim. Eski metodlar insanları nedense böyle görüyor. Fakat ötekilerin göremediği, insanların çok değişken, ve başarı-başarısızlık dalgalarının bile çok değişik olduğudur. Bu etkenler o kadar birinci derece de önem taşıyor ve ayrıca planlanamaz türden oluyorlar ki, bu tür değişkenleri hesaba katmayan metod mucidlerimiz, projeler metodlarını kullanınca hüsrana uğruyorlar, ve bu sonuçlar başa gelince nedense şaşırıyorlar".

Bu tür "insan öncelikli" yaklaşımlarda Cockburn arkadaşımız bayağı uç noktada olsa bile, tanıdığımız proje lideri arkadaşlarımız da benzeri gozlemleri bizle çok paylaştılar. Klasik metodun en eksik tarafı, bu tür gözlemleri nedense dinlememesidir.

Bu eğilimin işaretlerini de görmüyor değildiniz herhalde. Mesela bütün programcılariniz lego parçası gibi gördüyseniz, onları kişi olarak görmüyorsunuz demektir. Bunun yan etkisi takım moralini düşürür. Kaliteli olan programcılar buna dayanamayıp, mutlaka daha iyi olarak gördükleri yere gitmeye başlarlar, ve sizde parça-yedek parça fikirlerinizle yanlız kalırsınız.

Evet, aksine karar verip uygulamak çok büyük bir adımdır, uygulamaya koymak büyük kararlılık ister. İnsanların işlemci parçası olarak görülmesi, çok eskiden beri bilinen işletmeci kafasına dayanır, Fredrick Taylor mesela "Bilimsel İdare" sanatında böyle bir yaklaşımdan bahsetmiştir. Eğer fabrika isletiyorsanız, Taylor'ın fikirleri işinize yarayacaktır. Fakat yaratıcı bir olaydan bahsediyorsak, o zaman Taylor'ın fikirleri bırakalım. (Modern üretici tesisleri de aslında Taylor fikirlerini bırakmaya başladı). Yazılım işi yaratıcı bir olgudur.

Kendinden Sorumlu Programcılar

Taylor fikrinin merkez noktası sudur: "Herhangi bir isi yapan kişi, o işin nasıl en iyi şekilde yapılacağını bilemez". Bir fabrikada bu doğru olabilir. İşçiler bir makina gibi kullanıldığı için çok zeki olmaları gerekmez.

Yazılım dünyasında bunun ne kadar yanlış olduğunu görüyoruz. Gün geçtikçe yazılım dünyasının parlak ışıklarından, oturduğun yerden büyük şeyler yaratabilme arzusu, daha çok akıllı ve becerikli insanları bu sektöre çekiyor. Ve hisse senedi hakları, programcıları iyice şirketlerine bağlıyor, kader birliği getiriyor.

İşte bu şekildeki bir gruptan insanları işe alabilmek, ve aldıktan sonra tutabilmek istiyorsanız, bu insanların profosyonel düşünceli işini seven insanlar olduğunu kabul etmeniz lazım. O yüzden teknik sorunları çözerken, unutmayın ki probleme en iyi çözüm getirecek olan insanlar, bu teknik arkadaşlarınızdır. Taylor modelinin işlemesi için, ayrı olan planlama bölümünün, işçilerin ne yaptığını onlardan iyi anlaması gerekir. Eğer işi yapan zeki ve becerikli insanlar ise, bu düzen ise yaramayacaktır yani.

Martin Fowler

Java İle Toptan İşlem Kalıbı

Kaynak kod

Toptan (batch) işlem yapmak, bilgi işlem sistemlerinde çoğunlukla karşımıza çıkan bir problemdir. Mesela, iki ayrı sistem arasında bilgi transferi yapmak gerekiyor. Kaynak tablo var, sonuç tablosu JDBC Connection nesnesi ile erişilebiliyor. Fakat ayrı sistemler oldukları için, bir "toptan" çalışacak bir Unix sürecinin, sürekli ayakta bekleyerek yeni gelen kayıtları görmesini bekliyoruz; Süreç yeni kayıt gördüğü an transferi yapması gerekiyor, işi bittiği zaman belli bir süre için uykuya yatması lazım.

Bu kodu basit bir şekilde while(true) .. döngüsü içinde ve tek bir işlem içinde yazabiliriz. Fakat, birim testten geçirmemiz zamanı gelince, testleri nasıl yazacağız? İşlemci, sonsuz döngüye girdi ise, birim testlerin de sonsuza kadar beklemesi mi gerekecek?

Bu tabii ki imkansız. Demek ki yapmamız gereken, "dışarıdan" (test ortamı içinden) işlemcinin döngüsüne karışabilmek. Yani sadece birkaç tur atmaya zorlamak. Böylece, birkaç turden sonra beklediğimiz değerleri jUnit assertEquals işlevi ile test edebiliriz.

Öteki bir kavram, uykuya yatmak: Toptan işlemler bazen 5-10 dakika kadar işleme ara vermeyi seçebilirler. Mimarinize göre bunun kararını programcılar verecektir. Fakat, birim testler için bu tekrar bir problem yaratacaktır. Testlerin geçti/geçmedi cevabını verebilmesi için (her derlemeden sonra), 5-10 dakika beklemesi mi lazım?

Gene hayır. Bu probleme çözüm, "taklit nesne" kalıbından geliyor. Eğer işlemci, uyumayı kendi içinde tuttuğu bir nesneye devrecek şekilde yazılırsa, birim test ortamı bu nesne yerine kendi taklit nesnesini koyabilir. Bu taklit nesne, gerçek nesneyi kalıtım (extends) yolu ile uzatacak, ve uyku fonksiyonunu "tekrar" tanımlayacaktır. Bu yeni tekrar tanım, derhal geri dönecek şekilde yazılacaktır. Ek olarak taklit nesnenin içinde 'sözde uyku' boolean değerini true (doğru) değerine bile değiştibilir. Böylece birim testleri, uyumuş olma/olmama gibi koşulları bile testlerine dahil edebilirler.

Taklit nesneler ile gerçek nesneyi aldatmak, birim testler için son derece önemli bir kavramdır. Bir bakıma test edilen nesnenin etrafını çepeçevre sarıyoruz, sarılan nesnenin bundan hiç haberi olmuyor. O nesneye kalırsa, o, hala Uykucu nesnesini çağırıyor, dış bağlantılarını yapıyor, iletiler yolluyor. Fakat bu işi bizim 'uzatılmış' nesneler üzerinden yaptığı için, sonuçlar "kısıtlı" oluyor. Testlerimize de aynen böylesi lazım...

Kaynaklar

Örnek Java kodlarını ekte bulabilirsiniz. Bu örnek programda, hayali bir muhasebe sistemine veri aktarıyoruz. Özellikle IslemciTest'e dikkat etmenizi tavsiye ediyorum. Ve Islemci nesnesi üzerindeki main() tanımını da inceleyin. Main, bir Java nesnesinin komut satırından başlangıç noktasıdır, bu noktadan giriş yapılınca İşlemci'nin taklit olmayan nesneler ile çalışacağına dikkat edin. Yani, bu şekildeki çalışım, gerçek ortam hâlidir, yani Uykucu gibi nesnelerin gerçek hâlleri kullanılacaktır. Fakat Test'ten giriş yapılınca, setUykucu ile bu nesnelerin yerine taklit olanların konulacağını göreceksiniz.

Tasarimin Temelleri

INTERNET açilali beri, PC World Online'a koydugumuz Misafir Defteri'ne biraktiginiz mesajlar, kendi Web sitenizi tasarlamaya ne kadar hevesli oldugunuzu açikça gösteriyor. Bizi aradiniz, mesajlar biraktiniz, deneyimlerimizden yararlanarak kendi Web sayfalarinizi tasarlamakta yardimci olacak bilgiler istediniz.

Iste biz de isteklerinizi kirmiyor ve bu sayidan itibaren bir Internet gezgininin kendi sayfalarini tasarlayarak Web'de nasil aktif rol alabilecegini açiklayan yazilarimiza basliyoruz.

Bir Web sayfasi tasarlamanin yolu HTML dilini bilmekten geçiyor. Elbette Microsoft'un Ofis programlari için gelistirdigi Internet Asistanlari, Web sayfasi tasarlamak için onlarca pratik program var, ancak HTML kodlarini bilmiyorsaniz, herhangi bir tasarim problemi ile karsilasinca takilip kalabilirsiniz. Tabii, Java, Java Script, ActiveX, PERL gibi ileri seviye Web programciligina yönelik araçlar da var.

Bu sayfalarda temelden baslayarak hepsi hakkinda bilgiler verecegiz. Bunlarin arasinda grafik tasarimlarinizi verimli ve etkin bir biçimde yapmanizi, sayfalariniza erisim hizinizi yükseltmek için grafikleri küçültmenizi saglayacak püf noktalari da olacak. HTML kodlarina ve diger teknik detaylara girmeden önce, Internet üzerinde bir Web sayfasi nasil edineceginizi anlatarak yazimiza baslamak istiyoruz.

Daha sonra HTML dilinin nasil kullanilacagina iliskin bir giris yapacagiz. Ilerki aylarda ise PC World Online'in webmaster'lari Cenk Tarhan ve Deyvi Levitas size isin teknik detaylarini anlatmaya devam edecekler.

WEB'DE NASIL YER ALIRIM?

INSANIN dünyada bir mekani ve World Wide Web'de benim diyecegi, küçük de olsa bir alani olmali. Bunu saglamak için iki seçeneginiz var. Bunlardan birincisi baska birine (muhtemelen bir ISS'ye ait) Web sunucusundan belirli bir sabit disk alani kiralamak. Türkiye'deki servis saglayicilar bu tür hizmetler veriyor. Hatta bazi ISS'lerde Internet hesabi açtirdiginizda size küçük de olsa ücretsiz bir Web sayfasi alani sagliyorlar. Ama hazirlayacaginiz Web sayfalarini ticari amaçlarla kullanacaksaniz, örnegin firmanizin ürünlerini Web sayfalarinizda tanitmak ve pazarlamak istiyorsaniz belirli bir ücret ödemek zorundasiniz.

Ikinci seçenek yine genelde firmalara yönelik. Yani, Türk Telekom'a basvurup bir kiralik hat (leased line) araciligi ile Web sayfalarinizi kendi Web sunucunuz üzerinden yayinlamak veya Web sunucunuzu bir ISS'ye yerlestirip buradan yayin yapmak. Kuskusuz bu seçenekler içinde bir ISS'nin sunucusundan - kiraladiginiz yerin MB cinsinden büyüklügüne göre ücret ödeyerek - yer kiralamak en ucuzu. Bunun karsiliginda Web sayfalariniza karsilik gelecek bir Web adresi (URL) ediniyorsunuz. Bu adres ISS'nizin ismi ile baslayip kendi sitenizin ismi ile devam edebilecegi gibi (örnegin http://www.iss.com.tr/benimsitem), ISS'nizle yaptiginiz anlasmaya göre tamamen kendi verdiginiz isim de olabilir (örnegin http://www.benimsitem.com.tr).

Elbette ISS'ler belirli bir ücret karsiligi Web sayfalarinizi tasarlayabilirler, ancak burada amacimiz kendi Web sayfalarinizi tasarlamayi ögretmek olduguna göre sayfalarinizi kendinizin tasarlayacaginizi ve ISS'nizin sunucusuna yaptiginiz anlasmaya göre belirli zamanlarda modem ile ' upload' edeceginizi varsayiyoruz. Buraya kadar ticari anlamda bir Web sitesi kurmak için neler yapabileceginizi açikladik, ancak yazimiz daha çok amatörlere yönelik oldugu için size ücretsiz alternatiflerden haberdar etmek de boynumuzun borcu. Türkiye'de bazi ISS'lerin Internet erisimi için hesap açtirdiginizda size ücretsiz bir Web sayfasi alani sagladiklarini söylemistik. Yurtdisinda hesabi olsun olmasin herkese Web sayfalarini yayinlamak için ücretsiz belirli bir alan açan ISS'ler de var.

Örnegin ABD'de faaliyet gösteren Geocities (http://www.geocities.com/homestead/) herkese 2MB'lik bir Web sayfasi alani açiyor. Internet'te sörf yaparken kuskusuz bu tür baska promosyonlarla da karsilasabilirsiniz. Hazirladiginiz sayfalari bir FTP client programi ile (örnegin ws_ftp) bu sitelere ' upload' edebiliyorsunuz. Yine de bu hizmetin sürekliligi konusunda emin olamazsiniz. Bu yüzden Web sunucusunda yer açan bir ISS bulmanizi öneririz.

WEB SAYFASI TASARIMIN TEMELLERI

EVET, nihayet bir Web sunucusunda kendinize ait bir alan elde ettiniz ve Web araciligi ile baskalarina söyleyecek çok seyiniz var. Peki bir Web sayfasini tasarlamaya nereden baslamali? Ögrenmeniz gereken temel dilin HTML (Hypertext Mark-up Language) oldugunu belirtmistik. Bu dil aslinda, normal metni, hypertext adi verilen ve web browser'larla görüntülenmeye uygun metin haline dönüstüren bir kodlar silsilesi. Diger bir deyisle HTML, basit bir belgeyi alip içine bu belgenin sayfa düzeni ve metin biçimleri ile ilgili bilgiler yerlestirmenin ve bu belgeyi diger metin (ve/veya grafik) içerikli belgelerle iliskilendirmenin yoludur.

Web'de yayinlanmak üzere belgeler hazirlarken, HTML kodlari ile metinlerinize vereceginiz biçimler belirteç (Ingilizce adi ile mark-up veya tag) adini tasir. Bunlar metnin çesitli yerlerinde, ' <' ve ' >' seklindeki parantezlerin arasina yerlestirilen kodlardir. Bunlar arasinda diger Internet sayfalarina (veya URL'lere) geçisi saglayan "link'ler" de bulunabilir.HTML bir dil olarak adlandirilsa da, HTML belgelerinin (kisaca Web sayfalarinin) hazirlanmasi klasik bilgisayar dilleri ile programlama yapmaya pek benzemez. Daha çok kelime islemcilerle çalismaya benzer. Ancak burada yazitipi büyüklügünü ayarlamak, bir metni kalin veya italik yapmak için menü komutlarini kullanmaz, bunlari metnin basina ve sonuna koydugunuz kodlarla belirlersiniz. (WordPerfect ile çalisanlar bunu kolayca anlayacaktir, çünkü bu kelime islemcide yazdiginiz metinlerin biçim kodlarini da Reveal Codes komutu ile görüntüleyebilirsiniz.) Metni ve bu kodlari nerede yazacagiz diyorsaniz, baslangiçta (hatta PC World Online'nin webmaster'larina sorarsaniz her zaman) Windows'un Not Defteri fazlasiyla yeterli olacaktir.

Bu kisa giristen sonra bir örnek ile HTML kodlarini kullanmaya baslayalim. Diyelim ki elimizde söyle bir metin var: Düsünde bile göremez isler, Düslerin gördügü isleri. Bu metni HTML kodlari ile söyle yazarsak: <B>Düsünde</B> bile göremez, <B>isler</B>,<BR><B>Düslerin</B> gördügü <B>isleri</B>.<BR>

Web browser'da asagidaki gibi bir görüntü elde ederiz:

Düsünde bile göremez isler,

Düslerin gördügü isleri.

Bu örnekte <B> ve </B> belirteçleri Web browser'a aralarindaki metni kalin (bold) göstermesini söyler. <BR> belirteci ise satir basi verilmesi gerektigini. Bunlar gibi baska pek çok belirteç var ama güzel bir Web sayfasi tasarlamak için baslangiçta ögrenmeniz gereken belirteç sayisi 30-40 kadardir. Profesyonellestikçe yeni belirteçler kullanmaya baslayabilirsiniz.

Bir de yazdiklarinizin düzgün görünmesi için her html dosyasinin basinda:<html> <head> <baslik> </baslik> </head><body> sonunda: </body></html>

belirteçlerinin bulunmasina dikkat edin. Bunlar sayfanin basini sonunu belirlemek için gerekli belirteçlerdir. Koymazsaniz, Web browser'inizda metin belirteçleri ile birlikte görünebilir.Bu örnekteki belirteçleri kendiniz denemek istiyorsaniz, Not Defteri'ne istediginiz metni bu belirteçleri kullanarak girin. Belgeye bir isim ve htm soyadini (Windows 95'te html soyadini da kullanabilirsiniz) vererek kaydedin. Sisteminize bir Web browser yüklü ise htm soyadli bu belgenin üzerine çift tikladiginizda browser açilacak ve metniniz biçimlendirilmis haliyle ekrana geelcek.

HAYDI BIR WEB SAYFASI YAPALIM

HTML dilini ögrenmenin en kolay yolu, deneme yanilma ile web sayfalari hazirlayarak bu sayfalari web tarayicisi ile kontrol etmek, hatalari düzelterek ilerlemektir. Ayrica bilmediginiz kodlarin nasil kullanildigini ögrenmek için Internet baglantiniz varsa varolan HTML sayfalarini web tarayicinizin kaydetme seçenegini kullanarak sabit diske kaydedip herhangi bir metin editörü kullanarak açip inceleyebilirsiniz. Simdi adim adim bir web sayfasi hazirlayalim. Adim 1. Pencere Basliginin, arka planin belirlenmesi ve renkler. Her web sayfasinin bir basligi olmalidir. Bu baslik web tarayicisinin baslik çubugunda görüntülenecektir. Bu is için <baslik> tag'i kullanilir.

<baslik> ve </baslik>

tag'lari arasina yazacaginiz metin web sayfasinin basligi olarak görüntülenecektir. <baslik> tag'i asagidaki gibi kullanilir. <baslik>Bu benim ilk denemem!</baslik>Web sayfalarinin arka planini da istediginiz gibi ayarlayabilirsiniz. Bu asamada iki adet seçeneginiz var. Birincisi bos bir arka plan kullanarak bu arka planin rengini ayarlamak, ikincisi ise bir resim dosyasindaki resmi alip web sayfasinin arka planina ' dösemek'. Bu islemi aynen Windows 95'in masaüstündeki duvar kagidina benzetebiliriz. Önce bos bir arka plani renklendirmeyi görelim. Web sayfasinin arka planinin rengi <body> tag'ini kullanarak degistirilir. Default arka plan rengi gridir. Arka plan rengini örnegin beyaz yapmak için body tag'ini

<body bgcolor='white'> veya <body bgcolor='#FFFFFF'>

seklinde kullanabilirsiniz. Birinci seçenekte rengin Ingilizce ismi, ikinci seçenekte ise ayni rengin RGB cinsinden renk kodu hexadecimal (onaltili sayi sistemi) olarak verilmektedir. Eski tarihli browser'lar renk isimlerini algilayamazlar, bu yüzden sayfalarinizda renklerin onaltili sayi sistemi kodlarini kullanmak daha hayirlidir. Yan tarafta gördügünüz tabloda, web sayfalarinin arka planlarinda kullanilabilecek olan temel renkler isim ve sayi kodu olarak listelenmistir. Onaltili sayilarin RGB kombinasyonlari ile oynayarak istediginiz rengi web sayfasi arka plan rengi olarak belirleyebilirsiniz.

Bir Web sayfasinin arka planina bir resim döseyebilirsiniz. Bu islem için ilk önce elinizde bir resim dosyasi olmasi gerekir. Web sayfalarinda kullanilabilecek bütün resimler JPG veya GIF formatinda olmalidir. Web okulunu hazirlarken elinizde bir resim düzenleme programinin oldugunu ve JPG veya GIF formatindaki dosyalarla çalismayi bildiginizi varsayiyoruz. Örnegin elimizde arka.gif diye bir resim olsun. Bu resmi web sayfasinin arka planina dösemek için yine <body> tag'ini kullanacagiz. ARKA.GIF adindaki bir resmi web sayfasinin arkasina dösemek için tag'ini asagidaki gibi

<body background=' arka.gif'>

kullanmalisiniz. Bu asamada ARKA.GIF dosyasinin, HTM dosyasi ile ayni klasörde yer almasi gereklidir. Örnek bir resim dösemesi asagidaki resimde gösterilmistir. Bu asamada bir web sayfasinin arka planinda bir resim dösediginizde, arka plan rengi kullanmaya gerek kalmadigi gibi bir hisse kapilirsiniz, yanilirsiniz. Genelde Internet yavas bir sey oldugu için, çogu kullanici sörf yaparken resimleri kapatma yoluna gidiyorlar. Böyle olunca arka plana dösenmis resimler görünmeyecek, arka plan rengi de default olarak gri oldugu için sizin hiç düsünmediginiz bir web sayfasi ortaya çikabilecektir. Bu yüzden size tavsiyemiz, arka plan grafigi kullandiginizda arka planda kullandiginiz resme uygun bir arka plan rengini de <body> tag'inin içinde belirtmenizdir. Iki belirteç bir tag içerisinde kullanilabilir. Ve resmiler kapatildiginda web tarayicisi otomatik olarak belirtilen arka plan rengini web sayfasina uygulayacaktir. Sari içerikli bir arka plan resmi ile kullanilmasi gereken<body> tag'i asagida gösterilmistir.

<body background=' arka.gif' bgcolor='#ffff00'>

Adim 2. Web sayfasinin metin içerigi. Web sayfalarinda aynen kitap veya dergi sayfalarinda oldugu gibi metinler ve resimler kullanilabilir. 2. Adimda web sayfalarinda metinlerin kullanimina deginecegiz. Web sayfalarinda metinler aynen Word veya benzeri bir kelime islemci programda oldugu gibi bold, italik vs.. seklinde formatlanabilir, font tipi, rengi ve boyutu ayarlanabilir. Web sayfasinin içerisine yazdiginiz metin web tarayicisinin genisligi boyunca yazilir, artan kisim otomatik olarak alt satira atilir. Örnegin asagidaki gibi bir metnimiz olsun.

Merhaba. Bu benim ilk web sayfasi denemem. Yazdigim metni bold, italik, veya altçizgili olarak görüntülemek istiyorum.

Bu metni web sayfasina girdiginizde asagidaki gibi bir ekran görüntüsü ile karsilasacaksiniz. Simdi bu metni formatlamaya baslayalim. Öncelikle merhaba kismini büyük yapmak lazim. Bunun için de <hx> tag'ini kullanacagiz. Bu tag'da x yerine birden 6'ya kadar numara verebilirsiniz. 1 en büyük boyut, 6 en küçük boyuttur. Denemeyle sabittir, 1 ile 4 arasinda rakamlar kullanmak en iyisidir. Simdi merhaba yazisini büyütmek için onu <h1> tag'ina alalim.

<h1>Merhaba</h1> Burada, <h1> ile </h1> arasindaki metin, büyültülecektir. Asagidaki resimde merhaba tag'i degisik <hx> boyutlarinda kullanilmistir. Böylece merhaba yazisini istedigimiz gibi büyüttük. <hx> tag'ini kullanirken ögrendigimiz bir ikinci sey ise metin formatlamasinin nasil yapildigi. Demek ki, bir tag'in formatlamasi iki tag arasina (<h1> ile açilis, </h1> ile kapanis) aldigimiz metne uygulaniyor. Simdi hizli bir biçimde diger metin tag'larini inceleyelelim. <b> </b> aradaki metni bold (kalin) yapar <i> </i> aradaki metni italik yapar <u> </u> aradaki metnin altini çizer

Bu tür metin formatlama tag'lari birbirlerinin içinde kullanilabilirler. Örnegin bir metin parçasini hem bold hem de italik yapmak için <b><i> ..... </i></b> formatlamasini kullanmak gerekecektir. Ã�zgün metnimize geri dönelim. Bu metinde adi geçen formatlamalari uyguladigimizda HTML sayfamizdaki metin asagidaki gibi olacaktir. <h1>Merhaba. </h1>Bu benim ilk web sayfasi denemem. Yazdigim metni <b>bold</b>, <i>italik</i>, veya <u>altçizgili</u> olarak görüntülemek istiyorum. Böyle bir formatlama yapildiginda elde edilecek olan web sayfasi görüntüsü asagidaki gibidir. Metin parçalarini web sayfasinda görüntülerken paragraf basi ve satir sonunu da elle isaretlemek zorundasiniz yoksa metin otomatik olarak alta kaydirilacaktir. Burada karsimiza iki adet tag çikiyor. Bunlardan birincisi <br>, ikincisi de <p> tag'i. Birincisi satir sonu, ikincisi ise paragraf basi anlamina geliyor. Söz konusu metinde ' Bu benim ilk web sayfasi denemem' yazisindan sonra bir satir sonu yani <enter> verelim. Ayrica paragraf basini denemek için de ' bold, italik, veya altçizgili' metnini yeni bir paragraftan baslatalim. Bu durumda kullanacagimiz formatlama asagidaki gibi olacaktir. <h1>Merhaba. </h1>Bu benim ilk web sayfasi denemem. <br>Yazdigim metni <p><b>bold</b>, <i>italik</i>, veya <u>altçizgili</u> <p>olarak görüntülemek istiyorum.Dikkat ederseniz, <p> yani paragraf basi tag'inin kullanildigi yerlerde <br> yani satir sonu kullanmiyoruz. Çünkü paragraf basi tag'i zaten satir sonunu da belirlemektedir. Yukaridaki örnekte kullanilan tag'lamanin ekranda gösterecegi sonuç asagidadir. Son olarak HTML sayfalarinda enter tusunu kullanmanin web sayfasinin görünümüne bir etkisi olmadigini söyleyelim. Web sayfalarinin ekranda görünümünde satir sonlari, satir aralari ve paragraf baslari tamamen tag'lar ile belirlenir. Bu yüzden metin dosyasinda enter kullanmanin web sayfasina herhangi bir etkisi yoktur. Ancak web sayfasini düzenlerken her seyin derli toplu gözükebilmesi için bu tür bir enter'lama yapabilirsiniz. Gelecek sayimizda metin formatlarken renk ve font kullanmayi, <pre> tag'inin ne ise yaradigini, metinlerin bir liste halinde nasil alt alta siralanacagini görecek ve web sayfalarinda resim kullanimina giris yapacagiz.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Tablolar

Tablolar, HTML sayfasinda listeler ve sablonlar hazirlamak disinda, resimleri ve metinleri sayfa içerisinde istenilen bölgelere yerlestirmek ve bunun gibi bir çok alanda kullanilirlar. HTML 3.2 ile birlikte pek çok yeni özellige kavusan ve daha görsel hale getirilen tablolar konusunu iyi ögrenen bir webmaster, hayalgücü ile tasarladigi "TÜM" sayfalari tablolar yardimi ile olusturabilir.<TR>,<TD>,<TH> ve bunlari kapatma taglariyla birlikte kullanilan <TABLE...> tag'inin genel kullanimi söyledir:

<TABLE BORDER=X CELLPADDING=X CELLSPACING=X WIDTH=[% veya X] HEIGHT=[% veya X] BGCOLOR=X BACKGROUND="X">

BORDER degiskenine verilecek 0 veya daha üstü bir deger tablonun kalinligini belirler. CELLPADDING degiskenine verilebilecek herhangi bir sayi, tablonun sinirlari ile tablo içerigi arasindaki mesafeyi, CELLSPACING ise hücreler arasindaki mesafeyi belirler. WIDTH ve HEIGHT degiskenleri bir yüzde degeri veya bir sayi olabilir. WIDTH=590 degeri verildiginde 640*480 çözünürlükte ekranin tüm genisligini kaplayacak bir tablo olusturulur. WIDTH=%50 degerini verildiginizde ise Web tarayiciniz o tablonun her zaman ekran genisliginin yarisini kaplamasini saglar.

<TABLE> tag'inin içerisinde kullanilan BGCOLOR degiskeni tablonun fon rengini tayin eder. X degeri geçen aylarda degindigimiz HEX kodlarindan (#FFFF00) veya renk isimlerinden (white, olive...) biri olmalidir. Tablonuz daha canli ve profesyonel görünsün istiyorsaniz, arka fonuna bir GIF veya JPG resmini de BACKGROUND ekini kullanarak dösetebilirsiniz.

Gelelim tablonun olusturulmasina. Genel prensip sudur: <TABLE> tag'iyla tabloya basladiktan sonra her satiri olusturmak için <TR>, her sütunu olusturmak için ise <TD> tag'ini kullanmalisiniz. Aman bu taglari kullaniyorsaniz her satirin sonuna </TR> ve her sütunun sonuna </TD> tag'larinin koymayi unutmayin!

Bir diger durum da, herhangi bir hücrenin yanindaki iki ya da daha çok hücreyi enine ya da boyuna dogru içine almasidir ki bu islemi yapmak için <TD [COLSPAN=X, ROWSPAN=X]> veya <TR [COLSPAN=X, ROWSPAN=X]> ekleri kullanilir. Örnegin 2 satir ve 2 sütunlu 1.tablonun olusturulmasi için asagidaki kodlara ihtiyaç vardir, bu kodlar ayni zamanda COLSPAN ve ROWSPAN eklerini de anlatmaktadir.

<TABLE BORDER=1 CELLSPACING=2 CELLPADDING=3>
<!---Bu kodlarla, çerçeve kalinligi 1, hücreler arasi boslugu 2, hücre ile yazi araligi 3 olan yeni bir tablo olusturuyoruz.--->
<TR><TH COLSPAN=2> <!---iki kolonu içine alacak, yazilar kalin olacak -->
<!--ve ortalanacak (yani baslik olacak) --->


Tablo Örnegi:

</TR></TD><TR><TD>
deneme1
</TD><TD> <!-- yeni bir kolona basliyoruz... -->
deneme2
</TR></TD><TR><TD>
deneme3
</TD><TD> <!-- yeni bir kolona basliyoruz... -->
deneme4
</TD></TR></TABLE> <!-- tüm tag'lari kapatip tabloyu sonlandiriyoruz. -->


Eger renkli tablolar elde etmek isteseydik <TABLE .... ifadesinin yanina BGCOLOR="#FFFF80", <TD.. ifadesinin yanina ise BGCOLOR="#000080" eklerini girmeniz gerekecekti.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Tablo Çercevelerine Kontrol

Tablolarda BGCOLOR ifadesini kullanarak hücrelerin veya tüm bir tablonun arkaplan rengini tayin edebilirsiniz. Peki tablo çerçevelerinin de renklendirilebilecegini biliyor muydunuz? BORDER takisi ile kalinligini tayin ettiginiz tablo çerçevelerinin isik gören ve görmeyen yönlerini yine HTML komutlarini kullanarak degistirebilirsiniz. Bunu gerçeklestirmek için tek yapmaniz gereken<TABLE..> komutu içerisinde BORDERCOLORDARK, BORDERCOLORLIGHT ifadelerini veya bu iki takinin yerini tutan BORDERCOLOR ifadesini kullanmak. Adlarindan da anlasilabilecegi gibi BORDERCOLORDARK tablo çerçevesinin gölgeli kismini digeri ise çerçevenin isiga bakan kismini renklendiriyor. Sadece BORDERCOLOR kullanildiginda çerçevenin tüm kisimlari ayni renge boyaniyor.

<table border="5" BORDERCOLORDARK="navy" BORDERCOLORLIGHT="blue">

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Java İçin Sıkça Sorulan Sorular (SSS)

Java ile yazilan uygulamalar yavas mi?

Günümüzde ünlü olan derleyiciler, ya makina kodu çikartirlar, ya da arakod (bytekod) denilen ve yorumlayici gerektiren isler kod yaratirlar. Eger isler kod makina koduysa (mesela .exe dosyalari), bu dosyayi hemen isletmek mümkündür. Java ise arakod yarattigi için, isler kod için yorumlayici lazimdir. Java programlarini isletmek için komut satirindan "java dosya_ismi" tabirinin kullanilmasinin sebebi budur.

Yorumlayici, adindan da belli oldugu üzere, her arakodu teker teker alip makina koduna program islerken 'anlik' çeviri yapar. Böyle olunca, mikroislemci hizinin belli bir yüzdesi bu çeviri islemine gider.

Fakat, "Java daha yavas mi" sorusu, ortama göre degisik cevaplar getirebilir. Mesela, is sistemleri denen, veri tabanina sik sekilde erisen sistemlerde Java kullanilirsa, hiz farki pek farkedilmeyecektir. Çünkü is sistemleri zaten, zamaninin %80 kadarini veri tabani üzerinde geçirir. Geri kalan %20'nin (örnegin) %10'u az bir rakam olacaktir.

Diger ortamlarda, mesela matematik formülü çözen ve hesap yapan sistemlerde, C++ ile fark görülebilir. Yüzde veremiyoruz, çünkü aradaki fark her gecen gün kapaniyor. Ayrica, Java'cilar bazi "agir" islemleri yerli "native" olarak C dilinde kodlayabiliyorlar. Java içinden C islemleri çagirmak JNI (Java Native Interface) araciligiyla mümkündür.

Böyle olunca aradaki seçimi çok açidan ele almak gerekir. Fakat rahatlikla söyleyebiliriz ki, is sistemleri için hiz farki önemli bir faktör degildir.

CLASSPATH nedir? java.lang.NoClassDefNotFound hatasi neden geliyor?

Java programciliginda karsimiza çikan ilk hata belki de budur. Sebebini anlamak için, Java'nin paket kavramini anlamak gerekir.

Her Java sinifi bir paket içine konabilir (tavsiye edilen yöntem de budur). Beraber çalisan siniflar genelde ayni pakete konur. Örnegin /usr/local/work altinda bir sinif tanimlanmis olsun. Paket tanimlamasi söyle olabilir:

package com.sirket.vs;...public class TestSinifi { ...} Derledikten sonra, çikan TestSinifi.class dosyasi /usr/local/work/com/sirket/vs dizini altina gitmelidir. (Ant bu dizini otomatik olarak yaratir). Yani Java Paket düzeni ile, dizin düzeni arasinda direk baglanti vardir.

com.sirket.vs dizini com/sirket/vs dizinine denk gelir. Bu yüzden TestSinifi'ni isletmek için /usr/local/work altina gidip java com.sirket.vs.TestSinifi komutunu isletmek gerekir.

Yarattigimgz TestSinifi sinifinin gerçek ismi ise com.sirket.vs.TestSinifi olarak geçer.

En uygun veri taban yönetim yazilimi hangisi?

Son zamanin en gözde veri tabani tartismasiz Oracle. SQL diline en erken gecen veri tabanlarindan biridir. Her ortamda bulunabilir (Linux, Windows, Solaris, vs.). ABD finans merkezlerinde sikça kullanilir (ayakta uzun sure kalmasi gereken sistemler için).

Orta ve büyük ölçekli uygulamalar için Oracle uygundur. Daha büyük (devasa) veri tabanlari için IBM DB2, NEC'den Terradata gibi yazilimlar vardir.

Bedava veri tabanlari arasinda MySQL uygun programlardan birisidir. InnoDB eklemesi ile hizli veri tabanlarina yetisti diye duyumlar aldik.

J2EE ile .NET karsilastirmasi yapabilir misiniz? Hangisi daha iyidir?

Bu iki teknoloji arasindaki seçim, su üç noktada baglanir:


* Hangi ortama baglanmak istiyorsunuz, tek isletim sistemine mi, yoksa tek programlama diline mi?
* Sistemin uzun süre ayakta kalmasi ne kadar önemli?
* Sistemin idare edilebilmesi ne kadar önemli?

Eger proglamla teknolojisi olarak COM, VB bilgi dagarcigi sirketinizde varsa, .NET uygun olabilir. Eger Java'yi yeteri kadar güçlü bir yazilim dili olarak görüyorsaniz, her ortamda programinizi çalistirabilmek açisindan Java uygun olabilir. Biz, gelecegin degisik donanim ortamlarinda ve degisik boyutlardaki bilgisayarlarda, elektronik aletlerde olacagini düsünüyoruz. Cep telefonu, ufak devreler, dizüstü ya da sunucu ortamlarinda Java'yi artik bulmak mümkün.

Ayrica, .NET kodlari Windows'a göbekten bagli olduklari için, kodlarin ayakta çökmeden kalabilmesi isletim sisteminin istikrarli islemesine baglidir. Windows ailesi nisbeten yeni bir sistem oldugu için, hala büyümekte ve hatalari onarilmaktadir. Bu yüzden hala kritik sistemler denen, ayakta surekli kalmasi gereken ortamlarda tercih edilmiyor. Bu ileride degisebilir ama simdilik durum budur.

Ayrica sistemlerin bakimini ve idaresini yapan uzmanlar, tekrar edilen isleri genelde betikler ile (script) tekrar tekrar isletebilmeyi tercih ederler. Windows'un geçmisi görsel agirlikli oldugu için komut satirina fazla agirlik verilmemistir. Sistem idarecileri o yüzden Perl gibi Unix dunyasindan gelen kavramlari Windows'da kullanmak zorunda kaliyorlar. Fakat gene de Windows'un her tarafi betiklemeye açik degildir.

JSP-Tomcat-Java kullanirken, Türkçe karakter sorunu oluyor. Ne yapmak lazim?

JSP ya da Servlet'in javax.servlet.http.HttpServletResponse nesnesinin setContentType(java.lang.String type) metodunu da kullanabilirsiniz:

request.setContentType("text/html;charset=ISO-8859-9");

Daha güzel bir yöntem ayni nesnenin setLocale() metodunu kullanmaktir: request.setLocale(new java.util.Locale("tr", "TR"));

Eger HTML (ve HTML içeren JSP) dosyalarinin kodunu degistirerek ayni sonucu yaratmak isterseniz, baslarina su ibareyi eklemek gerekir:

<head>
<meta content="text/html;charset=ISO-8859-9" http-equiv="Content-Type">
</head>

Tekil Nesne Kalıbı (Singleton Pattern)

Java programlarımızda bâzen bellekteki herhangi bir sınıfın sadece bir nesnesi olmasını isteyebiliriz. Meselâ: Bazı değerleri merkezi bir yerde tutmak istiyoruz, ve bu nesneden sadece bir tâne olmasını istiyoruz. Ayrıca bu kayıt nesnesine erişim için programda oradan buraya aynı nesne referansını geçirmek istemiyoruz. Bu gibi durumlar için Tekil Nesne kalıbı biçilmiş kaftandır. Nerede olursak olalım, SINIF.nesneyiVer().herhangiBirIslem() gibi bir kullanımla bu tek nesneye erişebiliriz.

Tekil nesne kalıbının temeli çok basittir. Java dilinde static kelimesinin nesneler bazında (instance) değil, sınıf bazında geçerli, yani hep aynı olduğunu biliyoruz. Bu özelliği kullanarak bir Tekil Nesne yaratmak mümkündür.

Öyle bir sınıf yazarız ki, kurucu metodu (constructor) dışarıya kapalı olur. Bu bir. İkincisi, sınıf kendi tipinden bir nesneye işaret eden bir göstergeçi static olarak kendi içinde taşır. Bundan sonra yapmamız gereken, static bir nesneyiVer() diye bir işlem yazmaktır. Bu işlem şunları yapar. Önce sınıf içinde tutulan static göstergecin bir şeyi gösterip göstermediğine bakar. Eğer gösteriyorsa, bu değeri geri döndürür. Eğer göstergeç boş (null) ise (ilk başta böyle olacaktır), o zaman yeni bir tekil TekilNesne yaratılır, ve static göstergece yazılır, ve bu nesne döndürülür.

Yâni, sonuç olarak TekilNesne yaratılması sadece ve sadece tek bir static metod üzerinden olacak. Bu metod da "tek bir" ve "hep aynı" nesneyi yaratıp geri döndürdüğü için, TekilNesne sınıfından sâdece bir tâne nesne olmuş olur.

public class TekilNesne {

private static TekilNesne nesne;

private TekilNesne() {
nesne = new TekilNesne();
}

public static TekilNesne nesneyiVer() {
if (nesne == null) {
nesne = new TekilNesne();
}
return nesne;
}
...

public void birseylerYap() { .. }
public void baskaseylerYap() { .. }
}

Kullanmak için

..
TekilNesne.nesneyiVer().birseylerYap();
..
TekilNesne.nesneyiVer().baskaseylerYap();
..

Önemli bir nokta olarak, birseylerYap() ve baskaseylerYap() metotlarının static metot olmadıklarına dikkatinizi çekerim. Bu metotlar, sınıf bazında değil nesne bazında tanımlanmıştır. Fakat bu sınıftan tek bir nesne çıkacağı için zaten hep aynı nesnenin üzerindeki birseylerYap() ve baskaseylerYap() metodunu işletiyor olacağız. Bu bağlamda metot davranışı static bir metodun davranışına benzer, fakat konuşulan iç değişkenler nesne bazlı olacaktır, bunun akılda tutulması gerekir.

Sihirli Tag'lar

Sihirli bir TAG: <PRE>

HTML haline dönüstürmeye üsendiginiz ve Internet'te aynen yer almasini istediginiz bir metin var diyelim. Fakat bu metni HTML sayfasi içine yerlestirdiginizde ve web tarayiciniz araciligiyla görüntülediginizde bütün formatlamalar ve paragraflar yok oluyor... Iste bu asamada bir tag imdadiniza kosar ve tüm metni HTML'ye dönüstürmenize gerek kalmaz. <PRE> ile baslayan metin aynen not defterinde göründügü gibi görünür, tüm sekme karakterleri, ENTER karakterleri HTML sayfasi içinde yer alir. Metnin eski haline dönmesi için </PRE> kullanilmasi yeterlidir. Her gülün bir dikeni oldugu gibi bu gülün de bir kötülügü uzunlugu bir sayfayi geçen metinleri bir alt satira kaydirmamasidir, metnin tamaminin görünebilmesi için kullanici sayfayi saga dogru kaydirmalidir.

SIHIRLI BIR TAG: <PLAINTEXT>

Ellerinizle hazirladiginiz nadide bir web sayfasina, uzunca bir paragraf eklemek istiyorsunuz diyelim. Fakat paragrafi formatlamaniz çok uzun zaman alacaktir; üstelik paragrafi HTML sayfaniza oldugu gibi koyarsaniz tüm paragraflar ve sekme karakterleri yok olacak. Geçen ay bahsettigimiz PRE tag'ini kullandiginizda bu sefer baska bir sürprizle karsilasacak ve genisligi bir sayfadan fazla olan satirlari ekranda göremeyeceksiniz. Iste bu asamada bütün bunlari ortadan kaldiran bir tag yardima kosuyor.

Web tarayiciniz sayfa içerisinde <plaintext> tag'ini gördügü anda <plaintext>e kadar olan kismi not defterinde görünüyormus gibi gösterir. Iki taki arasinda kalan hiç bir tag göz önüne alinmaz ve normal bir metinmis gibi islem görür.

Sihirli Iki Tag: topmargin ve leftmargin

Sayfanizda sol üst köseye dayamaniz gereken bir resim, bir yazi ya da bir tablo bulunuyor diyelim. Web tarayiciniz ise her HTML sayfasinda soldan ve üstten yarim santimetre pay birakmakta kararli görünüyor.

Bunu önlemenin bir yolu var: <BODY... tag'inin yanina getireceginiz topmargin= ve leftmargin= ekleri, sayfanin marjin ayarlarini sizin belirlemenizi saglayacaktir. Ölçünün piksel oldugu bu iki ekin kullanimi söyledir:

<body bgcolor="#ffffff" topmargin=0 leftmargin=0>

eklerin sadece birisini ya da ikisini birden kullanabilirsiniz. Eklerden birini kullanmadiginizda Web tarayicisi o ek için varsayilan degeri yani yarim santimi kullanacaktir. (Bu iki ek sadece Internet Explorer 2.0 ve üstü Web tarayicilari için geçerlidir.)

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

İnternet Sayfası İstenince Ne Olur


Sayfa istenince yapılan işlemler aşağıda sıralanmıştır.


* Kullanıcı tarayıcı ile bir veb sayfası ister
* Bu komut, sayfa servisi tarafından alınır. Eğer sayfa HTML değil, JSP/JHTML gibi yazılım servisi gerektiren bir sayfa ise, yazılım servisine aktarılır.
* Yazılım servisi sayfa içindeki Java veya diğer kodu işletir, veri tabanına ulaşması gerekiyorsa ulaşır ve sonuçları HTML olarak sayfa servisine geri gönderir.
* Sayfa servisi öteki HTML bilgilerini ekleyerek bütün sayfayı kullanıcıya yollar.

Saydam GIF'ler

Internet üzerinde gezinirken, resimlerin arka plan ve arka renkler ile uyum içinde oldugunu, resmin kare olmasina ragmen arka planin resmin bosluklarindan görünebildigine sahit olursunuz. Eger web sayfanizda bir resim kullaniyor ve resmin bos taraflarindan arkaplanin görünmemesinden ve resmin sayfa üzerinde yama gibi görünmesinden yakiniyorsaniz bu bölümü dikkatle okuyun.

Bu bölümde resmi transparan hale getirirken en çok kullanilan shareware grafik editörlerinden biri olan Paint Shop Pro'nun 3.12 sürümünü kullanacagiz. PSP 4.0 sahipleri de yaptiklarimizi aynen kendi programlarinda uygulayabilirler. Öncelikle Paint Shop'u açin ve transparan yapmak istediginiz GIF dosyasini yükleyin, unutmayin transparan dosyalar sadece GIF formatinda ve 256 renkte olabilirler.

"Select" araç kutusundan asagidaki resimde de seçili olan "Color Picker"i seçin ve resim üzerinde transparan yapmak istediginiz, yani yaprak ve dünyanin disinda kalan alanin üzerine götürün. Fareyi bu bölgeden ayirmadan durum çubugunun sag bölmesinde I: degerinin yanindaki degeri aklinizin bir kenarina kaydedin.

"File" menüsünden "Save As..." komutunu çalistirin ve format olarak GIF89a - Interlaced'i seçin. Diyalog kutusunun sag tarafinda bulunan Options butonuna bastiginizda GIF Transparency Options Diyalog kutusu karsiniza gelecektir. Bu kutucukta "Set Transparency Value to:" seçenegini isaretleyip karsisindaki metin kutusuna "I:"nin karsisinda okudugunuz degeri (yani yalniz bu resim için 215'i) yazarsaniz GIF dosyasinin renk seçici ile seçtiginiz rengi transparan olacak böylece arkaplanlar bu bölgeden görülebilecektir. Resimler her zaman basarili olarak transparan yapilamazlar, bunun sebebi bazen resmin istemediginiz alanlarinda transparan yaptiginiz renge ait parçaciklarin kalmasidir. Bunu önlemek için resmi yüksek renge getirdikten sonra resim ile alakasi olmayan bir renk seçip transparan yapmak istediginiz alani bu renk ile boyamali ve resmi tekrar 256 renge getirerek bu rengin indeksini okuyup transparan hale getirmelisiniz. Bir transparan GIF'in hikayesi kisaca böyle, "Benim isim gücüm var, bu kadar isle ugrasamam" diyorsaniz, Internet üzerinde yüzlerce GIF dönüstürme seti bulabilirsiniz, hizli olmalarina ragmen insan elinin yerini tutmaz ama olsun.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Daha Gelismis Satir Sonu

HTML 1.0 standardi ile gelen en basit komutlardan biri <BR> dir. Satir sonunu ifade eden bu taki kullanildiginda satirin neresinde olunursa olsun yeni bir satira baslanacaktir. <P> ifadesinden farkli olarak bu komut yeni bir paragraf olusturmak için kullanilmamalidir. HTML 3.2 ile birlikte bu komuta bir de CLEAR özelligi eklendi. <BR> komutunun resimlerle birlikte kullanildiginda fonksiyoneligini arttirmak için kullanilabilecek bu özelligin tag içinde kullanimi söyledir:

<BR CLEAR=NONE|LEFT|RIGHT|ALL>

Ilgili metnin resmin altinda mi yoksa yaninda mi görünecegini belirler. Varsayilan degeri NONE'dir. NONE Bir sonraki yazi resmin hemen yaninda görüntülenir. LEFT Bir sonraki yazi resmin altinda sol marjin'in hemen yaninda görüntülenir. RIGHT Bir sonraki yazi resmin altinda sag marjinin hemen yaninda görüntülenir. ALL Bir sonraki yazi resmin altinda sag ve sol marjinlerin yaninda görüntülenir.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Resim Kullanmak

Gelelim web dünyasinin en önemli ögelerinden birine, resimlere. HTML dilinde her sey çok kolay oldugu gibi sayfalara resim yerlestirmek de çok kolaydir. Resimler sayfa içerisinde metne göre saga, sola, asagi ve yukari dogru yerlestirilebilirler, ayrica boyutlari sadece belirli degerler degistirilerek ayarlanabilir.

Dokümanin herhangi bir yerine bir resim yerlestirmek için en sade haliyle <IMG SRC="RESIM.GIF"> tag'ini kullanabilirsiniz. Bu tag'i kullandiginizda resim hiç bir yere yaslanmayacak, boyutu ayarlanmayacak, metin olarak bir alternatifi olmayacaktir.

Yukarda da belirttigimiz gibi resimleri kullanirken bir çok seçeneginiz var, bu seçenekler sayfanin görünümünde kuskusuz büyük rol oynayacaktir. Seçeneklerden birincisi Internet erisiminin yavas oldugunu bildigimiz ülkemizde sayfalarinizi görüntüleyecek olan kisilere biraz yardimci olmak en azindan resim yüklenene kadar kullanicinin meraklarini gidermek için kullanilabilir, bahsettigimiz taki "ALT" tir. <IMG SRC="RESIM.GIF" ALT="deneme resmi"> satirini yazdiginizda web tarayiciniz RESIM.GIF adli resmi yüklenmeden önce resmin yerine "deneme resmi" metnini girecektir, böylece kullanici resmi görmeden ne oldugunu bilecek ve aninda STOP tusuna basabilecektir. (!)

Seçeneklerden biri de resmin ekranda görünecek boyutlarini ayarlamak için kullanilir bu taki HEIGHT ve WIDTH'tir. Bu takilar bir arada kullanilmalidir, tek basina kullanildiginda web tarayicisi takiyi göz ardi edecektir. <IMG SRC="RESIM.GIF" WIDTH=100 HEIGHT=50> satirini yazdiginizda RESIM.GIF isimli resmin boyutu ne olursa olsun 50 piksel yükseklige ve 100 piksel genisligine getirilerek ekranda gösterilecektir. Resim gösterirken isinize yarayacak diger bir seçenek ise BORDER'dir. Bu taki ileride deginecegimiz "Internet Kisayollari" (Hyper Link) ile ilgili olsa da simdi birkaç püf noktasi vermek gerekir. Baska bir URL'ye kisayol yaratildiginda kisayolun ismi bir alt çizgi ile belirlenir, bu islem resimlerde resmin mavi bir çerçeve içerisine alinmasiyla belirtilir, Eger bir resmi baska bir sayfaya kisayol olarak kullanacaksaniz ve çerçevenin görünmesini istemiyorsaniz BORDER=0 ifadesini kullanmalisiniz.

Resimleri kullanirken dikkat etmeniz gerekenler:

Daha önce de belirttigimiz gibi Internet'te uzun süredir yer alan kullanicilar, sitelerdeki büyük resimleri çok islerine yaramadigi sürece görmek istemeyeceklerdir. Bu yüzden, her zaman resimlerin boyutunu küçük, miktarini az tutmalisiniz.

Eger büyük resimler kullanacaksaniz, (büyük resim derken ekrani kaplayacak kadar büyük degil), bunlari JPEG formatina çevirmenizi ve kalitesini düsürmenizi tavsiye ederiz. JPEG resimler her zaman GIF'lerden daha az yer kaplarlar, bu yüzden daha hizli yüklenirler.

Resimlere her zaman ALT tag'ini kullanarak alternatif metinler verin, Internet'i kullananlarin her zaman resim görüntüleyebilecek, browser'i olan makineler oldugunu varsaymayin. Eger resimlere alternatif metinler verirseniz terminal ekrani kullanan kullanicilarda bilgiye erisebilirler.

GIF'leri kullanirken "Interlaced" haline getirin, bu tip GIF'ler kademe kademe yüklenir ve yavas yavas netleserek resmi daha hizli yükleniyormus gibi gösterir.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Yeniden Düzenleme (Refactoring)

Extreme programming yönteminin diger tasarım/kodlama yöntemlerinden büyük farkları vardir. Bunlardan en önemlisi, tasarım ne zaman ve ne kadar yapilacağıdır.

Bildiğiniz gibi eski tasarım yöntemlerinde, başta uzun sureli tasarım yapmak, ve ciltler dolusu tasarım belgesi ortaya çıkartmak gerekir. Bu fikre göre, bu devre icin ne kadar uzun zaman harcanırsa, o kadar iyidir.

Böyle projelerin başarı yüzdesi %50'dir. Sektörde bunun birçok örneğini gördük ve yaşadık.

Bu yüzden yeni seçenek olarak gelen her yöntem, ne kadar ve ne zaman tasarım yapılacağını tanımlamalıdır.

Elimizdeki silahlar

Teknolojide ve diğer birçok konuda, "çapımızı" elimizde olan yetenekler, bildiğimiz püf nokta gibi yararlı bilgiler belirler. Bu noktalara dayanarak çözüm üretiriz. O yüzden, XP yönteminin tasarıma yaklaşımı açısından, yeni bir 'numara' öğrenmek zorundayız. Bu numara 'yeniden düzenleme' denilen refactoring numarasıdır.

Yeniden Düzenleme

İlk once kabul etmemiz bir nokta: Hiç bir programcı bir defada kafasında kurduğu tasarımı, hiç değisiklik yapmadan kodlayıp ortaya çıkaramaz. Kafada kurulan tasarım ile, yazılan kod arasinda 'kodu yazarken' muhakkak bazı değişiklikler gerekecektir. Bunun sebeplerinden biri, kod yazmanın gerçekle yüzyüze gelinen yer olmasıdır, derleme yaptiğınızda sonuç ya, gecer ya kalır. Ayrıca, kodu yazarken daha ilginç 'tasarım fikirleri' aklınıza gelecektir. Bu gayet normal. Zaten tasarım/kodlama surekli bir davridaim icinde gecer, biri ötekini etkiler.

İşte bu yüzden, XP yöntemi tasarım surada baslar, surada biter, sonra kodlama baslar demez. XP'ye göre, programcı her zaman tasarım yapar, her zaman kodlar. XP programcısı için kodlamak bazen Lego gibi yap-boz ruhu ile uğrasılan, bazen çok ciddi bağlantıları kurulan bir ortamdır.

Daha uzatmadan, öğretecegimiz 'numaraya' gelelim. Yeniden duzenleme, adindan belli oldugu gibi, kodu yeniden duzenleyip tasarımını değistirmeye denir. Fakat bu oyle yapilir ki, programin değisim öncesi ve sonrasındaki özellik listesinde hiçbir değişiklik olmaz.

'Ozellik listesi niye degismez?' diye bir soru sorulabilir. Bunun cok pratik sebepleri var. En onemlisi sudur: Tasarım değişikligi program yapisini değistirdiği icin, değişimin dogru yapılıp yapilmadığının kontrolunun en rahat yolu özellik listesininin kullanıcı yüzünü kontrol etmektir. Hatta ve hatta daha iyisi, sanal bir kullanıcı sayılabilecek JUnit birim testlerinizi bu iş için kullanmaktır. (Zaten yazılma amaçları da budur). Yani, test programlarını degisimden önce ve sonra isletirsinizseniz ve testler, iki sefer de basari ile geçiyor ise, demek ki tasarım değişikliginiz yeni hatalar yaratmamış.

Boylece o hepimizin basina gelen, tasarım degistirken programa 'yeni hata ekleme' olayindan korunuruz.

Tekrar soyleyelim: Yeniden duzenleme teknigi icin test programlarinin varlığı ZORUNLUDUR. Bazı programcıların yeniden düzenleme tekniğinden uzak durma ve hatta secenek olarak bilmemesinin sebebinin altinda, test programı yazma disiplinindeki eksiklik yatar. Eger elinizde test programı yoksa, tasarım değişikliğinin doğru olup olmadığını nasıl anlayacağız?

Şimdi yeniden düzenlemenin ABC'sine, yani alt duzey tekniklerine gelelim: Bu tekniği uygularken yaparken amacımız şu olmalidir:
* Kod içinde tekrar eden olguların merkezilestirilmesi, yani tek bir yerde toplanmasıdır.
* İşlemlerin ait olduğu nesneler üzerinde toplanmasıdır.

Bir örnek yeniden düzenleme şöyle olabilir. Mesela, Araba adlı nesnemiz var, ve Araba nesnesini kalıtım (inheritance) ile uzatan Tofas adli nesnemiz. Bildiginiz gibi kalitim ile kalitim yaptiginiz nesnenin islemleri size gecer. Yani Tofas nesnesi, Araba nesnesinin butun islemlerini kullanabilir.

Simdi diyelim Serce adli bir nesne yarattik. Birden farkettik ki, Serce nesnesi ile Tofas arasinda benzerlikler var. Fakat Serce ile Tofas arasinda tek baglanti Araba nesnesi! Ortak olmasi gereken islem Araba uzerinde degil.

Bu gibi durumlarda, hemen acele bir yeniden duzenleme yapip, ortak olmasi gereken islemi Tofas nesnesinden, Araba nesnesine 'yükseltmemiz' gerekir. Bunu yapinca artik bu isleme Serce'den erismek mumkundur.

Bu islemi yaptiktan sonra, test programlariniz tekrar isletmeyi unutmayin..