Windows Phone Camp Geliyor!

Herkese merhaba,

22-23 Aralık tarihlerinde Microsoft Türkiye İstanbul ofisinde Windows Phone Camp etkinliğini gerçekleştiriyor olacağız. Detaylar aşağıda!

Windows Phone Camp’ e  Davetlisiniz!…

22-23 Aralık tarihlerinde Microsoft Türkiye Istanbul ofisinde gerçekleştireceğimiz 2 tam gün sürecek ve sonunda kendi Windows Phone Uygulamanızı, Windows Phone Marketplace’ de göreceğiniz Windows Phone Camp etkinliğimize davetlisiniz.

Windows Phone Kampı, ‘Mango’ kod adlı Windows Phone 7.5 sürümü için Windows Phone uygulamaları geliştirmeniz ve yayınlayabilmeniz için gerekli her şeyi öğrenebileceğiniz ücretsiz bir etkinliktir. Windows Phone, Android, Symbian, Web OS ya da iOS uygulamaları konusuna yeni başlayan bir geliştiriciden deneyimli geliştiricilere kadar herkesi Windows Phone için uygulama geliştirmek için bekliyoruz.

Etkinlik Konuşmacısı:

Ekin Özçiçekçiler
Microsoft MVP

Etkinlik Programı:

Yaz Geliştir Forumları Yenilendi!

Yazgeliştir forumları yeni arayüzü, yeni özellikleri ve yeni moderatör kadrosu ile hizmetinizde.

Forumlarda yapılan bu köklü değişikliğin temel faydaları,

• Gönderilere code snippet ve resim ekleme özelliği ile daha fonksiyonel ve anlaşılır bir kullanıcı arayüzü.
• Sorulara daha hızlı cevap verebilmek ve soruların takip edilebilmesi.
• Rss ile takip imkanı.
• Sosyal sitelerde paylaşım imkanı.
• Daha önceden cevaplanan sorular arasında daha rahat arama yapılabilmesi.
• Aktif forum kullanıcılarını daha iyi takip ederek editör adaylarını ön plana çıkartmak.

olacaktır.

Forumları ziyaret etmek için http://forum.yazgelistir.com adresini ziyaret edebilir veya Yazgeliştir üzerinden forumlara giriş yapabilirsiniz.

Windows Phone 7 – Arayüz Mimarisi

Windows Mobile üzerinde uygulama geliştiren tüm uygulama geliştiricilerin Windows Phone 7 üzerinde uygulama geliştirmeye geçmeden önce, neredeyse her anlamda sıfırdan hazırlanan bu yeni mobil cihaz işletim sistemi ve platformu tanımaları detaylı olarak tanımaları gerekmektedir. Uygulamaların tümüyle Windows Phone için özel olarak hazırlanmış olan Silverlight ile geliştirilebilecek olması, native code desteğinin olmaması, ciddi cihaz kısıtlamalarının belirlenmiş olması gibi detaylar da göz önünde bulundurulduğunda, konuya en baştan başlamak, yani platformu en genel çizgileriyle incelemek faydalı olacaktır. Bu bağlamda, Windows Phone 7’ nin yeni arayüzünün temel noktalarını inceleyerek konuya hızlıca bir giriş yapacağız.

Windows Phone 7, önceki ismiyle Windows Mobile olan eski sürümlerine nazaran neredeyse sıfırdan geliştirilen yeni Microsoft mobil cihaz işletim sistemi ve platformudur. Windows Phone 7, kullanıcılarına en mükemmel deneyimi sağlayabilmek adına birçok farklı konsept kullanılarak tasarlanmış, farklı kullanıcı profillerinde test edilerek bugünkü halini almıştır. Bu açıdan bakıldığında, günlük hayatta kullanıcıların sıkça kullanıyor oldukları “arayüzler” incelenmiş ve bilgiye; ihtiyaç duyulan “içeriğe” en kolay ulaşılabilecek ve bugün Windows Phone 7’nin temelini oluşturan “Metro” arayüzü oluşturulmuştur. Metro arayüzü (Metro UI) günlük hayatta sıkça bulunduğumuz havalimanı, metro istasyonu v.b. gibi lokasyonlarda yönümüzü belirlemeye yardımcı olan “yönlendirme tabelaları” esas alınarak geliştirilmiştir. Bu “tabela” larda kullanılan “görsel dil” her tür kullanıcı profiline “ihtiyaç duyduğu” bilgiye en hızlı ulaşabilecek bir dil olmakla birlikte, birçok açıdan “her ne kadar farkedilmese de” birçok detay barındırmaktadır. Bunlardan en önemlisi, yüzlerce destinasyon bilgisinin olduğu bir yönlendirme tabelasında ihtiyaç duyduğumuz destinasyon ile ilgili bilgiye en hızlı ve sade bir biçimde ulaşabiliyor olduğumuzdur. Aslında bu noktada dikkat edilmesi gereken detay, bu kavramın yine günlük hayatta en çok iletişim kurduğumuz elektronik cihaz olan telefonlarımızda da olması gerekliliğidir. Acil bir anda telefon defterindeki bir kullanıcıyı aramak, mesaj atmak ya da en sevdiğim uygulamaya cihazın içinde kaybolmadan ulaşmak güçlü bir mobil deneyimin en başında gelen detaylar olmaktadır. Bu detaylar göz önünde bulundurularak Windows Phone 7 üzerinde bulunan Metro UI geliştirilmiş ve kullanıcılarına maksimum verimliliği sağlayabilecek bir deneyim sağlaması hedeflenmektedir.

Windows Phone 7 üzerinde bulunan Metro UI, genel hatlarıyla “bir anlayış” ya da “bir prensip” olarak ele alınmalı ve Windows Phone 7 üzerinde uygulama geliştiren tüm uygulama geliştiricilerin detaylı olarak incelemesi gereken bir kavram olmalıdır. Kullanıcıların maksimum seviyede mobil deneyim yaşabilmeleri adına, bu prensip kapsamında anlatılan tüm detaylar incelenmeli ve geliştirilecek olan mobil cihaz uygulamasının her aşamasında kullanılmalıdır.

