Dr. Volkan Tunalı

Masaüstü ya da dizüstü farketmeksizin ne zaman yeni bir bilgisayar alsam, bilgisayarın fiyatı aşağı yukarı aynı iken sabit disk kapasitesi bir öncekinden çok daha fazla oluyor. Bu durum ana bellek ve işlemci gücü için de geçerli ama sabit disk kapasitesinin durumu çok farklı.

Matthew Komorowski sabit disk kapasitesi/fiyat verisi toplayıp aşağıdaki grafiği elde etmiş:

Kaynak: http://www.mkomo.com/cost-per-gigabyte

Komorowski ayrıca kapasite/maliyet trendi için de şu sonuca varmış:

Over the last 30 years, space per unit cost has doubled roughly every 14 months (increasing by an order of magnitude every 48 months)

Son 30 yıl boyunca, birim maliyet başına disk kapasitesi kabaca 14 ayda bir iki katına çıkıyor (48 ayda bir ise ciddi bir artış gösteriyor)

Ayrıca maliyet için bir formül de çıkartmış:

Aşağıdaki iki resim 80′lerin bilgisayar dergilerinden alınma. İnanılmaz!

Bilgisayar ve Yazılım Mühendisliği bölümlerinde öğretim programı hazırlayan bazı hocalarım ve akademisyen arkadaşlarımla birinci sınıftan itibaren öğrencilere hangi programlama dilinin öğretilmesinin uygun olacağı konusunda çeşitli zamanlarda görüş alışverişlerimiz oldu. Programı hazırlarken ve dil seçimini yaparken genellikle aşağıdakiler gibi bir takım kriterler üzerinde durduklarını gördüm:

• Bu bölümden mezun olan kişi piyasada yaygın olarak kullanılan bir programlama dilini doğrudan uygulamaya yönelik olarak iyi derecede biliyor olsun, piyasaya çıktığında bu dili kullanarak gerçek hayat uygulamaları geliştirebilecek düzeyde olsun
• Bu dil mutlaka tam anlamıyla Object Oriented bir dil olsun, öğrenciler OOD (Object Oriented Design) ve OOP (Object Oriented Programlama) kavramlarına tam anlamıyla hakim olsunlar
• Web uygulamaları geliştirilmesi konusunda da dilin desteği ve kolaylıkları olsun

Bu kriterler göz önüne alındığında ve bölümlerin Bilgisayar Bilimleri’nden ziyade Yazılım Mühendisliği ağırlıklı olmasının istenmesi de hesaba katıldığında genellikle en iyi tercihin MS.Net tabanlı C türevi bir dil olan C# (C Sharp) olduğunu düşünüyoruz. Her ne kadar Microsoft çatısı altında geliştirilen ticari bir ürün olsa da C#, C’ye ve Java’ya benzerliklerinin yanı sıra son derece olgunlaşmış, gelişmiş ve güçlü bir genel amaçlı programlama dili durumunda. Aslında Java da bu kriterlere uygun bir dil gibi görünüyor ancak C#’ın Türkiye’deki artan popülerliğini ve yaygınlığını da dikkate aldığımızda Java ikinci planda kalıyor.

