Evcil.NET

Türkçe Hâl Ekleri'ni Programatik Olarak Eklemek

Muhammed Tahiroğlu — Mon, 08 Sep 2008 11:12:00 GMT

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

Etiket: C#, Open Source, Türkçe, Türkçeleştirme

Arşivden

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

Muhammed Tahiroğlu — Wed, 21 May 2008 21:23:00 GMT

"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.

Servisinizi denetlemek için WCF Auditing özelliğini kullanın:

WCF servisinizin denetim özelliğini, güvenlikle ilgili başarı ve başarısızlık durumlarını log'lamak üzere yapılandırın. Log'lar tahmin edebileceğiniz gibi Event Log'a yazılacak. Bu log'lar size güvenlik ile ilgili istenmedik durumları yakalamanızı sağlar. Bakım için de veri oluşturur. Kod örneğini şuradan alabilirsiniz.

Denetimsel bir hataya hoşgörünüz yok ise SuppressAuditFailure özelliğini kapatın:

Bu özellik açık olursa ortaya çıkan herhangi bir denetimsel hata servisin çalışmasını durdurmaz. Özelliğin açık olması "denial of service" (DoS) ataklarını da göz önünde bulundurmanızı gerektirir.

Mesaj log'lamalayı kullanın:

WCF mesajlar üzerinden çalışıyor mâlum. Gidip gelen mesajları takip etmek için mesaj log'lamayı açın. Config'ten kolayca yapabiliyorsunuz. Ama dikkatli olun. Nedeni son maddede açıklanacak.

Log dosyalarını meraklılardan sakının:

Denetleme ve log dosyalarını Windows'un "Access Control List" ile koruyun ve bunlara erişimi kısıtlayın. Dosya dışında başka bir yere yazıyorsanız oranın erişim denetimini gözden geçirin. Mesela yazma müsadesini kendi uygulamanızın hesaplarına, tüm hakları yöneticilere ve okuma hakkınını da operatörlere vererek temiz bir iş yapın.

Bu tedbir, saldırganların izlerini kaybettirmelerini zorlaştırır.

Hassas bilgileri log'lamayın:

Hassas ve mühim kullanıcı ve uygulama bilgilerini log'lamayın. Çünkü bu bilgilerin gerçekte durduğu yerden daha farklı erişim yetkileri var log dosyalarında. Kredi kartlarının bulunduğu tabloya erişemeyen birisi bu log dosyalarına da erişememelidir. Yukarıdaki nasihatlere uyup her giden gelen mesajı içeriğine bakmadan gövdesiyle log'larsanız bu maddeyle katı bir çelişkiye düşebilirsiniz.

Log'lamaktan sakınmanız lâzım gelen bilgiler: kişileri kimliklendiren vergi no, kimlik no, kredi kartı no vs. bilgileri; uygulamaya dair tercihler, giriş bilgileri gibi kişisel hassasiyeti olan veriler ve veritabanı bağlantı cümlesi, servise ait hesap adı gibi uygulama bilgileri.

...

Patterns&Practices yukarıdaki maddede "tüm mesajları loglayın" nasihatiyle biraz çelişmiş. Zaten ilgili maddenin yorumlarında da bir şahıs bu çelişkiye kayıtsız kalamamış. Yetkili kişi de bu çelişkiyi özel log'lama yazarak çözün diyor. Buradan şu mesajı almamız gerekiyor: söyleyen her kim olursa olsun duyduğunuz, okuduğunuz sözleri etraflıca düşünmeden uygulamaya koymayın. Biri size "mesajları log'layın, süper olur, olan biteni görürsünüz" dediğinda cazip bir tavsiye hediye ediyormuş gibi görünebilir. Oysa işinizin ciddiyetine göre değişebilecek düzeyde bir güvenlik zaafiyetine kapı araladığınızı da söylemelidir aynı kişi. Söylemiyorsa ya eksik bilgilidir ya da kötü niyetlidir.

Kolay gelsin.

Sonraki bahis: Kullanıcı doğrulama

Etiket: Güvenlik, Security, SOA, WCF

Arşivden

WCF Güvenlik Kılavuzu - 1 (Tasarım Hususları)

Muhammed Tahiroğlu — Sat, 17 May 2008 21:23:34 GMT

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.

Tasarım Hususları

