yazılım geyiklemeleri

Çok eski bir konu ama halen bu konuda hatalı kodlarla karşılaştığım için anlatayım. .Net Framework 2.0 versiyonu ile string karşılaştırmalarda yeni bir özellik geldi.

Back To Basics

Geçmiş ile işim olmaz diyenler bu bölümü atlayabilir, meraklılar için önce biraz zamanda geri saralım.

Bundan 15 yıl öncesinde DOS tipi işletim sistemleri kullanılırken dillerdeki farklı karakterleri göstermek için ISO 8859 adında bir standart kullanılmaya başlandı. O tarihlerde bilgisayarlar daktilo niyetine kullanıldığı için temel olarak ingilizce'yi alan bu standart farklı diller içinde 255 karakter içerisinden sık kullanılmayan karakterlerin şekilleri ve karakterlerin sıralaması değiştirilerek çözüldü.

Örneğin; Türkçe için Ş,İ,Ö,Ç gibi karakterlere değiştirerek Latin-5 (Tam ismiyle ISO-8859-9) isimli ISO standardı uyduruldu.

Eğer farklı bir dil setini kullanıyorsanız "I" harfi ile "ı" (yada ekranda göreceğiniz şekliyle "Y" benzeri bir şey) aynı anlamda değildi.

O zamanları hatırlayınca Türkçe karakter problemleri şimdi yaşananlar bunca karmaşaya rağmen çok hafif kalır aslında ama neyse.

1990'ların sonuna doğru tüm bu sorunları ortadan kaldırmak için Unicode adı verilen yeni bir standart yayılmaya başladı ama ancak şimdilerde yaygın olarak kullanılmaya başladı. .Net'in ilk yayınladığı 1.0 versiyonunda da varsayılan olarak Unicode kullanılması belki de tüm bunlara bir katkısı olmuştur.

Problem nerde ?

Framework 1.0'daki tüm string işlemlerinin kullanılan dilin özelliklerine göre çalışması bir sürü karakter sorunlarını çözdü ama bu sefer farklı bir problem yarattı.

Örneğin; Diskinizdeki C:\Inceden.txt isimli bir dosyayı açmak niyetiyle aşağıdaki gibi bir iş yaparsanız

Code:

Dosyanın adı "c:\ınceden.txt" gibi bir şeye dönüşüyor, normal olarakta dosyayı bulamıyordunuz.

Aslında bu normal çünkü Türkçe size "I" harfinin küçülmüş halinin "ı" olduğunu söyler.

Bu sefer karşılaştırma işlemlerinde üzerinde işlem yapmak istediğiniz şeyin ne olduğu bu sefer değişmeye başladı. Bu bir kişinin adı mı ?, yoksa dosya adı mı ? gibi.

1.1 versiyonuna kadar devam eden problem benimde katkımla yoğun şikayetler yüzünden framework'deki string işlemlerine Invariant ve Ordinal isimli yeni karşılaştırma tipleri eklenerek çözüldü. Bu konuyla ile ilgili daha fazla detayı buradan öğrenebilirsiniz.

Nasıl ?

Eğer kullanılan dilden bağımsız hareket etmek istiyorsanız Invariant, dil ile ilgisiz tam eşleşme istiyorsanız Ordinal kullanılması gibi bir çözüm çıktı.

Örnekle gidelim;

Biraz önceki dosya adını invariant kullanarak küçük harflere çevirirsek;

Code:

Örneğin Invariant karşılaştırırsak;

Code:

benzeri ordinal karşılaştırma yaparsak;

Code:

ordinalin farklı davrandığı bir örnek olarak

Code:

İşin özeti

Herhangi bir string karşılaştırma yapacaksanız, string içindeki değerin ne olduğunu bilerek davranmanız ilerde daha az ağrısız bir ortam yaratır size.

Size tavsiyem hiç bu özellikleri kullanmadan asla ama asla myString1 == myString2 şeklinde bir karşılaştırma yapmayın. Bu tür karşılaştırmalar işletim sisteminin seçtiği dilin özelliklerine göre çalışır, eğer yazdığınız uygulama birden fazla dil desteği sağlıyorsa uzak durun derim.

