Diskden bir klasör içerisindeki tüm dosyaları okumak, elimizde bulunan birden fazla URL adresinden feedleri veya web sayfalarını download etmek ve elimizdeki verilerin güncel kopyalarının olup olmadığını kontrol etmek. Bütün bu örnekler için genellikle bir döngü yapısı kullanırız. Fakat kodu yazma amacımız belirli bir sırayı takip etmesi değil de, tüm sistem kaynaklarını kullanarak işlemi gerçekleştirmesi olduğunda birden fazla thread ile işlem yapmak en uygun çözümdür.
Threading’le ilgili biraz bilginiz varsa “Producer/Consumer Queue” kavramını duymuşsunuzdur. Bu kavramı en basit haliyle “dış bir kaynaktan beslenen iş kuyruğu, ve bu iş kuyruğundan objeleri çeken birden fazla thread” olarak tanımlayabiliriz.
Klasik thread yaklaşımında kullanacağımız kadar thread oluşturur ve bu threadlerin sürekli veya iş kuyruğu tamamiyle boşalana kadar kuyruktaki objeleri aldığı bir yapı oluştururuz. Yönetimi low-level bilgi gereksinimi istediğinden zor ve mantık hatalarına açık bir yöntemdir.
.NET CLR bu nedenle .NET 2.0 ile birlikte ThreadPool yapısı, ardından .NET 4.0 ThreadPool üzerine oturttuğu daha high-level bir yapı olan TPL yani Task Parallel Library ile oluşabilecek sorunlar konusunda yazılımcılara çözümler sunmakta. ThreadPool ve TPL’in çalışma mekaniği yapılacak her kalem iş’e bir Task (Görev) olarak bakmak, ve bu işleri yazılımcının yalnızca tanımlayıp kodların işletim kısmıyla ilgilenmemesini, ancak bu görevleri iptal etmek veya görevler tamamlandığında haberdar olmak gibi genel kısımlarda yazılımcının kod yazmasını sağlar.
Fakat .NET 4.0 ile gelip, işlemcinin sanal/fiziksel tüm çekirdeklerini sonuna kadar kullanmamızı sağlayan TPL’in bir kaç eksikliğinin olduğunu fark ettim. Çalışacak maximum thread sayısına biz karar veremiyoruz, dolayısıyla vermiş olduğumuz her kalem iş .NET tarafından içeride bir yerlerde kuyruğa dahil edildiğinden kod ile bu kuyruğu izleyemiyoruz.
Bu nedenle kendi yazdığım ve aslında daha büyük bir Framework’ün parçası olan Channel sınıfını burada paylaşmak istiyorum.
Örnek Kullanım:
// yapılacak her iş için çalışacak action delegate'ini tanımlayalım
Action<object> _action = new Action</object><object>(delegate(object obj) {
// yapılacak iş objesi delegate'e parametre olarak geldi
Console.Write("{0}\t", obj);
});
// belirttiğimiz action delegate'ini her iş için maximum 5 thread halinde çalıştıracak Channel sınıfını oluşturalım
Channel _channel = new Channel(5, _action);
// kuyruğa dummy olarak 1000 adet iş objesi ekleyelim
for(int _i = 0;_i < 1000;_i++) {
_channel.AddTask(_i);
}
// işlerin oluşturulmasına başla
_channel.Fill();
Cep telefonunlarımıza gelen kısa mesajlarda genel kanının aksine geleneksel 8bit’lik ASCII tablosu değil de, GSM operatörü tarafından özelleştirilebilen 7bit’lik GSM alfabesi kullanılmaktadır.
Bunun zorluğu ile en çok servis sağlayıcı tarafından filtrelenmeyen, daha doğrusu işin bu kısmını tamamiyle biz API kullanıcılarına bırakan kısa mesaj gönderimlerinde karşılaşırız. Sık karşılaştığım ve internet üzerinde pek kaynak bulamadığım için işin başa düştüğünü ve kendim .NET’in klasik Encoding’leri ile çevirim uyumlu bir sınıf yazmam gerektiğini düşündüm. GsmEncoding’e ait kaynak kodları bu post’un ekinde bulabilirsiniz.
Kodları kullanmak için .NET’in CLR’ında herhangi bir Encoding’i nasıl kullanıyorsanız, yeni oluşturduğunuz bir GsmEncoding instance’ını da bu şekilde kullanmanız yeterli. Örneğin:
Encoding _encoder = new GsmEncoding();
byte[] _data = _encoder.GetBytes(text);
Bu kez programcılıktaki kullanımı benim için oldukça “gri” olan bir konu hakkında yazacağım. Lambda benim için her zaman okuması ve bazen de yazması oldukça zor bir yazılım dili fonksiyonu olmuştur. Benim kağıt kalemle algoritma debug edilen bir dönemden kalma bir yazılımcı olmamla ilişkisi olduğunu düşünsem de; koda bakan kişinin hafızasıyla çalışma anını öngöremeyeceği şekildeki kodların evrimleşiyor olmasını eleştirmem çok da haksızlık değildir diye düşünüyorum.
Yine de, her iyi programcı gibi kodlama hakkındaki yeni bir bilgiyi reddetme lüksümüz olmadığı için MSDN dökümantasyonu dışında bir kaç kaynak arayışına girdim. Önceleri CodeHappy’nin Introducing Lambdas in C# makalesini bulmuştum. Fakat bunun internet üzerinden kısa bir süre sonra kaldırılmasıyla Eric White’ın MSDN bloglarından Lambda Expressions yazısına ulaştım.
C# özelinde konuşmak gerekirse Lambda’nin en büyük özelliği “kasvetli” delegate kullanımı yerine C’den alıştığınız void* kullanımına daha yakın bir şekilde Action<> ve Func<> isimli iki hazır delegate template ile birlikte gelmeleri.
XAML ile ilgili yaptığım bir araştırma esnasında dış bir kaynaktan gelen kodu XAML içerisinde nasıl çalıştıracağım konusunda bir kaç örnekle karşılaştım. Eğer özellikle banner rotation yapacaksanız, veya canlı bir feed’i tamamiyle dışarıdan almayı düşünüyorsanız eminim oldukça işe yarayacaktır.
using Sys = System;
using SysIO = System.IO;
using SysWinMarkup = System.Windows.Markup;
using SysXml = System.Xml;
using SysXmlLinq = System.Xml.Linq;
public static class XamlUtils {
public static object GetXamlObject(string source) {
SysXml.XmlDocument _xmlDocument = new SysXml.XmlDocument();
_xmlDocument.LoadXml(source);
return Xaml.GetXamlObject(_xmlDocument);
}
public static object GetXamlObject(SysXml.XmlDocument xmlDocument) {
const string xmlns = "http://schemas.microsoft.com/winfx/2006/xaml/presentation";
const string xmlns_x = "http://schemas.microsoft.com/winfx/2006/xaml";
if(string.IsNullOrEmpty(xmlDocument.DocumentElement.GetAttribute("xmlns"))) {
xmlDocument.DocumentElement.SetAttribute("xmlns", xmlns);
}
if(string.IsNullOrEmpty(xmlDocument.DocumentElement.GetAttribute("xmlns:x"))) {
xmlDocument.DocumentElement.SetAttribute("xmlns:x", xmlns_x);
}
SysIO.TextReader _stringReader = new SysIO.StringReader(xmlDocument.OuterXml);
SysXml.XmlReader _xmlReader = new SysXml.XmlTextReader(_stringReader);
return SysWinMarkup.XamlReader.Load(_xmlReader);
}
}
Kullanımı:
System.Windows.Controls.Grid _gridObject = XamlUtils.GetXamlObject("<grid><textblock>ok</textblock></grid>") as System.Windows.Controls.Grid;
this.Content = _gridObject;
Görüldüğü gibi, dış bir kaynaktan alınan/okunan string’i XamlUtils.GetXamlObject metodu ile XAML’e dönüştürebiliyoruz. Burada dikkat etmemiz gereken bu metoddan dönen objenin XAML’in root element’ine düzgün cast edilmesinin gerekliliği. (Örnekte root element’i Grid olarak ele aldım)
Bir çok kişi type’lar arasındaki cast işlemleri için C-tabanli (Type)Variable dizilimini kullanmaktadır. Bildiğimiz üzere, .NET CLR type casting işlemleri için aynı zamanda (Variable as Type) dizilimine de sahiptir. Genel tanıma göre bu dizilimin avantajları olarak okunabilirlik ve casting esnasındaki hatalar için Exception yerine null döndürmesini sayabiliriz.
Microsoft Code Analysis’in tavsiyelerini dikkate almaya başlayana dek benim de konu ile ilgili bilgim arada yalnız davranış farklılığı olduğu yönündeydi. Oysa ki .NET klasik type casting dizilimini kullandığımızda aynı tipi birden fazla kez dönüştürüyormuş. Microsoft’un önerisi ise (Variable as Type) dizilimi ile performans arttırarak ve bu double-check’den kurtulmamız yönünde.
Durum böyle olunca ister istemez kendime sormaya başladım, Microsoft Managed Code’u inşa ederken sistemler büyüdükçe karşılaşılan escape karakterleri, sql injection gibi mevzularda daha akıllı davranacak diye pazarlamıyor muydu? Code Analysis’in bu noktada kullanıcıya output vermesi beni ikilemde bırakıyor. Dilerim Microsoft da bunları göz önünde bulunduruyordur.
Her neyse, ekstra referans olarak ufak bir araştırma sonrasında .NET BLOG isimli bir blog’da iki type casting dizilimi için performans karşılaştırmasına ulaştım. Aynı zamanda MSDN’de How to: Safely Cast by Using as and is Operators isimli bir makale bulunmakta.
Son iki haftamı Windows Presentation Foundation ve XAML üzerine çalışarak geçirdim. Şimdiden ileride HTML’in dahi yerini alabilecek kadar geniş ele alınmış olduğunu söyleyebilirim.
Aslında Microsoft’un bu teknolojiler hakkındaki tutumu beni biraz şaşırtıyor; Öncelikle Silverlight hakkında WPF’nin “basit” hali ve Microsoft’un Adobe Flash’a alternatifi diyebiliriz. Adobe’un Flash’da ActionScript kullandırıyor olması gibi Silverlight için JavaScript ve C# kullanabileceğiz ama Silverlight ile hiç bir zaman WPF’nin gücüne erişemeyeceğiz.
Silverlight 2 ile vaad edilenler:
http://weblogs.asp.net/scottgu/archive/2008/09/25/silverlight-2-release-candidate-now-available.aspx
Microsoft’un Silverlight Sitesi:
http://silverlight.net/default.aspx
Gelelim WPF’e;
Silverlight ve WPF aynı kütüphaneleri kullanmadığı için Silverlight’a eklenen yenilikler için WPF’de biraz beklememiz gerekecek gibi görünüyor. Çünkü Microsoft’un şu anki politikasına göre WPF ancak ve ancak .NET Framework sürümleri ile güncellenecek.
Yine de tekrar edeyim, Silverlight ile yaptıklarınız WPF ile yapacaklarınızın yanında hiç kalıyor. Çünkü WPF ile muhasebe programından 3d oyuna kadar herşeyi tasarlayabiliyoruz.
WPF 3.5 SP1:
http://windowsclient.net/wpf/wpf35/wpf-whats-new-35sp1.aspx
Microsoft’un WPF Sitesi:
http://windowsclient.net/
Generic olarak List sınıfının kullanılması tavsiye edilmiyormuş. Hemen bir alıntı ile durumu özetleyeyim:
We don’t recommend using List<T> in public APIs for two reasons.
- List<T> is not designed to be extended. i.e. you cannot override any members. This for example means that an object returning List<T> from a property won’t be able to get notified when the collection is modified. Collection<T> lets you overrides SetItem protected member to get “notified” when a new items is added or an existing item is changed.
- List<T> has lots of members that are not relevant in many scenarios. We say that List<T> is too “busy” for public object models. Imagine ListView.Items property returning List<T> with all its richness. Now, look at the actual ListView.Items return type; it’s way simpler and similar to Collection<T> or ReadOnlyCollection<T>.
Kaynak ve Yorumlar: http://blogs.msdn.com/kcwalina/archive/2005/09/26/474010.aspx
