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? 

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

   
   

Yenilen takımın teknik direktöründen "önümüzdeki maçlara bakacağız" sözünü duymaya alıştıysanız, o zaman benden duyduğunuz zaman da garipsemeyeceksiniz demektir :) Bu alan adı altında daha önceki sitelerimi görenler, kişisel site yapımı konusunda ne kadar farklı (ve yanlış olduğunu yeni farkettiğim) bir yaklaşıma sahip olduğumu bilirler, statik html ile siteyi yapacak, sitede hiçbir görselliğe yer vermeyecek ve kesinlikle hazır kod kullanmayacak kadar işi ileri götürmüştüm ki sonradan bu yaklaşımların hepsinden caydım.

Neyse konuya dönelim, "önümüzdeki maçlara bakacağız" derken neleri kastettiğime kısaca bir göz atalım:

• http://wiki.ceviz.net (şu anda http://wiki.ceviz.net ) adresindeki DOM Level 1 referansının bir şekilde toparlanması gerekiyor.
• Ceviz.net teki asp ve asp.net e meraklı arkadaşları bir araya toplamalı uygun bir vakitte.
• Bir köşede unutulup kalmış  irc://irc.freenode.net/#asp-tr kanalının bekleyen işleri yapılmalı o kanal aktifleştirilmeli
  • Kanala bot yazılacak
  • Loglar düzenli olarak ayıklanıp, yayınlanacak
• #dotgnu geliştiricileriyle yeniden irtibat kurulacak
• İngilizce içeriğe ağırlık verilecek ve çeşitli blog topluluklarına rss verilecek.

 (13 Kasım 2007)

İlerlemeyi ve bu konudaki detaylı vizyonumu sizinle buradan daha sonradan da paylaşacağım. 

(14 Kasım 2007 Eklemesi)

• Eski sitedeki içerik hedeflerini ve ilerleme için bir tabloyu da bu yazının içine dahil etmeliyim.