beklenen linq tepkisi

İlk çıktığı zamandan beri mümkün olduğu kadar uzak durduğum linq ile ilgili beklentim boşa çıkmadı. Linq to sql'in geliştirilmesine son verildi. Okuduğum yorumlardan çoğu kişi bu konuya baya bir sinirlenmiş ve şaşırmış. Hatta open source yapın biz bakarız diyenleri bile var.

İşin aslı ben o kadar fazla şaşırdım diyemem, sebebi ise şimdiye kadar uzak durmam ile aynı sebep.

Henüz gün ışığı almamış yazılımcılarımız için biraz geçmişten bahsedeyim. Aşağıda Microsoft'un her biri için zamanında "bakın süper oldu! hadi kullanın" dediği data access teknolojilerinin listesi var.

• Microsoft Jet Engine
• Data Access Objects (DAO)
• ActiveX Data Objects (ADO)
• Remote Data Objects (RDO)
• Remote Data Services (RDS)
• Open Database Connectivity (ODBC)
• OLE DB
• ADO.NET

Bu listenin içinde şimdi kullanayım dediğinizde şu anda sadece ADO.NET kullanılabilir durumda, bunun dışında yeni gelmiş Linq2SQL ve Entity Framework var. Üzerinde geliştirme yapılabilen diğer platformlar (Java gibi) ile karşılaştırdığınızda Microsoft'un bu Data Access konusunda bir türlü karar veremediğini görürsünüz.

Şimdi bu yazıyı okuyupda beni Microsoft düşmanı filan sanmayın, Microsoft sayesinde para kazanan biriyim, hatta mecbur kalmadığım sürece Java yada benzeri bir şey ile ilgim olmaz.

Geçen o kadar yıldan sonra emin olduğum tek şey var. Data Access konusunda Microsoft'a güvenme.

Neden ?

Microsoft eşlenik olduğu rakipleri içerisinde geliştiricilere en çok önemi veren şirket, ürettiği herşeyde "platform" tadı vardır ama belli konularda her zaman "kaygı ayrılığı" durumu yaşanır. MS'inde güçlü ve zayıf olduğu yerler var, örneğin yaptığınız projenin Oracle veritabanı ile çalışıyor olmasını (gayet doğal olarak) tercih etmez.

Eğer tek atımlık bir projeden bahsediyorsak bu veritabanı taşınabilirliği o kadar önemli olmayabilir ama eğer mermi adedi belirsiz bir üründen bahsediyorsanız ortaya çıkacak ürünün tüm sinir, sindirim ve dolaşım sisteminde Sql Server, Active Directory gibi MS ürünlerinin bulunmasını ister.

Bu yüzden MS belli konularda (data access gibi, IIS gibi) geliştiriciler ile bağlılık arasında kendi kendine sürekli bir savaş yaşar. Eğer mobility'ye çok açık bir durum var ise bir süre sonra Entity Framework benzeri yeni bir versiyon çıkar ortaya. Yukarda listesini gördüğünüz data access componentlerinin sayısının çok olmasının nedeni budur.

Linq ile derdim

Bilmeyenler için önce ufak detay vereyim. Linq, IQueryable ve Expression denilen bir yapı üzerine kurulu ve siz bu IQueryable ve Expression'lar ile bir sorgu hazırlayarak, herhangi bir sisteme execute edilmesi için gönderiyorsunuz. Bu sistem bir c# array'i olur veya db olur çok fark etmiyor, hatta birden fazla sistemi birbirine join bile edebilirsiniz.

Linq2SQL ise database'de duran tablolara göre üretilmiş/generate edilmiş classlar'a göre bu Expression'ları SQL komutlarına çevirerek çalışan bir mantıkta zaten.

Öncelikle lambda konusu benim gözümde anonymous delegate'lerin biraz daha şekillisi, kolay kullanılanı. Eğer dümdüz, 1 kez yazdığınız zaman işiniz bitecek ise kullanmamak için hiç problem görmüyorum.

Eğer reuse ihtimali olacak bir kod yazıyorsanız, sorunlar o zaman başlıyor.

