evcil.net noktanın egemenliği

1808 / 090

Programlama Dünyası Nereye Koşuyor?

Bu soruyu, Microsoft olsa şöyle cevaplardı:

"Siz nereye isterseniz oraya!"

Şahsım adına konuşursam; yıllardır Microsoft'un bu soruya verdiği cevapları dinleyerek durduk. Hatta bir seferinde Max Planck ne ise Microsoft da odur diyerek iyice saçmaladık.

Saatler geçti, aylar geçti, seneler geçti. Şimdi 2009'dayız. Bir söze göre bir adet Facebook, 120 adet ToyotoSA ediyor. Sun MySQL'i, Oracle Sun'ı yutuyor. Adobe, web'in eskilerinden Macromedia'yı hamlıyor. Amazon bir web servisidir tutturmuş gidiyor. OpenID daha koşamadan Facebook Connect'ler çıkıyor. Google Apps diyor, Microsoft Azure. Micorsoft tosun gibi Exchange'e güvenirken, Google "gelin Exchange'iniz ben olayım" diye çapkınlığa çıkıyor. Ve Microsoft hâlâ Office'ini buluta geçirecek, gelecek sene diyor.

Oluyor da oluyor. Her gün bu bulut kümesinde yeni bir vaka cereyan ediyor.

Peki programcı, hani şu kod işçisi, parmak ucu terinin sahibi, emek yorgunu insan bu filler savaşında ne yapıyor?

Şimdi bu soruyu en çok Microsoft dünyasındakiler soruyordur eminim. Şu ALT.NET hikâyeleri de bu soruyu sormuş olanların birliği değil mi?

Artık bu insanlar, dev tekel stratejilerinin arasında pusulayı kaybettiklerini düşündüler.

Şu olaylara bir bakın mesela.

Web'i seven, her şeyine hâkim insanları ASP.NET'in radikal değişimiyle kabuğuna çeken ve web'den soğutan kimdir?

Bir dünya insan web'den soğurken kimsenin adamdan saymadığı PHP ile dünyanın en pahalı sitelerini, web framework'lerini oluşturan... web'e takla attıran kimlerdir?

Ya peki şu anda IIS 7'ye PHP'yi süper hızlı çalıştıralım diye özel moduller ekleyen kimlerdir?

Dağıtık yapıları 2002'de COM+'a, 2005'te Remoting'e ve nihayet 2008'de ise SOA'ya dayayan kimdir? Her 3 sene bir, insanları kodları değiştirmeye ikna eden kimlerdir?

Sizce programcı bu kadar gevezelikten bıkmamış mıdır? Onun da bir midesi yok mudur?

Vardır efendim, vardır.

Konuşacak, yazacak, tenkit edecek, takdir edecek... çok şeyleri vardır onların.

Biz şimdilik iki arkadaş olarak bir araya geldik ve Bulutlararası'nda programcı hasbihâli etmeye karar verdik.

Midesi olan programcılar olarak artık bulut, küme, Ruby, Mono, Google, SOA... ne bulursak lafını edeceğiz. Dev strateji sahiplerini ufak ufak rahatsız edeceğiz. "Programcılar elinizde oyuncak mı?" mealinde sözler hazırlayacağız.

Bulutlararası nedir, nereden çıktı derseniz buyrun.

Peki Evcil.NET'e ne olacak derseniz. İşte orada, bu işi yeniden düşünmenin gerekliliğini vurgulamamız lazım. Siz de elinizi vicdanınıza koyun. Şu saatte kim artık uzun uzadıya programlama makalesi okuyup bir şey öğreniyor? Tüm Hindistan ahalisi zaten yazıyor bunları. Hem de basit ve alelade bir İngilizce'yle. Türkiye'de de yazanlar oluyor, hem de bol bol.

Bizce teknik makale yazmanın vakti ve modası geçmiştir. Artık insanlar cik cik'leyerek (twitter cıvıltı demek) iletişim kuruyor bu internet masalında. Siz kimden oturup makalenizi okuyup hayır duası etmesini bekliyorsunuz. Makale yazan sadece kendini tatmin ediyordur ya da bizim bir zamanlar yaptığımız gibi o konuyu öğrenmek için yazıyordur. Akademisyenler de böyle yapar ya hani; öğrenmek için tez yazmış olurlar.

