Genel

İş hayatına adım attığımda tarihler 1999 yılını gösteriyordu. Bilgi İşlem Sorumlusu unvanı ile yarı zamanlı başladığım şirkette bir çağrı merkezi uygulamasının geliştirilmesinden, bilgisayarların kurulumlarından ve kullanıcı destek işlemlerinden sorumluydum. O zamanlar sahip olduğum bilgiler çok kıt ve tamamen programlama üzerindeydi. Ne katmanlı mimarilerden ne de tasarım kalıplarından bihaberdim. Hal böyle olunca yazdığım uygulama buton arkası kodlamanın ötesine geçemiyordu. Üstelik web tabanlı değil Windows tabanlı bir programdı ve dağıtımı çağrı merkezi bilgisayarlarına kopyala yapıştır usulüne göre yapılıyordu (Neyse ki şirkette sadece on iki çağrı personeli vardı) ancak bir sonraki işimde dengeler tamamen değişti. Bu sefer yazılım dünyasının milenyum başındaki yükselen yıldızlarından olan.Net platformu üstünde yeni yetme bir yazılımcı olarak işe başlamıştım. Bana Junior Software Developer unvanı vermişlerdi ve bu kez web tabanlı bir uygulama ile bol miktarda katman söz konusuydu. Tipik olarak katmanlı mimariye göre geliştirilmiş ve müşterisi olan bir ürün üstünde çalışan birkaç yazılımcıdan birisiydim.

Uygulama geliştirme yaşam döngümüzün henüz otuzuncu Sprint başındaydı. İki haftalık koşu görevlerini Sprint Planning toplantısında zaten belirlemiştik. Takım olarak 13 Story Point’e sahip Production Support Buffer mecburen her sprint içerisine dahil ettiğimiz bir maliyet. 17 yaşındaki Microsoft.Net tabanlı devasa ERP (Enterprise Resource Planning) ürünümüz ek geliştirmeler veya önceki yıllardan kalan teknik borçlar sebebiyle bazen üretim ortamı sorunları ile karşımıza gelmekte. Büyüklüğüne nazaran Code Coverage oranının düşük olması yeni ilavelerin var olan yapılara olan etkisini anlamamızı zorlaştırıyor. Ben, Mali İşler ve Ortak Modüller (Kimsenin bilmediği bir modül varsa böyle gelin) ekibindeyim. Lakin ERP’nin diğer modüllerinde de benzer sorunlar olabiliyor.

Seksenli yıllarda İngilizlerin Central Computer and Telecommunications Agency isimli departmanı, IT hizmetlerindeki sıkıntıların tespiti ve doğru yolun bulunması amacıyla ITIL olarak kısaltılan bir konseptin temellerini ortaya koymuş. Tam olarak açılımı Information Technology Infrastructure Library şeklinde. Ona kütüphane denmesinin makul bir sebebi de süreçlere ait pratikleri içeren beş kitaptan oluşması. O yıllarda temelleri atılan ITIL zaman içerisinde yeni versiyonları ile birlikte gelişmeye devam etmiş. Bugün pek çok IT firmasının (ki sadece IT ile sınırlamak doğru değil nitekim içerisinde hizmet geçen her alanda ele alınabilir) uygulamaya çalıştığı bir, bir…Şey…Immm…Bir ne?

Satranç oynamayalı yıllar olmuştur. Lise yıllarında kadim dostum Burak Gürkan ile karşılıklı maçlar yapardık. Kerata çok iyiydi. Maçları çoğunlukla kaybederdim ama yine de hoşuma giderdi onunla rekabet içerisine girmek (Bir ara arayayım da yine satranç oynayalım) Herhalde sevdiğimiz bir arkadaşımızla yapabileceğimiz en güzel aktivitelerden birisidir Satranç. Sebat etmek, stratejik düşünmek, saygı göstermek, kabullenmek, odaklanmak…Faydaları saymakla bitmez.

