Bu şiir benim yazdığım bir şiir değil, google da aratmama rağmen bulamadım. Türki cumhuriyetlerin birine ait ama bir türlü ilk defa nerede okuduğumu hatırlayamıyorum.

Biz de toprağında yetişen
Bir başağın taneleriydik
Geçti nice dört mevsimler
Dört renk içinde
Arzularım
Dedemin gümüş kılıcının kabzasında
Bir aslan hırsı
Hıncım.
Demir çemberler arasında
Bir parlar, bir söner
Derken uzak bir diyardan
Yaralı bir kuş geldi.
Dedi : "Senin için ağlar,
Yarası var ırmak ırmak
Dertleri var dağlar dolusu
Sana selam gönderdi
Ana gibi, yar gibi sıcak bir selam"

Sonra can verdi yaralı kuş.
Canlanan emelime
Silkindi seneler
Tozlanmış hatıralardan
Kükredi aslan hırsım
Demir çemberler arasından
Parladı hıncım.

Dedemin, dedemin gümüş kılıcında.

Bu bir yerlerde yazılı olarak durmalıydı, mısralarından unuttuklarım var, eğer kimin şiiri olduğunu bilen varsa ve beni haberdar ederse çok sevineceğim.

İşte üstadımın resmi. Buraya onu tanıtan bir yazı yazmak istiyorum.

Bana neler öğrettiğinden kısaca bahsetmek istiyorum. Sadece kodlardan ibaret olan internet programcılığı hayatımda ilk defa kodların aslında her şekilde birbirine bir şekilde (hatta hiç programlama bilmeyen kişiler tarafından dahi) eklenebildiğini ancak bizim ekip olarak yaptığımız işi esas öne çıkartanın, o sitenin güzel görünümü olduğunu hatırlatan öğreten kişidir.

Tasarım uyarlama konusunda tüm beceriksizliğime rağmen sabırla beni eğiten ve eğitmeye devam eden kişidir aynı zamanda. "Sensey" ime buradan selamlarımı iletiyorum. Saygılar.

Link : http://www.flashtr.com/

Birkaç gün önce yazdığım uygulamalardan birinin kod arka planında "Sql Injection" adı verilen sızmaya karşı açık bırakmış olduğumu anladım. Yaptığım denemeler sonucu Stored Procedure kullanmak dahi %% arasına yazdığım karakterin sql injection açığını meydana getirmesine engel olamıyordu. Çareyi şöyle ufak bir süzgeç hazırlayıp, sadece belli karakter ve sayı aralıklarına izin vermekte buldum.

using System.Text.RegularExpressions;

public class SqlInjection
{  

public static bool InjectionWhiteList(string s)  

{   

Regex rx = new Regex(@"^[A-Za-z1-9\sğüşıöçĞÜŞİÖÇ]+$");   

return rx.IsMatch(s);  

}

}

Her ne kadar eski klasik ASP günlerini hatırlatsa da, dinamik arama sorgusu oluştururken bunu engellemenin daha pratik bir yolunu bulamadığım için, bunu kullanmaya devam edeceğim bir süre.

wwroot a teşekkürler.

1. Rainbow : Dotnetnuke ile birlikte benim çalıştığım alanda açık kaynak kodlu modüler projelerden bir tanesi.
2. Mono : Linux altında .net çalıştırabilmeyi amaçlayan bu proje (her ne kadar kullanışsız olsa da) en azından dökümantasyonunda yardımcı olmak istediğim bir projedir.
3. Anthem : asp.net için ajax kütüphanesi. Bu projenin içine bir imza tanıma (Mehmet Ecevit kaynaklı kod) bileşeni uyarlamak istiyorum.
4. Singularity : Peki, peki ben bir sistem programcısı değilim, hatta uygulama programcılığını bile unuttum denilebilir. Ve bu projenin içinde yer almak için bir MS çalışanı olmam da gerekebilir, belki de Sharp OS un bir kıyısından bulaşıp, ona bir satır kod, veya döküman ekleme şerefine erişebileceğim. Bunlar benim için kutsal projelerdir :)