Serialization

Linq'in açılımı "Language Integrated Query" demek. Eğer bir query dilinden bahsediyorsak benim ilk baktığım, sorgunun nasıl serialize edildiğidir. Eğer serialize edemiyorsam disk'e kaydedemem, networkden geçiremem, viewstate'e yazamam.

Örneğin serialization var ise örneğin müşterileri listeyecek bir servis yapıyorsam;

Code:

gibi bir metodla dışardan gelcek sorguyu dinamik olarak çalıştırabilirim. Eğer yapamıyorsam aşağıdaki gibi her case için ayrı düşünmem gerekli.

Code:

Linq için baktığımız zaman, Expression class'ı "by design" olarak query'ler serialize edilemiyor. Bu konuda WCF içerisinde geçen buradaki bilgi var. Okuduğum kadarıyla pek tatmin edici değil, ciddi işler için kullanılabilecek bir boyutta değil.

Type-Safety

Sorgu dili direk c# içerisine gömüldüğü için hazırlanan sorgu ilgili Type'a göre değişiyor. Yani genel bir sorgu yazayım istediğim yere göndereyim gibi bir mantık olamıyor, mutlaka bir class tanımı istiyor.

Örneğin bir Xml dosyasındaki entity tanımlarına göre çalıştıramıyorsunuz. Bu yüzden dinamik bir yapı kurmanız çok zor. ( Eğer arka tarafda xml'e bakarak otomatik class generate edecek bir yapınız yok ise, bu da yapanı var gördüm.)

Bazıları ne yaptın, o kadarda değil diyebilir, en fazla ne yapabileceğinize örnek vereyim.

Code:

Bu xml içerisinden linq ile sorgulamanın bir örneği. Aynı şeyi birde xpath (evet w3c standardı) ile deneyelim.

Code:

Hmm..

Yazım şekli (syntax)

Kolay anlaşılması için standart c# ile yazılmış bir kod parçası üzerinden gidelim. Aşağıda 2 array içinde eşleşen kayıtları bulan bir kod parçası var.

Code:

Aynı kodun birde linq ile yazalım;

Code:

Bunlardan hangisine baktığınızda 5sn içerisinde ne olduğunu anlıyorsunuz ? Anlaşılır, temiz syntax'ın cevabı ile aynıdır bu. Sizi bilmem sql-vari dil bana pek anlaşılır gelmiyor.

Özet

Eğer tek atımlık bir iş yapıyorsanız, yazdığınız koda geri dönüşünüz az olacak ise Linq gayet kullanılabilir, c# içerisindeki Query sorunlarını halledebilecek bir yapı. Buna uzun süredir de ihtiyaç vardı.

Eğer API gibi, extend-reusability falan istiyorsanız c# sınırları dışına çıkmayan bir API içerisinde yine kullanılabilir ama dış dünyaya açtığınız kapılardan Linq geçirmemeniz sizin için faydalı olacaktır.

Linq2SQL'in ise geleceğine zaten Microsoft karar vermiş gözüküyor.

Bundan bir süre önce Google+’ın başındaki kişi Steve Yegge aslında Google çalışanlarına gönderdiği bir makaleyi kazara public olarak yayınladı, biraz uzun olsa da herkese bu yazının içeriğini okumasını tavsiye ederim.

https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

Henüz ülkemiz için erken olsa da (bu iyi bir şey), bu yazıdan öğrenilecek çok şey var. Bu yazıda beni en çok şaşırtan bir kamyon danışmanı olan bir şirket bunun nasıl farkına varmazdı ama neyse. Ben bizim şartlarımıza uyan başka bir konudan gitmek istiyorum.

Bizde de Google’ın yaptığına benzer gayet başarılı olmuş gayet çeşitli (bunun içerisine e-ticaret, ilan sitelerini, teknoloji şirketlerini de dahil ediyorum) ürünler var. Ancak bu şirketlerin başına Jeff Bezos gibi bir patron henüz gelmedi. Görünüşe göre de en az 1 jenerasyon boyunca da gelmeyecek.

Tüm bu bizim ürettiğimiz ürünlerin temel problemi bu Steve amcanın yazdıkları galiba. Başarılı bir ürün yarattıktan sonra onunla ne yapacağımızı bilmiyoruz.

Örnek isterseniz tüm başarılı olmuş, e-ticaret ya da ilan sitelerine bakın 1 tanesi bile elle tutulur bir API sağlamaz. Bu sitelerin patronları için bir kategorideki ürün listesi kaynak kodlar kadar değerli. Hatta web sitelerinden bu verileri almaya çalışırsanız size dava açarlar.

Bana göre asıl kaçırdıkları bu API’leri sağlayarak etraflarında yaratacakları ekosistem. Bir ürünü ayakta tutan aslında bu ekosistemdir. Microsoft bu ekosistemi daha ilk zamanlarından beri kullandı, bununla tüm karşısına dikilenleri yola getirdi. Facebook’da aynı yoldan geldi, şu anda canı sıkılan insanları eğlendirmesi için içinde yüzlerce uygulaması var.

Tersi örnek Google Maps. Eğer bu ekosistemi yaratacak API’leri sağlayamazsanız bir gün o ürünü sizden daha iyi yapan (misal Yandex Maps) gibi birileri mutlaka çıkar ve o gün aldatılırsınız. Başka bir örnek; sahibi bir kamu kuruluşu olmasına rağmen IBB Trafik sitesidir.

Halen ikna olmadıysanız; limitsiz kaynağınız olsa bile bu ekosistem’in yaratacağı inovasyon’a hiçbir zaman erişemezsiniz. Inovasyon olmadan sürekliliği sağlamanız imkansızdır.

Bu ekosistemi yaratmak için düşünülenin aksine ağır bir yükü omuzlamak gerekmiyor. Bezos’un kurallarını takip edin yeterli, eğer okumaya üşendiniz ya da anlamadıysanız ben özetleyeyim.

1. Tüm takımlar (Bezos tam tarif edememiş, modül diyeyim) verilerini servisler ile yayınlayacak.
2. Tüm takımlar arasındaki iletişim sadece bu servisler aracılığıyla olacak.
3. Başka bir iletişim yöntemi geçerli değildir. Direk linkler, direk veri tabanı bağlantıları, arka kapılar yada benzeri hiçbir yöntem. Tüm iletişim bu servisler ile network üzerinden yapılacak.
4. Ne tür bir teknoloji (HTTP, Corba, custom... ) kullandığınızın önemi yok.
5. Tüm servisler dışarıya açılabilir olacak. Tüm bu servisler dış dünyadan geliştiricilere açılacak şekilde planlanıp, tasarlanacak.
6. Bunları yapmayan kişi işten atılacak.

Bu maddeleri ben yazsaydım bu kadar güzel özetleyemezdim heralde Tüm tasarımınızı bu maddelere uyarak yaptığınızda gerisi kendiliğinden gelecektir.

Bunları yazmamın sebebi;

Eğer girişimciyseniz mevcut sitelere alternatif bir şeyler yapmak isteyip de mevcut olanlar yüzünden cesaret edemiyorsanız, bu konuda denemeye değer.

Eğer patronsanız bir an önce Bezos’un gönderdiği bir mail’in benzerini sizde gönderin çok geç kalmadan.

Eğer geliştiriciyseniz bir an önce proje, ürün, platform arasında ne fark vardır onu öğrenin.

Uzun bir aradan sonra sonunda hakkında yazabileceğim bir şey yeni aklıma geldi. Eğer yamulmuyorsam Parallel kütüphanesi Framework 4.0 ile beraber geldi, daha öncesinde MS Research'in geliştirdiği bir extension olarak gizli bir köşede saklanıyordu.

Parallel kütüphanesi ( yada AsParallel() ) Nedir ?

Parallel kütüphanesi son 2-3 yılda yeni çıkan birden fazla işlemcilerin avantajını kullanmak için işleri kolaylaştırmak amacıyla geliştirilmiş bir kütüphane.

Temel olarak yaptığı sıralı olarak yapılacak işleri birden fazla CPU'ya dağıtarak aynı anda birden fazla iş yapmaya, dolayısıyla da verilen işi daha hızlı yapar.

Neden ihtiyacım olur

Bundan yıllar öncesinde C yada ASM'de yazdığım zamanlarla karşılaştırınca, bisikletle bir ferrari'yi karşılaştırmaya benziyor. İronik olan kısım ise yazdığımız programlar halen o zamanki programlar kadar yavaş.

Önce herhangi bir programı yavaşlatan nedir diye düşünelim;

* Donanım
* Network
* For, Foreach, While gibi döngüler.

Bunların dışında bir programın yavaş çalışmasına neden olacak bir etken yok. Donanım ve Network kısmı için zaten sürekli olarak bir şeyler yapılıyor zaten konumuzun dışında.

Eğer yazdığımız kodun hızlı çalışmasını istiyorsak yapacağımız tek şey bu döngü'lere dikkat etmek, ne kadar az döngü varsa kod o kadar hızlı çalışacaktır. Bu optimizasyonu tabiki belli dereceye kadar yapabiliriz ve nihayetinde bazı kısımlar kalacak.

Standart kodlama yaparken (eğer thread filan yaratmıyorsanız) yazdığımız kod her zaman ve her zaman tek CPU üzerinde çalışacaktır. Bazen CPU bir şeylerle uğraşırken Task Manager'i açtığınızda tüm CPU'ların bir şey yaptığını görüyor olursunuz ancak burası biraz yanıltıcıdır.

Çok merak ediyorsanız basit bir loop yaratarak CPU'yu sürekli meşgul tutan bir kod çalıştırın ve Task Manager'da olanları izleyin, eğer 2 CPU'lu bir makinanız varsa test yaptığınız exe asla %50 (4 CPU'nuz varsa %25) cpu kullanımının üzerine çıkmayacaktır. Task Manager'ın grafik kısmına baktığınız zaman tüm CPU'larda aktivite gözükür ancak bu işletim sisteminin yapılan işleri farklı CPU'lara dağıtması yüzünden kaynaklanır. Yani kodunuz kısa bir süre 1. CPU daha sonra 2. CPU'da çalışmaya devam eder. Ancak yaptığınız iş tek CPU sınırını aşmadığı için asıl rakamlara baktığınız zaman bu söylediğim görünmez bariyer'de takılırsınız.

