Masaüstü ve Web programcılığı arasındaki farklar
Bir arkadaşımın (web geliştirme uzmanı), patronunun (delphi programlama kökenli) verdiği bir görevinin ardından, gelişen tartışma bu bilgiyi gerektirmiş, hani çok öyle derinine inebileceğim bir konu da değil ama aklıma geleni `blog`ladım işte..
Ana farklar:
- HTTP Stateless’dır.: Eski mainframe mantığıyla çok benzer çalışır, pratik anlamda hiçbir aksiyon, bir önceki aksiyonla haberleşme halinde değildir ( stateless nedemektir, geniş anlamı için http://whatis.techtarget.com/definition/0,,sid9_gci213051,00.html ) Aslolarak herşey, istek başlıkları dediğimiz GET (görme), POST (gönderme) methodları ile döndürülür. Cookie başlık bilgisi çok sonra bu haberleşme sürecine kıyısından katılacak, günümüzde büyük uygulamalarda yapıştırıcı göreviyle neredeyse merkeze oturacaktır.
- Eskidir, yapı itibariyle düşük seviyeden programlama gerektirir: Yaygın olarak kullanılan ‘oturum açma” , “çıkış yapma” gibi özellikler acılı süreçlerden geçmiş, hala tam anlamıyla standardize olamamıştır. İlk programlama gerektiren interaktif web sayfası, perl’i alınan bir parametre ile çıktı yaptıran daha sonra adına “cgi-bin” denecek, perl veya c rutinleriyle çalışan düz yazı üreten uygulamalardan ibarettir. Bunlar, işleyiş standartları çok belli olan HTTP protokolüne yapılan dışarıdan müdahelelerdir ve web programlama kabuğu burada oluşur. Gelişen ve webde düz yazı işlemesine katılan PHP, Asp, .NET, Java gibi diller, aynı yolu web sunucusuyla biraz daha kısa yollardan gittilerse de, bu HTTP’nin stateless olma kuralını asla bozamamıştır. Masaüstü programcılığında, nadirliği nedeniyle bu anlaşılması zor bir kavram olabilir, bir işletim sistemine, iki aynı kullanıcının aynı anda işlem yapıp, aynı çalışma ortamını aynı anda kullanmasıyla örneklenebilir. Bu iki kullanıcıyı yapılan iki istek arasında ayırtetmek, yapılan ‘eklemeler’ olmadığı sürece imkansızdır. Şu anda HTTP protokolünde, bir ‘oturum’ inceleyicinin sunucudan aldığı bir anahtar sözcüğü, her işlem başlangıcında sunucuya geri göndermesinden ibarettir (çerezler). Kullanıcılar arasında bu kadar basit bir sisteme sahip oluşu, HTTP protokolünü bazı güvenlik sorunlarıyla baş başa bırakmıştır. Genel olarak bu sorunları ’session fixation’ ve ‘XSS’ adı altında inceleyebilirsiniz. Ayrıca, çerezlerin kullanılamayacağı alanlar (inceleyicinin olmaması ve adresten haberdar olmama durumu) olduğu için, genelde tasarlanan web uygulamasının içinde bu tanışma sürecinin de programlamasını gerektirir.
- Birbirinden bağımsız, çok parçalı ve değişkendir. Sadece geçmiş 5 yıl için,
Kullanıcı arabirimine bakacak olursak:
- Adobe Flash plugini HTML ‘in içinde (flash) ve uygulama çaplı dışında (flex) ayrı bir katman oluşturmuş,
- Son zamanlarda FLV, MPEG4 gibi video yayın standardı oluşmuş,
-VBScript yokolarak, yerini önemini eskisine nazaran uzmanlık gerektirecek kadar arttırarak Javascript’e bırakmış,
-Web’e ait grafik, tasarım, arayüz ve resim üretmek uzmanlığa ayrılmış,
-Hem arayüz, hem javascript konusunda tümleşik arayüz sistemleri çıkmış, ki ayrıca bunların da kendilerine göre uzmanlıkları oluşmuştur. (jQuery, Ext, Yahoo UI)
-CSS ile Kolay anlaşılabilir ve tanımalama bazlı, anlamsal ilişkili arayüzler oluşturmak bir uzmanlık gerektirir hale gelmiştir
-daha gider..Sunucu tarafına bakacak olursak:
-Arayüzde Javascript programlamasının öneminin kat kat artmasıyla oluşan, arkaplan-önplan haberleşme protokolleri: XML, JSON
-Gelişkin projelerde başka web uygulamalarının arkaplan motorlarıyla haberleşme araçları (REST API) : XMLRPC, JSONRPC
-İnceleyiciden bağımsız gelişme okuyucuları formatları : RSS 1- RSS 2 – ATOM
-Video ve dosyaları (görsel veya statik herhangi dosya) hızlıca ve güvenli teslimatını yapabilecek web sunucuyla haberleşme halinde ek sunucular (flash media server, lightweight http thumb sunucuları, red5, ffserver .. )
-Sunucular arası cacheleme (flat dosyalar , memcache )
-Özellikle webde çalışma için ağırlaşan veritabanları: mysql, postgre, ..
-MVC Frameworkler, Ruby on Rails, cakePHP, Zend Framework, Kohana, Code Igniter, Agavi, ..
-Çok parametreli sayfaları, arama motorları ve insanlar için güzelleştirmeye/düzenlemeye yardımcı olan sunucu modülleri (url rewrite)
–daha gider..
Minik not: Kimi .NET geliştiricileri, tersine iddia etse de, asla event driven değildir. Stateless olan hiçbir protokol, event oluşturamaz. .NET ile suni eventlar, tıpkı çerezlerle ‘oturum açma hilesi’ gibi, her sayfada bir önceki sayfaya özgü bir takım bilgileri yollayarak bildirmesini sağlar. Fakat tam bir haberleşme sözkonusu olmaz ve aslında sunucu ve kullanıcı arasında arkaplanda çok farklı bir anlaşma(azlık) vardır.
Haziran 9th, 2009 @ 2:21 am
Merhaba,
Konu ile alakasız olucak ama şunu sormak istiyorum size. Mysql ile stored procedure kullanmak hakkında önerebileceğiniz bir örnek varmı? yada bu konuda bilgi alabileceğim bir kaynak? Sıfırdan basit bir stored procedure yapıp php ile çalıştıracağım bir örnek arıyorum. Ayrıca stored procedure kullanmak nekadar faydalıdır yada zararları varmıdır. Basit bir blog yazıyorum kendimi geliştirme sürecinde, joinler ile yada diğer sql sorguları ile tüm ilişkilendirmeleri yaptığım halde stored procedure ile daha sağlıklı olacağını düşünüyorum. Ayrıca querystringleri filtrelediğim halde pdo kullandım. mysqli daha hızlı çalışıyor deniliyor. Acaba hangisi doğru yada MDB2 kullanmak mı daha sağlıklı olur?
Blogunuz mükemmel içeriğe sahip benim gibi öğrenme aşamasında olanlar için harika bir kaynak. Yazdığınız her kelime için elinize sağlık.
Haziran 9th, 2009 @ 11:45 am
Konuyla alakasız evet ama iyi oldu, çerez bi yazıydı zaten bari yorumu bir şeye yarasın :-)
1- Stored Procedure’lar: genellikle çok sorgu gerektiren uygulamalarda, sorguların bir arada toplanması ve uygulamaların basitleştirilmesi için kullanılırlar. Başlıca avantajları, performans, uygulama mantığının (business logic) ayrılması ve stored procedürlere ACCESS verilebildiğinden (örneğin kullanıcının yazma hakkı olmayabilir, ama o kullanıcıya yazma işlemi içeren bir sorgu atanabilir), yönetimi kolaylaştırmaktı. SP’ler sorguyu gönderi zamanında değil, önceden yorumlayıp, yorumlanmış sorguyu kullanarak performans artışı sağlıyor. FAKAT, yeni nesil uygulamalar artık kodun veritabanı etrafında değil, uygulama kodunun etrafında dönmesini gerektiriyor, bu yüzden SP’ler gibi uygulama kodunun haberi olamayacak bütün işlemler koda dahil edilir oldu. Buna bir örnek de url_rewrite yerine, PHP ile yazılmış routerları örnek verebiliriz. Uygulama alt yapıları geliştikçe, SP’ler neredeyse sadece performans için kullanılır oldu. Çünkü ORM gibi yenilikler bütün uygulama mantığının kodda düzgünce kodlanmasına ve kodun veri işleme mantığından haberdar olmasını sağlamakla uygulamanın yeteneklerini arttırdılar. Fakat, bir çok sorguyu tek tek göndermek, hala sorgu başına uygulamaya mal olan fonksiyon çağırma, ve çağrılan fonksiyonun işlediği performansını düşürmek bir sorun haline gelebiliyordu. mysqli ‘nin performans artışı tam da burada.
2- mysqli, birden fazla sorgunun tek bir çağırım yaparak uygulanmasını ve bu sorguların tümünün cevabının alınabilmesini sağladı. Bu da SP’nin kullanım alanını bir kez daha daralttı. Nitekim uygulama altyapısının yönetimini olabildiğince kodun içinden ve tek bir yerden yapmak uygulamanın geleceği için önemli. (bakım kolaylığı, genişletilebilirlik, vb) Bu yüzden birbiriyle alakalı sorguları birbiri ardına göndermektense, bütün sorguları hazırlayıp göndererek tek bir defada sonuçlarını almak, sorgunun çokluğuna göre uygulamayı (100+ sorgu için kimi zaman 10 kat, 20 kat) hızlandırabiliyor.
3- Stored Procedure’a bir örnek: ben SP’yi çok nadir yerlerde kullanıyorum. InnoDB’nin count yavaşlığı için önlemler almak veya bir tablodan rasgele 200 kayıdı seçip, o kayıtları başka bir tabloya aktarmak gibi:
bi-ki örnek:
– CALL photo_check(1);
CREATE DEFINER=`root`@`localhost` PROCEDURE `photo_check`(_user_id Int(10))
BEGIN
DECLARE c tinyint;
SELECT count(*) INTO c FROM user_photos WHERE user_id=_user_id AND def=’1′;
IF c=0 THEN
UPDATE user_photos SET def=’1′ WHERE user_id=_user_id LIMIT 1;
END IF;
SELECT count(*) INTO c FROM user_photos WHERE user_id=_user_id;
UPDATE users SET photo_count=c WHERE id=_user_id;
END;
–fake_online (bi uygulamada böyle bişeyi kınıyorum ama.. iş öyle buyuruyor n’aparsın :-)
CREATE DEFINER=`root`@`localhost` PROCEDURE `fake_online`()
BEGIN
DECLARE _user_id INT(10);
DECLARE done INT DEFAULT 0;
DECLARE cur1 CURSOR FOR SELECT id FROM users WHERE fake=’1′ ORDER BY RAND() LIMIT 0,75;
DECLARE CONTINUE HANDLER FOR SQLSTATE ‘02000′ SET done = 1;
open cur1;
REPEAT
FETCH cur1 INTO _user_id;
IF NOT done THEN
INSERT INTO mem_online VALUES (_user_id,UNIX_TIMESTAMP()) ON DUPLICATE KEY UPDATE lastaccess=UNIX_TIMESTAMP();
END IF;
until done END Repeat;
close cur1;
DELETE FROM mem_online WHERE lastaccess < (UNIX_TIMESTAMP()-3600);
END;
Son olarak, hangi DB wrapper hoşuna gidiyorsa onu kullan ve performansa o kadar da takılma derim, günümüzün sorunu performansdan çok yeniden kullanılabilir ve genişletilebilir kod yazabilmek – hepsinden önemlisi ve başı tabii ki insan emeği ve zamanı. Çünkü şu anda bu piyasada en pahalı şey bu, 3GHz’lik işlemci gücü veya RAM değil.
Haziran 9th, 2009 @ 5:53 pm
Çok teşekkürler. Bukadar açıklayıcı bir cevap alabileceğimi düşünmüyordum. Gerçekten ziyaretçilerinize önem verip makale olabilecek postlar yazıyorsunuz. Özelliklede son söylediğiniz “hangi DB wrapper hoşuna gidiyorsa onu kullan ve performansa o kadar da takılma derim, günümüzün sorunu performansdan çok yeniden kullanılabilir ve genişletilebilir kod yazabilmek…” bu pragrafı hep aklımda tutucam. Çünkü performans kısmı tam bir sıkıntı olmuştu benim için. Allah razı olsun. ( Bu üç kelimeyi senede en fazla 3-4 kez kullanırım (: )