Hızlıca Metro UI ile incelenmesi gereken detayları inceleyemeye geçelim.

Windows Phone 7 işletim sistemine sahip bir cihaz açıldığında kullanıcıların karşısına belkide gün içerisinde en sık kullanacak oldukları bir ekranı görüntülemektedir; Start. Start, adından da anlaşılabileceği üzere sahip olunan cihaz ile sahibi arasındaki tüm iletişimin başladığı, ihtiyaç duyulan içeriğe en hızlı ulaşılması gereken, sade ve kolay kullanılabilir bir “başlangıç noktası” olarak karşımıza çıkmaktadır.

Start, cihaz üzerinde bulunan “Start” tuşu ile istenildiği herhangi bir anda açılabilen bir ekrandır ve sadece dikey görünümde görünmektedir. Start ekranı üzerinde “Application Tile” adı verilen “canlı kutular” ya da farklı bir deyişle “ihtiyaç duyulan bilgilere, uygulamalara, kişilere kısayollar” bulunmaktadır. Kullanıcılar, istedikleri uygulamaların, kişilerin ya da içeriklerin kısayollarını Start ekranı üzerinde “Tile” olarak ekleyebilmektedirler. Bu “Tile” lar, Windows Phone 7 ile birlikte gelen “notification” altyapısı sayesinde “canlı” olarak tutulabilmekte, herhangi bir güncelleme olduklarında bu güncelleme hakkında kullanıcıyı bilgilendirebilmektedirler. Bu güncellemelere örnek olarak devam eden bir online oyunda hamle sıranızın geldiğinin bildirilmesi, bir e-posta’ nın cihazınıza ulaşması ya da bir arkadaşınızın Facebook üzerinden göndermiş olduğu bir mesajın bildirilmesi gösterilebilmektedir. Bu güncellemeler "ilgili” Tile üzerinde bulunan metin alanında gösterilebileceği gibi bir sayaç ya da değişen bir arka plan görseli ile de belirtilebilmektedir.

Emülatör ya da reel bir Windows Phone 7 cihazı üzerinden detaylı olarak incelendiğinde, bir önceki sürümlerinde neredeyse cihazın her ekranında görünen bilgilendirme ikonları, Windows Phone 7 üzerinde istenilmediği zaman neredeyse “hiç bir zaman” görünmemektedir. Ekranın en üstünde bulunan boşluğa yapılacak olan "bir “çift” dokunma hareketi sonucunda bu ikonlar aşağıya doğru düşecek ve kullanıcıya cihazın şarj durumu, baz istasyonu ile arasındaki sinyal gücü, eğer bağlıysa kablosuz ağ bağlantısı sinyal gücü gibi bilgileri görüntüleyecektir. Bu ikonlar, bir önceki sürümlerine nazaran “katı kurallar” ile standartize edilmiş ve belirli boyutlarda görüntülenmektedir.

Uygulama geliştiricilerin dikkat etmesi bir diğer konu ise, geliştiriyor oldukları uygulamaların arayüzlerinde kullanacak oldukları arayüz kontrolleridir. Bu noktada, Windows Mobile’ ın arayüz bileşenleri ne kadar başarısız ise Windows Phone 7’ nin arayüz bileşenleri o kadar başarılı diyebilmekteyiz. Standart kontrollerin mükemmelliğinin yanı sıra 3. parti firmaların Windows Phone 7 için hali hazırda geliştiriyor olduğu bileşen paketleri ile uygulama geliştiriciler eskiye nazaran çok daha şık ve kullanışlı uygulamalar geliştirebileceklerdir. Bu bağlamda bakıldığında, uygulama içerisinde kullanılacak olan “menü” kontrolleri ile ilgili de belli başlı bazı kısıtlamalar Windows Phone 7 ile birlikte gelmektedir.

Yukarıdaki ekran görüntüsünde görüyor olduğunuz ve 4 adet button’ un olduğu kontrol neredeyse birçok Windows Phone 7 uygulamasında görüyor ve görecek olduğumuz “Application Bar” kontrolüdür. Bu kontrolün temel amacı, uygulamada anlık olarak kullananabileceğimiz “pratik” kısayolların kullanıcıya görüntülenmesi olarak ifade edilebilmektedir. Bu kontrol her ne kadar kullanışlı olarak görünse de, bazı kısıtlamalar ile birlikte gelmektedir.

Application Bar kontrolü, ekranın o an ki görünümüne göre ekranın altında ya da cihazı çevirdiğiniz yöne göre sağa ya da sola otomatik olarak taşınabilmektedir. Bu noktada, bu kontrol standart olarak gizli olarak görünmekte, köşe tarafında bulunan “…” 3 noktalı tuşa basarak içerisinde tanımlı olan menüleri görüntülemektedir. Bu noktada, temel fonksiyoneliteler için en fazla 4 tuş, alt menü içinse en fazla 5 adet menü eklenebilmektedir. Bu menüye olabildiğince “az” eleman eklemek, kullanıcı arayüzünün sadeliği bakımından her zaman daha faydalı olacaktır.