Açıkçası ben kendi adıma, bitirdiğim Bilgisayar Mühendisliği bölümünün öğretim programını düşündüğümde Bilgisayar Bilimleri alanındaki konulara verilen ağırlığın çok yerinde ve dengeli olduğunu düşünüyorum ve Pascal ile başlayıp C ile devam eden programlama derslerinin iyi ve sağlam bir temel oluşturduğuna inanıyorum. Bence Bilgisayar Bilimleri’nin ağırlığının yüksek olduğu bölümlerde Pascal ve C gibi bir dilin mutlaka ders programında yer alması gerekir. İlk öğretilen programlama dili olarak Java veya C# gibi nispeten daha yüksek seviyeli bir dil olsa bile devamında Veri Yapıları ve Algoritmalar derslerinin uygulamaları için Pascal ya da C gibi prosedürel bir dilin kullanılması yararlı olur. Sonrasında zaten ihtiyaca ve bireysel tercihlere göre yeni dillerin öğrenilmesi ve bu dillerde uzmanlaşılması çok büyük bir sorun olmayacaktır. Elbette ki öğretim programı içerisinde hangi dil kullanılırsa kullanılsın OOD ve OOP ağırlıklı en az bir dersin bulunması gerekir. Bunun yanı sıra bir süre öncesine kadar sadece akademik olduğu düşünülen ancak artık yazılım sektöründe oldukça ciddi bir yer edinmeye başlayan fonksiyonel dillerden birine de (mesela bir Lisp türevi olan Scheme) öğretim programında yer verilmesi çok yerinde olacaktır.

Yurtdışında da akademik dünyada uzun süredir bu konuda çok çeşitli, benzer görüşler ve tartışmalar var. Hatta ilk yıl programlama ile ilgili bir ders konulmasının Bilgisayar Bilimleri bölümünü zorlaştırdığını, programlama dersinin ileriki yıllarda görülmesi gerektiğini savunan görüşlere bile rastlamak mümkün.

Konuyu daha fazla dağıtmadan bitireyim. Uzun lafın kısası, Bilgisayar bölümlerinde hangi programlama diliyle başlanmalı, nasıl devam edilmeli, bir dil ile temelleri öğretip sonra başka bir dile mi geçilmeli, yoksa başından sonuna kadar bir dil üzerinde uzmanlaşılacak bir program mı hazırlanmalı? Emirsel/komutsal (Imperative) bir dil yerine günümüzde epeyce popüler hale gelen fonksiyonel dillerden biriyle mi başlanmalı? Bu konudaki düşünceleri duymak isterim, lütfen yorumlarınızla katılın.

Birincil Anahtar (Primary Key) olarak ne kullanılması gerektiği veritabanı tasarımında en sık karşılaşılan ve çözümü de çok kolay olmayan bir sorundur. Aslında veritabanı teorisi açısından en doğrusu Doğal Anahtar (Natural Key) olan kolonun birincil anahtar olarak kullanılması. Ancak pratikte bunun çeşitli sakıncaları bulunduğu için pek tercih edilmiyor. Günümüzün Nesne Yönelimli (Object Oriented) tasarımlarıyla daha iyi örtüştüğü için Doğal anahtar yerine Surrogate Key (harici, vekil anahtar) kullanımı daha çok tercih ediliyor. Özellikle de ORM (Object Relational Mapping) gibi veri ve iş mantığı katmanlarının kullanıldığı yazılım projeleri için Surrogate Key tek seçenek durumunda.

Surrogate Key’i kısaca tanımlamak gerekirse; kayıtlardaki veriyle hiçbir doğal bağlantısı ve ilgisi olmayan, tek amacı kayıtları eşsiz olarak nitelemek olan, genellikle de değerini veritabanı sisteminin kendisinin ürettiği tablo kolonudur. Çoğunlukla bu kolonun veri tipi olarak otomatik artan (Auto Increment, Identity, Sequence gibi) Integer ya da GUID (Globally Unique Identifier = Küresel Eşsiz Tanımlayıcı) tercih edilmektedir. İşte asıl sorun da bu noktada yaşanmakta: Bu ikisinden hangisini seçmeli ve neden? Ne yazık ki bu sorunun tek ve kesin bir yanıtı yok. Tasarlanmakta olan sistemin bugünkü ve de öngörülebilen gelecek ihtiyaçlarına bağlı olarak bir tercih yapılması gerekiyor. Bu tercihi yaparken her iki seçimin de avantaj ve dezavantajlarını ortaya koymak ve bunları iyi değerlendirmek gerekiyor. Bu makalede her iki veri tipini ayrı ayrı ele alacağız ve bir sonuca ulaşmaya çalışacağız.