Yazdığınız kodu hızlandırmak için birden fazla CPU kullanmayı istiyorsanız kodunuz içinde ekstra olacak bir şeyler daha ekleyerek, niyetinizi belli etmeniz gerekir.

Nasıl ?

Anlaşılır olması için örnekli gidiyorum; basit bir örnek olsun diye elimizde bir int array'i olsun ve biz array üstündeki elemanı string halline dönüştürmek isteyelim. (Pratikde string'e dönüştürmekten başka bir şeyler olacaktır)

Önce array'i tanımlayıp içini çöp'le dolduralım.

Code:

Standart olarak yazacağımız kod aşağıdaki gibi;

Code:

Şimdi bu kodu benim 8 CPU'lu canavar bilgisayarımda çalıştırdığımda süre olarak 01.520 saniyede tamamlanıyor.

Aynı kod üzerinde biraz değişiklik yaparak paralel kütüphanesinin kullanılmasını istersem;

Code:

Araya eklediğim bu AsParallel ile çalışma süresi 0.619 saniyeye düştü.

Karşılaştırma yapınca arada devasa bir fark var. Geriye tek sorun kalıyor;

Paralel çalışacak kod parçası üzerinde sıralı işlemler yapmamanız gerekli, örneğin toplama gibi sıralı olması gerekmeyen bir kod yazabilirsiniz ancak bir önceki değere ihtiyacınız olduğu durumlarda işler biraz zorlaşabilir.