Uygulama geliştiricilerin dikkat etmesi gereken noktalardan biride, kullanıcıların cihazı sağa ya da sola çevirdiğinde ilgili uygulamanın bu eyleme ne şekilde tepki vereceğidir. Windows Phone 7 üzerinde temel olarak 3 farklı “görünüm” desteklenmektedir; Dikey, Yatay (Sola) ve Yatay (Sağa). Uygulama geliştiriciler, cihaz tarafından otomatik olarak algılanan bu eylemi uygulamalarında yakalamaları ve uygulamanın arayüzlerinde ilgili eyleme istinaden gerekli boyut değişikliklerini yapmaları gerekmektedir. Ayrıca, projenin geliştirilmesi esnasında, hangi sayfanın bu eyleme tepki vereceğini programatik olarak belirleyebilir, bir sayfanın sadece yatay ya da sadece dikey görünmesini sağlayabilmektedirler. Dikkat edilmesi gereken en önemli nokta, bu değişikliğin çalışma zamanında kod ile yapılamamasıdır. Başlangıçta belirlenen özellikler read-only olarak ele alınacak olup, çalışma zamanında değiştirilememektedir.

Uygulama geliştiriciler tarafında üzerinde durulması gereken belkide en önemli konulardan biri olan “Navigasyon” konusunu da inceleyerek yazımıza son vereceğiz. Temel olarak geliştirilen tüm uygulamalar, birçok farklı amaca yönelik “ekranlardan” oluşmaktadır. Bu noktada, mobil cihazlarda yaşanabilecek kaynak sıkıntıları da göz önüne alındığında, bu ekranların düzgün ve belirli kurallara göre tasarlanması ciddi anlamda önem kazanmaktadır.

Bu açıdan bakıldığında, Windows Phone 7 üzerinde uygulama geliştirecek olan tüm uygulama geliştiricilerin anlamış olması gereken ilk ve en temel konu “ilgili ekranlar” ve bu ekranlar arasındaki “gezintinin” nasıl olacağıdır.

Tüm Windows Phone 7 uygulamaları, “frame” adı verilen “temel taşıyıcı” bünyesinde ekrana getirilen “page” adı verilen sayfalardan oluşmaktadır. Frame, top-level olarak ifade edilebilecek uygulama seviyesinde bir yapı olarak ele alınmalıdır. Uygulama içerisindeki tüm ekranlar birer Page olarak ele alınmalı ve bu hiyerarşide tasarlanmalıdır. Ekran üzerinde gösteriyor olduğumuz tüm içerikler bu sayfalar (Page)’ ler içerisinde bulunmaktadır.

Windows Phone 7 üzerinde uygulama geliştiriyor olduğumuz Silverlight sürümünün Silverlight 3’ e çok yakın olduğunuda düşündüğümüze, bu sayfalar arasındaki geçiş ve navigasyon çokta zor olmayacaktır. Silverlight üzerinde tanımlı olan Navigation Service isimli servis aracılığıyla ekranlar arasında gezinilebilmektedir. Cihaz üzerinde bulunan “back (geri)” tuşu ile bu ekranlar arasında geriye gidebilir ya da programatik olarak bu gezinme sağlanabilmektedir. Bu konu ile ilgili detaylı bir örnek önümüzdeki yazılarda anlatılacaktır.

Bu yazımızda Windows Phone 7’ nin temel arayüz mimarisi yüzeysel olarak incelenmiş; temel arayüz bileşenlerinin genel anlamda nasıl kullanılacağı konularına değinilmiştir. Bu konular ve daha fazlası ile ilgili teknik detayları sonraki yazılarda inceliyor olacağız.

Kaçıranlar için PDC 2010 Türkiye Etkinlikleri!

Ekim ayı sonunda Redmond’da düzenlenen Microsoft Professional Developers Conference – PDC10’u takiben, konferansın önemli duyurularını da içerecek özel etkinliklerde Türkiye’deki profesyonel yazılım geliştiricilerle bir araya geldik. Ankara, İzmir ve İstanbul’da düzenlenen PDC10 Türkiye Özel etkinliklerinde, özenle seçilmiş teknik oturumlar, Microsoft Türkiye çalışanları ve teknik alanda uzmanlıklarını kanıtlamış deneyimli Microsoft RD’leri tarafından gerçekleştirilmiştir.

Kaçırdım diye üzülmeyin! Bu adresten hem PDC10 Türkiye oturumlarını ve yanısıra PDC10 Redmond konferansı açılış konuşmasının Türkçe altyazılı versiyonunu ve tüm oturumları izleyebilir, hem de sizin için faydalı teknik kaynaklara ulaşabilirsiniz.

Windows Phone 7 Cihaz Özellikleri

Herkese uzun zaman aradan sonra merhaba…

Çok uzun zamandır işlerin yoğunluğundan blog üzerinden paylaşımlarda bulunamıyorum. Paylaşımı seven biri olarak bunun sıkıntısını maalesef uzun zamandır çekiyorum diyebilirim. Ama niyetliyim, 2011 ile birlikte paylaşım konusunu belirli bir düzene sokmayı planlıyorum Diğer bir yandan bakıldığında ise Şubat ayında Seattle’ da katıldığım Microsoft MVP Summit’ te belkide birçok kişiden önce detaylarını öğrenebilme imkanı bulduğum Microsoft’ un yeni mobil cihaz işletim sistemi Windows Phone 7 hakkında paylaşımlarda uzun bir süredir bulunmuyor olmamın sebebini neredeyse katıldığım her etkinlikte soran arkadaşlar oluyor. Kasıtlı olarak uzun bir süredir bu konu ile ilgili paylaşımlarda bulunmuyor olmamın sebebi öncelikli olarak teknik açıdan ilgili platform’ un birazda olsa olgunlaşmasını beklemem ve ülkemizde halen satışta olan ve yoğun olarak sorularını cevapladığım Windows Mobile 6.5’ un bulunması diyebilirim. Fakat şu an için bakıldığında hem ilgili platform’ un paylaşım yapılabilecek düzeyde olgunlaştığını düşünüyorum hem de bundan sonraki aşamada Windows Mobile 6.5 noktasında paylaşımlara çok fazla zaman ayırmamayı hedefliyorum. Yakın zamanda ise başlıklarını kısa zaman önce tamamladığım Windows Phone 7 teknik makalelerini hazırlamaya ve blog üzerinden paylaşmaya başlayacağım.

