Visual Studio 2012 Update Enkazı

28 Mar

Visual studio ürün ailesine dahil edilen 2012 sürümünü çoğumuz kurup çalışmaya başlamışızdır. Bu versiyonda dikkatimi en çok cezbeden nokta Update süreleriydi. Daha Visual Studio ürününü yükler yüklemez bir Update uyarısı verdi. Yeni ürünün yeni güncellemesini yüklemek istedim. Aman Allah’ım! Tam üç saat. Tabi bu internet hızı ile alakalı bir durum mu yoksa bilgisayar donanımı ile alakalı mı diye bir düşünce sardı beni hemen. Derken güncelleme işlemi hayırlısıyla sona erdi.

Visual Studio Update
Visual Studio Update

Aradan bir iki ay geçti, Visual Studio’yu başlattığımda bu sefer de Update1 diye bir uyarı belirdi Windows’un sağ alt köşesinde. Eyvah! dedim içinden. Gene kabus başladı. Tam 2 saatte Update1 için zaman harcadım.

Bu kadar uzun süren Update yapacaklarına yeni versiyon çıkarsalar daha isabetli olurdu bence. Çünkü Visual Studio ürününü sıfırdan yükleme süresi zaten yarım saat. Bu yarım saat üzerine 5 saatlik güncelleme yükü çok can sıkıcı oluyor. Bu kadar can sıkıcı olmasaydı bu yazıyı ele almazdım inanın.

Ürünün önceki sürümlerinde böyle bir durumla karşılaşmamıştık. Umarım buna bir önlem alırlar ve Update 2 çıkmadan ürün yenilenir. Yeni bir güncellemeye ayıracak vaktim yok.

Bir sonraki yazıda görüşmek üzere.

Kitap – The Art of Unit Testing

24 Mar

Kitap tanıtım bölümü kategorisine eklediğim bu yazı “The Art of Unit Testing” adlı kitap üzerine olacaktır. Roy Osherove tarafından yazılmış olan bu kitap Manning yayıncılık tarafından piyasaya sürülmüştür. Kitabı amazon.com üzerinden temin ettim. Kargo maliyetinden kaçınmadığımdan kitap 4 günde elime ulaştı. Resimde de görüldüğü üzere artık elimde.

Amazon Kargo Paketi
Amazon Kargo Paketi

Hemen paketi açıp merakımı gidermek istedim. İçeriği, dış kapağı, faturası… her şeyini merak ediyordum.

Kitap
Kitap

Kitabı bir hafta gibi bir sürede okudum. Bende oluşturduğu izlenim, Unit Test konusunda bilgisi olan geliştiricilerin okuması gereken bir kitap olduğu şeklindeydi. Test Driven Development konusunda hiç bilgisi olmayan bir geliştiriciye çok faydalı olacağını söyleyemem. Çünkü sıfırdan Tets Driven tekniğini anlatan bir içeriğe sahip değil. Ancak unit testleri yazarken dikkat edilmesi gereken kuralları güzel bir şekilde anlatıyor. Diğer yandan unit test yazarken gerekli olan ve kullanılması framework’lerden bahsetmektedir. Unit test yazma sanatını anlatan bir çeriğe sahip. Kitaptaki örnek uygulamalar .Net platformunda C# programlama dilinde yazılmıştır. Sade ve anlaşılır bir dille kalema alınmıştır.

Test Driven Development ile geliştirme yapanların baş ucunda bulunması gereken kitaplardan biri diyebilirim.

Kitabın amazon.com linkine buradan ulaşabilirsiniz.

Yazılarıma Yapılan Backlink Amaçlı Yorumlar

22 Mar

Uzun süredir blog sayfamdaki makalelere gönderilen spam yorumları silmekle uğraşıyorum. Yorum gönderme formuna eklediğim doğrulama kodları da bir şekilde aşılıyor olmalı ki uyduruk yorumlar gelmeye devam ediyor. Bende sürekli bu tarz yorumları silmek zorunda kalıyorum. Aşağıdaki resimde bir aylık bir sürede sitemdeki makalelere gelen işe yaramaz yorumların sayısı 1761’dir.

