Arda Çetinkaya Yazılım ve arada kendim ile ilgili karaladıklarım…

Önceki yazılarımdan bir tanesinde hatırlarsanız MEF’e giriş yapmıştık. Çok basit bir uygulama ile MEF’in nasıl işlediğini anlatmaya çalışmıştım.

Bu yazımda biraz daha derin konulara girip, “extension”larımıza(MEF’de ki adı “Part” oluyor) nasıl kendi “metadata” bilgilerimizi verebileceğimizi anlatmaya çalışacağız. Öncelikle neden böyle bir şeye ihtiyaç duyuyoruz, buna bir bakalım.

MEF ile geliştirdiğimiz bir uygulamayı doğası gereği esnek bir yapıda oluyor. Bu esnekliği MEF sağlıyor bize. Kendi yarattığımız arayüzlerden türeterek uygulamıza MEF Part’ları katabiliyoruz. Ama uygulamamızın sadece arayüzlerden türeyen “Part”lar ile esneklik kazanıyor olması bazen istenmeyen bir şey olabilir. Mesela IPlugin diye bir arayüzümüz var diyelim. Ana uygulamamız, bu arayüzden türeyen nesneleri kendi içinde çalıştırabiliyor olsun. IPlugin arayüzünü kullanarak kötü niyetli biri uygulamamızda kötü şeyler yapabilir. Bundan dolayı uygulamamızda “metadata” diye adlandırabileceğimiz ekstra içerik sağlayan özellikleri kullanmakta fayda var. Bu sayede IPlugin arayüzünden türeyen nesneleri kontrol edebiliriz. Ve uygulamamız için geçerli olmayan “metadata”ları uygulamamızın çalıştırmasını engelleyebiliriz.

Peki kendi geliştirdiğimiz “Part”lara kendi “metadata”larımızı nasıl ekleyeceğiz?

Çok basit…Öncelikle kendi “metadata”mızın ne gibi bilgiler içereceğini tanımlamamız lazım. Bunun için bir “interface” ya da “class” kullanabiliriz. Ama ben “interface”i seçeceğim bu örnekte. Aşağıdaki gibi bir kod işimizi görecektir.

    9     //"Metadata"mızın içeriğni belirliyoruz.

   10     //Ne gibi bilgiler tutabileceğimizi istediğimiz gibi tanımlayabiliriz.

   11     public interface IPluginMetaData

   12     {

   13         string Name { get; }

   14         string Version { get; }

   15         string Author { get; }

   16 

   17     }

Daha sonra bu arayüzü kullanan bir “Attribute” yaratmamız gerekmekte ki, geliştireceğimiz “Part”lara bu “metadata” özelliğini verebilelim. Bunun içinde aşağıdaki gibi bir kod işimizi görecektir.

   21     //ExportAttribute tipinde, "Attribute" tanımlıyoruz ki

   22     //Yaratacağımız Part’da bu "Attribute"u kullanabilelim

   23     //Burda önemli olan constructor’da base’i çağırıp

   24     //ExportAttribute’da hangi arayüz ile tanımlama yapacağımızı belirtmek.

   25     [MetadataAttribute]

   26     [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]

   27     public class PluginMetadataAttribute : ExportAttribute

   28     {

   29         public PluginMetadataAttribute(string name, string version,string author)

   30             : base(typeof(IPluginMetaData))

   31         {

   32             Name = name;

   33             Version = version;

   34             Author = author;

   35 

   36 

   37         }

   38 

   39         //IPluginMetaData arayüzünde ki özellikleri burada da tanımlıyoruz

   40         //Hepsini tanımlama zorunda değiliz.Tanımlamadıklarımız varsayılan

   41         //değerleri ile gelecektir.

   42         public string Name { get; set; }

   43         public string Version { get; set; }

   44         public string Author { get; set; }

   45 

   46     }

   47 

Artık yaratacağımız “Part”lar için kendi tanımlamamızı yapabileceğimiz “metadata” yapısına sahibiz. Şimdi tek yapmamız yaratacağımız “Part”da bu “metadata” özelliğini kullanmak.Bunun için de aşağıdaki gibi bir kod bloğu kullanmamız yeterli olacaktır.

   48     [Export(typeof(IPlugin))]

   49     [PluginMetadata("İlk Plugin", "1.0", "Arda")]

   50     [PartCreationPolicy(CreationPolicy.NonShared)]

   51     public class FirstPlugin : IPlugin

   52     {

   53 

   54     }

