yazılım,c# ve domates kabuğu

responsive != performance

  12/09/12 22:28, by ertan, Categories: Yazılım

Herşeyden önce biraz kelime anlamlarını deşelim. Yazılım dünyasında "responsive" hızlı cevap veren demek, "performance" ise çalışma hızı demek.

Bizim yazılımcılarımız genelde bu 2 kelimeyi sürekli karşılaştırırlar, hızlı çalışan her uygulama responsive'dir gibi yanlış bir anlayış var.

Öncelikle uğraştığınız yazılımın hızlı çalışması gibi bir hedef aslında yanlış bir hedefdir. Uygulamanın hızlı çalışması için harcadığınız zamanda aslında boşuna bir uğraştır. Asıl hedef uygulamanın "responsive" olmalıdır.

Bu ne demek örnek vereyim. Mesela bir mail programı düşünün, mail'i gönder dediğinizde mail'in karşı tarafa ne kadar hızlı gittiğinin aslında hiç bir önemi yoktur, kullanıcı için "gönder" bütonuna bastıktan sonra pencerenin kapanıyor olması yeterlidir, e-mail'in sonraki dakikalar içinde arka planda gönderiliyor olması ile programı kullanan kişi ilgilenmez.

Başka bir örnek olarak bir arama ekranı düşünün. Arama ile ilgili kullanıcının istediği sonuçların ekrana kısa sürede gelmesidir. Bunu arama fonksiyonunu hızlı çalışsın diye zaman harcayarak çözmeye çalışmak çoğu zaman anlamsızdır.

Örneğin 100 kayıt içinde çok hızlı arayan bir algoritma, 1 milyon kayıt için siz ne yaparsanız yapın yavaş çalışacaktır. Asıl çözüm arama yapılırken kayıt bulundukça kullanıcının önüne getirirken, paralel olarak aramayı devam ettirmektir. Eğer düzgün bir sıralama mantığı var ise kullanıcı ilk 100 kayıt içinde zaten aradığını bulacaktır, eğer bulamıyor ise sonraki yüzbin tane kayıda tek tek bakan bir kullanıcı zaten yoktur, vazgeçip başka bir şekilde aramaya çalışacaktır.

Bunu yapabilmenin yollarından birisi (pek sevmesemde) listelerde sayfalama yapmaktır ama genelde pratikte yapılan "Client Paging" denilen tüm uyan kayıtları bulduktan sonra içinden ilgili sayfaya gelecek 50 kayıdı seçip kullanıcının ekranında göstermektir. Yani her durumda 1 milyon kayıt bulunana kadar kullanıcı beklemek zorundadır. Eğer bir sonraki sayfayı görmek istediğinde aynı işlemler tekrar tekrar yapılır, bu yüzden "yavaş" çalışan bir programınız olur. Bunun nasıl yapılacağını çoğu yazılımcı bilir ama genelde bir çeşit tembellik yüzünden erteleriz. Bilmeyenler var ise SQL Server için "TOP", "ROWNUMBER", MySQL için "Limit" anahtar kelimeleri yardımcı olacaktır.

Eğer yeni bir uygulamaya başlıyorsanız veritabanı erişimi için mutlaka ek bir (data access layer) şeyler kullanmanızı ve bu sorunu "yılanın başı küçük iken" çözmenizi tavsiye ederim zira daha sonraları bu devasa bir kartopu haline gelebilir.

Algı

Şimdi öncelikle bir kullanıcı için "responsive" algısını düzgün kurmak için temel şeylerden bahsedeyim. Kullanıcının yaptığı her bir işlem için 3 çeşit zaman limiti var. Kolay anlaşılması için google benzeri bir arama ekranı olduğunu hayal edin, verdiğim örneklerde buna uygun olacak.

Geri bildirim (Feedback)