Yorumlar
Yorumlar

Gelen yorumların çoğu kumar siteleri, alışveriş siteleri, ilaç siteleri, kredi veren sitelerin backlink içeriğiyle dolu. Bu eski bir SEO tekniğidir. Bu yorumların amacı web sitelerinde backlink yaratarak arama motorlarında üst sıralara çıkmak. Fakat Google gibi aramama motorları bu tarz girişimlere karşı her zaman hazırlıklı olduğundan sürekli sıralama algoritmalarını güncel tutarlar. Bu şeklide backlink alma teşebbüslerine karşılık ceza uygulamaları yaparlar. Örneğin wordpress, joomla v.s gibi hazır portallar bu tarz backlink girişimlerine karşılık yorumlardaki linkleri “nofollow” olarak işaretlemektedir. Bu da arama motorlarının bu linki backlink olarak dikkate almayacağı anlamına gelir.

Diğer taraftan bu kadar işe yaramaz yorumun yanında yazılarıma gayet güzel geri dönüşler alıyorum. Yorumlarını esirgemeyen okurlara teşekkürlerimi sunuyorum.

Bir sonraki yazıda görüşmek dileğiyle.

Abstract Factory Method Tasarım Deseni

20 Mar

Factory Method tasarım deseni, nesne oluşturma ihtiyacı doğrultusunda ortaya çıkmış bir tasarım desenidir. Bu tasarım deseni, oluşturulacak somut nesnenin türünü belirlemeye gerek duymadan nesne oluşturma işlemini temel almaktadır.

Resim-1
Resim-1

Factory deseninin temel amacı nesne oluşturma karmaşıklığını kullanıcıdan gizlemektir. Ayrıca kullanıcı, oluşturulacak nesnenin somut türünü belirlemek zorunda değildir. Bunun yerine somut nesnenin implemente edildiği soyut tür olan interface veya abstract class tipini bilmesi yeterlidir. Yani sorumluluk somut nesnelerden soyut nesnelere aktarılmaktadır. Genel olarak Factory sınıflar “static” erişim belirleyicili bir metod barındırırlar. Bu metod, kullanıcıya interface veya abstract class tipinde bir nesne döndürür. Bu sayede kullanıcılar, alt sınıfların oluşturulması sorumluluğundan dolayı oluşabilecek hatalardan da uzak tutulmuş olur.

Örnek Uygulama

Bu örnek uygulamamızda Grafik türüne göre Grafiğin temsilini yapan Sembollerin oluşturulmasını Factory Method yöntemiyle üretmeyi amaçlamaktayız.

Yukarıdaki şekildeki tasarım deseninin uygulanışını şu şeklide yapabiliriz.

Resim - 2
Resim – 2

Gerçek bir uygulamadan alarak göstereceğim bu örnekte bir REST servisinden gelen Graphic nesnesinin türüne göre sembol nesnesinin belirlenmesi işlemini Factory Method inceleyeceğiz. Tabi bu örnekteki konumuz Factory uygulaması olduğundan Servis işlemlerini temsili olarak göreceğiz. Bizi ilgilendiren sadece nesne üretimi olduğundan nesne üretim aşamasını inceleyeceğiz.

   public class Graphic
   {
      public Symbol Symbol { get; set; }
   }

Bize servis tarafından sunulan Graphic nesnesi Null olarak gelmektedir. Biz yazılım tarafında Graphic nesnesinin türüne göre Sembolünü üretmekle sorumluyuz.

public abstract class Symbol
{
     public abstract void draw();
}

Symbol sınıfının soyut bir tip olduğunu görüyoruz. Graphic sınıfında da bu soyut tip kullanılmıştır.

public class SimpleLineSymbol: Symbol
{
    public override void draw()
    {
       // Draw line
    }
}