Böyle durumlar biraz daha karmaşık, bunun detaylarını daha sonra yazarım ancak sadece bu yöntemle kodunuz içindeki döngüler'in büyük bir çoğunluğunda bu parallel kütüphanesini halen kullanabilirsiniz.

Umarım işinize yaramıştır. Unutmadan denemek isteyenler için tüm test kodu aşağıda;

Code:

Klavyem sanırım aşırı kullanım yüzünden o (noktalı olanı) harfini yazmamakta inat ediyor. çok uğraşamadım idare ediniz.

wikipedia'ya gore

Turnaround, in computing scheduling, the total time between submission of a process and its completion

anlamına gelen bu kelime biz farkında olmadan yazılım geliştirme için harcadığımız zamanın büyük bir bolumunu alır.

Diyelim ki ofisinizde sakin bir şekilde çalışırken, yazdığınız uygulamada ufak bir hata buldunuz. Basit anlamda bu süre IDE açıkken uygulamayı derleyip, hatayı deneyip, tekrar IDE'ye dondugunuze kadar geçen süredir aslında.

Çoğu developer bu süreyi etkileyecek sorunları çozmek yerine gozardı edip bir an once hatayı test etmeye odaklanır. Tanıdığım bir developer'ın yaptıklarını ornek vererek gideyim