Daha ne kadar söylemekten çekineceğim bilemiyorum. Php ye karşı daima mesafeli durmaya çalışan, hatta sırf bu yüzden nice elverişli imkanı kullanmayan ben, 2007 nin başlarından itibaren aslında onu fanatik olarak savunacak kadar, savunur hale gelmişim. Daha doğrusu eşiğindeyim.

Eminim ki "php ye mesafeli durmak" çoğu kişiye saçma gelecektir. Gelmeli de. Evet, şu anda usb belleğimde bir wos server çalışıyor ve kişisel notlarımı onun üzerinde çalıştırdığım bir mediawiki üzerinde tutuyorum. Mediawiki yazılımını çok seviyorum. Bir şekilde kullanmaya başlamışım bile. Yıllardan beri, bazı durumlarda tercih edilebildiğini, ancak ideal bir yazılım mimarisini bize sunmadığını söyler dururdum. Peki ideal yazılım mimarisini sunan çok çok nesne yönelimli diller acaba neden yaygın değil? Yaygın yaygın olmasına ama onun kadar tercih edilmiyor değil mi? Ben şu tip bir tablo hazırlayıp, neyi neden tercih ettiğimi, hangi dilin neden ve hangi şekillerde üstün olabileceğini belirleyen kriterler oluşturmaya başladım. İstiyorum ki kendi dar, kısıtlı bakış açımdan kurtulup gerçekleri görebileyim.

• Modülerlik
• Köklü ve tercih edilen bir dil olması
• Tercih edilen bir paradigmaya (nesne yönelimi gibi) sahip olması
• Geniş destek verilmesi
• Farklı ürünlerle çalışabilmesi
• Ucuz olması
• Arkasındaki kütüphanelerin gücü
• Daha önce görülen eğitimin o dile zemin oluşturması veya yakınlık duyulması

Daha buna ekleyecek maddelerim var şimdilik bu şekilde yarım olarak dursun.

Bu güne kadar takip ettiğim sitelere, mail gruplarına wiki lere bakıyorum da.

En önemli kriterim o bilgi kaynağının, günlüğün vesairenin ne kadar hareketli olduğuymuş.

Bir de kendi siteme bakıyorum, kendi kriterlerimle bir çelişme var.

Neyse.

Bu arada quirksmode.org çevirisine hafiften başladım:

http://wiki.ceviz.net/index.php/Quirksmode.org_-_%C4%B0%C3%A7indekiler

Çeviri sürecinde yardımcı olan arkadaşların çıkacağını umuyorum.

Mono bizim için ne kadar kullanışlı olabilir?

Bir x86 assembly e-kitabında gözüme takılan ingilizce bir ifade vardı. Kişisel bilgisayarların çoğunun x86 türevi olduğunu (intel in piyasaya hakim olduğunu), söyleyip diğer op code ları kim dikkate alır manasına "who cares?" diyordu. Bu kodlar her işlemcide çalışmaz ama kimin umurunda?

Sonra bu zihniyete assembly ile winapi ye ulaşmayı anlatan dökümanlarda gördüm. Çok yüksek performanslı windows uygulamaları geliştirilebileceğinden bahsediyor, ancak tek bir işlemci ve tek işletim sistemi (veya işlemci ailesi ve işletim sistemi ailesi)

Sadece internet explorer da çalışan, sadece netscape navigator de çalışan js komutları da bu zihniyetin ürünüdür. Ne zaman pazar payları daralsa standartlara sarılıp, güçlendiklerinde nasıl olsa herkes bana uyuyor, öyleyse bildiğimi okuyayım mı diyorlar?

Yoksa biri daima önden gidiyor, diğerleri onu takip mi ediyor? Ben bunu iki şekilde de yorumlayabilirim. Ajax, remote scripting hakkındaki yazımda belirttiğim gibi ie 5.5 e konulan ve standart olmayan xml nesnelerinin türevleri bugün aynı arayüzü gerçekleştirdiği için halen kullanılıyor.

