Türkçe'nin İngilizce'ye göre önemli bir farkı var: çekim ekleri. Türkçe'de ismin hâllerine çekim ekleri vasıtasıyla geçiş yapılıyor. Misâl; yalın hâli "armut" olan bir kelimenin "gösterme" hâlini oluşturmak için sonuna -i çekim ekini koyuyor ve biraz çeki düzen veriyoruz: "armudu". "Çıkma" hâli için neticemiz: "armuttan".

Programcılar için parametrik Türkçe ifadeleri, programatik olarak çekimlemek İngilizce'ye göre biraz efor isteyen iş. İngilizce'de "x" kelimesi "of x" diye çekimlenebilirken biz kelimeye bir ek ilave edip bir de sesli uyumlarını, sessiz benzeşmelerini dikkate almak zorunda kalıyoruz.

Yıllardır bu meşakkatli yola girmektense hep cümleleri uzatarak çözümü geçiştirdik: "Ahmet'in profiline göz atın" demek yerine "Ahmet adlı kullanıcının profiline göz atın" deyip yanyoldan dolaştık.

Bu yazıda haberini vereceğimiz ufak C# sınıfı "Türkçe Hâller", bu kronik arızayı giderme maksadı taşıyor. Kodunuzun içerisine ekleyip doğrudan kulllanabileceğiniz basitlikte. Basit bir matematikle kelimelere uygun eki eklemeye çalışıyor.

Kullanımı gayet basit:

string result = TurkceHaller.Uygula("Ahmet", TurkceHaller.IsminHali.Yonelme);

Herhangi bir veri kaynağı kullanmadığı, sadece algoritma olduğu için isim/sıfat tamlamalarında %100 başarılı olamayan C# sınıfını aşağıdaki proje sayfasından indirebilirsiniz.

http://code.google.com/p/turkcehaller

"WCF Güvenlik Kılavuzu" ana başlığı altında döktürmeye devam ediyoruz. İlk çeviri yazımızda "Tasarım Hususları"nı işlemiştik. Bu yazıyla WCF servislerinde denetimi ve log'lamayı "güvenlik" paradigmasıyla ele alacağız. Tekrar hatırlatmakta faide var ki bu yazı serisi, Patterns&Practices ekibinin "WCF 3.5 Security Guidelines" belgesi esas alınarak hazırlanıyor.

Denetleme ve Log'lama

Denetleme ve log'lama "sürekli güvenlik" için iki ayrı vazgeçilmez unsur. İkisi de bir uygulamanın hayatı boyunca karşılaştığı durumlardan haberdar olmamızı sağlıyor. Görelim bakalım, neler yapmalıyız.

"WCF Güvenlik Kılavuzu - 2 (Denetim ve Log'lama)" devam ediyor »

Windows Communication Foundation (WCF) uygulamaları geliştiriyorsanız "güvenlik" asla ihmal etmemeniz gereken bir boyut. Ancak WCF'nin henüz yeni bir altyapı oluşu (1.0 sürümünde) nedeniyle işin sahiplerinden nasihatler bekliyoruz.

Microsoft'un Patterns&Practices bölümünden bir grup hayatlarını sadece WCF güvenliğine adamışlar ve CodePlex'te konuşlanmış bu sahife ile çeşitli "yol yordam" tavsiyeleri yazıyorlar. Ekibin ilgili projedeki "WCF Security Guidance" başlıklı kaynak belgesini doğrudan değil ama katkılar yaparak parça parça tercüme etmeye çalıştık. Faydalı olması dileğiyle.

Özgün Belgenin Müellifleri: J.D. Meier , Jason Taylor , Prashant Bansode , Carlos Farre, Madhu Sundararajan, Steve Gregersen

Aşağıda verilen nasihatler dizisi tekrar kullanılabilirlik adına olabildiğince soyutlanmıştır. Bu nedenle başlangıç noktası olarak dikkate almanız ve yolculuk esnasında kendi yoğurt yiyişinizi geliştirmeniz salık verilir.

"WCF Güvenlik Kılavuzu - 1 (Tasarım Hususları)" devam ediyor »

"Biz büyüdük de kirlendi dünya" der şarkı. Aynı şarkıyı internet için de söyleyebiliriz. İnterneti büyüttük, büyüttük ve kirlettik. Artık elimizde kir ve pas içinde koca bir yumak var ve aradan doğru düğümü bulmaya, onu çözmeye çabalıyoruz.