Gelelim başlıktaki konuya. Neredeyse katıldığım tüm etkinliklerde aldığım soruların en başında Microsoft’ un yeni mobil cihaz işletim sistemi vep platformu Windows Phone 7’ nin varolan cihazlarda çalışıp çalışmayacağı sorusu gelmekte. Öncelikle bilmemiz gereken, Windows Phone 7, önceki sürümleri ile geriye uyumluluğu olmayan, tamamen sıfırdan hazırlanan, .Net Compact Framework, Silverlight ve XNA gibi üç güçlü platform üzerine uygulama geliştirme mimarisi oturtulmuş bir işletim sistemi. Bu açıdan bakıldığında Microsoft’ un 10 yıldan fazladır pazarda olan Windows Mobile işletim sisteminin en büyük dezavantajı olan “bir işletim sistemi, birçok farklı cihaz” konseptinin tam anlamıyla dışına çıkılıyor diyebilmekteyiz. Her ne kadar Windows Mobile birçok cihaz türünde çalıştırılabilecek bir mobil cihaz işletim sistemi olarak tasarlanmış olsa da, farklı cihazlarda yaşanan performans sıkıntıları yüzünden son kullanıcıların hiç bir zaman yüzünü güldüremeyen Microsoft, Windows Phone 7’ de bu işletim sistemini çalıştırabilecek cihazlar için spesifik özellikleri üreticilere belirledi ve aslında “son kullanıcı deneyimini” tüm kullanıcılarda eşitlediğini görebilmekteyiz. Kısaca, aşağıda özellikleri bulunan cihaz türleri dışında diğer cihazlarda maalesef Windows Phone 7 işletim sistemi çalışmayacak.

• WVGA (800 x 480) çözünürlüğüne sahip ekran.
• Telefonun etkin kullanılabilmesi için ekranın kapasitif, 4-noktadan çoklu dokunmaya destek vermesi gerekiyor.
• Etkili ses ve görüntü için DirectX 9 desteği.
• Cihaz üzerinde A-GPS, accelerometer, pusula sensörlerinin bulunması gerekiyor.
• Dijital kamera (Min. 5MP) .
• Start (Başlat), Search (Arama), and Back (Geri dön) tuşları.
• Wi-Fi (Kablosuz Bağlantı) desteği..
• 256 MB (ya da daha fazla) RAM ve 8 GB (ya da daha fazla) flash depolama alanı.

Windows Phone 7 almayı düşünenler için belirtmek gerekirki 2011’ in ortalarından önce cihazları Türkiye’ de görmek pek mümkün durmuyor. Bunun en büyük sebebi cihazın Türkçe desteğinin şu an olmaması diyebiliriz.

Görüşmek üzere.

Dependency Inversion Principle

Genel olarak bakıldığında yazılım geliştirme çok yönlü düşünmeye dayalı bir kavram olarak ifade edilmektedir. Bu noktada geliştirilecek olan yazılımın ihtiyaç analizinin yapılması, onun önümüzdeki 10 yıl boyunca sağlıklı çalışabileceği anlamına gelmemektedir. Beklenmedik istekler, beklenmedik durumlar,  hesaba katılmamış kullanıcı kaynaklı hatalar, en başta belkide aylarca süren ihtiyaç analizinde bir anlık bir hatayla es geçilen bir detay geliştirilen yazılımın çalışmasını, güncellenebilmesini belkide imkansız hale getirebilecektir. Analitik ve çok yönlü düşünme noktasında kendini geliştirmiş ya da zaten yetenekli olan kişilerin ise bu gibi durumlarda hayati rol oynadıkları tartışılmaz bir gerçek olarak ifade edilebilmektedir. Vizyoner bir yazılım geliştiricinin 10 yıl önce üzerinde durduğu bir detay, bugün belkide söz konusu yazılımın en temel taşlarından biri olarak ifade edilecek ve yeni geliştirilecek olan birçok modül bu detay temeline dayandırılarak inşa edilecektir.

Bu perspektiften bakıldığında geliştirilecek olan yazılımın “anlık ihtiyaçları karşılamasının” yanısıra, “gelecekteki ihtiyaçlara” düzgün bir temel oluşturacak şekilde geliştiriliyor olması gerekmektedir. Yazılım geliştirme dünyasında sıkça duyduğumuz “tekrar kullanılabilirlilik”, “modüler programlama”, “nesneye dayalı programlama” gibi kavramlar aslında yazılım geliştirme tarihinde yaşanan hayati sıkıntılara çözüm olarak geliştirilmiş metodoloji ve tekniklerden bazıları olarak ifade edilebilir. Bu teknik ve metodolojiler, geliştirilen binlerce yazılımın yaşam döngüsü içerisinde yaşanan sıkıntılara çözüm olarak geliştirilmiş ve günümüzde birçok yazılım projesinin temel prensipleri olarak ele alınmaktadır.

Yazılımların ihtiyaç analizlerinin detaylı ve dikkatli yapılmasının ardından bu projeleri belirli prensipler, teknikler ve metodolojiler üzerine geliştirmek ilk bakışta “kaynak” ihtiyacı noktasında sıkıntılar oluştursa da, belkide milyonlarca liralık bir zararın engellenmesine ve yıllar süren bir çalışmanın uzun yıllar sorunsuz bir şekilde çalışmasına sebep olabilecektir. Bu noktada bir önceki cümlede ifade edilen “kaynak” kavramını kısaca açmamız gerekirse; bu tip prensiplerin ve tekniklerin kullanımı öncelikli olarak uygulama geliştirme süresini gözle görülür oranda uzatacağından uygulama geliştirme maliyeti de ciddi oranda artacaktır. Bu artış sonucunda yazılımımız tahmin edilenden çok daha pahalıya geliştirilmiş olacaktır. Fakat uzun süreli sonuçlar ele alındığında, daha öncede belirttiğimiz üzere belkide milyonlarca liralık bir zararı birkaç bin liralık bir maliyet artışı ile engellemiş olabilmekteyiz.