Önceki yazımızda WsHttpBinding kullandığımız sertifika tabanlı bir WCF senaryo çalışmamız vardı. Aynı örneği göz önüne alarak BasicHttpBinding kullanabileceğimizi de belirtelim. Nitekim bu bağlayıcı tipi ile de Message tabanlı güvenliği sertifika bazlı gerçekleştirebiliriz. Bunun en gerekli sebeplerinden birisi de servis tüketicilerinin eski nesil uygulamalar olabilmesi sebebiyle sadece SOAP 1.1 haberleşme kurmasıdır. Olmaz demeyin oluyor. Geliştirmekte olduğumuz projede buna benzer bir ihtiyaçla karşılaştık. Bazı servis tüketicilerimiz sadece SOAP 1.1 paketi gönderebilir durumdalar. Tabii öncelikle bizim.Net ortamında bu senaryoyu test edebilmemiz gerekmekteydi. Bağlayıcı tipini belirledik, Message güvenliğini ayarladık, sertifika tanımlamalarını yükledik ve servisi ayağa kaldırıp istemciye proxy tipini indirttik. İstemci web.config dosyasında gerekli ayarlamaları yaptık. Ne varki istemci tarafındaki endpoint bildiriminde yaptığımız aşağıdaki örnek tanımlama işe BasicHttpBinding tipi özelinde işe yaramadı ve çalışma zamanında “The request message must be protected” şeklinde hata aldık.

Nitelikler bildiğiniz üzere çalışma zamanına bilgi taşımak amacıyla kullanılan önemli tiplerdendir. Visual Studio tarafında da işimize yarayan bir çok nitelik (Attribute) yer alır. Bunlardan birisi DebuggerDisplay’dir. Önce aşağıdaki ekran görüntüsündeki kod parçasını göz önüne alalım.

Programlardaki About Info kısımlarını bilirsiniz. Yazdığımız uygulama hakkında bir takım bilgiler verir. Genellikle ürünün adı, bir iki cümle ile ne yaptığı, üreticisi ve hatta versyion numarası ve benzeri bilgiler yer alır. Micorosoft.Net tarafında aslında bu tip bilgileri Assembly’a ait niteliklerde (attribute) belirtiriz. Aynen aşağıdaki ekran görüntüsünde olduğu gibi.

Geçtiğimiz günlerde üzerinde çalıştığımız projede şöyle bir ihtiyaç oldu: Uygulamanın şirket ağı dışındaki bir kuruma ait REST (Representational State Transfer) tabanlı servis noktalarını kullanması gerekiyordu. Bu noktalara göndereceğimiz HTTP Get,Post taleplerine göre bir takım sonuçlar alacak ve kurum içi süreçleri işletecekti. Söz konusu servis ve sunduğu EndPoint’ler ile olan iletişim ise X509 standardındaki bir sertifika üzerinden gerçekleştirilmeliydi. Test ortamında yaptığımız çalışmada, sunucu sertifikasının doğrulanması sonrası devreye girecek Callback operasyonunda hata mesajı aldık. Kurumla yaptığımız mutabakat sonrasında ise bu adımı atlayabileceğimizi öğrendik. Çözüm olarak küçük bir hile yaptık. Nasıl mı? Aynen aşağıdaki fotoğrafta görüldüğü gibi.

Yazdığımız bir uygulamada kullanıcının anne kızlık soyadı, kimlik numarası, şifre ve benzeri bilgilerini aldığımızı düşünelim. Bir arayüz üzerinden giriliyor olabilirler. Bu bilgileri herhangibir amaçla veritabanında sakladığımızı varsayalım. Şirket güvenlik politikları gereği ilgili bilgiler açık bir şekilde tutulmamalı. Yani anne kızlık soyadı, şifre veya kimlik numarası gözle okunabilir halde tutulmamalı. Buna göre ilgili bilgileri veritabanı üzerinde maskeleyerek saklamak doğru bir çözüm olabilir. Bunu yapabilmek için akla gelen yollardan birisi de tahmin edileceği üzere Hash algoritmalarına başvurmaktır. Peki güçlü bir Hash algoritması ile bu maskeleme işlemini yapmak ister misiniz? Aşağıdaki fotoğraf size yol gösterebilir.