Şu fotoğrafa bakın:

"title" etiketi Eminönü meydanına çevrilecek son yer. Biz buna "başlık kirliliği" diyoruz.

Son günlerde "hafif HTML" kirliliğine dair bir duyarlılık yaşıyoruz. Ne olacak bu HTML alternatiflerinin hâli diyorlar. Hak veriyoruz.

"Kirletmek Güzel midir?" devam ediyor »

Borland, mutlaka bir yanımıza değip geçmiştir. "Kral" olduğu devirler çok uzak değil: .NET'ten öncesi desek pek de hatalı olmaz.

Borland'ı IDE imalatında zirveye taşıyan ürün, Pascal'ın üzerine bina ettiği Delphi. Herkesin bir hikâyesi vardır Delphi'yle alakalı. Benimki bir demo CD ile başladı. Özerinde antik tapınak figürleri... Delphi kaçtı acaba? Belki 2, belki 3. Oyun yapabilir miyim diye sorarak başlayıp en fazla hesap kitap programı yapmıştım o dönem. Biraz hazırlıksız bir girişti.

Delphi, Win32 programlama hatırı sayılır bir yere sahip olmuştu. .NET öncesindeki rakibi VB X ile mukayese bile edilmiyordu. Hatırlayan olacaktır Delphi-VB kıyaslarını. Canon-Nikon atışmasından veya FB-GS müsabakasından bir farkı yoktu.

Delphi, Pascal'ı evirip çevirip modern bir dil hâline getirmekle kalmıyor programcılara alışıp da bırakamayacakları bir geliştirme ortamı sunuyordu. VCL dediği kontrol paketi her istenene cevap veriyordu neredeyse. Pascal'ın o VB ve C arasında kalmış akademik diline bile katlanıyordu programcılar, sırf bu güzel IDE hatrına.

Ama Seattle'da saatli bomba kurulmuştu. .NET Framework adında bir şey var olan tüm Win32 programlama tecrübesinin üzerine silgi çekip beyaz bir sayfa açıyordu. Ve ne yazık ki bu sayfada Borland'a yer yoktu. Daha da yazığı şu ki bu sayfayı, Delphi'yi icat eden adam, bir Microsoft çalışanı olarak açıyordu. Vah vah!

Programcılar, terkedemeyeceklerini zannettiğimiz o IDE'yi .NET'in tehcir emriyle terkettiler. Bu terk-i diyar, ıssızlaşan Borland vadisini biraz düşünmeye sevketti. Düşündüler ve Delphi for .NET diye bir çözümle .NET'e de IDE sunmayı denediler. Olmadı. Delphi for Java ve Delphi for PHP de bu beyhude çabaların birer örneğiydi. Çok erkenden olacakları gördükleri için belki Kylix ile Linux'a gülümsemişlerdi ama sanırım Linux onlara daha az gülümsedi. Kurtulmanın zamanı gelmeliydi şu IDE heybesinden.

CodeGear, Borland'ın Delphi'den ve biraderleri C++ Builder, JBuilder gibi tüm programlama ortamlarından kurtulmanın ilk adımıydı. Resmi açıklamaya göre Borland, odağına Application Life-Cycle Management (ALM) çözümlerini almıştı. Programlama işini CodeGear adında bir alt müesseseye devretmişti. Bunun bir paketleme olduğunu cümle âlem anlamıştı.

CodeGear sözlükte "Sahibinden Satılık IDE'ler" diye geçiyordu. Ve programcının Borland defteri, 23 milyon dolarlık bir anlaşmayla kapanacaktı.

Delphi, antik temeline uygun bir şekilde "antika" oluverdi. Yeni sahibi onunla neler yapacak bilemiyoruz. Yalnız programlama dünyasına kazandırdığı standartlar, konfor ve bakış açısı bugün ve bugünden sonra çıkacak tüm araçlarda etkisini muhafaza edecek. Bundan dolayıdır ki hep saygıyla yad edilecek.

Vefa ile.

Modern nasihat yazısı yazıyor olsak, böyle bir başlık seçmemiz işten bile değildi. Neyse ki öyle değil sevgili okuyucu; ne bir nasihat yazısı yazıyoruz ne de sakalımız var.

