Emacs Web Geliştirme Ortamı Devam

Aycan iRiCAN

2007-05-24 12:21:19 UTC

An itibariyle Emacs Wiki sayfasına da ekledim.
Aycan Bey ilginiz ve olumlu yorumunuz için teşekkür ederim. Ben bu
konuda biraz farklı düşünüyorum.
Topluca Web 2.0 diye adlandırdığımız ; Ajax - Javascript etkileşimiyle
web uygulamaları oluşturma konsepti bence programcı ile tasarımcı
Artık görsel yönden ne kadar güçlü tasarım yaparsanız yapın;
kullanıcıyla etkileşim halinde olmazsa; webde çığla büyüyen örneklere
bakan müşteriler ve kullanıcılar; yapılan çalışmayı yetersiz
bulacaklardır. Kullancıyla etkileşim için de; Temel web kodlama
altyapınız olmalıdır; içeriği sunumdan ayırmayı; css-html-javascript
üçlemesini iyi kodlamayı becerebilmeniz gerekir. Bu da tasarımcıyı bu
işe dahil edecek bir süreçtir.
Adobe firması bile Spry diye lisansı görece serbest teknolojileri web
geliştiricilerinin kullanımına
açtı:http://labs.adobe.com/technologies/spry/ adresine bakın. Ortalık
Framework-Library diye kaynıyor. Programcılara KISS (Keep it Simple
Stupid) and DRY(Don't Repeat Yourself) prensipleriyle; mevcut
sunucu-istemci taraflı frameworklerle kolayca çalışabilecekleri empoze
ediliyor.
Bu yaklaşımlar küçük projelerde tasarımcıların da; frameworklerle
kendi işlerini görebilecekleri anlamına geliyor. Eski tasarım araçları
artık yetersiz kalıyor. Dreamveawer en yeni sürümünde bile bir
"Firebug" eklentisinin yaptıklarını yapamıyor. Ortalık herzamankinden
güçlü ve işlevsel CMS'lerle dolu. Ben şahsen işlerimi bu şekilde
halletmeye çalışıyorum. (Bu yüzden ne tasarımcıyım ne de programcı:)
Bu durumda ister istemez tasarımcı bile olsa herkes elini koda atmak
zorunda. Yapabileceği en iyi şeyde kolay kullanabileceği, işlevsel bir
metin editörü ile html-css-js kodlayıp, Firefox ile test etmek:)
Mac makinalardaki Textmate bu yüzden patladı; Tüm bilgi veren
Screencastlerde en çok göreceğiniz kodlama ve tasarım unsurları
MacOSX-Textmate ve Firebug:)
Ben sadece eski tüfekler metin düzenleyicilerine de emek verildiğinde
istenilen editör işlevselliğinin her platformda; özellikle web
kodlamasında fazlasıyla yakalanabileceğine bir örnek vermeye çalıştım;
kendim zevkle kullanıyorum...Win32 ortamında temiz screencast üretmeyi
becerdiğimde bu tür örnekleri de ekleyip buradan haber verme
niyetindeyim...Özellikle merak ettiğiniz modlar varsa onları
belirtirseniz, tanıtımda öncelik sahibi olurlar.

Beni yanlış anlamanızı istemem. Bahsettiğiniz araçları kullanıyoruz ve
sizin paylaşımlarınız ile bu araçlardan daha iyi faydalanıyoruz. Ancak
ben tasarımla ilgilenen insanlardan yıllardır ufak tefek de olsa kod
yazmalarını beklerken, bu ısrarlarımın yersiz olduğuna tanık oldum.
Tasarımcılar bazen acemilikleri ile, bazen de sanatsal bakış açılarıyla
üretimlerini tamamen görsel kaygılar üzerine yoğunlaştırıyorlar. Böyle
de olması gerektiğini düşünüyorum. Aksi endüstriyel bir tasarım sürecine
ve belki de bir miktar mühendisliğe de giriyor ki böyle bir sonuç
yaptığımız web sitelerinin "ciddi anlamda tasarım çalışmaları var mı?"
sorusuna götürüyor beni.

Bu düşüncemi desteklemek için var olan ürünlerin ve bunların
çıktılarının ne kadar birbirine benzediğini örnek verebilirim. Biz
yıllardır sütunlarla, menülerle desteklenmiş sitelere tanık olduk. Çünkü
kaygılarımız görselden uzaktı. Tasarım deyince bilgisayar ile insan
arasındaki etkileşimi anladık yıllarca. Oysa bunun ötesinde birşeyler
yapmaya çalışanlar vardı. Hoş olanın ötesinde birşeyler var mıdır?

Gerçek tasarımcılarla çalışabilecek yöntemleri bulmamız gerektiğini
söylemeye çalışıyorum aslında. Bunun yönteminin de icra edene teknik
eğitim vermekten geçmediğini düşünüyorum.