Mono kodlarını az-çok inceledim, dökümantasyonu zayıf ancak bire-bir çalışma imkanını büyük oranda sağlamışlar. Şu şekilde bakıyorum alternatif .net implementasyonlarına: Önceden piyasanın hakim tarayıcısı Netscape vardı, bir de onun rakibi Internet Explorer. İkisine de uygun javascript kodu yazabilmek bir maharetti. Bugün ise nesnelerin kullanımından efektlere kadar javascript kütüphaneleri var.

 Yazarken mümkün olduğu kadar taşınabilir kütüphaneleri tercih edeceğim, bazı önceden yapılmış projeleri de taşımaya, çeşitli I/O işlemlerinin linux karşılığını öğrenmeye çalışacağım. Asp.net uygulamalarının taşınması daha kolay oluyor.

Silverlight hakkındaki görüşler

Azer Koçulu sayesinde Silverlight hakkındaki yanlış görüşlerimin çoğudan ayıklandım. Düz bir xml gelecek, javascript ile kolayca etkileşebilecek, kod editörleriyle düzenlenebilecek ve formatı açık olacak. Bu gerçekten büyük bir vizyon. Kaynak kodunun görünebilmesi, onu html kadar iyi bilinir hale getirir mi bilemem ancak onun için yapılacak araçların sayısını oldukça arttıracağını düşünüyorum.

Şöyle de bir tahminim var, eğer açık kaynak yapmaz da standardını açık yaparsa o standardı ms in desteklemediği platformlarda destekleyenler daha hatasız, daha hızlı yorumlayıcılar üretebilir. Bu trajikomik olur.

Ajax, dhtml frameworks 

Bu konuda bir javascripti sayfaya entegre etmek için en doğru yolun;

1. Nesnenin oluşturduğu olayın
2. Nesnenin kendisinin

parametre olarak atandığı bir olay yöneticisine aktarılmasından ve bu olay yöneticinin nesneye bağlanmasının kod içinde değil kodun dışında nesne bulunarak iliştirilmesini düşünüyorum.  Ki bundan şu adreste  http://en.wikipedia.org/wiki/Unobtrusive_JavaScript bahsedilmiş.

asp.net in yapısı ve diğer cgi tabanlı işlere göre üstünlüğünü hep abartmışımdır biraz. Fanatiklik mi diyelim artık buna, yoksa "kuzguna yavrusu şahin görünür" diye mi açıklamalı? Yazdığım kodları gözden geçirdiğimde, gerek benim .net framework ün istediği standartlara tam uyamadığım için, gerekse aslında en ideal mimari yapı asp.net yorumlayıcısı tarafından render edilemediği ama işlerin bir şekilde yürümesi gerektiği ve kodların araya sıkıştırılması sonucu, tam modüler bir yapıya halen kavuşamamışım. Ve sağda solda reklamı çıkan Dundas Upload, netadvantage chart gibi bileşenleri yazmak için takip edilmesi gereken süreç, tıpkı eski perl scriptlerini yazmak için gereken süreç gibi geliyor bana. Bu yüzden bu çelişkiye yeninin içindeki bu eskiye şaşırmaktayım daha geniş bir bakış açısından baktığımda.

Javascript kodlarının kontroller içine gömülmesi : Tasarım zamanında müdahale edilemeyen Repeater, DataList, DataGrid ve GridView gibi bileşenlerin her satırına veya her öğesine ItemDataBound veya RowDataBound olayı ile erişip, onların özelliklerine js eklemek, örneğin memnun olmadığım şeylerin başında geliyor. asp.net 3.5 örneklerinde yazılan js örneklerinde (sender,eventargs) şeklinde bir göndermeye rastladım. Acaba, biz kontrolün render edilme şeklini tahmin ederek, onların içine gerekli olayları sonradan iliştirip, js ile aspx kodlarını birbirinden iyice ayırabilir miyiz? Yapı itibarıyla her cihaza farklı render çıktısı verdiğinden (en azından teorik olarak böyle) bu hareketten çekinmekteyim.

