Made With Notepad Campaign 

Uzunca bir süredir, C# yazıyorum. Asp.net ile kullanmak için "Class Library" türünde projeler oluşturuyor, bunları projeye dahil ediyorum. Sayfalarım da zaten Page türünden bir nesne. 

Daha önceki yaptığım işlere nazaran (daha önceki projelerim genellikle katalog türü siteler ve sipariş verilebilen küçük firma siteleri idi) hayli büyük bir projeye ikinci girişimimi gerçekleştireli epey oluyor. Şu günlerde, özellikle son birkaç haftada eskisi kadar faaliyet gösteremiyorum internet üzerinde. Geçtiğim günler içinde, eğer özeleştirisini yapacak olursam oldukça aptalca kararlar vermiş olduğumun farkına vardım. Meslekte benden daha tecrübeli olan ve bir ağabeyimin tavsiyesiyle bilgisayarıma Visual Studio 2005 yükledim. Aynı zamanda diğer küçük projelerim için de Visual Web Developer 2008 ile Sharpdevelop 2.2 yi koordineli kullanmaya başlamıştım.

Aynı kodu hem bir metin editöründe, hem de bir IDE ile çıkartabiliyorsam metin editörü kullanmanın bana avantajı nedir? Kocaman bir hiç değil mi? Büyük dosyaları düzenlemek ve içinde değişiklikler yapmanın kolay olması durumu dışında metin editörü kullanmanın bir mantığı yok ki. Bunu benim anlamam neden bu kadar uzun sürdü, sanırım daha önceden girdiğim projelerin büyük olmayışından. Böylece Made With Notepad Campaign den ayrılmış oluyorum. Sonuca giden yolda beni en hızlı götüren vasıtaları kullanmaktan çekinmeyeceğim. Metin editörleri de tabii buna dahil :-) 

Derleme zamanı hataları (compile time errors)

Hangi dilde yazdığımızdan bağımsız olarak, hataların ortaya çıktığı zamana bağlı olarak sınıflandırılması gibi bir alışkanlık vardır. Eğer biz hatayı projeyi (veya kaynak kodunu) derleyiciye gönderirken alıyorsak bu bir derleme zamanı hatasıdır. Güçlü tipli bir dil ile (C#, Java gibi) uygulama geliştiriyor iseniz derleme zamanı hataları gidermeden projeyi derleyememeniz gerekir. Typed dataset, güçlü tipler vs. bir çok özellik hatayı hemen almanızı sağlar.

Burada altın kuralımız şu : Hatanın farkına ne kadar erken varıyorsak, o kadar iyi. Bu anlamda derleme zamanı hataları en iyisidir.

Çalışma zamanı hataları (runtime errors)

Bu hatalarla genellikle geliştirme yaptığımız dil, belli yeteneklerden yoksun ise ve bunu dış kaynaklardan karşılıyorsa o noktalarda karşılaşıyoruz. Çok bilinen bir örnek olarak SQL sorgularını gönderdiğimiz zaman. SQL sorgusu veya Stored Procedure adı alelade bir string değil midir? Bunun çalışma zamanında hata vermesi ancak kodun işleyişinin o noktaya gelmesiyle anlaşılacağından çalışma zamanı hataları kötüdür.

Çalışma zamanı hatalarını sevmiyorum. Eğer ben bir tablodan veri çekiyorsam ve tablonun ismi değişti ise beni uyarabilmeli geliştirme yaptığım dil. Veya ben, araya bir ek katman yerleştirme pahasına, çalışma zamanı hatalarını derleme zamanı seviyesine çekebilmeliyim. Bu hataların daha çabuk farkında olmamı sağlayıp program yazma hızımı arttıracaktır.

MS in her şeyi IDE ye bağlama fikrinden nefret etmem belki de boşunaydı. Her şey tek merkezden yönetilince hataları yakalamak daha kolay olacaktır.

Güçlü tipin önemi

Dinamik dillere zaman zaman sempati duyuyorum ancak, güçlü tiplerin gerçekten hata yakalamayı kolaylaştırması (derleme zamanına çekebilmesi) büyük bir avantaj. Bu dinamik dillerde TDD (Test Driven Development) ile aşılabilir. Madem kod o noktaya erişmeden hata olup olmadığını anlayamıyoruz o halde kodun o ihtimali de denemesini sağlarız diyebilirsiniz. Nitekim Dive Into Python içinde roma rakamı çeviren betik geliştirilirken ufaktan çevik yaklaşıma giriş yapılmış.

Ama güçlü tipli dillerde aynı zamanda çevik yaklaşım kullanma şansı da var. O cephede tek eksiğim sanırım tanımlanabilecek en düşük sayıda nesneyi tanımlamak. En iyi pratikleri (Design patterns) inceleyip anlamak, anlatmak.

Son haftalarda bunların üzerine düşünüyorum. 

I writing a patch for recently finished admin panel, a product entry form.

I used Anthem in its front face and admin panel for user attraction. But FCKEditor's update status being a problem. I decided using Anthem_PreCallBack and Anthem_PostCallBack events in js so update the textarea (asp:TextBox) value with js do i can use at server-side this value. Sounds good, eh?

First, I use this way:

http://www.fckeditor.net/forums/viewtopic.php?f=6&t=4222

 But Firebug alerts, hmm this way doesnt work, i cannot understand why. How strange. How sad.

Then, I use more standard way: API there:

http://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/JavaScript_API

Example:

-----------------------------------------------------------------------------

function Anthem_PreCallBack()
 {
    //document.getElementById('<%=textboxSample.ClientID%>').value =
    //frames[0].objContent.DOM.body.innerHTML;
    var oEditor = FCKeditorAPI.GetInstance('<%=textboxSample.ClientID%>');
    document.getElementById('<%=textboxSample.ClientID%>').value =
        oEditor.GetHTML(true);
}

function Anthem_PostCallBack() {
    //alert(document.getElementById('<%=textboxSample.ClientID%>').value);
    //frames[0].objContent.DOM.body.innerHTML =
    //document.getElementById('<%=textboxSample.ClientID%>').value;
    var oEditor = FCKeditorAPI.GetInstance('<%=textboxSample.ClientID%>');
    if(document.getElementById('<%=textboxSampleIsEditing.ClientID%>').value.length>0)
    {
       oEditor.SetHTML(document.getElementById('<%=textboxSample.ClientID%>').value);
    }
    else
    {
        oEditor.SetHTML("");
    }
}

-----------------------------------------------------------------------------

textboxSample is our primary textbox. Other (textboxSampleIsEditing) is for we are in editing status. For example, if we are editing a row in database we dont want Anthem_PostCallBack reset the fields value. I setting this textboxSampleIsEditing value for different from empty string than js dont reset other textbox, get it? Yes its sucks but i cannot run other ways.

Hope this helps. 

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?