Microsoft’un Çöpe Giden Yazılım Teknolojileri

25 Ara
  • Silverlight
  • WCF
  • WPF
  • Windows Forms
  • Web Forms

Microsoft teknolojilerinde son yıllarda önemli gelişmeler yaşanıyor. Takip etmekte zorlandığımız bu değişiklikler şüphesiz olması gereken şeylerdir. Yukarıda listelediğim teknolojiler, Microsoft’un  bir dönem parlayan yıldızlarıydı. Geçen zaman içinde yazılım dünyasında yaşanan evrim sonucu , Microsoft tarafında bir takım sorunlara çözüm bulmak ve bazı teknolojilerle rekabeti yakalayabilmek adına bir takım gelişmelere neden oldu. Yazılım dünyasındaki her yeni gelişme, karşımıza yeni bir ürün olarak çıktı. Gelişme ilerledikçe evrim, bir takım organların sonunu getirdi. Şunu da belirtmeliyim ki bu yazı Microsoft teknolojilerine karşı durmak için değil, bazı teknolojilerin zamanla yerini başka teknolojilere bıraktığını anlatmak amacıyla kaleme alınmıştır. Serbest pazar ortamında her firma ürününü ortaya koyar ve herkes istediği teknolojiyi dilediğince seçmekte özgürdür.

Silverlight

Adobe Flash, Java Flex v.b gibi client taraflı uygulamalara alternatif olarak üretilen zengin içerik ürünü Silverlight, mobil internet tarayıcılar tarafında yetersiz kalınca ve geliştiricilerin Javascript gibi tüm tarayıcılarda çalışabilen bir teknolojiyi tercih etmesiyle fişi çekilen teknolojilerden biri oldu. Ülkemizde ve diğer ülkelerde Silverlight düşkünü yazılımcılar için adeta bir hayal kırıklığı oldu. Çünkü bu gelişme birçok yatırımın güncelliğini yitirip zamanla çöpe gitmesi demekti.

WCF

Servis odaklı altyapı sistemleri için geliştirilen WCF teknolojisi SOAP ve RESTful servisler oluşturmak için bir altyapı sunmaktadır. HTTP tabanlı REST servislarinin yaygınlaşmasıyla ivme kaybeden ve durma noktasına gelen hatta bitti denilebilecek teknolojilerden birisi. WCF teknolojisi SOAP servisleri oluşturmak için ideal bir seçimdir. Ancak RESTful servisler oluşturma konusunda liderliğini WEB API teknolojisine kaptırmıştır. (Güncelleme: WCF servislerinin REST ve SOAP ayrımına vurgu yapıldı. 21.02.2015)

Windows Forms

Masaüstü programlama araçlarından Windows Forms teknolojisi ise WPF teknolojisinin gelmesiyle silikleşen teknolojiler arasında. WPF teknolojisini Windows Forms teknolojisine göre makul kılan özelliklerin başında View tarafı ile Model tarafının birbirinden ayrılmasını sağlamasıydı. Windows Froms, kod arayüzü ve grafik arayüzü ile çalışmaktadır. WPF ise kod arayüzü, grafik arayüzü ve grafik arayüzünü şekillendirebilen XAML arayüzü ile ortaya çıkmıştır. Bu durumda MVVM (Model-View-ViewModel) yazılım desenlerinin uygulanması kolaylaşmakta ve daha kolay yönetilebilir uygulamalar geliştirilebilmektedir.

WPF

Windows 8 ile birlikte bizi işletim sistemi düzeyinde şaşırtan Microsoft, XAML teknolojisini .Net framework tarafından işletim sistemi üzerine alarak bizi tekrar şaşırttı. Bu da demek oluyor ki artık masaüstünde artık WinRT teknolojisi yer alacak. Bu durumda WPF teknolojisi de yıkılmak üzere demektir.

Web Forms