GUID – Globally Unique Identifier

+ Bu veri tipinin en büyük avantajı evrensel olarak (ve en azından teoride) eşsiz değerlere sahip olması. Sadece bir tablodaki bütün satırlar değil, veritabanındaki tüm satırlar, hatta ve hatta evrendeki tüm tablolardaki tüm satırlar eşsiz kimliğe sahip olacak.

+ Eşsiz olma özelliğinden dolayı dağıtık durumdaki veritabanlarını bir gün gelip de merkezi hale getirmek gerektiğinde yani merge etmek (birleştirmek) gerektiğinde hiçbir sorun yaşanmadan, hiçbir dönüşüme gerek kalmadan bu işlem gerçekleştirilebilir. Dolayısıyla bu veri tipinin tercih edilmesinde kurulan sistemin böyle bir gereksinime cevap verebilir olmasının gerekliliği en önemli etkendir. (Örneğin MSSQL Server’da replikasyon yapıldığında eğer yok ise sistem her tabloya bir adet GUID kolon ekliyor.)

+ Programsal olarak üretilebildiği için veritabanına Insert işlemi sırasında değeri bilinebilir ve böylece Insert’ten sonra bir kez de en son kullanılmış değeri elde etmek için veritabanı sunucusuna bir erişime daha ihtiyaç duyulmaz. ORM açısından da bunun güzel bir özellik
olduğu düşünülebilir.

- GUID’nin en büyük dezavantajı veri boyutunun çok büyük olmasıdır. GUID’nin boyutu 128 bit = 16 byte’tır. Birincil anahtar olarak GUID kullanılan bir tablodaki diğer bütün index’lerin de bu 16 byte’ı taşıyacağı anlamına gelir. Sonuç olarak fazladan veritabanı boyutu ve disk alanı demektir. Elbette ki fazladan I/O işlemi = performans sıkıntısı.

- Veritabanı açısından değil belki ama yazılım geliştiriciler açısından B85E62C3-DC56-40C0-852A-49F759AC68FB gibi değerlerin debug etme işini epeyce zorlaştıracağı da bir gerçek.

- Çoğu veritabanı yönetim sistemi artık GUID veri tipini kendiliğinden destekliyor olsa da bunu doğal olarak desteklemeyen sistemlerde karakter veri tipi olarak tutulması gerekebilir (gerçek bir uygulamada böyle yapılmak zorunda kalındığını biliyorum).

- GUID’ler üretildiklerinde belli bir sıra takip etmezler, yani tamamen rastgele üretilirler. Yani, sonradan üretilen GUID, bir önceki GUID’den daha büyük olmak zorunda değildir. Bu durum bize Clustered Index şeklindeki birincil anahtar olarak tanımlanan GUID kolonlarda büyük bir
dezavantaj oluşturmaktadır. Bildiğiniz gibi Clustered Index demek, verilerin bu index’e göre veritabanı sayfaları üzerinde gerçekten doğal sırasıyla tutulması anlamına geliyor. Yani Clustered olmayan indexler gibi sadece index olmaktan ibaret değil. Bu durumda her sırasız Insert için tabloya ait sayfalarda yer değiştirme ve yer ayırma yapılması gerekiyor. Bu soruna çözüm olarak mesela MSSQL Server 2005′ten itibaren Sequential GUID gibi -bence zorlama ve uydurma- veri tipleri gelmekte ya da sıralı GUID üreten fonksiyonlar yazılmakta. Ek olarak, GUID türündeki birincil anahtarların Clustered yapılmaması da dikkat edilmesi gereken bir konu.

Identity Integer

+ Eğer 4 byte’lık Integer veri tipi kullanılırsa işlemci için en doğal ve en hızlı işlenen veri tipi olması bakımından ilişkisel veritabanı operasyonları için en uygun veri tipi olduğu söylenebilir.
16 byte genişliğinde GUID veri tipiyle kıyaslandığında veritabanı ve disk alanı bakımından da son derece avantajlı olduğu görülüyor.