1. Derle 45sn (7sn) Normalde çok kısa süren bu iş, diskinde yer olmadığı için kodları USB diskten kullanıyor bu yüzden çok yavaş.

2. Kopyala 90sn. (0sn) Normalde build script'i ile kopyalanan dll dosyası, build script'ini güncellemediği için elle kopyalamak zorunda. Derlenen dosyayı programı çalıştırdığı dizine kopyalıyor ama uygulamayı açık unuttuğu için dosyaları kopyalayamadı. programı kapatıp kopyalamayı tekrar başlatıyor.

3. Çalıştırma 35sn. (4sn) Her ne amaçla kullanıldığını anlamadığım bir cehennemden gelmiş bir antitrojan uyarı mesajı çıkarıyor. Mesaj kapatılıyor.

4. Deneme 70sn. (2sn) Denemek için uygulamadaki ekrana gidip parametreleri giriyor, ama hatayı oluşmadı. Biraz düşündükten sonra hatalı parametre girdiğini farkedip düzeltip tekrar deniyor. Hata düzelmemiş. tekrar baştan başla.

Bu saydıklarımın aslında daha fazlası var ama sıkıcı olmaması için daha detaylandırmadım. Şimdi normalde 13sn süren "turnaround" zamanı bu developer için 240 saniye yani 4dk.

Gün içinde bunu yüzlerce kez tekrar ettiğimiz için işimizi yaparken harcadığımız zamanın çok çok büyük bir bölümünü anlamsız, kimseye faydası olmayan, can sıkıcı işlerle geçiririz.

Verdiğim örnekler için bir build script'i ve unit test yapmanız yeterlidir ama yaptığınız işin detaylarını sizden başka kimse bilmez.

Bu konuda size sadece bazı genel olabilecek önerilerim olacak;

* Kod yazarken dikkatinizi dağıtacak, antivirüs, outlook gibi zıpır zıpır popup mesaj çıkaran şeyleri kapatın.

* Age of Empires eski makinalarda da çalışıyor olsa bile ofisdeki en hızlı makinayı kullanın, bunun için gerekirse patronunuza yalvarın. Şirketin bik bik standartları var bu yüzden veremeyiz denirse gidip kendinize hızlı bir makina alın, bu kendinize yaptığınız bir yatırımdır.

* Sürekli tekrar ettiğiniz şeyleri daha kısa sürede yapmanın bir yolunu bulun, gerekirse telefonda ağlayan kullanıcıyı beklemeye alıp browser'ın address barına günde 150 kere yanlış yazdığınız programın adresini bookmark'lara ekleyin.

* Yazdığınız uygulamayı arayüzler içinden test etmekten vazgeçin, felsefik saçmalıklardan olacak ama unit test için ilk adımı atmak uzun bir yolun ilk adımıdır.

* Geliştirdiğiniz uygulamayı güncellemek için tek tek dosya kopyalamaktan vazgeçin, hayır daha hızlı değil. Tüm değişmiş dosyaları güncelleyecek bir script dosyası yazın.

* Bunların içerisindeki en önemlisi "hurafe"lere inanmayın. 10dk önce çalışan bir şey mars'dan gelmiş kırmızı etekli uzaylılar tarafından bozulmuş olamaz.