Bu yazımızda ise son dönemde birçok yazılım projesinde sıkça duyduğumuz, yaklaşık 14 yıllık bir geçmişi olan ve kendisini birçok yeni prensibin çıkmasına zemin hazırlayarak ispatlamış bir uygulama geliştirme prensibinden bahsedeceğiz: Dependency Inversion Principle.

Uygulama geliştirme prensipleri, daha önce de ifade ettiğimiz üzere belirli sorunlara çözüm olarak geliştirilmiş tekniklerdir. Dependency Inversion Principle başlığı altında incelediğimiz zaman ise temel olarak birkaç net sorun göze çarpmaktadır.

Bu sorunların başında “modüler” olarak geliştirilen uygulamalarda bu “modüllerin” birbirleri ile olan ilişkileri ve yazılımın yaşam döngüsü bünyesinde bu modüllerin birbirleri ile olan “bağımlılıkları” gelmektedir. Bağımlılık kavramını düz mantık olarak incelediğimizde bile, herhangi bir kavramın farklı bir kavrama olan ihtiyacı söz konusu olduğu net bir şekilde ortaya çıkmakta ve aslında bu durum bünyesinde çok ciddi bir sorun kendini net bir şekilde göstermektedir. En önemli yazılım geliştirme tekniklerinden birisi olan “tekrar kullanılabilirlilik”, bu tür bağımlılıkların artması ile “gerçek anlamda” uygulanamamakta ve tam olarak tabir etmek gerekirse “tekrar kullanılabilir” görünümlü “yekpare” türden yazılımlarla karşı karşıya kalınmaktadır. Bu tür yazılımlarda yapılan en ufak değişiklikler birçok modülün bağlantılı olarak değiştirilmesi ile sonuçlanmakta, bu da ciddi anlamda maliyet oluşturmaktadır.

Tekrar kullanılabilmek adına geliştirilen modüller temel olarak iki kategoride incelenebilmektedir; Üst Seviyeli ve Alt Seviyeli modüller. Üst Seviyeli modülleri yazılımın temel işlevlerini yerine getiren, farklı bir deyişle o yazılımı o yazılım yapan ana iş akışlarını düzenleyen, çalıştıran ve kendi içerisindeki diğer Üst Seviyeli modüller ile de çalışan ana program parçacıkları olarak ifade edilebilmektedir. Birçok uygulama geliştirici bu tür Üst Seviyeli modülleri tekrar kullanabilecek şekilde tasarlamaya çalışır ve uygulama içerisinde benzer iş akışları söz konusu olduğunda bu boşlukları zaten hali hazırda geliştirmiş olduğu bu Üst Seviyeli modülleri kullanarak doldurmaktadır. Alt Seviyeli modüller ise bir önceki cümlede ifade edilen bu Üst Seviyeli modülleri anlamlı kılan, her biri belirli bir görevi yerine getirmek adına geliştirilmiş, çoğu zaman birbirlerinden “bağımsız” olarak geliştirilmiş olan program parçacıkları olarak ifade edilebilmektedir. Bu program parçacıkları en ufak bir değişiklik yapmaya gerek olmadan sayısız kez tekrar kullanılabilmekte ve hiç bir problem oluşturmamaktadır. Fakat Üst Seviyeli modüllere bakıldığında Alt Seviyeli olan modüllere “çok sıkı” bir bağımlılık görülmekte, çoğu zaman Alt Seviyeli modüllerin çalışmadığı durumlarda işlevsiz olarak kaldıkları görülmektedir. Üst Seviyeli olarak ifade edilen ve uygulamanın ana program parçacıklarından bir modülün kendisini oluşturan bir Alt Seviyeli bir modül yüzünden tekrar kullanılamaması ciddi anlamda can sıkıcı olmakta, Üst Seviyeli modül içerisinde programatik olarak bazı değişikliklerin yapılmasına yol açmaktadır. Sürekli bu tür değişikliklerin olması ise Üst Seviyeli modülleri işlevsiz kılmakta ve yazılımın yaşam döngüsü içerisinde ciddi problemler oluşturmaktadır.

İşte tam bu noktada Mayıs 1996 tarihinde Robert C. Martin tarafından ele alınan bir yazılım geliştirme prensibi yardımımıza koşmaktadır; Dependency Inversion Principle!

Prensip incelendiğinde içerisinde çok net ve yukarıda bahsi geçen “bağımlılık” altyapılı sorunlara yönelik bir cevap bulundurmaktadır: Üst Seviyeli modüller Alt Seviyeli modüllere değil; Alt Seviyeli modüller Üst Seviyeli modüllere bağımlı olmalıdır! Yani geleneksel prosedürel programlamaya göre kıyaslandığında bağımlılık “ters” çevrilmiş olmalıdır. Bağımlılığın ters çevrilmesi sonucunda Üst Seviyeli modüller istenilen her noktada içerisinde en ufak bir değişikliğe gerek olmadan “Alt Seviyeli modüllerden” bağımsız olarak kullanılabilecek ve bu iki kategori arasında bağımlılık neredeyse sıfıra indirilecektir. Bu noktada belirtilmesi gereken en önemli nokta ise bağımlılığın ters çevrilmesi işlemi iki modül arasına soyut sınıflar ya da arayüzler getirilerek gerçekleştirilmiş olacak, dolayısıyla tüm modüller “modüler” olarak farklı noktalarda kullanılabilecektir. Kavram kargaşasının yaşanmaması ve yukarıda izâh edilen detayların çok daha net bir şekilde anlaşılabilmesi adına bu noktadan itibaren örnek bir uygulama üzerinden giderek konuyu detaylandırmak çok daha faydalı olacaktır.