Microsoft’un Web geliştirme tarafında sihirli çubuğu olan Web Forms teknolojisi de MVC uygulama mimarisine yenik düştmüştür diyebiliriz. Web Forms ile oluşturulmuş birçok popüler web sitesi bu günlerde MVC teknolojisine geçiş yapmaya başladı bile. Web Forms teknolojisinin hakkını yememek lazım ki çok sayıda popüler uygulamaya temel oluşturmuştur. Ancak MVC teknolojisinin iş birimlerinin birbirinden ayrılmasını sağlayan mimarisi ve bu sayede geliştirici hakimiyetini ön plana çıkarması ayrıca birim test yazmaya olanak  sağlaması zamanla onu popüler hale getirmiştir. Şahsen ben Web uygulamalarına direk MVC tarafından başlayanlardanım. (Güncelleme: 21.02.2015)

Microsoft gelişime, yeniliğe önem veren bir şirket. Ancak insanların yıllarca üzerinde çalışıp yatırım yaptığı teknolojilerin birden yok olması geliştiricileri ve şirket yöneticilerini sıkıntıya sokabiliyor. Bu durumda şu soru akıllara geliyor. Bu teknoloji de son bulursa ne yapacağız? Gelişim oldukça bir şeylerin sonu gelecek elbette.

Çöpe giden teknolojiler sadece Microsoft tarafıyla sınırlı değildir. Open source tarafında da çok fazla proje çöpe gitmiştir. Örneğin java tarafında da MVC yaygınlaşınca Serve taraflı bileşen teknolojiler pek tercih edilmez hale gelmiştir.

Bu durumda öngörülü olmak önem arz etmektedir. Spesifik teknolojiler yerine platform bağımsız teknolojilere eğilim göstermek her zaman faydalı olacaktır. Hangi programlama dili olursa olsun, yapılan iş genele hitap edecek şekilde tasarlanmalıdır. Bu sayede genişletilebilirlik(extensibility) ilkesi ile hareket etmiş oluruz ve hiç bir teknolojiye sıkı sıkıya bağımlı kalmayız.

Renk Tabanlı Unit Test Süreci ve Örnek Uygulama

25 Oca

Renklerle ilgili işlemler yapmak, component’lerin renk tabanlı özelliklerini değiştirmek, yazılım geliştirme sürecinde uyguladığımız basit operasyonlardır. Bu kez reklerle ilgili işlemlerin unit test mantığı kullanılarak nasıl gerçekleştirilebileceği incelemeye çalışacağız. Aslında yapacağımız işlem basit olarak bir ana renge ait değişik renk tonlarının oluşturulması şeklinde ilerleyecek. Örneğin “kırmızı” renge ait “N” adet renk tonunu unit test ile oluşturmaya çalışacağız. Daha sonra oluşturulan bu renk tonlarını bir WPF uygulaması içerisinde uygulayacağız. Senaryomuzu basitçe sunduktan sonra işleyişe geçebiliriz. Ortaya çıkan ürün aşağıdaki gibi olacaktır.

colorUnitTest2

Sürecimiz önce testlerin yazılıp daha sonra geçen testlerden kod üretimi şeklinde gelişmektedir. Bunun için öncelikle Visual Studio üzerinde “ColorManager” isimli bir proje başlatarak ilerleyelim.

colorUnitTest1

Devamında “ColorManager.Tests” adında bir proje daha ekleyerek test sürecinin işletileceği bir proje başlatıyoruz.

Bu uygulama için kullanılan Unit Test aracı, Nunit test aracıdır. Nuget Package Manager üzerinden eklenebilen bir referanstır.

İlk testlerimizi aşağıdaki geibi geliştirmeye başlayabiliriz.

[Test]
public void Create_WithClassSize1_ReturnsOneColorInList()
{
      var inputColor = Colors.Red;
      var inputSize = 1;

      ColorToneCreator creator = new ColorToneCreator();

      var result = creator.Create(inputColor, inputSize);

      Assert.AreEqual(1, result.Count);
}

İlk testimizde inputSize olarak yani kaç çeşit renk tonu oluşturulacağını 1 olarak belirleyip, bize dönen listede 1 adet renk tonu oluştuğunu idda ediyoruz.

[Test]
public void Create_WithClassSize1_ReturnsSameColorInList()
{
    var inputColor = Colors.Red;
    var inputSize = 1;

    ColorToneCreator creator = new ColorToneCreator();

    var result = creator.Create(inputColor, inputSize);

    Color color = result[0];

    Assert.AreEqual(255, color.R);
    Assert.AreEqual(0, color.G);
    Assert.AreEqual(0, color.B);

}