Nesneler kodlarımızın olmazsa olmaz enstrümanları. Özellikle Domain odaklı çözümlerimizde POCO (Plain Old CLR Objects) tiplerini sıklıkla kullanıyoruz. Bu tipler (genellikle class olarak tasarlanıyorlar) içlerinde sayısız özellik (Property) de barındırabiliyorlar. Nesneler örneklendiklerinde ve sonrasındaki yaşam süreleri boyunca çeşitli değerler ile nitelendiriliyorlar. Peki t anında bir nesne örneğinin tüm özelliklerine varsayılan değerlerini atamanız gerekseydi ne yapardınız? Peki ya bunu herhangibir T tipi için uygulanabilir hale getirmek isteseniz ne yapardınız? Yoksa aşağıdaki gibi generic bir genişletme metodu (Generic Extension Method) ile mi çözüm arardınız?

Bu yaz için kendime güzel bir hobi buldum. Raspberry PI. Biraz geç kalmış olabilirim bunun için ama merak ettiğim IoT (Internet of Things) konusunun önemli parçalarından birisiydi. Üstelik çocukların programlamayı öğrenmesi için de kullanılan vakıf destekli açık kaynak bir çalışmaydı. Hatta bu sene gerçekleştirebilyseydik eğer NedirTv?com etkinliğinde Raspberry Pi ile ilgili sunum yapacak olan DevNot yazarlarımızdan Recep Duman arkadaşımız ile aynı ekipte çalışıyor olmamız gibi bir gerçek de vardı. Kolları sıvadım ve işe koyuldum.

Böyle yeni bir şeyler öğrenmek için enerji bulamadığım vakitler oluyor zaman zaman. Ya çevremdekilerin ya da işlerin etkisi ile azalır enerjim. Bir şeyler öğrenmeyince de kendimi kötü hissettiğimden en azından genişletme metodu (Extension Method) yazmaya çalışayım da pas tutmayım derim. Tabii önce konu seçmek gerekir. Bu kez aklıma “bir servisin yaşayıp yaşamadığını nasıl anlarım?” sorusu takıldı. Mesela bir Uri için Http durum kodu bilgisinin 200 olmasını kontrol eden bir genişletme metodu yazabilirdim. Örneğin aşağıdaki fotoğrafta görüldüğü gibi.

Koleksiyon bazlı veri kaynaklarında LINQ (Language INtegrated Query) sorgularını yoğun şekilde kullanmaktayız. LINQ bildiğiniz üzere pek çok genişletme metodundan oluşan ve ifadesel olarak koleksiyonlar üzerinde SQL benzeri sorgular yapabilmemizi sağlayan bir alt yapı sunmaktadır. Sıklıkla Select, Where, Count, Sort, Max, Min, Reverse, GroupBy, OrderBy ve daha pek çok metodu kullanırız. Bunlar zaman zaman ifadeler şeklinde ele aldığımız gibi zaman zamanda metod zincirleri biçiminde değerlendiririz.

Geçtiğimiz günlerde çalışma arkadaşımın oldukça enteresan bir sorusu ile karşılaştım. Projesinde referans ettiği bir kütüphane içerisinde yer alan POCO (Plain Old CLR Objects) tiplerine ait ToString metodlarını ezmesi (Override) gerekiyordu. Ne yazık ki ilgili kütüphane dll olarak referans edildiğinden, içerisindeki sınıflara girip ToString metodunu ezmek mümkün değildi. Bir şekilde ToString metodunu genişletebilir miyiz diye düşünmeye başladık. Bu mümkün gibi görünmüştü. Ancak varsayılan ToString metodu genişletilse dahi kod her zaman Object tipinin ToString metoduna gitmekteydi. Dolayısıyla istediğimizi bir türlü gerçekleştiremiyorduk. Sonrasında var olan projede kullanılan ToString çağrılarında ufak parametre değişiklikleri yaparak ilerleyelim dedik ve aşağıdaki gibi bir extension method yazmaya karar verdik.

Diyelim ki kullandığınız harici bir metod size DataTable tipinden bir nesne örneği döndürmekte. Ne var ki kendi sisteminizde bu nesne içeriğini List tipinden koleksiyon örnekleri ile dolaştırmanız gerekiyor. Hatta DataTable içeriğinin doldurulduğu tablonun kolon adları da sizin programınızdaki standartlar ile uyumlu değil. Bu durumda karşımıza şöyle bir soru çıkıyor. Herhangi bir DataTable içeriğini bir List tipine nasıl dönüştürebiliriz? Dahası dönüşüm işlemi sırasında T tipinin özellik adlarının tablodaki asıl kolon adları ile eşleştirilmesini nasıl sağlarız? İşin sırrı aslına bakarsanız kendi tarafımızdaki Entity tiplerinde birer Attribute kullanmaktan ve bunu çalışma zamanında ele almaktan geçiyor. Aşağıdaki ekran görüntüsü size bir fikir verecektir.