Örnek uygulamaya geçmeden önce klasik ve sorunlu olan modelin kafamıza daha net canlanabilmesi adına diagram üzerinden ilerlemek faydalı olacaktır.



[Diagram – 1], temel işlevi bir şirketin giriş kapısında bulunan standart bir kart okuyucudan kartlarını geçiren çalışanların kart bilgileri ile birlikte giriş/çıkış saatlerini şirket içerisinde bulunan bir Sql Server veritabanına kaydeden bir uygulamayı temsil etmektedir. Bu noktada dikkat edilmesi gereken en önemli detay sistem tamamen birbirine “bağımlı” modüllerden oluşmakta, asıl iş akışının bulunduğu Security Logger isimli modül çalışabilmek için diagram’ ın altında bulunan 2 adet alt seviyeli modüle ihtiyaç duymaktadır. Alt seviyeli modüller ise asıl işleri olan kart okuma ve veritabanına kayıt etme eylemlerini üst seviyeli modüle ihtiyaç olmadan gerçekleştirebilmekte; yani herhangi bir modüle bağımlılıkları bulunmamaktadır. Bu noktada çok ciddi problemler ortaya çıkmaktadır. Hızlıca bu problemlere değinerek örneğimize devam edelim.

Öncelikli olarak belirttiğimiz üzere üst seviyeli modülün “asıl işi yapan” modül olarak konumlandırdığımızda herhangi bir modüle bağımlılığının olması çok ciddi bir sorundur. Bu noktada yaşanabilecek en önemli problem üst seviyeli modül herhangi bir kart okuyucusu ve bir sql server veritabanı olmayan ortamlarda kesinlikle çalışmayacak, yani tekrar kullanılabilir durumda olmayacaktır. Bu, işin en önemli kısmının çözüldüğü bir modül için çok ciddi bir problemdir.

Bir diğer problemi düşündüğümüzde, geliştirilen bu yazılımın farklı bir şirkette, fakat kart okuyucusu yerine çalışanları parmak izi ile takip eden bir şirkette kullanmaya çalışalım. Ve işleri biraz daha zorlaştıralım ve şirkette Sql Server yerine farklı bir veritabanı yönetim sistemi olan Oracle’ ın kullanıldığını varsayalım. İşte problem! Sadece kart okuyucu sistemi ve Sql Server ile çalışan güvenlik yazılımı bu sistem için tekrardan elden geçmesi ve” üst seviyeli modül” içerisinde uygulama geliştirme çalışması yapılması gerekmektedir. Bu soruna yönelik yapılacak en basit ve “yanlış” çalışma, ilgili modül içerisindeki ilgili fonksiyonun kullanılacak olan sisteme yönelik bir parametre alması (muhtemel bir enum değeri) ve çalışma zamanında bu parametreye göre ilgili güvenlik sistemi üzerinden gelen personel numarasını (parmak izi, kart okuyucu v.b.) yine bir diğer parametreden gelen değere göre aktif veritabanı yönetim sistemine gönderecektir. Yarın birgün farklı bir şirketteki altyapıya göre fonksiyona yeni bir parametre daha, yeni bir parametre daha… Üst seviyeli modülün tekrar kullanılabilir olması adına yapılan tüm bu değişiklikler varolan sistemde problemlere sebep olabilmekte, fonksiyonun şişmesi sebep olmakta ve en önemlisi bu değişikliklerin yapılması adına sürekli bir maliyet gündeme gelmektedir.

Çözüm ise yazımızın konusunu oluşturan bir yazılım geliştirme prensibinde net bir şekilde bulunmaktadır. Bağımlı olan üst seviyeli modülün hiç bir alt modüle bağımlı olmadan tasarlanmış olması yukarıda bahsi geçen problemleri engellemiş olacak; üst seviyeli modülün tekrar kullanılabilir olmasını sağlayacaktır. [Diagram – 2] üzerinden prensibimizi incelemeye devam edelim.

[Diagram – 2]’ den anlaşılabileceği üzere üst seviyeli modül “detaylardan” tamamen arındırılmış bir sistem üzerine oturtulmuş, alt seviyeli modüller ile arasında bağ tamamen koparılmıştır. Bu noktada üst seviyeli olan modül, soyut sınıflara ya da arayüzlere göre programlanmış, haliyle bu soyut sınıflar ve arayüzleri uygulayan tüm alt seviyeli modüller ile “en ufak bir değişiklik yapmaya gerek olmadan” kullanılabilecek şekilde hazırlanmıştır. Sembolik olarak konunun özetlenmesinden sonra dilerseniz konunun teknik olarak ifade edilebilmesi adına bahsi geçen sistemi programatik olarak inceleyelim.

Hatırlanacağı üzere bağımsız olarak işlev gören alt seviyeli modüllere “sıkı sıkıya” bağlı üst seviyeli bir modülden bahsetmiştik. Modülü programatik olarak [Kod – 1] içerisinde hazırlayalım.

Kod – 1

[Kod – 1] ‘ i incelediğimizde bahsi geçen üst seviyeli modülün içerisinde bulunan IdentifyAndLog isimli fonksiyonun alt seviyeli olarak tasarlanan ve kendi başlarına tekrar kullanılabilecek durumda olan PasscardIdentifier ve SqlServerLogger isimli modüllere bağımlı olduğunu net bir şekilde görebilmekteyiz. Farklı sistemler ile çalışılması gerektiğinde (Parmak izi okuyucusu, göz retinası, Oracle veritabanı yönetim sistemi v.b.) sistemin çalışmayacağı ve tekrar kaynak kodlarına dönerek bir takım değişikliklerin yapılması gerektiği çok net bir şekilde ortadadır.