Etrafımızda olanları algıladığımız süre yaklaşık 0.1 saniyelik zamandır. Örneğin hareketli bir animasyon yaratmak için en az 0.1sn içerisinde bir hareket olması gerekir. Bunu filmlerde çoğunlukla görürsünüz, bu süreyi aşan (eski) filmlerde görüntü kesik kesik hareket ediyor gözükür, ne olduğunu algılamak için özel çaba sarfederiz.

Örneğin; arama kutusu içinde klavye'den bir tuşa basılması ve basılan karakterin ekranda gözükmesi.

Örneğin; mouse ile ekrandaki "ara" bütona tıkladığında bütonun şekil değiştirmesi.

Sizde bu tipdeki işlemler için bu süre içerisinde ilk tepkiyi vermeniz gereklidir, eğer bu süreyi aşarsanız kullanıcının koordinasyonu bozulur. Bu koordinasyonu bozduğunuzda kullanıcı kendini rahat hissetmez ve bir problem olduğunu düşünerek yaptığı işi yarıda keser ve konsantrasyonu bozulur.

Genelde bu konuları dert etmenize gerek yoktur, işletim sistemi yada browser'lar bu konuları sizin yerinize hallederler. Bazı uygulamalarda denk gelirseniz "KeyUp/Down" yada "MouseMove" gibi eventlar içinde bir şeyler yapan uygulamalarda bu tür problemler görülür.

Örneğin arama kutusunda kullanıcı textbox üzerinde klavyeden bir şeyler yazdığında aramayı hemen başlatmak gibi. Çok iddalı değilseniz böyle bir şey yapmaktan kaçının, eğer mecbur kalıyorsanız yapılacak işi ayrı bir Thread içinde yapmanız bu dertlerden biraz uzak kalmanızı sağlar.

Kabul (Acknowledge)

Etrafımızda olan olaylara 1sn içerisinde tepki veririz. Örneğin araç sürerken önümüze bir şey çıktığında yaklaşık 1sn içerisinde frene basmaya karar veririz.

Google örneği için; "ara" bütonuna basıldığında en fazla 1sn içerisinde ekranda "arama yapılıyor"/"yükleniyor" lafının çıkmalıdır.

Sizde yapılan işi yapmaya başladığınıza dair 1 saniye içerisinde bir cevap vermelisiniz. Bu süreyi aştığınızda çoğunlukla "olmadı galiba" kararını vererek bırakır veya yaptığı işi tekrar etmeyi dener.

Eğer yapacağınız iş 1sn'den daha uzun ise sizde bu şekilde bir "işleniyor","yükleniyor" benzeri bir ilerleme raporu verirseniz kullanan kişinin kafasının karışmasına engel olabilirsiniz. Bu tür geri bildirimler için genelde ekrandaki durum mesajı görüntülendikten sonra asıl iş başka bir Thread içerisinde yapılır ve belirli aralıklarla thread'in ne aşamada olduğunu görüntülersiniz.

Buna en iyi örneklerden birisi Windows içinde dosya kopyalama penceresidir. Siz dosyayı kopyala dediğinizde işlem başlatılır ve asıl kopyalama işi başka bir thread içerisinde yapılır, pencere sadece kopyalamanın ne kadar süresi kaldığını ekranda göstermekle ilgilenir. Eğer bu pencerenin ekrana gelmesi 1sn'den uzun sürer ise "bir şeyler yanlış" hissine kapılırız.

Yapacağınız her iş için bu şekilde bir mesaj çıkarmanıza gerek gerek yoktur, bunu sadece 1sn'yi geçme ihtimali olan işler için yapmanız yeterlidir. Uygulamayı yazan kişi olarak bu ihtimali bilmek sizin işiniz.

Cevap (Response)

Beynimiz yaklaşık her 10sn içerisinde yapacağı işleri tekrar gözden geçirip düzenler ve bir sonraki yapılacak işe odaklanır.

Google örneği için; ilk arama sonucunun görüntülendiği sayfa denilebilir.

Genel kural olarak kabul edilebecek şekilde; kullanıcının bir işin yapılması için sabredebildiği en uzun 10 saniyedir denilebilir.