Dikkat ederseniz “PluginMetadata”, “Attribute”u bizim kendi yarattığımız “attribute” sınıfı.

İlerleyen yazılarda da bu “metadata” bilgilerini nasıl okuyup, MEF’de nasıl “Import” işlemi yapabiliyoruz bunu anlatıyor olacağım.Şimdilik bu kadar…

,

Visual Studio 2010′ da projenizde ki System.Core referansını kaldırdığınızda ve bir şekilde tekrar eklemeye çalıştığınızda aşağıdaki gibi bir hata alıyor olacağız.

Hata bize bu referansın otomatik olarak zaten referans olarak eklendiğini/ekleneceğini söylüyor. Peki ne demek bu? Visual Stuio 2010’da projelerin referansları “build” sırasında belirleniyor. Bazı referanslar ise her koşulda otomatikman “build” sırasında ekleniyor. Yani silseniz bile, aslında Visual Studio 2010 için silmiş olmuyorsunuz. Bu Visual Studio 2010 ile beraber gelen bir değişiklik. IDE’nin bazı özelliklerini kullanabilmek adına.

Peki System.Core’u bir şekilde sildik ve eklememiz lazım, ne yapacağız?

Bunun için öncelikle proje üzerine sağ tıklayıp “Unload Project” dememiz gerekmekte. Dağa sonra tekrar projenin üzerine sağ tıklayıp projeye “Edit…” dememiz gerekmekte. Bu işlemden sonra karşımıza proje dosyamızın içeriği XML şeklinde açılıyor olacaktır.

Referansların eklendiği kısma;

<Reference Include=”System.Core” />

ifadesini ekleyip, “Save” dedikten sonra, tekrardan projeye sağ tıklayıp “Reload” dediğimiz zaman System.Core referansının projemize eklendiğini görebiliriz.

Bu konu ile ilgili “bug” olarak girilen bazı şeyler ile karşılaştım. “Visual Studio Platform” ekibinden ilginç cevaplar dönmüş.

…………………

Unfortunatley, we are at a point in the cycle where we cannot change the UI. As such, I am resolving this bug as Postponed so that we can look at this again in a future release.

…….

So, in this case, we would want to prevent you from removing the reference in the first place.

Since we just release the RC (Release Canidate), we are too late to make any changes of this size at this point, as it would require a large amount of testing, and could introduce regressions in the code. As such, we have postponed the bug so that we can take a look at this for a future release.