Yazı içerisinde bahsi geçen ve “önerilmeyen” çözüm ile sorunumuzu çözmeye çalışalım. Bu noktada ilk düşünüldüğünde gerçekleştirilebilecek en kolay çözüm IdentifyAndLog isimli üst seviyeli modül fonksiyonunun kullanılacak olan sistemlere göre parametre almasıdır. Bunu bir “enum” tipi ile basit bir şekilde ilgili fonksiyona uyguluyoruz.

Kod – 2

[Kod – 2] standart bir uygulama geliştirici için mükemmel bir çözüm gibi dursa da, geleceğe yönelik yatırımlarını şimdiden yapmayı tercih eden bir uygulama geliştirici için ise tam anlamıyla ciddi anlamda problemlidir. Yazımızın içerisinde de bahsettiğimiz üzere anlık bir çözüm olarak görünse de, farklı sistemler için entegrasyon gerektiğinde her seferinde kaynak kodları değiştirilecek, enum tipleri içerisine yeni tipler eklenecek, yeni implamantasyonlar gerçekleştirilecek ve en önemlisi “üst seviyeli modülün” kaynak kodları ile oynanacaktır. Hem bağımlılık devam ediyor, hem zaman, hemde maliyet.

Ve gelelim sorunun asıl çözümüne. Yazı içerisinde bahsettiğimiz üzere bu noktadaki en temel sorun bağımlılığın yok edilmesi ve sistem içerisindeki modüllerin birbirlerinden bağımsız olarak güncellenebilmesi, yeni modüllerin eklenebilmesi ve zaman – maliyet parametrelerini minimize edebilmektir. Bu aşamada üst seviyeli modülümüzü abstract sınıflara ya da arayüzlere yönelik bir sistem üzerine oturtarak bağımlığı yok ediyoruz. Araya yerleştirdiğimiz bu katman ile alt seviyeli modüllerin üst seviyeli modül tarafından kullanılabilmesi için gereksinimleri de belirlemiş oluyoruz. Kod – 3 üzerinden devam edelim. [Kod – 3] içerisindeki çözüm arayüzler ile gerçekleştirilmiş, duruma göre abstract sınıflar ile de aynı çözüm elde edilebilecektir.

Kod – 3

Hızlıca [Kod – 3]’ ü inceleyelim. Dikkat edileceği üzere bağımlılığın yok edilmesi adına çok ciddi değişiklikler bulunmaktadır. Kod bloğunun altında bulunan arayüzlere dikkat edelim. Bu arayüzler sistemin çalışabilmesi için gerekecek olan 2 alt seviyeli modülün temel olarak uygulaması gereken operasyonların tanımlamalarını içermektedir.

Üst seviyeli modül incelendiğinde ise, gerçekleştirilen kodlamanın spesifik bir modüle yönelik olması yerine dikkat edilebileceği üzere arayüzlere bağımlı kalarak gerçekleştirilmiş, bu sayede spesifik bir alt seviyeli modüle bağımlılık neredeyse kalmamıştır. Sınıfın constructor (yapıcı metot)’ u ilgili arayüzleri uygulamış sınıfların örneğini (instance) parametre değeri olarak istemektedir ve gelen bu objeleri sınıfın içerisinde tanımlamış olduğumuz arayüz tiplerindeki özelliklere (property) atamaktadır.  Aslında çözümün sırrı bu noktada bulunmaktadır. İlgili arayüzleri uygulayan herhangi bir sınıf üst seviyeli modülümüz tarafından kullanılabilecektir, bu şekilde herhangi bir sisteme bağımlı kalmadan çalışma zamanında istenilen kombinasyon uygulanabilecektir. Ayrıca üst seviyeli modül herhangi bir sistem bünyesinde tekrar kullanılabilecek durumdadır.

Bu noktada farklı bir soru işareti daha oluşmaktadır. Üstte de belirttiğimiz üzere ilgili sınıfın (üst seviyeli modül) yapıcı metodu (constructor) bizden ilgili arayüzleri uygulamış olan objeleri istemektedir. Bu objelerin sistem içerisinde statik kodlanarak gönderilmesi ise farklı bir problem oluşturacak, amacımız olan “sistemin bir kez kodlanması ve çalışma zamanında tekrar değişikliğe gidilmeye gerek kalmadan çalışmaya devam edebilmesi” prensibine uymayacaktır. Bu sorunun çözümü ise farklı bir yazıda inceleyecek olduğumuz “Dependency Injection” ya da “Inversion Of Control” isimli tekniklerde gizlidir.

Genel olarak bakıldığında, geliştirilen uygulamaların bünyesindeki üst seviyeli modüllerin alt seviyeli modüllere bağımlı olması ciddi bir problem oluşturmaktadır ve bu bağımlılığın minimize edilmesi gerekmektedir. Yazımızda bahsi geçen “Dependency Inversion Principle” isimli yazılım geliştirme prensibi ile bu bağımlılığı ortadan kaldırabilmekte; başka bir ifade ile “bağımlılığı tersine çevirebilmekteyiz”.

Sonuç: Birkaç cümle ile açıklamak gerekirse, geliştirilen uygulamalarda modüller arası bağımlılık zayıflatılmalıdır. Üst seviyeli modüller alt seviyeli modüllere bağımlı olmamalıdır. Bağımlılıkları zayıflatılan modüller birbirleri ile direk konuşturulmamalı, Dependency Injection, Inversion Of Control gibi teknikler kullanılarak haberleştirilmelidir.

Türkçe Microsoft Forumları Hazır

Merhaba,

Microsoft cephesinde 1 sene öncesinden başlayan ve Newsgroup’ lar yerine Forum mantığını devreye alan süreç tamamlanmış bulunuyor. Bu anlamda özellikle Microsoft Technet, MSDN ve Microsoft Answers Forum’ larının Türkçe versiyonlarının da açıldığını bildirmek isterim. Bu Türkçe konuşan geliştiriciler için oldukça önemli bir fırsat.