Merkezimizde yine işçimiz, emekçimiz, yani kodcumuz var. Birçok kereler (1, 2) kendisinden söz açmış idik, elbette yeterli olmuyor. Yine ekmeğini klavyeden, noktalı virgülden ve debug'tan çıkaran bu insan formuna çeviriyoruz bakışlarımızı.

Kodcu için hiçbir tercihin sıradan olmadığını söyledik. Bu, kodcu hep tercihler arasında yaşıyor iddiasını da ihtiva ediyor. Kodcu için yazdığı kod rasgele değildir. Yapabilecekleri arasında en iyisini seçerek (tercih ederek) yapmıştır. Böyle yaptıysa eğer ve yapıyorsa, kodcu olmuştur.

Kod yazan insanların hangi platformda koşarsa koşsun, önlerine birçok yol çıkmaktadır. Ve bu yolları aşmak için yanlarına alacakları birçok alet.

Misâl, .NET veya Java bir tercihtir. .NET'e girdikten sonra C# veya VB.NET ayrı bir tercih olur. C#'ı tercih edenin önünde tasarım kalıpları ayrı bir tercih. Basit bir for-loop içerisindeki sayaç değişkenine vereceği adı bile tercih eder kodcu.

Kimi zamanlar aynı işi görebilecek birden fazla yöntemle başbaşa kalır kodcu. Ona kim rehberlik edecektir o zaman? Rasgele birisini seçip devam mı etmelidir? Yoksa ben bu konuda biraz daha bilgileneyim mi demelidir?

...

Abdullah Nehir, .NET kodcularının hemen her gün başvurduğu hazır koleksiyon nesnelerini üşenmemiş bir performans tetine tâbi tutmuş. Detaylı grafik ve çizelgenin ardından vardığı netice şu:

• Anahtar-değer çiftleri tutulduğunda araması en hızlı olan: 10'dan az eleman için SortedDictionary, fazlası için Dictionary.
• Sadece değer listesi tutulduğunda arama yapmayıp çevrime sokacaksanız en iyisi List; arama yapacaksanız (varlık kontrolü yapacaksanız) en iyisi HashSet.

Bundan sonra koleksiyonları kullanırken bu bilgileri de göz önüne alırız. Eline sağlık Abdullah Bey'in.

...

Özcan Değirmenci ise static değişkenleri nasıl hazırlamak evlâdır diye sormuş ve üretilen IL kodlarını incelemiş. Static değişkenleri ya inline olarak (satır içi) ya da bir static constuctor bünyesinde hazırlayabiliyoruz, mâlum. Özcan Bey'in son cümlesi şu:

"Static'ler için yapabiliyorsanız, daima 'inline initialization' kullanmayı deneyin."

...

İki farklı konuda hususi bir çalışmalarla ortaya çıkacak neticeleri paylaşmış olduk. Bunun gibi yüzlerce durak vardır, kodcunun tercih yaparken bilgiye ihtiyaç duyabileceği. Demek ki makinelerdeki tüm ilerlemelere rağmen bu iş hâlâ bilgi ve şuur gerektirmektedir.

Velhâsıl şu acı tespiti yalancı çıkarmak gerek. En azından bu ülkede.
Şuur ile.

Kullanıcı adı ve parola. Web hayatımızın şüphesiz en çok tekrar eden ikilisi. Binlerce site ve kendi kendimize geliştirdiğimiz şifre algoritmaları ve ortak kullanıcı adları. Biraz ustalaşınca gelen "kategorizasyon"; sahte kullanıcı adları, çöp olarak kullanılan e-posta adresleri... Unutulan şifreler, cevaplanamayan gizli sorular... Güvenlik denen mevsim salatası.

Olmazsa olmaz olan kullanıcı kimliklendirme işi ne mutlu ki düğümlenmiş durumda.

Çaba

Şikâyetlerin bizde bile çok erken başladığı bu düğümü çözmek için her kesimden bir girişim geldi zaman içinde. .NET Framework nesli hatırlar ki Passport diye bir Microsoft hizmeti sunulmuştu. Yok şimdilerde. Yerine "Windows Live ID" geldi. Alın size bir tek "Live" hesabı ile tüm "Live" hizmetlere bağlanabilme özgürlüğü!

Evet, Microsoft kendi hizmetlerine tek bir hesapla girmeyi sağladı. Google da yaptı bunu, Google Account diyerek. Yahoo ise senelerdir yapıyor, hakkını yememek lâzım.