Servis'i sarmalayıcı (wrapper) olarak tasarlayın:

"Wrapper" Türkçeye çevirince manasını kaybeden birçok yabancı kelimeden birisi. Bu madde ile anlatılmak istenen, servisinizin işi yapan değil, işi yaptıran bir konumda olması. Bu servis kodları içerisinde mantık gömmeyin, o mantığı farklı bileşenlere dağıtın; bakımınız kolaylaşsın, modülerliğiniz artsın demek istiyorlar.

ASMX'ten geliyorsanız var olan istemcileri desteklemek için basicHttpBinding kullanın:

Klasik web servisleri (.asmx) sunuyor idiyseniz, WCF'ye geçiş yapıp aynı servisleri basicHttpBinding binding'i ile sunabilirsiniz. Bu binding seçeneğinin özelliği güvenlik için hususi müdahaleler gerektirmesi. Varsayılan olarak açılmış bir güvenliği yok. Östelik WS* özelliklerini de desteklemiyor.

DCOM'dan geliyorsanız netTcpBinding kullanın:

.NET'ten .NET'e konuşan sistemler üzerindeyseniz ve daha önceden de COM+ yollarından geçtiyseniz tercihiniz varsayılan olarak güvenlik ve güvenilirlik özelliklerini destekleyen netTcpBinding binding'i olmalıdır. DCOM'dan geçiş yapıyorsanız işleyişin çok da benzer olmadığını göreceksiniz. Alışın, SOA farklı.

İstemcileriniz intranet içinde ise "transport security"yi tercih edin:

Servisinizin müşterilerinin bir intranet ortamında olduğundan eminseniz, netTcpBinding'i kullanıp "transport security"yi açmak hem performanslı hem de gayet güvenli bir yöntem olacaktır. Ayarınıza göre iletimdeki güvenliği Windows ağının güvenli iletişim mekanizmasına veya sertifikasyona emanet ediyorsunuz demektir bu.

Kullanıcı doğrulama seçeneklerinizi bilin:

Hangi binding için nasıl doğrulama seçenekleriniz olabileceğini bilmelisiniz. Ona göre binding'lerinizi de çeşitlersiniz. Meselâ "transport security"yi netTcpBinding ile kullanıyorsanız kullanıcı doğrulama için sadece Windows veya "sertifika" seçenekleriniz var. Yok ben kendi kullanıcı adım ile doğrulama yapıyorum diyorsanız buna uygun binding ve security tercihleri yapmalısınız. Seçenek listeniz şurada.

Binding (bağlama) seçeneklerinizi bilin:

Şimdiye kadar da söyledik, binding tercihiniz güvenlik ve güvenilirlik mevzularını etkileyecektir. İhtiyacınıza uyuşan bir binding (bağlama) mutlaka vardır. Şu listeyi inceleyebilirsiniz.

Microsoft dışı sistemlerle beraber çalışacaksanız basicHttpBinding veya wsHttpBinding kullanın:

Eğer Microsoft haricindeki sistemlerle konuşacaksanız tabî olarak HTTP ve HTTPS protokolünü kullanmanız gerekecektir. Bu protokolü de bahsettiğimiz binding'ler destekliyor.

Microsoft dışı istemcileriniz "WS* stack"ten anlıyorsa wsHttpBinding kullanın:

Microsoft dışı sistemleriniz WS* stack'i destekliyorsa, "text encoding" (metin kodlamayı) ve HTTP prokolünü destekleyen wsHttpBinding tek seçeneğiniz.

...

Sonraki Bahis: Denetim ve Log'lama

Etiket: Design, Güvenlik, Kılavuz, Security, SOA, Tercüme, WCF, WCF Güvenliği

Arşivden

Kirletmek Güzel midir?

Muhammed Tahiroğlu — Sat, 17 May 2008 12:04:14 GMT

"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.

Nedir Hafif HTML?

Hafif HTML, web'ciler tarafından ortaya çıkarılmış alternatif işaretli biçimleme dilleri. HTML'e göre daha ufak çaplı ve basit oluyorlar:

Sözde böyleler. Kimisi HTML'nin tüm özelliklerini alıp üzerine yeni şeyler katıyor ve iyice karmaşıklaşıyor:

WikiText'i görüyorsunuz. Her gün en azından bir mevzu için başvurduğumuz bu mucizenin yazı dili böyle tuhaf ve zevksiz bir şey.