Velhâsıl, burada fasülyenin faziletlerine dair bir ürün beklemeyeceğinize söz veriniz. Didaktik cümleler kınına çekilmiştir.

Şimdi İstanbul için bulut vaktidir.

809 / 080

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

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

1705 / 080

Kirletmek Güzel midir?

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

başlık kirliliği

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

textile

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

wiki

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:

pilli

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.

1105 / 080

Bir Delphi Varmış

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.

delphi2

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.

delphiscreen

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

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

embarcadero

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.

1105 / 080

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

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.

505 / 080

OpenId Vatandaşlığı

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.

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

2904 / 080

Ne Yapacağımızı Bulduk

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!

1104 / 080

Uzaktaki GAC’ı Kurcalamak

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.

GAC, ortak assembly'leri bulunduran özel bir klasör yapısı. %SYSTEMROOT\%assembly deyincesi çıkan dümdüz liste biraz kandırıyor bizi. Arka planda daha karmaşık bir dizinleme yapısı var ve atılan her assembly'yi ayrıntılı olarak depoluyor.

GAC Nasıl Yönetilir?

GAC,

  • .NET 1.1 ve .NET 2.0 için ayrı ayrı sunulan yapılandırma snap-in'leriyle:
    gac1
  • Gacutil.exe isimli ufak bir konsol programcığıyla:
    gac2
  • Windows Explorer'da assembly klasörü üzerine giydirilmiş "shell extension" aracılığıyla:
    gac3

yönetilebilir.

GAC'ı yönetmekten kasdımız, içine yeni assembly'ler atıp, mevcutları silebilmek vs.dir.

Bu alternatiflerden ilk ikisi Microsoft SDK'larıyla bilgisayarımıza yüklendiği için üretim ortamı bir makinede yokluğu hissedilecek şeylerdir. O durumda başvuracağımız çözüm sonuncu maddeki Windows Explorer olacaktır.

Hepsinden önemlisi bu saydığımız maddelerin hepsi yerel makinedeki GAC'ın yönetimini sağlıyor. Bir makinenin GAC'ını kurcalayacaksak ve illaki bu aletleri kullanacaksak mecburen makineye giriş yapıp üzerindeki bu araçları çalıştırmamız gerekiyor.

İşte mesele de bu. Neden uzaktaki makinenin GAC'ına müdahale edemiyoruz?

"Deployment" Öyküleri

Genelde uzaktaki bir sistem üzerine assembly'lerimizin dağıtımını yapıyorsak ve bu sistemin de GAC'ını kullanmak istiyorsak az önce "mesele" dediğimiz noktaya gelmişiz demektir. Elimizdeki assembly'leri şu uzaktaki makinenin GAC'ına nasıl atacağızdır? Hep gidip RDP ile masaüstüne bağlanıp el ile gacutil mi çalıştıracağızdır? Ya da sürükle bırak ile C:WindowsAssembly'ye dosya mı atacağızdır?

Microsoft buna bir şey yapması lazım değil midir?

Eğer meseleyle ilgili bir "arama motoru" tecrübesi yaşarsanız, size MSI yapmayı tavsiye olunur. İşiniz gücünüz yok, her çıkacağınız assembly için kütür kütür MSI yapacaksınız dostlar. Bu çözüm sizi tatmin ediyorsa yazının devamını boşverin.

Ya Remote Gacutil?

Yok böyle bir şey. Olmalı ama yok.

Ancak biraz kafa yorunca, uzaktaki makinede komut çalıştırma konseptinden gacutil'i tetikleyebileceğimizi buluruz. Bunun için piyasaya doğru bir salınım yaptığımızda en adam akıllı aracın harikalar diyarı SysInternals'ın PsExec'i olduğunu idrak ediyoruz.

Uzakları Yakın Eyleyen Program: PsExec

PsExec ile yeterli haklara sahip olduğunuz bir makine üzerinde komut işletebiliyorsunuz. Bu aleti kullanarak, karşı makinenin üzerinde gacutil'i tetikleyip assembly listesini düzenleyebiliriz ve güncelleyebiliriz demektir. Tam olarak bir Remote Gacutil yazmayı başaramasak da ona yaklaşabiliyoruz. Ne mutlu!

gac4

Gerisi kodlamayı seven programcılara kalmış. Yazsınlar kendi GAC-deployer araçlarını ve oturdukları yerden keyifle "deployment" yapsınlar. Microsoft, eminim zaman içerisinde MSI'dan daha makul çözümler de sunacaktır. O sunana kadar bizim yan yolumuz (workaround) da bu olsun.