Javascript kodlarının <body> düğümü içine yazılması : Master Pages çıktı çıkalı bu tür hatalı örneklere rastlamaktayım. Ancak bunun çözümü basit. <head> içinde ayrı bir ContentPlaceHolder tanımlayıp, onun içinde CSS ve js kodlarımızı yerleştirebiliriz.

CSS veya Temalar : App_Themes ile birlikte nesneye iliştireceğimiz CSS class(ları) ve özellikleri kodun içinden ayıklanmış durumda. Bu durumdan çok memnunum. Ancak nesnenin ClientID değerini <%%> bloğu olmadan elde etmenin bir yolu olmalıydı diye düşünüyorum.

Platform anlayışı, (dil & kütüphane ayrımı) : Python un sloganı olan "batteries included" anlayışının bir benzeri bizde de var. Madem asp.net kullanıyorsun, o halde senin kullanacağın kütüphane bellidir? Common Type System nedeniyle aynı tipleri paylaşan tonla (ama pratikte iki adet C#, VB) dil var. Bu çok kullanışlı bir şey olsada gittikçe kullanılan kütüphanelerin  her  yeni  sürümle birlikte kullandığımız platforma eklenmesinin bazı sakıncaları olduğunu düşünüyorum. Nedir bunlar?

• "Platformumuzun" boyutu şiştikçe şişiyor.
• Platformumuzu başka işletim sistemlerine taşımak (port) isteyenlerin işi artıyor, zorlaşıyor.
• İdeal mimariden (sapla samanı, markup ile js i css i ayırmamak mesela) uzaklaşma tehlikesi doğuyor.

.net framework 1.0 dan bu yana, şu ünlü /bin klasörüne atılan assembly lerin otomatik olarak entry point inin bulunduğu ve üçüncü parti kütüphanelerin çalışmaya hazır hale gelmesi gibi büyük bir nimet var elimizde buna karşılık. Ancak bu doğal koda (native code) çağrı yapmayan kütüphaneler (mscorlib.dll harici dll ler) için geçerli.

Eğer biz, asp.net kullanıyor ve onunla kodluyor isek, (bence) kodlama konusunda bir takım prensipler belirlememiz gerekli. Öncelikle kullandığımız platforma, platform gözüyle bakmamız gerektiğine inanıyorum. Pazarlama amaçlı "her yerde çalışabilir" sloganlarını ancak biz gerçekten işler hale getirebiliriz, tabii eğer tercihimiz bu ise veya ileride bunu düşünüyorsak şimdiden bazı alışkanlıklarımızı değiştirmemiz faydalı olacaktır.

Haftaya yazmayı planladığım bir sonraki yazıda: 

• Mono bizim için ne kadar kullanışlı olabilir?
• Silverlight hakkındaki görüşler (Burada Azer Koçulu nun bir sunumundan da faydalanacağım)
• Ajax kütüphaneleri ve dhtml frameworks, nasıl entegre edebiliriz? 

Not: Bu yazı şu anda ceviz.net ana sayfasında  http://www.ceviz.net/ajax-remote-scripting_a1095.html  adresinde de yayınlanmaktadır.

Bu günkü yazımızda size remote scripting i anlatmayı planlıyorum, remote scripting, bir html sayfasının yeniden yüklenmesine gerek kalmadan yayınlandığı sunucu ile (evet sadece yayınlandığı sunucu ile, bu kısıtlama güvenlik sebebiyle konulmuştur, ama aşılabilir.) iletişimini sağlayan kodlama kalıplarıdır.

Google ajax ın reklamını yapmadan çok önce de ajax denilen şey remote scripting adı altında yapılıyordu, ama ne zaman ajax meydana çıktı javascript in yıldızı parladı, sinir bozucu java - javascript ayırt edememezliğinin yanına bir de ajax ile dhtml ayırt edememezliği çıktı.

Bildiğim kadarıyla size remote scripting in (rs, ajax ı kapsar bu yüzden ondan bahsedeceğim) tarihçesini kendi bakış açımdan anlatayım:

• Remote scripting ile ilk tanışmam www.yazgelistir.com dan bir arkadaşın sadece ie 5.5+ da geçerli olan <xml> elementiyle sunucu ile iletişim kurmasıyla başlar. (Şu an o site üzerindeki aramalarım ne yazık ki bir sonuç vermedi, yazıyı yazanın ismini burada anmayı ve yazıya link vermeyi çok isterdim rastlayan biri varsa veya o yazının yazarı şu an bunu okuyorsa bana bildirebilir, o yazı zamanının çok ilerisinde bir yazı idi çünkü) **Ekleme : Yazı sayın Turgut Haspolat tarafından yazılmış.**
  
• O tarihlerde .net 1.0 dan 1.1 e yeni yeni geçiyordu, asp.net sayfalarında SmartNavigation diye bir özellik vardı peki ne yapardı bu SmartNavigation? kendine özgü bir js kodu ile sayfanın içinde bir IFRAME elementi oluşturur ve sayfanın içine ekler, request i o iframe içinden yapar ve dönen yanıtı (IFRAME elementinin outerHTML özelliği) o IFRAME i içeren sayfaya (normal sayfamız) yansıtırdı, böylece sayfanın postback işlemi anlaşılmazdı. Ama bu özellik sadece IE ailesiyle çalışıyor, çünkü outerHTML standart bir özellik değil.
• Microsoft.XMLHTTP ve Msxml2.XMLHTTP2 vardı ama tüm tarayıcılarla çalışmadığı için popüler değildi. Açıkcası Mozilla, Mozilla Firefox olana kadar bu nesnelerden haberi olan kişi sayısı az idi.
• Sanıyorum XmlHttpRequest nesnesine ilk desteğini veren tarayıcı Safari idi, yanılıyorsam düzeltin ama onunla ilgili ilk dökümanlara apple sitesinde rastlamıştım.
• Firefox 1 in yaygınlaşması ve google ın gmail hizmetinde bu nesneleri kademeli olarak kullanması ayrıca "google suggest" adını verdiği daha aradığımız şeyi arama kutusuna yazarken sonuçların "ajax" ile sorgulanması ve hemen metin kutusunun altındaki bir (layer, div) içinde gösterilmesi söz konusuydu. Eh google bunu javascript (hem de anlaşılmaz yapmaya çalıştıkları bir javascript) ile yapınca herkes bunu merak edip sağda-solda bloglarda decode edebildiği ve mantığını anlatabildiği kadarını, yayınlamaya başladı.
• Sonra şu kalıp (ki sanırım çoğu ajax kütüphanesinin temel kalıplarından biridir.)  http://jibbering.com/2002/4/xmlhttp.js

• Daha çok php programcılarının kullandığına şahit olduğum sajax, xajax gibi kütüphaneler.

• Atlas ın geliştirilmesine başlandı (şimdiki adıyla asp.net ajax)
• Anthem ile tanıştık. ajaxpro, anthem gibi üçüncü parti kütüphaneler (ki anthem kendi içinde dosya upload ederken iframe kullanmaktadır) gördük.

Gerek cevizde gerekse diğer yerli ve yabancı sitelerde çokca rastladığım bir hataya, ajax ile javascript ayrımınının yapılamamasına karşılık, şimdi bir çizgi çizmek gereklidir diye düşünüyorum bu çizgi ajax denilen şeyin sadece sunucudan veri alınan durumlar için geçerli olduğunu savunduğumdur. Gelin örnek iskelet kod üzerinde birlikte inceleme yapalım.

Örnek iskelet kod olarak şunu kullanacağım : http://forum.ceviz.net/showthread.php?t=17334

Üye olmayanlar kodu şuradan indirebilirler (aslına sadık kalmak için içindeki saçma sapan açıklamaları silmiyorum)
http://www.ceviz.net/ceviz_main/uploads/uye7346/xmlhttp.zip

var xmlhttp = new_xmlhttp();/**alacaklı haciz koymuş bekire of offf*/

Bu kod xmlhttp nesnesini kurar. Nesne öncelikle Msxml2.xmlhttp ve microsoft.xmlhttp nesnelerine kurulmaya çalışır, eğer kullanıcı ie çalışmıyorsa bu kısımları atlayıp en sondaki XMLHttpRequest oluşturulup bu nesneye atanacaktır.

xmlhttp.open("POST","post.asp",true);

Geriye hangi nesne dönerse dönsün bu nesnelerin gerçekleştirdiği arayüz aynıdır. Aynı metot ve özelliklere sahiptirler. Bu satırda kullandığımız metot, "open" ve ilk parametresinde o nesne vasıtasıyla çağıracağımız dosyayı hangi fiil ile çağıracağımızı belirtiyoruz. Bu örnekte POST kullandık, asp de POST un karşılığı post ile gönderilen verilerin alış şekli Request.Form ile olmaktadır, eğer GET kullansaydık, Request.QueryString ile alacaktık. İkinci parametre yanıt döndürecek olan sayfanın ismidir.

Üçüncü parametre bu nesneyi kullanış biçimimizin asenkron (eş zamanlı olmayan) olup olmayacağını belirler. Ne işe yarar eşzamanlılık? Eş zamanlı olmayan kod, bir çeşit thread gibi, değişik bir kapsamda çalışır ve event tetikler (işini bitirdiği zaman) ama eş zamanlı kod, yanıt döndürene kadar scriptin çalışmasını bekletir ve scriptin donmuş hissi vermesine yol açar.

(Asynchronous javascript and xml) deki A harfine karşılık gelir, anlayacağınız ajax ın a sıdır :-)