Geçtiğimiz günlerde her zamanki gibi Google Chrome’ un RSS Feed Reader’ ındaki blog yazılarında geziniyordum. Derken Fatih Boy hocanın bu adresteki yazısına denk geldim. Aslında buradaki gibi Fluent geliştirilen tipler kod tarafındaki işlerimizi oldukça kolaylaştırmakta. Felsefesi oldukça basit olan bu yaklaşımda anahtar nokta, tipin kendisine ait çalışma zamanı örneklerini döndüren fonksiyonelliklere başvurulması. Böylece bir metod zinciri ile bir tipe davranışlar yüklemek son derece kolaylaşıyor.

Malumunuz nesne yönelimli (Object Oriented) dünyanın en önemli unsurlarından birisi de varlıklar (Entity). Uygulamaların çalıştığı alanlarda (Domains) bu varlıklar dolaşmakta. Birer sınıf olarak tasarlanan bu varklıklar çalışma zamanlarında örneklenmekte ve belirli içerikleri taşımakta. Varlığı niteleyen verinin kaynağı çeşitli enstrümanlar olabiliyor. Veritabanı üzerindeki bir tablo, fiziki bir dosya, bir servis uç noktası, başka bir donanım, bir ara motorunun ürettiği çıktı vb

Bazı uygulamaların çalışma zamanında sadece tek bir örneğinin yaşaması istenebilir (Single Instance Applications) Bilindiği üzere uygulamaların T anında birden fazla örneği olabilir (Multiple Instance Applications) Uygulamanın herhangi T anında tekil olması için ele alınabilecek bir kaç teknik vardır. Bunlardan birisi de Mutex tipinden yararlanmaktır. Aynen aşağıdaki fotoğrafta olduğu gibi.

Nesnelerin çalışma zamanında klonlanması ile ilişkili olarak bahsi geçen iki kavram vardır. Shallow (Yüzeysel) ve Deep (Derinsel diyelim) klonlama. Shallow türüne göre, kopyalanan nesnenin alanları orjinal nesnedeki aynı referans adreslerini işaret edecektir (Yani nesne içerisindeki referans türleri kopyalanacak ama aynı bellek adreslerini gösterecektir) Deep Copy tekniğine göreyse kopyalanan nesne alanları orjinal nesne alanlarının yeni kopyalarını referans etmektdir. Bir başka deyişle Deep Copy tekniğini uyguladığımızda, orjinal nesne içeriği ile aynı veri yapısına sahip yeni bir referans (bellekte farklı bir adreste konuşlandırılmış şekilde) üretmiş oluruz.

Bu aralar iş yerindeki projeler beni yeni bir şeyler araştırmaya ve öğrenmeye itiyor. Yeni bir şeyler olmasa bile daha önceden kullandığım ama unuttuğum konulara tekrardan bakmama vesile oluyor. Dün buna benzer bir durum gelişti. Bir projemizde kullanıcıların Active Directory üzerinden kod yoluyla doğrulanmasına ve belirli bir gruba dahil olup olmadıklarının öğrenilmesine ihtiyacımız oldu. (Pek tabi bu konuda yazılmış bazı NuGet paketleri bulunuyor ancak iş öğrenmeye gelince biraz kurcalamanın da yararı var elbette) Çok uzun zaman önce (tahminen 2006 yılı idi) eğitim verdiğim bir firmanın bu tip bir ihtiyacı olmuştu. Ama o günden bu yana hiç kullanmadığım için bilgiler de unutulmuştu. Tek hatırladığım System.DirectoryServices assembly’ında yer alan DirectoryEnrty ve DirectorySearcher sınıflarıydı. Biraz araştırma yapınca denemeler için basit bir kod parçası da ortaya çıkıverdi. Aynen aşağıdaki fotoğrafta olduğu gibi.