Sizin verdiğiniz UCW platformuna dayalı örneği inceledim. Mesela
http://mootools.net - Mootools diye bir javascript kütüphanesi; aynı
sizin yolunuzla javascript içinden Dom ve Css üretimi ve etkileşimine
imkan veriyor. Bu anlamda uygulamanız güçlü. Ama frameworkler de en
çok tercih edilen özellik; uygulama mantığının, veritabanın ve sunumun
ayrı katmanlarda çalıştırılması.(Sizin de bildiğiniz
Model-View-Controller Patterni) Bu programcı-tasarımcı ayrımını ve
işbirliğini kolaylaştırıyor.
Sizin uygulamanız bileşen tabanlı ve tüm bu uygulama üretim mantığı
içiçe anladığım kadarıyla(yanlış anlıyorsam lütfen beni düzeltin.)
Bu anlamda programcı-tasarımcı ayrımını tamamen ortadan kaldırıyor
gibi göründü bana...Yani genel yaklaşımdan farklı bir yol.

MVC'yi ben tasarımcı ve programcının ayrılması olarak görmüyorum, bunlar
zaten ayrık olgular bence. Uygulamanın görsel çıktısı, modeli ve
bunların etkileşimlerinin birbirini etkilemeyecek şekilde kodlanabilmesi
olarak algılıyorum. Bu şekilde düşünülürse geliştirmekte olduğumuz
uygulama sunucusu ve bunun kullandığı kütüphaneler işlerini görüyorlar.
Bir senaryoyla örnek verebilirim.

Bir ana sayfa tasarlarken, öncelikle tasarımcının her türlü aracı
kullanarak (kağıt kalemden, bilgisayar destekli çizim programlarına) bir
konsept ortaya koymasıyla başlıyoruz. Daha sonra konsept tasarımın
uygulanabilirliği üzerine düşünüyor ve gerekli durumlarda tasarımcıdan
güncellemeler talep ediyoruz. Bu tasarımı bir makina sunacağı için
sayısallaştırmak, işleri kolaylaştırmak için uygulamayı soyutlayarak
modellemek ve bir akış mantığı kurmak gerekiyor. Bunu da lisp
programcıları sürdürmeler ve nesnel programlama ile yapabiliyorlar.

Bir giriş kutucuğu (login box) düşünecek olursak. Bu sayfanın soyut
modelini nesnel olarak bileşenlerle aşağıdaki gibi kurulabiliyor.

(defcomponent login-box (ajax-widget)
((username ...)
(password ...))
(:default-initargs :dom-id "login-box"))

(defmethod render (lb login-box)
(<:form :id "login-form" :method "post" :action "#"
(<:input :type "text" :name "username" :id "uname")
(<:input :type "password" :name "password" :id "pass")
(<:input :type "submit" :value "giriş" :action (if (authenticated?
login-box)

(call 'secure-main))))

Buraya kadar bileşeni ve bileşenin nasıl görüntüleneceğini yazdım. HTML
çıktıyla birlikte giriş tuşunun ne işlevi olduğunu da ekledim. Ancak
dileyen programcı bu işlevi aşağıdaki gibi de verebiliyor (belirteyim,
benim tanıdığım programcılar bu ayrımı kullanmayı tercih etmiyorlar).

(defmethod render-javascript (lb login-box)
(ec :element "login-form" :event "onsubmit" :action ....))

(defserver-action submit-login (lb login-box)
(server side code...))

(defclient-action submit-login (lb login-box)
(client js code...))

Burada tanımlı javascript çıktısı elbette sayfanın içerisinde HTML ile
birlikte girişimli olarak üretilmiyor. Tanımladığımız her javascript
controller.js adlı kontrol dosyası olarak üretilerek HTML sayfamıza
bağlanıyor.

HTML çıktının nasıl bir görsel ile destekleneceğini ise aşağıdaki gibi
programlayabiliyoruz. Burada programlayabilmekten kastım, oluşturulacak
CSS çıktısının dinamik olarak (sunucu tarafındaki modele de bağlı
olabilerek) oluşturulabilmesi.

(defmethod render-css (lb login-box)
(<:css "#login-box"
:background-color (get-user-color (current-user))
:color "black"))

Gene buradaki CSS çıktısı da sayfamıza style.css adıyla bağlanıyor. HTML
içerisine girişmiyor.

Ayrıca bütün kodlamayı dikey olarak lisp ile yapabilmemiz, gelişmiş
özellikleri de kullanabilmemize olanak veriyor. Burada her problemi
çözen bir şeyden bahsetmiyorum. Sadece geliştiricilerin daha hızlı
uygulama geliştirmesine olanak sağlamaktan bahsediyorum.

Bu örneklerle siz nasıl bir şeyler beklerdiniz? Sizin karşılaştığınız
problemler neler ve nasıl çözümler önerebilirsiniz? Yorumlarınızı
bekliyorum.

Sevgiler...

--
Aycan iRiCAN
C0R3 Computer Security Group
http://people.core.gen.tr/~aycan.irican/