İkinci testimizde ise yine 1 çeşit renk tonuna karşılık oluşan rengin RGB değerlerinin ne olacağını idda ediyoruz. Kırmızı rengi gönderdiğimiz için R=255, G=0, B=0 olarak bize geri dönecektir.

[Test]
public void Create_WithClassSize2_ReturnsColorsInList()
{
     var inputColor = Colors.Red;
     var inputSize = 2;

     ColorToneCreator creator = new ColorToneCreator();

     var result = creator.Create(inputColor, inputSize);

     Color color = result[0];

     Assert.AreEqual(255, color.R);
     Assert.AreEqual(0, color.G);
     Assert.AreEqual(0, color.B);

     Color color2 = result[1];

     Assert.AreEqual(255, color2.R);
     Assert.AreEqual(127, color2.G);
     Assert.AreEqual(127, color2.B);
}

Üçüncü testimizde ise kırmızı renge ait iki farklı ton seçeneğini test ediyoruz. Ortaya çıkan iki renkten birincisi için RGB değerleri R=255, G=0, B=0 şeklinde iken ikincisi için R=255, G=127, B=127 şeklinde olacaktır. En yüksek değer 255 olduğundan eşit dağılım olması açısından 255 değeri renk tonu sayısına bölünerek değerler hesaplanmaktadır.

Buraya kadar gelişen test sürecinden üretilen kod ise şu şeklide olacaktır.

public class ColorToneCreator
{
     public List<Color> Create(Color inputColor, int inputSize)
     {
          int rgbFactor = 0;
          int incFactor = 255 / inputSize;

          List<Color> tones = new List<Color>();

          for (int i = 0; i < inputSize; i++)
          {
             byte r = (byte)(inputColor.R + rgbFactor > 255 ? 255 : inputColor.R + rgbFactor);
             byte g = (byte)(inputColor.G + rgbFactor > 255 ? 255 : inputColor.G + rgbFactor);
             byte b = (byte)(inputColor.B + rgbFactor > 255 ? 255 : inputColor.B + rgbFactor);

             tones.Add(Color.FromArgb(255, r, g, b));
             rgbFactor += incFactor;
          }

          return tones;
     }

}

Test sürecinden gelişen üretim kodu bu şeklide oluştuğuna göre artık geriye sadece bu kodu bir uygulama içerisinde kullanmak kallıyor.

Bu kodun kullanılacağı uygulamayı ise WPF uygulaması olarak seçiyoruz. Solution penceremize ColorManagerGUI adında yeni bir WPF projesi ekleyerek devam edebiliriz.

colorUnitTest3

Yeni solution penceresi yukarıdaki şeklinde olacaktır. WPF uygulaması MVVM deseni ile geliştirilmiştir. MainWindow.xaml view penceresinin DataContext’i için MainWindowModel şeklinde bir model sınıfı oluşturulmuştur. Bu sayede kod tarafı ile xaml tarafı birbirinden ayrılmış oldu.

Görüntü katmanında gelişen olaylar, form tasarımı ve bir butona tıklayarak parametrelerin, ColorManager tipine gönderilmesi şeklinde gelişmektedir. Aynı şekilde dönen rek tonları da formda bir ListBox içerisine yerleştirilmektedir.

Uygulamanın kaynak kodlarını ekte sunulmaktadır. Bu yüzden görüntü katmanını uzun uzun anlatmaya gerek duymadım. Zaten burada asıl vurgulanmak istenen, renk tabanlı bir uygulamanın test güdümlü olarak nasıl geliştirildiğidir.

Anafikir:

Bu örnek uygulamada renk tabanlı test güdümlü bir süreç işletilmiştir. Bu yöntemden yola çıkılarak görüntü işleme uygulamaları da test güdümlü olarak gelişitirilebilir. Bellek üzerine döşenmiş bir Bitmap nesnesi üzerinden de RGB tabanlı olarak test güdümlü geliştirmeler yapmak mümkün hale gelmektedir.

Örnek Uygulama:

Kodlara buradan ulaşabilrisiniz.