Microsoft tarafından yönetilen forumlara çeşitli teknolojilerle ilgili sorularınızı sorabilir ve yetkili uzmanların ve Microsoft MVP’lerinin önceden verdiği cevaplara göz atabilirsiniz.

Kaynakların özellikle Türkçe olması gerçekten çok çok önemli bir gelişme. Teşekkürler Microsoft…

MSDN

Microsoft Technet

Microsoft Answers

Yaz Geliştir Zirvesi Etkinliği

Merhaba,

Dün (29 Mayıs 2010) tarihinde yaklaşık 1 aydır duyurduğumuz Yaz Geliştir Zirvesi Etkinliği dolayısıyla Microsoft Türkiye İstanbul ofisindeydik. Yaklaşık 500 kişinin kayıt olduğu, ben dahil toplam 12 MVP’ nin konuşmacı olarak katıldığı etkinliğe AÖF ve F1 olması sebebiyle yaklaşık 170 kişi katıldı

Selçuk Uzun, Kerem Özsu, Atakan Kesler, Gökşin Bakır ve Baransel Doğan tarafından gerçekleştirilen Key Note ardından oturumlar başladı. Konuşmacılar olarak oturumlarımızı beklerken konuşmacı odasında vakit geçirdik

Etkinlik, diğer etkinliklerimizde olduğu gibi çok keyifli geçti diyebilirim. Katılımcılar, ilgilendikleri alana uygun oturumlara katıldılar ve seminer konuları ile ilgili bolca sorular sordular. Konuşmacısı olduğum “Windows Mobile 6.5 İle Mobil Cihaz Uygulamaları Geliştirmek” etkinliğine yaklaşık 30 kişi katıldı ve bolca soru geldi.

Yaz Geliştir 20.000 kişiyi bünyesinde barındıran çok büyük bir topluluk. Böyle bir topluluk bünyesinde gerçekleştirilen böyle keyifli bir etkinlikte konuşmacı olarak görev almak çok keyifliydi. Eminim Yaz Geliştir bünyesinde bu ve benzeri etkinlikler çok yakın zamanda yeniden organize edilecektir. Etkinliğin gerçekleştirilmesinde emeği geçen tüm görevli ve “gönüllü” arkadaşlara burada teşekkürlerimi iletiyorum.

Ege BootCamp Etkinliği – Windows Mobile Workshop

Merhaba,

Ege üniversitesi öğrencileri tarafından düzenlenen Ege BootCamp etkinliği bünyesinde 20 Mayıs 2010 tarihinde Ege Üniversitesi bilgisayar mühendisliği bölümünde “.Net Compact Framework ile Mobil Cihaz Uygulamaları Geliştirmek” konulu tam günlük bir workshop gerçekleştirdik.

Workshop’ a yaklaşık 20 öğrenci katıldı. Okulun son dönemleri olması dolayısıyla geri kalan 20 arkadaşla tanışma imkanım olmadı

Workshop’ ta temel olarak mobil cihaz ve mobil cihaz uygulama geliştirme teknolojilerinin üzerinden geçtikten sonra .Net Compact Framework ve Sql Server Compact edition platform ve araçlarını kullanarak örnek bir Windows Mobile 6.5 mobil cihaz uygulaması geliştirdik. Keyifli geçen etkinliğin ardından 17:55 uçağıyla tekrar İstanbul’ a döndüm. Etkinliğin düzenlenmesinde emeği geçen tüm arkadaşlara teşekkür ederim.

Microsoft Zirvesi 2010

Merhaba,

Etkinliklerim sayfası üzerinden daha öncede duyurduğum üzere 2 gündür Microsoft’ un yepyeni ürünleri Sharepoint 2010, Office 2010 ve Sql Server 2008 R2 lansmanları dolayısıyla Swissotel’ deydim. 1500 kişinin kayıt olduğu etkinlikte 37 farklı konuşmacının paralel olarak sunduğu 44 farklı oturumun düzenlendiği etkinlikte benimde “Office 2010 Backstage üzerinden Sharepoint 2010 Listelerine Erişmek” isimli bir oturumum vardı. Mutlu olduğum nokta ise geliştirdiğimiz bu çözümü ilk gün açılış konuşmasında (Keynote) Microsoft Genel Müdürü Tamer Özmen dahil tüm katılımcılara demo şeklinde gösterebilme imkanım oldu. Aşağıda Microsoft Türkiye Bilgi Çalışanı Ürün Grubu Pazarlama Müdürü Onur Görür sevgili Onur Görür’ ün beni sahneye davet ettikten sonra demoyu gerçekleştirdiğim dakikalarda çekilen bir fotoğraf bulunuyor!

Etkinliğin 2. günü ise saat 16:30′ da yukarıdaki başlıklı oturumumu gerçekleştirdim. Saatin biraz geç olması dolayısıyla katılımcı sayısı sabahki oturumlar kadar yoğun değildi, fakat sadece konu ile bizzat ilgilenen kişilerin kalmış olması da ayrı bir keyif vericiydi.

Swisotel’ de gerçekleştirilen etkinlik gerçekten kusursuzdu. Bir önceki gece saat 2′ ye kadar süren provada herkes inanılmaz derece yoruldu. Ama bir sonraki sabah sonucu gördüğümüzde bu yorgunluğa gerçekten değmişti. Aşağıda etkinlik öncesi gece saat 01:00 civarında çekilen bir fotoğraf yer alıyor

Swissotel gibi mükemmel bir otelde Microsoft gibi bir yazılım devinin bu kadar önemli bir organizasyonunda bizzat görev almak gerçekten gurur verici. Etkinliğin gerçekleştirilmesinde başta Yeşim Sünger ve Onur Görür olmak üzere tüm Microsoft ailesinin emeğine sağlık. Herşey mükemmeldi.