Hafif HTML dilleri hem güvenlik hem standardizasyon ve hem de kullanıcının öğrenmesini/işini basitleştirmek amaçlarıyla ortaya çıkmış. Benim hatırladığım en eskisi BBCode. Forumlara mesaj girişinde standart hâle gelmişti BBCode. Bunun yanında Textile, Markdown gibi diller de rağbet görmekte.

Ancak gün geldi ve insanoğlu bu hafif-meşrep dillerin varlığını sorgulamaya başladı. Etrafta birbirine benzemeyen veya az çok benzeyen onlarca HTML alternatifi var ve bunlar HTML'den daha az bilgi gerektirmiyorlar. Bir metni kalın göstermek için - arasına almayı öğrenmekle ''' - ''' arasına almayı öğrenmek çok mu alakasızdır?

Neticede konu, kullanıcıların metinsel girişlerinde, alternatif diller yerine web'in başından beri yanımızda olan (X)HTML'yi tercih etmenin daha makul olacağı noktasına geliyor.

Karşı görüş, HTML'nin son kullanıcı için öğrenilmesi zor bir dil olduğunu ve kolay okunamadığını öne sürüyor.

Ne Olacak Şimdi?

Anlaşılır bir noktaya varmalıyız. "Hafif HTML" kirliliğinden kurtulmalıyız. Her bir mesaj alanı, farklı biçimleme dili kullanırsa bizim hâlimiz (yani şu her şeyin sonunda duran son kullanıcının hâli) nic'olur?

Kanaatimiz o dur ki mümkün olduğunca "Sınırlı HTML" kullanmak - müsade verilen etiketleri belirlemek ve onların dışındakileri gözardı edip metni bilindik HTML'ye derlemek en ideal yol. (Bu kanaatten öncelikle Evcil.NET'in de nasibini alması gerektiğini adımız gibi biliyoruz.)

PilliNetwork bu işi emsal teşkil edecek şekilde güzel yapıyor:

Sadece maddeli ve numaralı listelerde HTML dışı alana kaymışlar. Ama yine de gidilebilecek yolu bize gösteriyor.

...

Birileri "Web'de HTML kullanılır" gibi gereksiz kampanyalara başlamadan evvel özümüze dönmek ve HTML alternatiflerinden oluşan bu kirliliği en azından evimizin önünü süpürerek azaltmak bir siber-vatandaşlık görevidir diye düşünüyoruz.

HTML ile.

Etiket: BBCode, HTML, Textile, Web, Wikipedia, WikiText, XHTML

Arşivden

Bir Delphi Varmış

Muhammed Tahiroğlu — Sun, 11 May 2008 20:51:18 GMT

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.

Etiket: Borland, Coder, Delphi, IDE, VS.NET

Arşivden

Kodcu İçin Hiçbir Tercih Sıradan Değildir

Muhammed Tahiroğlu — Sun, 11 May 2008 09:28:25 GMT

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.

Etiket: C#, Dictionary, Kodcu, List, Performans

Arşivden

OpenId Vatandaşlığı

Muhammed Tahiroğlu — Mon, 05 May 2008 21:30:52 GMT

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.

www.evcil.net'in "login" sayfasındasınız. Form'a OpenId URL'inizi yazıyorsunuz.
www.evcil.net, bu URL'in hangi sağlayıcıda doğrulanacağını belirleyip tarayıcınıza "şuraya git" diyor.
Tarayıcınız oraya gidiyor. Orada bir login formu daha varmış. Bildiğiniz bir yer burası.
Ş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.
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.
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.

İ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.

Etiket: CardSpace, Güvenlik, OpenId, Web

Arşivden

Team System Web Access Buluşması

Muhammed Tahiroğlu — Sat, 03 May 2008 11:47:20 GMT

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.

Etiket: Source Control, TFS, VS 2008

Arşivden

Yazılım Test Mühendisi Hata Yapar mı?

Burak Coşkun — Wed, 30 Apr 2008 07:10:24 GMT

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;

En baş şart olan müşteriş istekleri
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.

Etiket: Test

Arşivden

Test Araçları - 1

Ne Yapacağımızı Bulduk

Muhammed Tahiroğlu — Tue, 29 Apr 2008 20:51:43 GMT

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!

Etiket: Haber, Web