Yalnız bu büyük sağlayıcıların bir problemi var: verdikleri kimliklendirme sadece kendi hizmetlerinde işe yarıyor. Dünyanın Yahoo, Google veya Microsoft olmayan kısmına erişmek istediğimizde, yeni kayıt formları ve yeni kimlikler bizi bekliyor.

Çözüm arayan Microsoft, Passport'u dış dünyanın da kullanabileceğini yıllar evvel ilân etmişti. Lâkin tabî olarak kimse buna yanaşmadı. Çünkü insanoğlu kimliğini Microsoft'ta tutmak zorunluluğunu sevmezdi, sevmeyecekti.

Açık Kimlik

Biz yine o siteye "abc", bu siteye "def" diye şifrelerimizi girerken yetenekli adamlardan Brad Fitzpatrick OpenId diye bir şey icat etti. "Open" geldi mi başına bir şeyin, zaten doğrudan cezbedici oluyor bu âlemde bilirsiniz. OpenId de kalabalıkları cezbetti.

OpenId'nin getirdiği radikal değişiklik, aslında adındaki "Open"da saklı. OpenId, genel tanımıyla bir sayısal kimlik hizmeti. Ama kimlik doğrulayan bir otorite değil. Bu cümle çok önemli. İşin sırrı da burada. OpenId, sayısal kimliğin nasıl kullanılacağını belirlemiş ve otorite yolunu açık bırakmış. Sıradan bir vatandaş bile bir OpenId kimlik sağlayıcısı olabilir. Bu bizim her genel / yerel seçimde hissettiğimiz "Seçme Özgürlüğü" anlamına geliyor.