public class SimpleFillSymbol: Symbol
{
     public override void draw()
     {
       // Draw polygon
     }
}

public class SimpleMarkerSymbol: Symbol
{
    public override void draw()
    {
       // Draw point
    }
}

Somut sembol sınıfları ise SimpleLineSymbol, SimpleFillSymbol, SimpleMarkerSymbol şeklinde oluşturulmuştur.

public class GraphicSymbolFactory
{
    public static Symbol GetSymbol(Graphic graphic)
    {
        if(graphic is Point)
           return new SimpleMarkerSymbol();
        if(graphic is Polygon)
           return new SimpleFillSymbol();
        if(graphic is Polyline)
           return new SimpleLineSymbol();

        throw new InvalidExpressionException("Unknown graphic type");
    }

}

GraphicSymbolFactory sınıfına eklediğimiz GetSymbol metodu, Graphic türüne göre somut olan Symbol tiplerini oluşturmaktadır. Dikkat edecek olursak kullanıcıya soyut olan bir Symbol tipi vermekteyiz. Yani içerde olup bitenden kullanıcılar haberdar değildir.

public class GraphicService
{
    private readonly IGraphicRestService service;

    public GraphicService(IGraphicRestService service)
    {
       this.service = service;
    }

    public Graphic GetGraphicsFromRESTService(string serviceUrl)
    {
       Graphic graphic = service.GetGraphic(serviceUrl);

       graphic.Symbol = GraphicSymbolFactory.GetSymbol(graphic);

       return graphic;
    }

}

GraphicService sınıfı içerisinde tanımlı GetGraphicsFromRESTService metodu, bir servis yardımıyla Graphic nesnesini elde etmektedir. Gelen Graphic nesnesinin sembolü ise kullanıcı tarafından Factory sınıfı yardımıyla belirlenir. Burada kullanıcı diye adlandırdığımız GraphicService sınıfıdır aslında. Çünkü API içerisinde hazırladığımız GraphicSymbolFactory tipini kullanan sınıftır. Kullanıcı sınıf aslında Symbol tipinden türetilen SimpleLineSymbol veya SimpleFillSymbol gibi tiplerden haberdar değildir. Bu somut tipleri oluşturmak zorunda da değildir. Bu karmaşık sorumluluğu Factory deseni ile bir sınıfa aktarmış olduk.

Bir başka yazıda görüşmek dileğiyle.

LINQ sorgularında Karşılaşılan NotSuportedException

11 Mar

LINQ sorguları kolleksiyon temelli yapılarda sorgulamalar ve seçimler yapmak için bize imkan sağlar. Döngülerle diziler içerisinde boğuşmadan istediğimiz formatta sonuç almamıza yardımcı olurlar.

Bazen ihtiyaçlarımız doğrultusunda bir tipte oluşturulmuş kolleksiyon içerisinden başka bir tipte seçimler yapmak durumunda kalabiliriz. Bu noktada kurtarıcı olarak yine LINQ sorgularından faydalanabilmekteyiz.

Örneğin bir ürüne ait bilgileri tutan “Product” tipine ait kolleksiyon içerisinden bize lazım olan ürün başlıklarını seçip alacağımız “ProductTitle” tipli kolleksiyon oluşturma gereği duyduğumuz bir senaryo düşünebiliriz. Bu durumda tüm “Product” nesnesini taşımak yerine ürün adlarını barındıran “ProductTitle” adlı tipi tercih etmiş oluyoruz. Bu şekildeki bir seçimi yapmak için şu şekilde bir LINQ sorgusu yazabiliriz.

     var productTitles = db.Products.Select(p => new ProductTitle{
           Id = p.Id,
           Name = p.Name
     });

Ancak bazı durumlarda seçim yaptığımız tip özellikleri, Property ataması ile değil de bir kurucu metod (Constructor) ile tipe enjekte edileceği durumu senaryo edecek olursak nasıl bir durumla karşılaşacağımıza bakalım.

     StoreEntities db = new StoreEntities();

     var productTitles = db.Products.Select(p => new ProductTitle(p));