Neyse konuya dönelim, aradaki iki satırı atlayıp dikkatinizi

xmlhttp.onreadystatechange

Satırına çekmek istiyorum bu bir olay tutacağımı desem olay yönetici mi desem, ingilizcede "event handler" denilen nesnedir işte. Asenkron olan xmlhttprequest nesnesi her durum değiştirdiğinde (siz onu yolladıktan sonra dökümandan dönen yanıta göre status bayrağı değişir. 200 kodu OK anlamında olduğundan yanıtın döndüğünü anlayıp, işlemlerimizi yapıyoruz.

Kaynakça :

• Ajax in Action (Manner) (Manning)
• www.yazgelistir.com
• http://developer.apple.com/internet/...mlhttpreq.html

• http://www.sitepoint.com/forums/showthread.php?p=1618991#post1618991

Levent Kırca'nın bir skecini halen hatırlarım, vatandaş bilinmeyen numaraları arıyordu da günlük hayattaki dertlerine karşı "bilinmeyen bir numara" araştırıyordu. Neyse ki bizim bu kelime grubuna yüklediğimiz anlam biraz daha farklı, bir kenara not edip te üzerinde çalışacağım konuları veya kafamdan şu sıralar nelerin geçtiğini ve hakkında henüz tam bilgi sahibi olmadığımı hissettiğimi çıkartacağım bir liste olacak ki bunun bir benzerini Muharrem Taç yapmıştı, ben de ondan aldığım bir özentiyle kendi listemi çıkartıyorum:

1. Design Patterns
2. Javascript frameworkleri ve ajaxpro nun birlikte kullanımı
3. Sql server 2000 örnek sorguları
4. Visual Web Developer hakkında bir inceleme yazısı
5. Unobtrusive JavaScript
6. Starter kits hakkında bir inceleme
   1. Personal Web Site
   2. Classified ads
   3. The beer house