Kullanıcı istediği kimlik sağlayıcıdan kimliğini alıyor. OpenId destekleyen bir web sitesine bu kimliğinin anahtarını (URL'ini) yazıyor ve de doğrulanmak için kendi sağlayıcısına yönlendiriliyor. Doğrulama yapılıp asıl siteye geri dönülüyor. Şayet asıl site isterse kullanıcıya fazladan sualler sorabilir, kendi problemi.

Bu anlattıklarımızı şu şemada daha açık görebilirsiniz: (kaynak)

Anlaşıldı; bir takım kısaltmaları açıklamak gerekecek. RP, "Relying Party" bizden üye girişi isteyen OpenId ve destekleyen taraf. IP, "Identity Provider" ise herhangi bir kimlik sağlayıcı. Beraber adımlayalım. RP'yi burada www.evcil.net olarak farzettik.

1. www.evcil.net'in "login" sayfasındasınız. Form'a OpenId URL'inizi yazıyorsunuz.
2. www.evcil.net, bu URL'in hangi sağlayıcıda doğrulanacağını belirleyip tarayıcınıza "şuraya git" diyor.
3. Tarayıcınız oraya gidiyor. Orada bir login formu daha varmış. Bildiğiniz bir yer burası.
4. Şifreyi giriyorsunuz ve beni doğrula diyorsunuz. Eğer her şey yolunda giderse burası, sizin geldiğiniz yeri bildiği için akıllıca bir soru soruyor: "geldiğin yere yani www.evcil.net'e göndereyim mi?". "Evet" deyin madem.
5. Sağlayıcı, oluşturduğu jetonu sizin tarayıcınıza gönderiyor. Bu jetonla Evcil.NET'e git, sana kapılar açılır diyor.
6. Sizin tarayıcı www.evcil.net'e jetonuyla dönüyor ve kapalı kapılar ardındaki yerlere sizi ulaştırıyor.

Aslında şu an bizim OpenId ile yaptırdığımız bir iş yok ama ileride neden olmasın?

Gerçekleştirim

OpenId spesifikasyonu gerçekten karışık. Okuyup kendi kendinize uygulamanıza adapte etmeniz fazlaca vakit alabilir. Bunun yerine, her türlü geliştirme platformuna yönelik yazılmış hazır kütüphaneleri denemeniz daha akıllıca. .NET için de birçok kütüphane ortaya çıkmış.

http://code.google.com/p/dotnetopenid/ adresinde konuşlanmış gayet basit bir adla yayımlanan "dotnetopenid", OpenId 2.0'ı da destekleyen lokum gibi bir kütüphane. İçerisinde ASP.NET ile kullanım örnekleri mevcut. ASP.NET MVC üzerinde bile örneklemiş adamlar.

http://extremeswank.com/aspnet_openid.html adresinde de bir başka gerçekleştirim gözüküyor. Yalnız bu bir öncekinden eksik olarak "sağlayıcı" olmayı desteklemiyor. Sadece "tüketici" takılıyor.

Diğer platformlara ait kütüphaneleri ihtiva eden tam liste, burada.

Güvenilir OpenId Sağlayıcıları

Hemen şimdi gidin ve bir OpenId sahibi olun. Günün birinde mutlaka lâzım olacak. Akbil'ler bile OpenId destekleyebilir, olmaz demeyin. Şu listeden birine gidip, sağlam bir OpenId alabilirsiniz. Aldığınız yerin itibarlı bir yer olduğundan ve bir gün TMSF'ye devrolmayacağından emin olun.

• http://www.myopenid.com/
• http://openid.yahoo.com/
• http://www.claimid.com
• http://pip.verisignlabs.com

İlerisi

Umut vadeden bir gelişme: Microsoft, yeni isimlendirdiği sayısal kimlik sistemi CardSpace'te OpenId desteği sunacağını açıkladı. IBM, Sun, Google ve Yahoo da OpenId'ye sonsuz hürmetleriyle anılıyorlar.

Yalnız yine de kurumsal tarafta biraz çekince var. Çünkü OpenId'nin güvenlik zayıflıkları gülün dikeni misâli göze batıyor. Kötü niyetli oluşumların hem RP tarafını hem de sağlayıcı tarafını gerçekleyip zavallı kullanıcıların şifrelerini ele geçirmesi pek mümkün. Microsoft, bu probleme çözümün CardSpace ile sağlanacağını söylüyor.

Biz ne yapalım? Son-kullanıcı olarak, dikkatli ve şuurlu bir biçimde kullanabildiğimiz kadar OpenId kullanalım. Yazılım geliştirici olarak, yaptığımız işlerde OpenId'yi nasıl kullanabiliriz, ölçelim, tartalım. Teknoloji takipçisi olarak ise OpenId nereye koşuyor, nereden su içiyor, sağdan soldan takip edelim. Ve vatandaşlık numaramız da OpenId olsun diye bakanlığa baskı yapalım.

Güvenli ve güneşli günler sizlerle olsun.
OpenId ile.

Geçtiğimiz bir gün, Microsoft TFS'in Kuzey Carolina ekibinin ufak çaplı bir video konferansına katıldık. En sağdaki Hakan Eskici.

Hakan Bey'i tanırsınız belki, 2enetworkx zamanlarından. Pek güzel ASP uygulamalarıyla dünyada adından söz ettiren bir Türk'tü. Arkadaşıyla kurduğu ufak yazılım şirketi (bir İzmir Şirketi) DevBiz de bulduğu niş sahada yine dünyanın dikkatini üzerine çekmiş ve en nihayetinde Microsoft tarafından iç edilmişti.

Ekip, Microsoft'un yeni nesil proje yönetim ürünü Team Foundation Server'a web üzerinden erişim için bir ASP.NET uygulaması geliştirerek meşhur oldu. Şimdi bu uygulama Microsoft bünyesine katılıp Team System Web Access adıyla kullanıma sunuluyor.

Video konferans, daha çok bu ürünle ilgili tanıtıma adanmıştı. Israrla gelmesini istediğimiz soru-cevap kısmında ise, cevapların Web Access ile sınırlı olduğunu görmek TFS ile ilgili beklentileri ve talepleri olan geliştiriciler için biraz can sıkıcı oldu.

Web Access ile ilgili bizim söyleyeceklerimiz şunlar:

TFS'in kaynak kod kontrolü dışındaki mekanizmalarını (özellikle Work Item denen şeyler) kullanıyorsanız Web Access, bunlara web'den eriştiriyor ve hayatı biraz daha kolaylaştırıyor. (Bu zaten web'in erişim kolaylığından kaynaklanıyor, mucizevi bir haber değil.)

Yalnız, gülümseyerek kayda giren bir nokta var ki o da ekibin Web Access'i anlatırken, sanki son kullanıcıya internet'i anlatıyor gibi bir edaya bürünmesiydi. Diyelim ki ofisteki bilgisayarınızda değilsiniz. Laptop'unuzla bilmem ne...

Evden, ofisten, tatilden de kullanabileceğimiz bir şeymiş bu Web Access. Bu güzel ürün için tebrik ederiz.

Yazılım testi için ayrı test ekipleri olmayan firmalarda genel bir saplantı vardır. Bir gün, gerçekten bu iş için oluşturulmuş bir ekip ile yazılım testlerini gerçeklerlerse, yazılımlarının daha kaliteli olacağını düşünürler. Hali hazırda yazılım testi ekibine sahip firmalar, bu saptamanın doğru olduğunu görürler, fakat küçük bir detayı da eklemeden duramazlar.

Yazılım testi konusunda çalışan o işe has bir ekibinizin olması, her zaman geliştirdiğiniz uygulamaların daha kaliteli olacağı anlamına gelmez. Çünkü yazılım kalitesini test mühendisleri değil, tüm ekip beraber sağlar.

Test mühendisleri bir ürünü test eder ve hataları raporlar. Raporlanan hataların bir kısmı gerçekten ürün üzerinde düzeltilir ama bir kısmı düzeltilmez yada düzeltilemez. Yazılım kalitesini sadece geliştirici arkadaşlara hata raporlayarak, maalesef elde edemeyiz. Yazılımın kalitesinden şunu anlarız;

1. En baş şart olan müşteriş istekleri
2. O yazılımı geliştirme işine bir şekilde katılmış herkesin sorumlu olması

Test mühendisleri, ürün ile ilgili sürekli, anlaşılır ve kantitatif bilgiler üreten bir ekiptir. Bu sayede yazılımcılar geliştirdikleri ürüne ait hataları minimum hata ile öğrenirler ve düzeltirler. Yönetim tarafına gelince, sürekli olarak ürünün ne kadar hazır olduğu ile ilgili bilgiler edinirler.

Test ekibinin yaptığı hataların ürün kalitesine doğrudan yansıyacağı yadsınamaz bir gerçektir. Atlanan bir test case ya da unutulan bir konfigürasyon, sakıncalı anormallikler barındıran bir ürünün müşterilere gitmesine sebep olabilir.

Test Mühendisleri Her Zaman Hatasız Değildir

Fakat bu durum, yazılımcıların kodlarında hatalar olması, yapılan tasarımın eksik olması ya da ürün dokümantasyonundaki genel hatalar kadar normal bir durumdur. Tabi ki bizler test mühendisi olarak durumun bu tarafının farkında olsak da denetimde son kademe olduğumuzdan dolayı, takım içerisindeki herkesten daha sistematik çalışmak zorundalığını hissetmekteyiz.

Test mühendisleri, bir ürün geliştirilirken sistematik gözlem ve deneylerle, ürün ile ilgili şeffaf, objektif ve doğru amaca hizmet eden bilgileri üretir ve tüm ekip ile paylaşırlar. Bu oldukça zorlu bir iştir ve birden fazla disiplinde yaklaşıma ve deneyime sahip olunmasını gerektirir.

Bu bilgi ve deneyimleri sağlayan kişiler, üretilen ürünün kalitesinden sorumlu tutulamaz. Fakat ekibin ürettiği bilgiler olmadan da, geliştirilen yazılımın kalitesinin pek de yüksek seviyelerde olmayacağı unutulmamalıdır.

Değerli okuyucu,

Yazılımcıların içerik üretimindeki tembelliği dillere destandır mâlum. Bir sürü akıllı sistemler yazıp da kendi kendine içerik oluşturan sistemler yazamamışızdır. Müşteriler için içerik yönetim sistemleri hazırlarız da kendimize geldiğimizde bir hazır blog servisini bile canlı tutamamışızdır.

Nedendir bu atalet?

Bizim dünyaya haykıracağımız şeyler yok mudur?

Dünya, bizsiz de dönüyor elbette. Ama o dönen dünyanın içinde biz de olduğumuz sürece üstünde yaşananlardan payımızı alacağız. Ağzımızın payı da olabilir bu.

Neden denemeyelim bu serüvende bir paydaş olmayı?

Şu güzelim ana dilimizde, yazılım üzerine okuyucuyu germeden, mide spazmına yol açmadan bir iki kelâmın sarfedildiği kaç yer gördünüz efendim, samimi olun.

Yok.

Bu eksiği tespit ettik önce. Sonrası işe koyulmak.

Evcil.NET olarak ne yapacağımıza karar verdik. Daha önce alanında ilk defa Türkçe makaleler yazıp tarihe geçtik ama o tarih çok eski bir tarihti. Şimdi söylediklerimizin neredeyse hükmü kalmadı. Hâni bir şâirin ve Devletşah'ın dediği gibi: Artık yeni şeyler söylemek lâzım.

Unutun kanser olmuş projeleri. Gergin müşterileri. Eve dönüş yolunu.

Burada, bir sıcak kahvenin yanına, webden, koddan, debug'tan, etrafta olanlardan ve hepsinin ortasında - ekranın karşısında nefes alan bir varlık olan yazılımcıdan bahsedeceğiz. Ne yapacağımız budur.

Siz de ne yapacağınıza karar verin. Hemen RSS adresimizi gümletin. Yorumlarınızla söze katılın. Canınız çekerse ve zor gelmezse, siz de yazmayı deneyin.

Artık Türkiye'de yazılımcı olmak daha zevkli olacak!

Quality Assurance (QA) aktiviteleri üç önemli bileşenden oluşur.

• Yeterli kalifikasyona ulaşmış insan kaynağı
• Doğru Metodoloji
• Uygun Test Araçları

Test teknik yoğun bir aktivitedir. Gerek test aktivitelerinin planlanması gerekse de uygulanması için farklı bir bakış açısına sahip insan kaynakları gerekmektedir. Bunları göz önüne alarak test otomasyonu satan firmaları ile ilgili kısa bir analiz yapabilir ayrıca test araçlarının bir can simidi olup olmadıklarına karar verebiliriz.

Günümüzde test otomasyonu araçları satan firmalar, araçlarını neredeyse kendi kendine test eden robotlar olarak ifade ediyor. Bazı "test mühendisliği eğitimcileri" gereksinimlerin bire bir test edilerek ürünün kalitesi ile ilgili tam bir resmin çizilebileceğini işaret etmektedir. Kimi firmalar, hedefleri olmayan ve içi boş yük testleri yaparak, yazılım geliştiren firmaları göz göre göre kandırmaktan bir an olsun bile çekinmemektirler.

Gerçek hayatta, otomasyon çatısını kurmak ve sürekli değişen bir uygulamayı sürdürmek zorunda olmak, hazır olmayan firmalara çok ama çok pahalıya mal olmaktadır. Bu firmaların büyük çoğunluğu şimdi, per-seat lisansına onbinlerce dolar ödedikleri ürünler ile otomatik bir kaosa sahiplerdir.

Çoğu test mühendisi, tam olmayan gereksinimler ile geliştirilen ürünlerde, kimi testleri gerçeklemeyi reddediyor ya da daha kötüsü, kullanıcı beklentilerini es geçiyorlar.

Birçok ürünün, onbinlerce dolar ödenerek yaptırılan yük testleri ardından, performans tabanlı sorunlar sebebiyle, yarı yolda kaldığını görüyoruz ki bu büyük bir sorundur.

Ekipler belki iyi niyetle bu pratikleri alıp uygulama kararı veriyorlar fakat kısa sürede başladıkları noktadan daha da geri bir yerde buluveriyorlar kendilerini.

Bu sebeple, yapısal olarak test yapmak isteyen her ekibin gümüş kurşunları bir kenara bırakarak, yazılım geliştirme biçimleri ve kalite ihtiyaçlarına odaklanmaları gerekmekte.

Bir firma ya da ekip için en iyi yazılım testi, ihtiyaca uygun olarak planlanmış yazılım testidir. Metodolojiniz yoksa şablonlar arasında kaybolup gitmek kaçınılmaz olacaktır.

Sizin ihtiyaçlarınız, o alıntıların ve grafiklerin çok ötesinde ve size en uygun biçimiyle gerçeklenen test aktiviteleri olacaktır.

Bugünkü makalemiz, GAC üzerine. Nâm-ı diğer "Global Assembly Cache". Âşina olmayanlar için ufak bir girizgâhımız (iştah açıcı) olacak.

GAC Nedir?

.NET'in çıkış noktasını hatırlayınız. Windows'un birincil bileşen yapısına deva olarak ilan edildiği günleri hatırlayınız. O günlerde artık uygulamaların Registry'ye ihtiyaç duymadığı, XCOPY ile kopyalanarak eşeysiz üreyebildiği ve ürediği her yerde de kendi başına çalışabildiği söylenmişti. .NET hayatımıza, kendi bilgisini (metadata) üzerinde taşıyan "assembly"leri kazandırmıştı. Bir assembly, kendini tarif etmek için başka bir varlığa ihtiyaç duymuyordu. Versiyonu, kültürü, benzersiz anahtarı üzerindeydi. Assembly'ler bu özelliklerinden dolayı, birbirine karışmadan çalışabiliyordu. Herkesin kullanacağı ortak assembly'leri birbirine karışmadan atacağımız yer ise tam orasıydı işte: GAC.

"Uzaktaki GAC'ı Kurcalamak" devam ediyor »

C# 3.0 ile .NET dünyasına giriş yapan bu terim aslında epeyce akademik derinlikli bir geçmişe sahip. Meselenin odağımız dışında kalan bu tarafına merak duyanları Wikipedia maddesine şutlayarak devam ediyoruz.

Lambda'yı pat diye anlatmak yerine adım adım gidelim diyoruz, kabul ederseniz. Sıramız şöyle:

• Delegate yapısı
• Anonim Metodlar
• Lambda deyimleri

Delegate Yapısı (C# 1.0)

Delegate (delege) yapısı, tipli fonksiyon işaretçisi olarak tanımlanıyor. Ama bu tanım gayet soğuk durduğu için biz başka bir tanım verelim. Nasıl ki sayılar için int, long; karakterler için char, string vs. gibi veri tipleri tanımlanmışsa .NET dillerindeki "metod" yapılarının da tipi tanımlanmış. Bir metod, parametre listesine ve dönüş değerine göre bir "tip" yani bir delegate ifade eder.

"Lambda Deyimleri (Lambda Expressions)" devam ediyor »

Ülkemizde henüz rağbet görmese de hizmet temelli mimari yani SOA, önümüzdeki 5 senenin popüler temayülü olma yolunda. Tamam bu cümle güzel, akıcı, yasal. Ama SOA veya "hizmet"in ne olduğuna yabancı bir kişi için ne ifade eder?

İşbu söyleşide, soğuk yazılım geliştirme makalelerinde gördüğünüz SOA tasvirinden uzak şeyler bulacaksınız. En azından fakir öyle umud ediyor. Tevfik Allah'tan.

Derdimiz Nedir?

Efendim derdin tarifi biraz geniş.

Artık bilgisayar gani. Elinizdeki cep telefonu bile bilgisayar özellikleri taşıyor. Ve malesef "iletişim çağındayız." Kopuk bir çağ bu. (Bir sonraki çağı bekliyorum ben heyecanla.) Bu kadar nimet, yeni ihtiyaçlar doğuruyor ademoğlu için.

Bu iletişim imkanı bu kadar yaygınlaşmamışken, programcılar bileşen temelli mimariyle tekrar kullanılabilir kod parçaları meselesini çözmüşlerdi. Bir kere yazıp, elli yerde kullanabileceğiniz küçük birimler oluşturuyordunuz. (MS Örneği: COM)

İletişim çağı, bileşen temelli mimariyi de bozdu. Mühendisler, ya madem bileşenlerimiz var elimizde, bunları neden uzak makinelerde çalıştırmıyoruz, diye sorunca... Dağıtık bileşen mimarileri doğdu. Yine bir kere yazdınız ama bu sefer elli yere değil, tek yere koydunuz. Yine elli uygulama, sizin bileşeninizi kullandı. "Application Server" denen şeyler icat oldu. (MS Örneği: DCOM, COM+)

"SOA Nedir Hoca?" devam ediyor »

"Debug etme" keyfini duydunuz mu hiç?

Bir yan bilgi:

Yazılımcılar, kullandıkları araçlar tamamen teknik terimler içerdiğinden, Türkçe eylemler ile birbirine girmiş lafları çok kullanırlar ve hatta kullanmayı da severler.

"Brawzır'ını aç" veya "prapırti kullan" gibi laflar çok döner dolaşır. "Dibag etmek" de öyle bir kavramdır.

Bir yazılımcının "dibag'ta kodu var"ken aklı başka bir şey almaz.

Keyifli iştir "debug". Yazılan kodun sicim gibi akmasıdır, perde önünde. "Code Review" denen toplu ayinlerde müridler hep beraber "debug" eylerler ki tadına doyulmazdır.

"Seyreyle Gönül .NET Framework Kodunu" devam ediyor »