Yukarıdaki sorguyu, eğer bir Entity Framework modeli üzerinde çalıştıracak olursak karşımıza şu şekilde bir hata mesajı çıkacaktır.

Unhandled Exception: System.NotSupportedException: Only parameterless constructors and initializers are supported in LINQ to Entities.

LINQ provider, ProductTitles tipinini kurucu metodunda nasıl bir kodun çalıştırılacağından habersizdir. Entity Framework ise LINQ sorgularını olduğu gibi T-SQL sorgularına dönüştürmeye çalışır. Fakat sorgu içerisindeki bir tipin(ProductTitle) kurucu metodunda neler olup bittiğini bilmediğinden işlem durdurulur ve hata raporu oluşturulur.

Bu durumun çözüm yolu ise Entity Framework tarafından IQueryable olarak sunulan kolleksiyonu AsEnumerable extension metodu yardımıyla IEnumerable olarak değiştirmektir.

     StoreEntities db = new StoreEntities();

     var productTitles = db.Products
                           .AsEnumerable()
                           .Select(p => new ProductTitle(p));

Burada sorguda AsEnumerable() extension metodu önce veriyi çekiyor. Ardından seçilen kolleksiyon içerisinden seçim işlemi yapılıyor. Bu sayede hata giderilmiş oluyor. Entity Framework sorgularının IQueryable ve IEnumerable karşısındaki davranışları ve T-SQL dönüşümünü incelemek için Burak Selim Şenyurt’un buradaki ipucundan faydalanabilirsiniz.

Bir sonraki yazıda görüşmek dileğiyle.

Antipattern Nedir?

2 Mar

Antipattern kavramını yazılım geliştirme sürecinde programcıların günü kurtarmak adına uyguladıkları kötü çözümler olarak adlandırabiliriz.

Antipattern denilen düzensiz işleyişlerin bilgi ve tecrübe eksikliğinden kaynaklandığını söyleyebiliriz. Bilgi ve tecrübe eksikliği yazılım geliştiricide veya takım yöneticisinde olabilir. Sonuçta kötü etkilenen, yazılım süreci olmaktadır.

Yazılım geliştirirken yapılan Antipattern hataları sonucunda biriken problemler, yazılım ilerledikçe çığırından çıkmaya başlar. Yazılıma eklenmesi istenen yeni özellikler ekibin başına dert olmaya başlar. Hatalar artar, sinirler bozulur ve neticede ortaya konulan ürünün müşteriyi yeterince tatmin etmediği anlaşılır. Müşteri isteklerini yerine getirmeyen yazılım ise başarısızdır.

Kodlama sırasında sık karşılaşılan bazı antipattern kavramlarını şu şekilde belirtebiliriz.

  • Analysis Paralysis: Proje analizine harcanan fazla zaman.
  • Overengineering: Bir problemi olduğundan daha zor olarak algılamak.
  • Smoke and Mirrros: Yanıltıcı araçlar kullanmak.
  • God Object: Çok fazla üye içeren nesneler.
  • Golden Hammer: Bir çözümü birçok probleme uygulamaya çalışmak.
  • Hard Coding: Koda gömülen ve değiştirilemeyen değişkenler.
  • Boat Anchor: Kullanılmayan ancak lazım olur diye tanımlanan kodlar.

Daha fazla antipattern için buradan faydalanabilirsiniz.

Bu örneklere baktığımda yazılım geliştirme sürecini bu sıkıntılardan kurtaracak olan can simidinin çevik süreçler olduğunu görüyorum.

Gerçek anlamda uygulanan çevik sürecin hem tasarım aşamasında uygulanan yöntemler hem kodlama aşamasında uygulanan Test Driven Development tekniği hem de yazılıma uygulanan doğru tasarım desenleri ile antipattern denen illetten kurtulmanın mümkün olacağını düşünüyorum.