Hadi bakalım. GAC ile.

2001 / 080

SOA Nedir Hoca?

Ü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+)

Sandınız ki dert bitti, herkes mutlu oldu. Hayır efendim. Biter mi? Bu sefer de platform çeşitliliği, evrensellik kaygısını ortaya çıkardı. Yazdığımız bileşen aynı cins platformlarda çalışıyor ama farklı bir cinsle karşılaştığımızde elimiz ayağımıza dolaşıyordu. Şu dağıtık bileşen midir nedir o mimarinin tekrar ele alınması gerekliydi.

İşte dert buydu. Dert budur. SOA denen felsefe de bu derdin çözümünü adreslemektedir.

Peki nasıl?

SOA Teorisi

SOA'dan bahsederken felsefe dedik az önce. Maksatlıydı o. Zira, SOA denen şey, bir ürün veya teknoloji olmamakla birlikte bir firmanın tasarrufu altında da değil.

SOA diyor ki, yapacağımız işler sınırları sârih (açık), (explicit boundary) bir hizmet paketi içerisinde dursun. Bu paketler akıllı (autonomus) olsun. Mukavelelerle (contract) haberleşsin, işlesin.

soa

SOA sadece konsepti belirliyor, geri çekiliyor aslında.

Günümüzde SOA ile uyuşan bir çok uygulama görmekteyiz. Meselâ ülkemizde çılgın atan "Web 2.0" paradigması, o özündeki birlikteliği sağlamak için çevrim-içi hizmetlere dayanıyor. Nerede bir hizmet var ise orada SOA izi bulmak mümkündür.

Bildiğimiz Web Servisleri (XML Web Services) de SOA mimarisini uygulamanın ana yöntemlerinden birisi.

Çıkaracağımız ders şudur ki; SOA büyük büyük adamların kafa yorup ürettiği bir ilkeler topluluğu. Ne kadarını uygulayacağınız size kalmış. Hesap soran yok.

Teorisine daha detaylı inmek isteyenler için adres: http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf.

Kendi Kendine SOA

Eğer SOA'yı uyguladım diyorsanız ürününüzün aşağıdaki ilkeleri taşıyor olması lâzım:

  • Tekrar tekrar kullanılabilirlik.
  • Tanecikli yapı. (Hâni çikolata tanecikleri gibi. Ayrıştırılabilir.)
  • Modülerlik. (Tak-çalıştır.)
  • Bileşenli olma.
  • Birbiriyle çalışabilirlik. (Interoperability.)
  • Endüstriyel standartlara uygunluk.

Ayrıca sunduğunuz "hizmet"in:

  • Kapsüllenmiş. (Salça gibi bir kapsülü olmalı yani.)
  • Gevşek bağlı. (Bu çok önemli. X kişisi olmadan restorana gidememek kabul edilmiyor.)
  • Kendi kendini tarifi etmiş. Kendini soyutlamış, izale etmiş. (Gülüyorum ama içim kan ağlıyor ilkesi.)
  • Akıllı. (Kendi kararlarını kendi veren, aklı başında, özgür bir birey gibi.)
  • Kaliteli. (Ucuz etin yahnisi de servisi de ucuz olur.)
  • Keşfedilebilir, bulunabilir. (Sarı çizmeli Mehmet Ağa olmamalı yani.)

olması da gerekiyor.

Kolay SOA

Yukarıdaki ilkeleri uygulamaktan acizim diyorsanız hâzır SOA iskeletleri aramaya başlıyorsunuz. Microsoft da sesinizin yankısını dinleyenlerden. .NET 3.0'a koyduğu Windows Communication Foundation (WCF) iskeleti, yukarıdaki ilkelerle bir uygulama hizmeti oluşturmayı epey kolaylaştırıyor.

WCF, Web Servisleri'nin adını değişmişi diyebilirsiniz. Haksız da sayılmazsınız. Çünkü SOA'ya da aynı eleştiriler yöneltiliyor.

.NET perspektifinden bakıldığında, web servislerinin durduğu noktadan sıyrılmak gerekiyordu zaten. Hem Remoting, hem Web Servisleri, vs. WCF tüm dağıtık işleri birleştirip SOA ilkelerini dayatıyor bize. İyi de yapıyor hani. Artık uygulamanızın iş yapan kısımlarını bir "hizmet" olarak fikretmeye başlıyorsunuz. Ön yüz, yani kullanıcı son noktası, "hizmet"leri kullanan bir müşteri hükmünde kalıyor.