Her ne iş yapıyorsanız yapın, bu süre içerisinde verilen işin bitmesi gereklidir. Bu süreyi geçtiğinizde kullanıcı bu işi bırakarak, başka bir şey yapmaya odaklanır. (Örneğin yaptığı işi bırakıp, Facebook'a girmeye karar verir)

Geliştirdiğiniz uygulama ne olursa olsun yukardakilere uyduğunuzda yaptığınız işte ne kadar çok kayıt veya karmaşık olursa olsun "hızlı çalışan" görünen "responsive" yazılımlar üretebilirsiniz.

Kullanıcılar yavaş çalışan programlardan değil "responsive" olmayan programlardan şikayet eder.

Leave a comment »

Dünya düzdür.

  28/08/12 00:35, by ertan, Categories: Yazılım

Bu başlık bir globalleşme üzerine yazılmış bir kitabın başlığı.

Genelde yazılım geliştirme ile ilgili yazılar yazdığım için ne alaka diyebilirsiniz. Kitabın içeriği ile ilgili ilginç bir olabilecek bir detay var. Önce "dünya düzdür" ne demek onu açıklayayım.

Dünya gün geçtikçe küreselleşiyor. Ekonomi, sosyal, teknoloji, iletişim gibi tüm alanlarda giderek tarihi veya coğrafi bölünmelerin önemi gittikçe azalıyor. Dünyanın neresinde olursanız olun rekabet artıyor, aynılaşıyoruz.

Şu anda kullandığınız bilgisayarın her bir parçası dünyanın çok farklı yerlerinde üretilip, şu anda kullandığınız yere kilometrelerce uzak bir yerlerde birleştiriliyor. Çağrı merkezini aradığımızda cevap veren kişinin hangi şehirde hatta hangi ülkede olduğuna dair bile bir fikrimiz yok. Bankadaki paramız yada borcumuz, bir veritabanında kayıtlı rakam sadece. Biz istediğimiz zaman sadece kağıt haline geliyor.

5 yıl önce sadece hayal edebildiklerimiz şimdi gerçek. Bu süre giderek daha da kısalıyor.

Herşey daha kolay, daha ulaşılabilir, daha düşük maliyetli, daha yakın.

Genel olarak bu kitabın konusu bu globalleşme üzerine analizler ile ilgili ve dünyayı en çok düzleştiren bazı "şey"lerin listesini veriyor. Aslında 10 tane ama ben ilk 5 tanesini yazayım buraya. İlgilenenler yukardaki link üzerinden detaylarına bakabilir.

1. Berlin Duvarı

2. Netscape

3. İş Akışı Uygulamarı

4. Uploading

5. Outsourcing (Dış kaynak kullanımı)

Bunlardan benim ilgilendiğim konu ise 3. madde.

İlginç olan artık çeşitlerini benim artık takip edemediğim binlerce tür yazılım içerisinden yazılım anlamında iş akışının yer almış olması. Bu liste içerisinde milyon milyon dolarlar harcanan ERP'ler, CRM'ler, işletim sistemleri, veritabanı uygulamaları yok. Hatta liste içerisindeki diğer 6 madde'nin yayılma noktası olarak bu maddeyi gösteriyor.

Beni yakından tanıyanların bildiği gibi yazılım konusunda ilgilendiğim alan çoktur ama son 10 yılım sürekli iş akışı konusunda geçmiştir. Bu kitabın yazarının bahsettiği gibi benim içinde iş akışı yazılımları diğer tüm yazılımların yanında çok farklı bir yeri ve geleceği vardır.

Neden ?

Ünlü bir örnek üzerinden gideyim. Bir avuç fındık üretmek için artık fındığı toprağa eken, sulayan, toplayan, tartıp ambalajlayanlar artık makinalardır. Benzer şekilde giydiğiniz giysiler, bu yazıyı okuduğunuz bilgisayarlar artık insanlara pekte bağlı kalmadan makinalar tarafından yapılıyor. Üretimin her alanında artık insanlar bu süreçler üzerinde sadece karar noktalarında bulunup, sadece ne yapılacağını çeşitli şekillerde söylüyorlar, gerisini makinalar yapıyor.

Bir avuç fındık üretmek ise işin sadece yarısıdır, işin diğer yarısı bu ürettiğiniz fındığı satmaktır. Satmak için kocaman binalarda yüzlerce kişi iş ortaklıkları, kampanyalar, rakipler, insan kaynakları, tedarik, satınalma, mali işler gibi işlerle uğraşır.

Ancak 2000'li yılların teknolojisi ile ürettiğiniz fındığı satmak için halen 1950'lerin satış tekniklerini kullanılırız, 1950'lerde çantalarda taşınan defterlerin, mektupların yerini artık laptop'lar ve elektronik postalar aldı ama kullandığımız onca işletim sistemleri, ofis yazılımları, ERP'ler, CRM'ler, HR sistemleri temelde boş defterlere kaydettiğimiz bilgilerden daha fazla bir şey değildir. Tüm bu "fındığı satmak" için yapılan faaliyetler insanlar tarafından yönetilir/yapılır.

Üretim tarafındaki bu verimliliği sağlayan makineleşmenin benzerini bu "boş defterler" ile yapmamız mümkün değildir, bu yüzden tüm bu "işin diğer yarısı" diye düşünebileceğiniz tüm bu işlerin de makineleşmesine gerek vardır. Makineleşmek için gerekli kayıt ortamlarımız bolca var ama bunların işlemesini sağlayacak bizim yerimize faaliyet gösterecek bir "akıl" yoktur.

İş akışı işte bu "boş defterlere" bir akıl katmak için gereklidir, bu akıl'a fındığı üretmek için ihtiyaç duymadık çünkü doğa ve verimlilik ihtiyacı bu eksiği kendiliğinden tamamladı ancak işin diğer yarısı tamamen insanlar arasındadır ve bu noktada bir başımıza kalırız.

İş Akışı mı ? BPM mi ?

90’lı yıllarda bu "işin diğer yarısı" olan iş süreçlerini standartlaştırma ve iyileştirme amacıyla kullanılan uygulamalara “Workflow Engine” ismi verilmeye başlandı. Zaman geçtikçe bir çok alanda kullanılmaya başlayan ve Workflow’un ne demek olduğunu açıklamaya çalışan herkes kendi bakış açısıyla tanımlamaya çalıştı gün geçtikçe herkesin kafasını karıştıran bir konu haline geldi.

Nihayetinde tüm bu karmaşaya son vermek yeni bir isim olan BPM (Business Process Management) kullanılmaya başlandı.

Workflow terimi aslında çok genel olarak kullanılabilecek bir kelimedir. Örneğin “Veri” yada “Entegrasyon”, "Doküman" gibi çok genel anlamda kullanılabilecek kelimelerle aynı kapsamı taşır. Detayında ne olduğunu tarif etmez. Örneğin yemek yapmak, bir web sitesi tasarlamak, arabayla işe gitmek, bir kişiyi işe almak gibi tüm bu faaliyetlerin bir iş akışı/süreci vardır. Bu yüzden faaliyet gösterdiğiniz alana göre “Workflow”u farklı şekillerde tarif edersiniz.

Workflow Engine terimini kullanan çözümler ise genelde süreç içerisindeki adımlara odaklanır, bunların nasıl sıralandığı, kimin yapacağı gibi konularla ilgilenir. Veri olarak bir doküman yada veritabanındaki bir kayıda referans verir. Süreç modelleme, kodlama, kullanıcı arayüzü, veri modeli gibi konularla fazla ilgilenmez, bunlar diğer sistemlerin problemidir. Yukarda bahsettiğim kafa karışıklığından kurtulmak için genelde bu tür çözümler "Routing" (yönlendirme) ismiyle anılır. Çoğu basit bir sıralı tabloyu referans alarak insanlara iş götüren çözümlerdir.

BPM ise gün geçtikçe artan ihtiyaçlar nedeniyle “Workflow Engine” üzerinden evrilip süreç modeliyle birlikte veri ile de ayrıntılı olarak ilgilenen daha gelişmiş süreç geliştirme platformlarını tarif eder. BPM uygulamalarındaki grafiksel süreç modelleri teknik kişiler dışında sürecin asıl sahibi tarafından da anlaşılabilir ve bu grafiksel model üzerinde yapılan değişiklikler direkt olarak sürecin çalışma şeklini etkiler.

BPM uygulamalarındaki veri modelleme, form tasarımı ve süreç ile birlikte entegre kodlama ortamı ile dış bir sisteme ihtiyaç duymadan tüm süreci bir uygulama olarak modelleme mümkündür. XML tabanlı veri modeli ile karmaşık veritabanlarına ihtiyaç olmaz, hatta sürecin veri modeli herhangi bir anda değişebilir.

Tüm bunların dışında 2000’li yıllarla yaygınlaşmaya başlayan web servisleri BPM çözümleri ile alternatifsiz entegre çalışır. Sadece tasarım araçları ile hiç kodlama olmadan örneğin bir sipariş talebini BPM üzerinde başlatıp, onaylarını aldıktan sonra üretim sisteminde bir web servisi aracılığıyla iş emri yaratılabilir. Böylece "boş defter" üzerinde yarattığınız kayıtlar için minik bir "akıl" katarsınız işe.

Sonuç olarak “Workflow” çok genel bir kavramdır ve her çeşit uygulamada çeşitli formlarda bulunur. “Workflow Engine” ise süreç içerisindeki adımlara ve kimin yapacağına, kimde ne iş olduğu ile ilgilenir. Bir çok uygulama farklı bakış açıları ile içerisinde bir workflow engine taşır. “BPM” ise bir “Workflow Engine” üzerinden evrilerek herhangi bir iş sürecini geliştirmek için zengin araçlara sahip olan bir süreç yönetim sistemidir.

BPM uygulamaları üzerinde geliştirilen süreçler başlangıçta genelde işi basit tutmak için insan-insan arasında olur ancak bu konuda deneyim kazandıkça makina-insan-makina arasında olan süreçlere doğru gider, buda üretimde başardığımız makineleşmenin bir benzeridir.

Hangisine ihtiyacınız olduğu ise ne kadar makineleşme ihtiyacınız ile ilgilidir, BPM uygulamaları sadece bu konuyla ilgilendiği için en geniş imkanları tanıyan çözümlerdir.

İşin Özeti

Görünüşe göre önümüzdeki 10 yıl içerisinde bu "işin diğer yarısı"nı makineleştirebilen şirketler ayakta kalacak, rekabet etme şansı bulacak. İş Akışı ile bu makineleşmeyi sağlayabilecek bildiğimiz tek yöntem ve bunu "boş defterler"e kayıt yaparak yapmaya çalışanlar "mahalle bakkalı" vs "süper marketler" gibi kazanamayacağı bir iddaya giriyor demektir.

Leave a comment »

Sahte Bulutlar

  18/08/12 22:19, by ertan, Categories: Yazılım

Yavaş yavaş güzel memleketimizde hareketlenmeye başlayan bulut teknolojileri ile ilgili güzel gelişmeler var. Bundan 5 yıl önce şirketlere gidip "muhasebe programımız var ama gel bunu internetten kullan" dediğiniz zaman insanların devasa açılmış gözlerle "muhasebe bilgilerimi internette mi tutacağım ?" sorusuyla karşılaşmanız şaşırılacak bir şey değildi.

Çeşitli konularda halen bu tepkilerle karşılaşsakta şimdilerde bir sürü şirket muhasebe uygulamalarını internetten kullanıyor ve zaman içinde daha da alışacaktır, yazılımı satınalmak yerine kiralayarak asıl ilgilendiğiniz hizmeti çok daha kaliteli ve gerçek anlamda "yönetilen" bir yere doğru gidiyoruz.

Sırası gelmişken "Yönetilen" lafını biraz açmak gerekli. Şu anda genel pratik şöyle; satın alınan yazılım, ofisdeki bir ADSL modeme bağlı sunucu olarak kullanılan desktop kasadan ibarettir, yedekleme genelde iyi durumda olanları bilgisayar işlerine bakan dışardaki bir şirketin elemanı tarafından external disklere alınır, kötü durumda olanları ise aynı disk üstündeki bir alana yapılır ve yazılım bozulmadığı sürece ilgilenen pek kimse de olmaz. Bu iki yöntemi de bir "yönetim" şekli diye anlamak zor. Bu şekilde kullanılan binlerce CRM, Muhasebe vs benzeri kurulum olduğunu çok defalar gördüm. Yaşanan bir kaç kaza sonrası akıllı olanları bu kazaları tekrar hiç yaşamaya fırsat vermeden yavaş yavaş bu fikirden vazgeçerek bulut üstünden bu yazılımları kullanmaya başlıyorlar. Umarım ki zaman geçtiğince bu daha da yaygınlaşır.

Kullandığınız uygulamaları bulut'a taşımanın avantajı nedir derseniz ?

* Düşük lisans ücretleri.

* Donanım satınalmak almak bir kenara RAM, Disk vs gibi konularla ilgilenmek zorunda değilsiniz.

* Ofisinizde bir sunucu ortamı yaratmak, yedek almak, ilgilenecek bir kişi bulmak zorunda değilsiniz.

* Kullanacağınız bilgisayarlarda bir tarayıcı olması yeterli, bu 35 çekirdekli, 150 GB diskli bilgisayarlar yerine daha ucuza alabileceğiniz bilgisayarlar demek.

* Bilgisayarınıza bir yazılım kurmak zorunda değilsiniz, standart işletim sisteminde gelen herşey yeterli. Mail programları, antivirüsler, firewall kullanmak zorunda değilsiniz.

* Yeni versiyonu çıkan yazılımları güncellemek zorunda değilsiniz.

* Ofis dışından istediğiniz yerden bağlanabilir, müşteriye gittiğinizde VPN kullanmak zorunda değilsiniz.

İşin kısası çalışmaya başlamak için internet, masa, bilgisayar, koltuk ve çay/kahve'den başka bir şeye ihtiyacınız olmayan bir dünya aslında.

Ancak bu umudumu korkuya çeviren birkaç konu var ve yazının bundan sonraki kısmı yazılımcıları ilgilendiren bir konu olacak.

Piyasada bu talep arttıkça, buna cevap vermek içinde yazılım firmaları kendi yazılımlarını internet üzerinden çalışacak şekilde ayarlamaya çalışıyorlar ama malesef her yazılım bu mimari ile çalışacak şekilde uygun tasarlanmış değil.

Öncelikle yazılımınızın mimarisi ile ilgili olan multitenant bir yapıyı destekleyebiliyor musunuz ?

Multitenant bir yazılımlar işletim sisteminde tek bir kopya olarak çalışır ve birden fazla müşteriye cevap verebilir bir yapıdadır. Bu bağlı olan kullanıcının organizasyonuna göre tüm sistemi diğer müşterilerinizden izole olarak çalıştırmanızı gerektirir. Bu izolasyon veriyapısından, konfigurasyon seçeneklerine kadar her konuyu içerir.

Eğer yazılım mimariniz bu yapıda değilse üzerinde ciddi değişiklikler yapmanız gerekebilir veya alternatif olabilecek akla gelen ilk ve pratik yöntem olarak sanal sunucular kullanmaktır. Sanal sunucu kullanmanın maliyeti ise sisteme alacağınız her müşteri için yönetim maliyetleriniz artar. Bu kurulum, versiyon güncelleme, hataların düzeltilmesi gibi bir sürü bulut teknolojisinde olmaması gereken negatif problemler demektir.

Sizden bir yazılım değil, belirli süreli "hizmet" satınalan müşterilerinizin olması; son derece sadık olmayan müşteriler demektir. Maliyetleriniz yüksek ise hiç müşteri getiremeyebilir veya sonraki bir zamanda hizmette problemler olursa bir anda tüm müşterilerinizi kaybedebilirsiniz. Bu yüzden bu konuya çok dikkat etmeniz gerekli, eğer altyapınız buna uygun değil ise ne yapılabilir ciddi anlamda düşünmenizi tavsiye ederim.

Bu yazıyı okuyan ve işin "kullanıcı" tarafında olanlar için bu "sanal bulut" hizmetinin ipuçlarını görmek çok kolay;

* Hemen deneme imkanı yerine demo video ve ekran görüntüleri (vazgeçtim video'dan çoğunda ekran görüntüsü bile yoktur)

* Versiyon numarası ( facebook, gmail, youtube'un versiyon numarasını bilen var mı ?)

* Kurulum ücreti

* Sabit süreli kullanım sözleşmesi (örneğin 1 yıllık ücret talep etmek)

* Rakiplere göre çok yüksek lisans ücretleri

* Üyelik talebinizin bir kaç gün içinde aktif edilmesi

Maddelerinden birisi var ise kiralayacağınız yazılım ya multitenant bir yazılım değil yada satılan ürünün kalitesi ile ilgili problemler var demekdir.

Bu "sanal bulut" hizmetini verenleri gayet iyi anlıyorum, minimum yatırımla bu dünyada varolmak istiyolar ama her ne alanda olursanız olun, ileriki 5 yıl içerisinde bu alanda bir sürü firma ortaya çıkacak ve rekabet avantajları olmayacak. Şimdiden uyarmış olayım.

Leave a comment »

Invariant Case Türkçe İ ve I karakterleri

  12/01/12 22:19, by ertan, Categories: Algoritma Soruları

Ç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

string dosya = "C:\Inceden.txt";
 
 
 
File.Open( dosya.ToLower() );

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

? "Inceden.TXT".ToLowerInvariant()
 
"inceden.txt"

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

Code

? string.Equals("i","I", StringComparison.InvariantCultureIgnoreCase)
 
true
 
? string.Equals("ş","S", StringComparison.InvariantCultureIgnoreCase)
 
false
 
? string.Equals("ş","Ş", StringComparison.InvariantCultureIgnoreCase)
 
true

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

Code

? string.Equals("i","İ", StringComparison.OrdinalIgnoreCase)
 
false
 
? string.Equals("i","İ", StringComparison.OrdinalIgnoreCase)
 
false
 
? string.Equals("i","I", StringComparison.OrdinalIgnoreCase)
 
true

ordinalin farklı davrandığı bir örnek olarak

Code

? string.Equals("a","A", StringComparison.OrdinalIgnoreCase)
 
true

İş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.

Leave a comment »

beklenen linq tepkisi

  27/12/11 20:28, by ertan, Categories: Algoritma Soruları

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.

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

Customers[] GetCustomers( Expression query );

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

Customers[] GetCustomers( int? id, string name, ... );

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

var xml = XElement.Load("nurettin.xml");
 
 
 
  string t = "Belluci";
 
  var v = from page in xml.Elements("SitePage")
 
    where t == page.Element("Title").Value
 
    select page;

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

Code

var xml = new XmlDocument().LoadXml("nurettin.xml");
 
  
 
  var page = xml.SelectNodes("//SitePage[Title ='Belluci']");

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

foreach (string g1 in sourceGroups)
 
{
 
   foreach (string g2 in targetGroups)
 
   {
 
       if (g1 == g2)
 
       {
 
           matches.Add(g1);
 
       }
 
   }
 
}

Aynı kodun birde linq ile yazalım;

Code

maches.AddRange(
 
  from g1 in sourceGroups
 
    from g2 in targetGroups
 
      where g1 == g2
 
        select g1);

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.

1 comment »

:: Next >>

 

©2014 by Ertan Tike

Contact | Help | b2evo skin by Asevo | PHP framework | vps | François