RTM’de bu konu ile ilgili bir gelişme yok, sanırım ilerleyen zaman içerisinde Service Pack ile çözülecek diğer sorunlar arasında bunun iyileştirmesi de olur. Bu noktada paylaşmak istediğim bir nokta daha var aslında. Yukarıda ki açıklamadan da anlaşıldığı üzere Microsoft’un geliştirme süreçlerinin ne kadar düzgün işletildiği. Belli bir aşamaya gelmiş bir üründe ki sorunun önceliklendirilmesi yapılıp, ona göre çalışma planlanıyor bunu anlayabiliyoruz…Düşünelim bakalım beraber bu konu üzerinde…(:

patterns & practices ekibinden uzun süredir beklenen haber geldi. Microsoft Enterprise Library 5.0 versiyonu son halini alıp yayınlandı.  Bu adresten kütüphanenin kurulum dosyalarını ve kaynak kodlarını indirip, kendi geliştirmekte olduğunuz uygulamalarda kullanabilirsiniz.

Ayrıca ayrıntılı bilgi ve dökümantasyon için de MSDN sayfasına göz atmanızı tavsiye ederim.

Team Foundation Server 2010’a, Visual Studio 2008 ile bağlanarak, geliştirme ortamımızı(IDE) değiştirmeden, TFS 2010’nun nimetlerinden faydalanabiliyoruz. Bunun için öncelikle bu adresten Visual Studio 2008 için “Forward Compatibility Update”i indirmemiz gerekmekte. İndirdiğimiz bu güncellemeyi kurduktan sonra Visual Studio 2008’den Team Explorer ile TFS 2010’a bağlanabiliyoruz. Ancak küçük bir nokta daha var dikkat etmemiz gereken.

TFS 2010’daki yapı, önceki TFS versiyonlarına göre fark gösterdiğinden, TFS server’a bağlanırken kullandığımız “path”i biraz modifiye etmemiz gerekmekte.

http://[tfsserver]:[port]/[vdir]/[projectCollection]

Yukarıdaki yapıda yazacak olursak, Visual Studio 2008 ile TFS 2010’a rahatça bağlanabiliyor olacağız…Ne güzel değil mi (:

Scrum, son bir kaç yıldır oldukça popüler bir Agile geliştirme methodu olarak karşımıza çıkmakta. Önceki yazılarımda zaman zaman Scrum’a değişmiştim. Şimdi Team Foundation Server 2010 ile daha çok değiniyor ve geliştirme sürecinde Scrum’ı nasıl uygulayabiliriz, kendi tecrübelerim dahilinde bunu paylaşmaya çalışacağım. Team Foundation Server(TFS) 2010 ile beraber neden daha çok değineceğim, öncelikle bunu açıklamak istiyorum.

TFS 2010 ile Microsoft ALM(Application Lifecycle Management) ayağında değişikliklere gitti. Bu değişikliklerden en önemlisi bence, “MSF for Agile Software Development” kavramı oldu. Microsoft, TFS 2010 ile beraber “MSF for Agile Software Development” sürecini güncelleyen ve SCRUM’ın daha kolay uygulanabildiği şablonları bize sunuyor olması. Önceleri şablonları modifiye ederek ya da çeşitli eklentiler ile geliştirme süreçimize SCRUM kavramını dahil edebiliyorduk. TFS 2010 ile beraber gelen “MSF for Agile Software Development v5.0” şablonları artık fazla değişiklik yapmaktan kurtarıyor bizi.

“SCRUM’ı TFS 2010’da nasıl uyguluyoruz?” sorusuna cevap olabilecek, kendi tecrübelerimi paylaşacağım bir yazı dizisi planlamaktayım. Önceden altını çizmekte fayda var, SCRUM’ın ne olduğunu değil, TFS 2010’da nasıl uygulanabileceğini paylaşmaya çalışacağım.

Öncelikle SCRUM’ın yaşam döngüsünü bir hatırlayalım ve unutmayalım. İlerleyen yazılarda da çok işimize yarayacak.

İlk olarak yukardaki yaşam döngüsünde başlangıç olarak alabileceğimiz “Product Backlog” kavramını TFS 2010’da nasıl yaratabileceğimizi paylaşmaya çalışacağım. Öncelikle “MSF for Agile Software Development” şablonu ile TFS 2010’da yarattığımız projemizin Team Explorer altındaki “Work Items” kısmından “1 New User Story…” seçeneğini seçiyoruz.

Karşımıza çıkacak ekran ile “Product Backlog”umuz için ilk kaydımızı girebileceğiz. Bu noktada, “Product Backlog” giriş ekranının tüm alanlarını kullanmak zorunda olmadığımızın altını çizmek istiyorum. Yazılımımızın yol haritasını oluşturmaya başladığımız bu ilk adım ile fazla ayrıntılara girmesekte, ilerleyen aşamalarda bu ekranın diğer alanlarını kullanarak daha ayrıntıya giriyor olacağız.

“Product Backlog” ile temel olarak, ortaya çıkaracağımız yazılımın fonksiyonel özelliklerini bir araya getiriyoruz. Ancak sadece fonksiyonel özelliklerini yazmak zorunda değiliz. Belli iş kurallarından dolayı ortaya çıkabilecek ihtiyaçları da “Product Backlog”umuza yazabiliriz. Bu özellikleri ve ihtiyaçları şu an için belli bir sıralama ya da önceliğe göre yapmadan, olabildiğince açık bir şekilde girmemiz lazım. Sıralama ya da önceliklendirme diye adlandıracağımız kısımı daha sonra yapıyor olacağız, daha sonra da yapmamız da gerekiyor açıkcası.

Aşağıdaki resim üzerinden “Product Backlog”umuza TFS 2010 üzerinden nasıl giriş yapacağız bunu görelim.

  1. Title: “Product Backlog”daki her kayıt, “User Story” olarak adlandırılır. “User Story”ler tüm kullanıcılar, ürün sahibi ya da son kullanıcı için açık ve anlaşılır olmalıdır. Anlamı ve anlatmak istediği ne kadar açık olursa, o “User Story” o kadar anlamlı ve değerlidir. Bu açıdan bu ekranda ki “Title” alanı çok önemlidir.  “User Story”nin şablonu olan “As a <type of user> I want <some goal> so that <some reason>” ifadesi ile “Title” alanını doldurabiliriz. Her ne kadar bu ifade biraz aşağıda “Details” kısmında geliyor olsa da, “Title” da gözüküyor olması “Product Backlog” daki kayıtları daha iyi sorgulamak ve yönetmek için SCRUM adına daha geçerlidir.
  2. Assigned To: Bu alan, “Product Backlog”daki bu kaydın kime atanacağını gösterir. Ancak bu aşamada doldurulmasına gerek yoktur. “Sprint” planlaması yapıldığı zaman, bu alana tekrar dönüyor olacağız. Buradaki kullanıcıların TFS veya Windows kullanıcıları olduğunu belirtmekte fayda var.
  3. State: Bu aşamada bu alan “New” olarak gelecektir ve başka bir alternatif göremeyeceğiz. Nede olsa ilk “Product Backlog” için ilk “User Story”imizi giriyoruz…
  4. Area: Bu alan, “Product Backlog”umuzdaki “User Story”nin, hangi alt başlık ya da alan altında ele alınacağını gösteriyor olacak. Her hangi bir alan yaratmadığımız için direk proje adını görüyor olacağız. Bu kısmı “Word” uygulamasında ki, alt menüler olarak düşünebilirsiniz. Mesela Word’deki tablo özelliği ile ilgili “User Story”ler “Word” ürünü altında “Table” şeklinde bir “Area” altında işlenebilir. “Product Backlog” için kayıtları oluşturmadan önce bu alanları belirlemek faydalı olacaktır. Ama tabi ki daha sonradan bu alanları yaratıp, “Product Planing” sırasında bu alanı doldurabiliriz.
  5. Iteration: En sevdiğim alan…Ama ne yazık ki bu aşamada bu alan da bizim için fazla önemli olmayacak. Projemizin adı seçili gelecektir, şimdilik bırakalım böyle kalsın. TFS 2010’da “Iteration” kavramı SCRUM’daki “sprint” kavramı ile eşdeğer. İsterseniz “Iteration” kelimesini “Sprint” olarak değiştirebilirsiniz. “Sprint” planlaması konusuna değindiğim zaman bu alana tekrardan geliyor olacağım.
  6. Stack Rank: Bu alan “Product Backlog”daki “User Story”leri önceliklendirmek adına kullanılır. Bir nevi sıralama yani…Burada ki önemli nokta, bu işlemin “Product Owner” tarafından yapılması gerektiği. “Product Owner” bu işlemi, müşteri ile olan çalışmaları sonucu yapmalıdır. Müşteri için anlamlı ve müşteriye katma değer sağlayacak olan “User Story”ler yüksek önceliklendirme ile “Product Backlog”da yer almalıdır. SCRUM’ın doğru işleyebilmesi ve “Sprint”lerin oluşabilmesi için bu alan çok önemlidir.
  7. Story Points: Bu alan “User Story”lerin ölçeklendiği alandır. “User Story”nin boyutu belirler. Zorluk ya da yapılması gereken zaman süreçini…Ama önemli olan “Story Points”in SCRUM’da net ve kesin bir karşılığı olmamasıdır. Yani “Story Points”i saat veya dakika şeklinde ya da çok zor,kolay şeklinde kullanamayız. Sadece onu ifade ettiğini varsayabiliriz. “Story Points” kavramını “Sprint” planlamasına başladığımız zaman kullanmak daha anlamlı olacaktır. İlerleyen yazılarda daha netleştiriyor olacağım.
  8. Risk: “Product Backlog” daki “User Story”nin tamamlanmasının ne kadar kritik olduğunu bu alan ile belirliyoruz. “Product Backlog” altında ki “User Story”ler için pek geçerli olmasa da, “Sprint Backlog”larda daha anlamlı olacaktır.
  9. Details: Bu alan “Product Backlog” altında ki “User Story”lerin daha net bir şekilde ifade edilebileceği, gerekirse çeşitli ekler ile güçlendirilebileceği bir alan olarak karşımızı çıkıyor TFS 2010’da…Bu alan da, “Title” alanında ki ifadeyi netleştirmek için daha fazla ayrıntı kullanabiliriz.

Temel olarak “Product Backlog” altına “User Story”leri bu alanları kullanarak ekliyoruz. Son olarak “Product Backlog”un yaşayan bir alan olduğunu hatırlatmak isterim. Yani tüm geliştirme süreci boyunca “Product Backlog”a kayıt girebilmemiz mümkün. Hatta “Bug” gibi zamanla ortaya çıkan kavramları da SCRUM’ın yaşam sürecine ilk “Product Backlog” altından sokmak, temel yaşam döngüsünün daha sağlıklı işleyebilmesi için doğru bir adım olacaktır.

İlerleyen zamanlarda TFS 2010’da SCRUM’ı işleyen konulara daha çok değiniyor olacağım…Şimdilik bu kadar…