+ Sıralı üretildikleri için GUID’deki Clustered Index problemi yaşanmıyor.

+ Program geliştiriciler için debug edilmesi, gözle takip edilmesi son derece kolaydır.

- Kayıt Insert edildikten sonra son üretilen Identity değeri elde etmek için sunucuya fazladan bir erişim yapmak ve işlem yaptırmak gerekiyor.

- Ayrık veritabanlarını merkezi olarak birleştirmek gerektiğinde çakışan değerler için ekstra uğraş gerekiyor.

Sonuç ve Değerlendirme

Dağıtık veritabanlarının replike edilmesi ya da merkezileştirilmesi gibi ihtiyaçlar söz konusu ise GUID büyük boyutuna ve diğer dezavantajlarına rağmen en iyi seçenek gibi görünüyor. Bunun dışında, 32 bit ya da gerçekten gerekli ise 64 bit Integer Identity şeklindeki Surrogate Key daha az masraflı, daha fazla sistem tarafından doğal olarak desteklenen ve daha pratik bir seçenek durumunda. Bu aşamada kişisel bir tercih belirtmem gerekirse mutlaka gerekmiyorsa GUID’den uzak durmayı seçiyorum.

Mesai arkadaşlarımızla özellikle de Delphi geçmişi olan arkadaşlarımızla .Net Framework’ünün önemli özelliklerinden biri olan Garbage Collector (GC / Çöp Toplayıcı) üzerine zaman zaman tartışmalar yapıyoruz. Tartışmalarda en çok, eskiden olduğu gibi Create-Free ikilisini .Net uygulamalarında da kullanmanın bir yararının olup olmayacağı sorusu gündeme geliyor. Devamında şu sorulara yanıt aranıyor;

• GC ne kadar güvenilir?
• Ne kadar sıklıkla temizlik yapıyor?
• Sistemi çok meşgul etmiyor mu?
• Bir sürü nesne yaratılıyor, form açılıyor, kapanıyor, bunların temizliğini GC’ye mi bırakacağız?

Üniversitedeyken Java’nın orijinal kütüphanelerinin kodlarını incelediğimde de mesela dizilerle ilgili statik metodlarda sıklıkla “bırakalım gerisini GC halletsin” şeklinde yorumlara rastlamış ve bunu derste hocamızla tartışmıştım. Tartışmamızın sonucunda Garbage Collector özelliği olan bir dil/sistem kullanıyorsak buna güvenmekten ve kodlarımızda bunun verdiği rahatlığı kullanmaktan daha doğal birşey olmayacağı sonucuna varmıştık.

Yani sonuç olarak .Net’in sunduğu Garbage Collector bizi managed olmak koşuluyla hafıza yönetimi ve kaynak geri dönüşümüyle ilgili her türlü sıkıntıdan kurtarıyor. Artık create-free çevrimine çok fazla takılmadan kodumuzun asıl yapacağı işe odaklanabiliriz.

Garbage Collector hakkında MSDN’de de bir miktar bilgi bulabilirsiniz.

—————————————–

Bu konu ile ilgili Tess Ferrandez’in MSDN’deki blog’unda bir quiz ve bu quiz’in cevapları var.

Bazıları biraz daha derine iniyor ama mesela ilk bakışta benim ilgimi çeken ve pratik olarak yararlı bulduğum bir tanesini buraya alıntılamak istiyorum.

12. Why is it important to close database connections and dispose of objects? Doesn’t the GC take care of that for me?

I think pretty much all of you got this one:) To paraphrase Arnaud, “The finalizer will eventually be called, after the object has been made available for garbage collection. Knowing that there may be quite some time until an object gets GC’ed, and that many resources are limited, you call Dispose yourself as soon as you’re over with an object. It doesn’t get GC’d when you call Dispose, but it releases its resources.”

