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?