İlerisi...

SOA 2.0 veya Advanced SOA kavramları ortaya atılmış durumda. Mâlum SOA'nın şu hâlinde "olay" denen programlama yapısına yer verilmiyor. Bu gelişmiş sürümde SOA'ya olay güdümlü mimariyi de sokuyorlar. Bunu yapan Oracle aslında. Henüz yaygın kabul görmüş bir girişim değil.

SOA öksüz çocuk değil. Hızla ilerliyor ve kamu oyunda gördüğü kabul düzeyi artıyor. Lider yazılım firmaları da samimi olarak destekliyor. Microsoft desteklediği gibi Sun da destekliyor demek istiyoruz. Ortada kalmazsınız.

Bir müesseseye bağımlı olmaktansa evrensel ve açık standartlar düzleminde hareket etmek her zaman yeğdir. Bunu ActiveX bilgileri çöpe gidenler çok daha iyi anlarlar efendim.

Kalemin ucu bitmiş. Yeni bir kalemle, yeni bir söyleşide buluşmak üzere.

SOA ile.

1801 / 080

Seyreyle Gönül .NET Framework Kodunu

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

Debug Keyfine Limon Sıkmak

"Debug" esnasında .NET nesnelerinin üzerinde eğleşmeden geçerdik. O oturumlarda sadece kaynak kodu elimizde olan şeylerin içine dalabiliyorduk.

Şimdi Microsoft, güzel bir adım attı gönlümüze doğru. Debug keyfimiz, .NET kodunun içinde de devam edecek bundan böyle.

Kod Okur-Yazarlığı

.NET koduna müracat amaçlı bakmanın mümkün hâle gelmesi, kod okur-yazarlığı meselesini de gündemimize taşımış olacak.

Usta kodcular bilirler ki, kod okumak, yazmak kadar önemlidir. İyi bir kodcunun hem okuması hem de yazması güçlüdür. Okuması zayıf bir kodcunun, aylar sonra kendi yazdığı kodu bile kavrayamaması meselenin ehemmiyetini fehimlerimize çakmaktadır.

.NET kodunu seyretmek, yetişmekte olan kodcu adaylarına kod nasıl okunur-yorumlanır ve düzgün kod nasıl yazılır konularında güzel bir ders olacaktır.

.NET kodu çok mu düzgündür diye muhalif bir ses hep çıkacaktır. Düzgündür. En azından yetişmekte olan kodcu için tertipli, açıklamaları yazılmış, "self-documented" ve "best-practise"ler ihtiva eden bir kod kümesine "debug" vesilesiyle göz atmak mükemmel bir fırsattır.

Yetişmiş kodcu için de, daha önce Reflector mucizesi ile baktığı kodları, ona gerek kalmadan ("debug" amaçlı yorumlarıyla) canlı takip etmek mükemmel bir fırsattır.

Sonuçta bu olay, fırsat oğlu fırsattır; fazla uzatmayalım.

Nasıl ve Nerede?

Bu soruyu, ingilizce kaynakları Türkçe'ye birebir aktaran muhtelif kaynaklara sorsanız ya da doğrudan gidip işin mühendislerinden okusanız daha iyi olur efendim.

Nasıl kurulacağını Shwan Burke, güzel güzel anlatmış.

Kayda değer birkaç not:

  • Şimdilik kütüphanelerin tüm kodlarını indirmek mümkün değil, yakında mümkün olacak.
  • Kodların lisansı "Microsoft Reference License"; sadece okuma amaçlı, kurcalamaya müsade yok.
  • Bu olay Microsoft'un "Open Source" rüzgarında bir orta yol bulmaya çalıştığını gösteriyor.

Teşekkürler tüm "Open Source" .NET kodcuları.

Haydi, başlasın "debug"lar!

YENİ - Paket Yapalım mı?

http://www.codeplex.com/NetMassDownloader adresinden tüm kaynak kodları indirebileceğimiz uygulamayı Kerem Küsmezer iletti. Ellerine sağlık.

Sayfalar

Kısımlar

Desteklediklerimiz

Ay bazında arşiv

Haberleşme