Hızlıca bir çevirecek olursak;
Soru: İşimiz bittiğinde veritabanı bağlantılarını kapatmak ve ilgili nesneleri Dispose etmek neden önemlidir? GC bütün temizlik işini bizim yerimize zaten halletmiyor mu?
Cevap: İlgili nesne GC için uygun hale geldiğinde eninde sonunda GC tarafından temizlenecek. Ancak GC’nin bunu yapması için oldukça uzun bir zaman geçebilir. Veritabanı bağlantısı gibi kaynaklar sınırlı sayıda olduğunda Dispose çağrısı yaparak işimiz bittiğinde kaynakları elimizden çıkartmak gerekir. Şu da var ki Dispose çağrısı yaptığımızda GC tarafından hemen temizlik yapılmaz, sadece bize ayrılmış kaynaklar serbest bırakılır.

Sonuç olarak, IDisposable arabirimini destekleyen sınıflarda Dispose metoduyla temizlik yapmak –özellikle de veritabanı bağlantısı gibi nispeten daha sınırlı kaynaklar için– iyi bir alışkanlık gibi görünüyor. Zaten çoğumuz veritabanı bağlantısı ile ilgili olarak Dispose’un otomatik çağrılmasını sağlayan using bloğunu kullanıyoruzdur.

Keyifle okunacak ya da en azından göz atılacak, eğlenceli bir kitaptan daha bahsetmek istiyorum. Adında da yazdığı gibi yazılım endüstrisinin devlerinin tescilli/patentli (İng.proprietary) yazılımlarına karşı açık kaynaklı özgür (bedava olarak çevirsek daha mı anlamlı olur acaba ) yazılımların ve yazılım servislerinin savaşını anlatan ilginç bir kitap.

Kitapta yoğun bir şekilde Linux’un yaygınlaşmasının ve gücünün ardındaki etkenler ile Linux’un bu başarısına karşılık Microsoft’un yaptıkları/yapabildikleri üzerinde duruluyor. Linux-Windows-Mac gibi işletim sistemi savaşlarının yanı sıra OpenOffice.org-MS Office gibi son kullanıcı ürünleriyle birlikte Sun’ın Java’sı ve Microsoft’un programlama dilleri gibi geliştirme araçları da karşı karşıya getiriliyor.

Kitapta ayrıca patentlerden ve telif haklarından da bahsediliyor. Daha önce tanıtmaya çalıştığım Math You Can’t Use: Patents, Copyright, and Software adlı kitabın geniş olarak üzerinde durduğu programların da soyut matematiksel kavramlardan ibaret olduğu ve patentlenemeyeceği düşüncesi de işleniyor.

Son olarak kitaptan Definition of Free Software bölümünden bir alıntı yapalım:

Richard Stallman 4 temel yazılım özgürlüğü tanımladı:
1. Hangi amaç için olursa olsun programı çalıştırma (*) özgürlüğü.
2. Programın nasıl çalıştığını anlama ve gereksinimlere göre adapte etme özgürlüğü.
3. Programın bir kopyasını komşunuza verebilme özgürlüğü. Onları yaratmaya ve göstermeye yarayan programları paylaşmadan fikirleri paylaşmak imkansızdır.
4. Programı ilerletme, yeni sürümü kamuya dağıtma ve böylece kamunun bundan yararlanmasını sağlama özgürlüğü.

(*) “to run the program” ifadesini “programı koşturmak” şeklinde çevirenleri hiç anlamıyorum, anlamak istemiyorum.

Kitabın Adı: After the Software Wars
Yazarı: Keith Curtis
ISBN: 9780578011899

Kitabın önsözünde kitabın dijital kopyasının serbestçe dağıtılabileceği, edinmek isteyenlerin lulu.com üzerinden indirmelerinin uygun olacağı belirtiliyor. Bu yazıyı yazdığım sırada lulu.com’da boş bir sayfa geliyor olsa da şansınızı denemek isteyebilirsiniz.