50 Soruda Yapay Zeka - Kitap İncelemesi

3. Mayıs 2019

 

Bilim ve Gelecek Kitaplığı'ndan çıkan 50 Soruda Yapay Zeka, Boğaziçi Üniversitesi Bilgisayar Mühendisliği bölümünde profesör olan hocamız Cem Say tarafından tamamı cep telefonunda yazılmış yazılmış. Kitabın kapağını da Cem Say'ın kızı tarafından yine cep telefonunda çizilmiş. Kitap Cem Say'ın yapay zeka üzerine, belirlediği 50 soru ve bu sorulara cevaplar ile bilgisayar bilimlerinin ve programlamanın gelişiminden başlayıp yapay zekayı, makina öğrenmesini ve güncel yapay zeka uygulamalarına değinerek günümüzde sıkça sorulan sorulara yanıtlar veriyor. Farklı kaynakların çok satan listelerinde sıklıkla gördüğümüz, etrafımızdaki popüler kitapçıların hemen hepsinde rastlayabildiğimiz ve Türkçe bir kaynak olarak karşımıza çıkan bu kitap bu özellikleriyle öncelikle ilgimi çekti. Henüz Ekim 2018'de ilk baskısını yapan kitap Nisan 2019'da 8. baskısını yapmış, yoğun ilgi alan bir kitap. Cem Say'ın da özellikle belirttiği gibi yurt dışı kaynaklarda da farklı bir içerikle karşılaşmayacağınız şekilde yazılmış bir kitap. Yani dili oldukça akıcı, İngilizce kaynaklara ihtiyaç duymadan doyurucu bir içerik sağlıyor. Yer yer esprili bir üslupla yazıldığı içinde ilginiz düşmeden çok rahatlıkla okuyabiliyorsunuz.

Matematik, mantık, bilgisayarların çalışma mantığı, Alan Turing ve Turing Makinası, Gödel ile başlayan kitap ilk bölümünde yer alan sorular ile okuyucuya bir temel inşa ediyor. Bilişim Teknolojileri üzerine eğitim almamış meraklı okuyucuları sıkmayacak bir dile sahip, oldukça anlaşılır. İlk bölümdeki bazı soruları olmazsa olmaz nitelikte değerlendirip, fazla da detaya giremeden cevaplandığından ötürü bazı kısımlarda biraz yorucu olabilse de yazar ilgiyi her soruda yüksek tutuyor. Turing testi ile alakalı bölüm oldukça ilgi çekici, çok sevdiğim bir bilim kurgu filmi olan Ex_Machina'yı izlememiş olanlar için tavsiye ederim.

Programlama dillerinin felsefesi, hayatın matematiği, beynimiz nasıl çalışır gibi konularla düşünme şeklimiz ile yazılım geliştirme sırasında kullandığımız yapılar arasında bağlantılar kuran sorular ile okuyucuyu Yapay Zeka teknolojilerine ve temelde çözmeye çalıştığı problemlere hazırlayan harika bir kurgusu var kitabın. Bu ara Cem Say'ın ve öğrencilerinin yaptığı çalışmalar üzerine de bilgi sahibi olup, Türkiye'de yapılan çalışmalara da göz atıyoruz. 

Sonrasında günümüzde oldukça sık karşımıza çıkan sinir ağları, yapay zeka, derin öğrenme gibi kavramlara sıra geliyor. Bir bilgisayar programının Kasparov'u yenmesi ve bu tarz yazılımların algoritmalarının nasıl tasarlandığı üzerine şahane bir bölüm başlıyor. Kitabın bu bölümünden sonrası su gibi akıyor adeta. Kasparov'dan AlphaGo'ya, chatbotlara, otonom arabalara ve google'ın keşfettiği gezegene kadar her soruda ilginç ve çok güncel konulara cevaplar alıyoruz. Bu arada AlphaGo demişken, izlemeyenler için AlphaGo'nun hikayesini anlatan Netflix belgeseli AlphaGo'yu şiddetle tavsiye ederim. 

Burada araya girip İthaki Yayınları'ndan çıkan Bilimkurgu Klasikleri serisinde yer alan iki kitabı referans vermek istiyorum. Evrimsel Programlama'nın anlatıldığı, yazılımların kendi kendini sınayarak evrimleşmesi ile ilgili bölümü okurken anımsadığım, geçtiğimiz yıl okuduğum ve çok etkilendiğim Stanislaw Lem'in Yenilmez'ine referans vermek istiyorum. Yenilmez'de uzak bir gezegene inen bir gemideki robotların evrimleşerek gezegen üzerindeki tüm hayatı yok edişleri ve altedilemez bir tür robot oluşturmaları üzerine şahane bir kitap. Ayrıca otonom arabalar ve robotik konuları ele alınırken robotik kelimesinin ilk kullanımının Isaac Asimov'a ve şiddetle tavsiye ettiğim Ben, Robot'ta okuyabileceğiniz Yalancı! hikayesine atıfta bulunuyor Cem Say. Asimov'un hikayelerinde dile getirdiği Üç Robot Kanunu ile "robotlar dünyayı ele geçirebilir mi ?" ya da "insanlığın sonunu getirebilir mi ?" sorularına verilen yanıtlarda Asimov'a referans veriyor Cem Say.

Yapay zeka ile alakalı güncel sorulardan biri olan "Yapay Zeka mesleğimi elimden alacak mı ?"'ya bir nevi cevap arayan son sorular ile yapay zekanın, işin içeriğine bağlı olarak uzman bir profesyonelin görebileceğinden daha fazla vaka yüklenebildiği ve bunlardan öğrendikleri ile uzman profesyonellere göre çok daha başarılı olabildiği vakalar üzerine çok güzel örnekler inceliyor.

Son bölümde ise Yapay Zeka'nın geleceği üzerine sorular ele alıyor yazar. Yapay zekanın öğrendiği vakalardaki önyargılı eğilimlerin yapay zekaya da aktarılabildiği örnekler üzerinden kötü örneklere de değinip, mevcut problemleri de ele alıyor Cem Say.

175 sayfalık, 50 soruluk, çok akıcı bir kitap olan 50 soruda Yapay Zeka çok akıcı ve çok güncel konulardan verilen örneklerle Yapay Zeka hakkında hepimizin aklındaki sorulara cevap vermeye çalışıyor. Bilişim teknolojileri konusunda uzman olmayanların da rahatlıkla okuyabileceğini düşündüğüm Cem Say hocamızın bu kitabını tavsiye ederim.

, , , , ,

ASP.NET Core Web API ile NSwag Entegregrasyonu

8. Aralık 2018

OpenAPI, Swagger, NSwag nedir ? 

 

OpenAPI insiyatifi, dünya çapında kullanılan Restful API standartlarını tanımlamaya çalışan bir topluluk. Swagger  ise OpenAPI ile tanımlanan WebApiler için oluşturulan spesifikasyon ve üretilen araçlara verilen isim. 

Yani geliştirdiğimiz bir Web API için oluşturacağımız swagger spesifikasyon dosyası ile web apimizi dünyaca tanınan bir standarta göre tanımlamış oluyoruz. Bu dosyaya göre istenilen dilde servisimizi kullanacak istemciler yazılabilir. Web API’mizi web servis gibi düşünürsek aslında swagger spesifikasyon dosyaları wsdl’e karşılık geliyor.

NSwag, swagger spesifikasyon dosyalarını kullanarak .NET platformu için araçlar üreten kütüphane diyebiliriz. Aşağıda detaylarına gireceğimiz, swagger spesifikasyon dosyasını, Web API önyüzlerini ve C#, TypeScript (Jquery, AngularJS ve Fetch istemcileri) ile ASP.NET Web API controller istemcilerini üretebildiğimiz araç ve kütüphaneleri içeriyor.

 

VS.NET 2017 ile Örnek Olarak Kullanacağımız Web API Projesinin Oluşturulması

 

VS.NET 2017 ile Web API şablonunu kullanarak yeni bir ASP.NET Core web uygulaması projesi oluşturup derleyip varsayılan olarak gelen Values Web API’sini deneyebiliriz.

Values Apisinin Get metodunu tarayıcıdan çağırdığımızda aşağıdaki gibi basit bir JSON döndüğünü görüyoruz. Bunu makalemizdeki örneklerimizde kullanıyor olacağız.

  

 

Web API Metodlarını İncelemek ve Test Etmek

 

Gerek kendi yazdığım, gerekse başka sağlayıcılarca sağlanan web api metodlarını incelemek test etmek için yakın zamana kadar Postman kullandım. Kullanıcı dostu arayüzü ve tarihçe özelliği ile web api testlerinde ve hatta .NET Click Once uygulamaların manifesto dosyalarını inceleme konusunda olmazsa olmaz bir araç benim için. Örnek olarak hazırladığımız projeyi Postman ile aşağıdaki gibi test edebiliyoruz. Http metodunu değiştirerek, parametre var ise onları da girerek oldukça hızlı bir şekilde web api testi yapabiliyoruz.

 

Swagger UI ile Web API projemize oluşturacağımız önyüzler açıkçası Postman gibi bir araca ihtiyacı yok edecek gibi gözüküyor. Fazla vakit kaybetmeden projemizin NSwag entegrasyonunu tamamlayıp web api metodlarımız için oluşacak önyüzleri inceleyelim.

 

ASP.NET Web API Projesi NSwag Entegrasyonu

 

Hazırladığımız Web API uygulamasının swagger spesifikasyonu oluşturmak için öncelikle yapmamız gereken şey uygulamamıza NSwag.AspNetCore referansını eklemek.

Web API projesine nuget ile NSwag.AspNetCore referansı eklenerek NSwag projeye dahil edilmiş oluyor. Aşağıdaki ayarları yaparak Swagger Ui’i aktif hale getirerek Web API metodlarımız için hazırlanan Swagger önyüz ekranlarına ulaşabilir ve tarayıcı yardımı ile metodlarımızı test edebilir hale geliyoruz. Bu uygulayacağımız metodlar NSwag’in her versiyonunda değişikliğe uğramış görülüyor. Internetteki pek çok örnekte kullanılan metodlar obsolete olarak işaretlenmiş, kullanımı tavsiye edilmiyor, bu metodların yerlerine yeni metodlar eklenmiş kütüphanede. Fakat pek çoğunun dökümantasyonunu yada güncel bir örneğini bulmak çok zor. Açıkçası deneme yanılma ile Swagger Ui ekranlarını aktif hale getirebildim. 

 

 

NSwag.AspNetCore referansını projemize ekledikten sonra aşağıdaki gibi swagger ui entegrasyonunu yapıyoruz.

public void ConfigureServices(IServiceCollection services)
{ 
   services.AddSwaggerDocument();
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
     app.UseSwagger();
     app.UseSwaggerUi3();

    if (env.IsDevelopment())
    {
       app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseMvc();            
}

 

 

Yukarıda gördüğünüz gibi NSwag hem swagger spesifikasyon osyasını oluşturuyor, hem de uygulamamız altındaki web apiler için dökümantasyon ve test arayüzleri oluşturuyor.

 

 

NSwagStudio ile Web Api'mize Erişecek İstemci Kodunu Üretelim

 

Şuana kadarki örneklerimizde ASP.NET Core Web API ile hazırladığımız Web API'mize tarayıcı izlenebilen bir dökümantasyon sayfası üretip test edebileceğimiz önyüzleri nasıl oluşturabileceğimiz üzerinde durduk. Yani konuya sunucu tarafından, api sağlayıcı tarafından baktık. Şimdiki örneğimizde konuya istemci tarafından yani ilk örneğimizde sağladığımız web apiyi kullanacak uygulama tarafından bakacağız.

NSwag  Studio Studio uygulaması ile Web Api projemizde oluşturulan swagger.json dosyası analiz ettirilerek C#, TypeScript veya C# Web Api controller’ı şeklinde API’yi kullanan client kodların üretilmesi sağlanabilir. Studio projesi onlarca seçenek ile özelleştirilebiliyor ve oldukça parametrik gözüküyor. Aşağıdaki örnekte kendi yazdığım iki web api için oluşturulan C# istemci kodunu nasıl ürettiğimi ve kullanımın nasıl olduğunu inceleyebiliriz.

 
 

 

 

 

CustomerClient cusClient = new CustomerClient(new System.Net.Http.HttpClient());
List<Customer> customers = (List<Customer>)cusClient.GetAsync().GetAwaiter().GetResult();

foreach (Customer value in customers)
{
    Console.WriteLine("Customer received : {0} {1}", value.Name, value.Surname);
}

 

NSwag Studio sadece Windows GUI olarak değil, aynı zamanda komut satırı uygulaması olarak da kullanılabiliyor. Böylece derleme otomasyonumuz içerisine script olarak kod üretimini dahil edip, kullanacağımız istemci sınıfları otomatize bir şekilde güncel tutabiliriz. Tam da bu amaçla eklenmiş Cake ve MSBuild scriptleri desteği mevcut.

Kaynaklar

 

Bu örnekleri hazırlarken internette karşılaştığım çoğu kaynak eski kalmıştı, örnek olarak verilen neredeyse tüm kod parçaları kütüphaneden kaldırılmış ya da obsolete olarak işaretlenmişti. An itibariyle çalışır durumdaki metodlar makalemdeki metodlardır. Projeyi güncelledikçe makalemi de güncelliyor olacağım. Makaleyi hazırlarken aşağıdaki kaynaklardan faydalandım. Daha güncel ve orjinal dilindeki kaynaklara buradan erişebilirsiniz.

https://github.com/RSuter/NSwag

https://blog.rsuter.com/nswag-tutorial-integrate-the-nswag-toolchain-into-your-asp-net-web-api-project/

, , , ,

The Phoenix Project Kitap İncelemesi

18. Kasım 2018

 

The Phoenix Project, DevOps'u yoğun bir şekilde duymaya başladığımız bu aylarda DevOps'un neyi çözmek için nasıl ortaya çıktığını adım adım adeta bir macera romanı havasında takip ettiğimiz Parts Unlimited firması ve hayata geçirmeye çalıştıkları Phoenix Projesinin üretim ortamına alınması hikayesi hakkında.  Teknik olmayan, bilişim teknolojileri ekipleriyle az çok çalışmış kişilerin de rahatlıkla okuyup, anlayıp bakış açısını değiştirebileceği bir kitap.

Kitap roman gibi yazıldığı için bazı bölümlerde gerçekten çok heyecanlı devam ediyor ve bölüm sonunda kitabı bırakamayıp diğer bölüme devam ediyorsunuz çoğu zaman. Hikayedeki çoğu kişi, olay ya da diyalog, bilgi teknolojilerinde çalışan herkes için çok tanıdık. Kahramanlarımızın olaylara verecekleri tepkiyi siz daha olayın gelişimi sırasında veriyorsunuz bazen.

Bill, Wes, Patty ve hatta neredeyse hiç iletişim kurmadığımız ama romanın ana kahramanlarından biri olan Brent sanki beraber çalıştığımız kişiler gibi. Kitap DevOps'a operasyon ekipleri gözüyle bakıyor. Ana kahramanlarımızın tamamı operasyon ekiplerinde çalışan personeller. Yazılım geliştiren ekip ise çok tipik bir bakış açısıyla konuya yaklaştığı için açıkçası ilgili bölümlerde, bir yazılımcı olarak daha fazla yorumunuz ya da serzenişiniz olabiliyor. DevOps ve çevik metodolojiye yazılım ekibi açısından yaklaşım pek çoğumuz açısından daha yararlı olurdu görüşündeyim.

Konu olan pek çok sorunun çözümü aylar alabiliyor normalde kitapta birkaç sayfada çözüme gidilebiliyor. Bu bir yandan gerçekçi gelmiyor, ama bir yandan da kitabın vermek istediği mesajı hızlı verebilmesi için böyle olması gerektiğine hemfikirim. Otomobil üretim hattı örnekleri üzerinden yazılım geliştirme ve operasyon süreçlerindeki sorunların çözümü, Toyota'nın Single Minute Exchange of Die (SMED) adını verdiği, üretim ekipmanlarının üretim işlemleri sırasında değiştirilmesi sürecindeki iyileştirmeleri hakkındaki bilgiler ile bağlanan daha sık yazılım sürümü kurulumu arasındaki bağlantılar oldukça ilgi çekici bölümler. 

Kesinlikle çok eğlenceli ve sürükleyici dille yazılmış bir kitap.Teknik olsun olmasın herkese hitap edebilecek tarzda, hatta bilişim teknolojilerinde çalışmayan kişilerce okunmasının faydalı olabileceğini söyleyebilirim. Okuyalım, okutalım.

kitap incelemesi ,

Building Evolutionary Architectures: Support Constant Change - Kitap İncelemesi

3. Haziran 2018

 

Güncel hayatta günlük iş yaşamımızda sıklıkla, halihazırda var olan uygulamalara ek özellikler geliştiriyoruz. Bazen karşılaştığımız yazılımların mimarileri yeni geliştirilen özelliklerin adaptasyonunda çok zorluk çıkarıyor, bazen ise çok daha kolay bir şekilde adapte edebiliyoruz yeni özellikleri. İşte evrimleşebilir yazılım mimarisi tam da bu konu ile ilgileniyor. Yani günlük yaşamımızda sıklıkla karşımıza çıkan evrimleşen yazılımları, yeni gelecek özelliklere adaptasonunu kolaylaştırma, yazılımın hedeflediği mimari özellikleri riske atmadan yeni özellik geliştirebilmeyi, güncel teknolojiler ve güncel yazılım geliştirme pratiklerini kullanarak aktarmaya çalışıyor.

Yazılım mimarisi üzerine çok güncel ve ilginizi kitabın sonuna dek üst seviyede tutacak bir kitaba ne dersiniz ? Son yıllarda sık sık duyduğumuz ve hatta hayatımıza girmeye başlayan bu yeni trendlerin ve pratiklerin oldukça açık ve anlaşılır bir şekilde anlatıldığı bu kitabı şiddetle tavsiye ediyorum.

Aşağıda kitabı bölüm bölüm içerikleri ve benim ilgimi çeken kısımları ile kısaca özetlemeye çalıştım, umarım faydası dokunur.

1. Bölüm : Software Architecture

Bu bölüm konuya giriş mahiyetinde yazılmış, genel bilgiler vererek neden yazılım mimarileri değişikliğe uğrar, nasıl hazırlıklar yapılmalıdır ve zamanla karşılaşılacak değişikliklerin ne kadar normal ihtiyaçlar olduğu üzerine nispeten kısa bir bölüm. Yazılım geliştirirken yazılım mimarlarının, yazılım ile alakalı taleplere göre çıkardıkları karakteristik mimari özelliklerin nasıl belirlendiği ne nasıl korunduğu üzerine başlıklar içeriyor.

2. Bölüm : Fitness Functions

Benim için yeni olan bu terimi bu kitap sayesinde öğrendim. İlk bölümde bahsedilen yazılımın karakteristik özelliklerini, yazılıma zamanla yapılan değişikliklerle korunup korunmadığını test eden fonksiyonlara verilen isim fitness functions. Yazılım geliştirme süreci içerisinde continuous integration içerisine dahil edilen fonksiyonlar her değişiklikte karakteristik özelliklere yapılan etkiyi test ediyor.  Kısacası geliştirilen mimarinin, talep edilen ya da iddia edilen mimari özelliklere sahip olup olmadığını kontrol eden testlere fitness function deniyor. 

Fitness functionları açıklayan bölüm sonrasında atomik, yani tek özellik üzerine yoğunlaşan fonksiyonları ve holistik yani birden fazla özelliğe yoğunlaşıp birbirleri ile ilişkilerini test eden fonksiyonları açıklıyor. Statik / dinamik, otomatik çalışan / manuel tetiklenen ve geçici fonksiyonlar gibi pek çok kategoriye ayrılan fitness fonksiyon çeşidini açıklayarak devam ediyor bölüm.

3. Bölüm : Engineering Incremental Change

Continuous Delivery kavramını açıklayarak başlayan bölüm bu kavramın evrimleşebilir mimaride nasıl yer bulduğunu açıklıyor. Yapılancak değişikliklerin agile pratiklere de uygun olarak olabildiğince ufak yapılması ve otomatize edilmesi üzerinde duruyor. Sağlanan bir serviste yapılacak değişikliğin geriye dönük desteği nasıl sağlayabileceğini örneklendirerek çok anlaşılır bir şekilde aktarıyor.

Github'ın, sisteminde gerçekleştirdiği günde 60 kurulumu nasıl yaptığı üzerine yazılmış bölüm ve Github ekiplerinin geliştirdiği Scientist kütüphanesini tanıtan bölümler gayet güncel ve ilgi çekici. Scientist kütüphanesi, sistemde yapılan refactoring'lerin eski kodda ve yeni yazılan kodda nasıl sonuçlar verdiğini karşılaştırıp güvenle değişiklik yapmayı sağlıyor. Kendime not olarak da aldığım Scientist'in .NET port'u olan Scientist.NET gayet güzel örneklerle dökümante edilmiş açık kaynak bir kütüphane.

Ayrıca Hypothesis and Data Driven Development ve 2013 yılbaşında Facebook'un karşılaştığı inanılmaz sayıdaki fotoğraf yüklenesi ve bunların büyük bir çoğunun saldırgan olarak işaretlenmesi ile ilgili vaka, ve bunun altyapıda yarattığı yoğunluk üzerinde duruluyor. İnsanların kendi "hoş gözükmeyen" fotoğraflarını saldırgan olarak işaretlemesi eğilimi üzerine facebook ekiplerinin yaptığı çalışmalar ve bu probleme çözümleri anlatılıyor.

4. Bölüm : Architectural Coupling

Mimari açıdan uygulama modüllerinin birbirlerine referansları her zaman problem olmuştur. Modüllerin ne kadar bağlı olması gerektiği üzerine çalışmak mimarları zorlayan konulardan biri. Bu konuya ayrılmış olan 4. bölüm modülerlik ve mimari quantum'dan bahsederek konuyu monolith uygulamalara, plugin tabanlı uygulamalara, SOA, sunucusuz uygulamalara, BaaS ve FaaS ile microservislere bağlıyor. Birçok modern mimarinin anlatıldığı bölüm uzun ama oldukça zevkli ve kolay anlaşılır bir dille yazılmış.

Bu noktada yine kendime not olarak aldığım bir Channel 9'da yayınlanmış güncel bir videoyu paylaşmak istiyorum : Microservice Architecture with ASP.NET Core

5. Bölüm : Evolutionary Data

Uygulamaların olmazsa olmaz parçası veri kaynakları üzerine ayrılmış bölüm temelde veritabanlarında yapılacak değişikliklerin nasıl yönetileceği üzerine yoğunlaşmış. Veri kaynağı olarak veritabanlarını kullanan ortalama seviyedeki bir yazılım geliştiricinin sıklıkla kullandığı yöntemler üzerinde duruluyor. 

6. Bölüm : Building Evolvable Architectures

Bu bölümde eski bir uygulama nasıl evrimleşen hale getirilir, yeni geliştirilmeye başlanan bir uygulamada evrimleşen bir mimari kurabilmek için uygulanması gerekenler üzerinde duruluyor. Farklı tip uygulama mimarileri ve bunların evrimleşebilir hale getirilmesi ya da evrimleşebilirliğe ne kadar uygun oldukları açıklamalı anlatılıyor. Farklı tip mimarileri tanımak için bile okumaya değer bir bölüm. Ayrıca referans olarak eklenen kütüphanelerin evrimleşebilir bir mimari üzerindeki olası etkileri, eklenen kütüphanelere ya da bağımlı olunan frameworklere nasıl yaklaşılması gerektiği konusu inceleniyor.

7. Bölüm : Evolutionary Architecture Pitfalls and Antipatterns

Bu bölümde evrimleşebilir bir mimari tasarlarken karşılaşılabilecek tuzaklar ve kötü tasarım desenleri inceleniyor. Mesela genellikle düşülen tuzaklardan biri, geliştirilen yeni bir uygulama eğer temelde bir başka ürüne dayanıyor ise mimarinin bu ürüne göre şekillenmesinin yanlışlıklarından ve etkilerinden bahsediliyor. Ayrıca kitap genelinde sürekli referans konan The Last 10% tuzağı bu bölümde inceleniyor sonunda. Uygulama geliştirirken genellikle seçilen kütüphaneleri uygulamanın 80% - 90%'sini hızlandıracak, ya da geliştirmesini kolaylaştıracak şekilde seçiyoruz. Ama bazen kalan 10%'lik kısmın geliştirmesi ya da etkileri o kadar büyük olabiliyor ki uygulamaların başarısızlıkla sonuçlanmasına bile sebep olabiliyor. Bu tuzak, gerçek bir örnek anlatılarak inceleniyor.

Code Reuse ile alakalı oldukça aykırı fikirlerin yeraldığı bir bölüm var, benim oldukça ilgimi çekti. Üniveristeden beri şartlandığımız code reuse'un gerçek hayatta işleri ne kadar zorlanştırdığı üzerinde duruluyor. Loglama ve monitoring gibi temel mimari özellikler dışındaki kısımların kod kopyalanarak ya da yeniden yazılarak uygulamaların olabildiğince birbirinden ayrık tasarlanması üzerinde duruluyor.

Hatta yanlışlıkla yapılabilecek kod reuse'ları ve bunun sonucu oluşan bağımlıklıkları engellemek için her ayrık servis için farklı teknoloji seçimi bile yapılabileceği öneriliyor. 

8. Bölüm : Putting Evolutionary Architecture into Practice

Kitabın son bölümü gerçek hayatta evrimleşebilir bir yazılım mimarisinin nasıl hayata geçirilebileceği üzerine eğiliyor. Yazılım geliştirecek ekiplerin nasıl yapılandırılması gerektiğinden başlayıp süreçlere kadar eğiliyor.

 

kitap incelemesi , ,

ASP.NET 5 / ASP.NET MVC 6 View Components Yeniliği - Görsel Bileşenler

10. Kasım 2015

 Frameworklerin yeni versiyonlarında sıklıkla mevcut bileşenler tekrar kullanılabilirlik açısından ele alınır ve iyileştirmeler yapılır. ASP.NET 5 ve ASP.NET MVC 6.0 ile partial view ve child action özellikleri ele alınıp view components ile daha tekrar kullanılabilir hale getirilmiş. Tekrar kullanılabilir bir taslak yaratmak için controller'a bağımlılık ortadan kaldırılmış ve asenkron olarak kullanabilme sağlanmış. Bu yazımda öncelikle child action ile tekrar kullanılabilir bir görsel taslak hazırlamaya çalışıp, sonra bu örneği view components ile hazırlayıp kullanmaya çalışacağız.

 

ASP.NET MVC 2 Child Actions ile tekrar kullanılabilir bileşenler

Child Actions konusuna hakim okuyucular bu bölümü atlayıp bir sonraki bölüme devam edebilir. ASP.NET MVC 2 ile gelen Child Actions sayesinde controllerlarımıza tanımladığımız aksiyonları ChildActionOnly attribute'u ile işaretleyip, istediğimiz görsel taslak içerisinde çağırabiliyoruz. Böylece DRY prensibine uygun olarak aksiyonu ve görselini uygulamamız içerisinde defalarca kullanabiliyoruz. Aşağıda child action olarak tanımladığımız bir aksiyonu ve görsel taslağını inceleyebiliriz : 

public class HomeController : Controller
{
	public ActionResult Contact()
	{
		return View();
	}

	[ChildActionOnly]
	public ActionResult Movies()
	{
		List<Movie> movieList = new List<Movie>();
		movieList.Add(new Movie() { ImdbId = "tt0470752", Name = "Ex Machina" });
		movieList.Add(new Movie() { ImdbId = "tt2562232", Name = "Birdman" });
		movieList.Add(new Movie() { ImdbId = "tt0137523", Name = "Fight Club" });
		return View(movieList);
	}
}

Görsel taslak dosyası : Movies.cshtml 

@model List<ViewComponentsTrial.Models.Movie>

<div>Movies : </div>
<ul>
@foreach(var item in Model) {
    <li><a href="http://www.imdb.com/title/@item.ImdbId">@item.Name</a></li>
}
</ul>

Yukarıda hazırlamış olduğumuz tekrar kullanılabilir child action örneğini uygulamamız içerisinde aşağıdaki gibi kullanabiliyoruz : 

@Html.Action("Movies")

View Component'in Hazırlanması ve Kullanılması

Yukarıdaki örnekte child action yardımı ile hazırladığımız film listesini, uygulamamız genelinde kullanılabilecek bir View Component olarak hazırlamak istersek aşağıdaki gibi ViewComponent sınıfından türeyen bir sınıf hazırlamamız gerekiyor.

public class MoviesViewComponent : ViewComponent
{
	public IViewComponentResult Invoke(string imdbId)
	{
		List<Movie> movies = GetMovies();
		if (string.IsNullOrEmpty(imdbId))
		{
			return View(GetMovies());
		}
		else
		{
			return View(GetMovies().Where(m => m.ImdbId == imdbId));
		}
	}

	public List<Movie> GetMovies()
	{
		List<Movie> movieList = new List<Movie>();
		movieList.Add(new Movie() { ImdbId = "tt0470752", Name = "Ex Machina" });
		movieList.Add(new Movie() { ImdbId = "tt2562232", Name = "Birdman" });
		movieList.Add(new Movie() { ImdbId = "tt0137523", Name = "Fight Club" });
		return movieList;
	}
}

 

View Component olarak hazırladığımız sınıfların isminin ViewComponent şeklinde bitmesi gerekiyor. View component'imiz Invoke metodu ile görsel taslakta kullanılacak modeli dönüyor. Hazırladığımız view component'in görsel taslağını aşağıdaki gibi hazırlıyoruz. Burada dikkat edilmesi gereken nokta, görsel taslağın konumlandığı dizin. Görsel taslağımız ~\Views\Shared\Components\Movies dizininde bulunuyor. Yani kullanılmak istenen controller'ın sahip olduğu görsel taslak dizininin altında Components dizini oluşturup bunun altına view componentimiz için bir dizin oluşturmamız gerekiyor. Bu dizinde görsel taslağımızı Default.isml ismi ile kaydediyoruz. Ben örnek olarak kullandığım view component'i tüm görsel taslaklarda kullanabilmek için shared dizini altına konumlandırdım. Dilersek view component diğer dizinler altına konumlanıp sadece konumlandığı dizin altında kullanılması da sağlanabilir. Görsel taslağımıza göz atarsak :

@model IEnumerable<ASP_NET_5_TagHelpers.Models.Movie>
<div>Movies : </div>
<ul>
    @foreach (var item in Model)
    {
        <li><a href="http://www.imdb.com/title/@item.ImdbId">@item.Name</a></li>
    }
</ul>

Şimdi hazırladığımız view component'i kullanmak için yapmamız gereken tek şey sayfalarımızda aşağıdaki gibi çağırmak :

@Component.Invoke("Movies", "")
// Asenkron kullanım : 
@await Component.InvokeAsync("Movies", "")
// Parametreli kullanım : 
@await Component.InvokeAsync("Movies", "tt2562232")

Sonuç

View components, ASP.NET içerisindeki görsel taslakları yeniden kullanılabilir yapmak için getirilmiş ve önceki tekniklere göre çok daha etkili bir teknik. Sadece controller bağlantısının koparılması bile tekrar kullanılabilirlik açısından tercih sebebi olmasını sağlayacaktır. Örneğimde yer alan kod bloklarına ve dosyalara aşağıdaki github projesi ile ulaşabilirsiniz : 

View Components Örnekleri

 

asp.net , , , ,

ASP.NET 5 Tag Helpers - Etiket Yardımcıları

28. Ekim 2015

ASP.NET MVC ile Razor View Engine ilk çıktığında HTML helpers ile tanıştık ve MVC projelerinde yoğun olarak HTML Helper metodlarını kullandık, kullanımı kolaylaştırmak için kendi yardımcı metodlarımızı yazdık. ASP.NET MVC ile alakalı pek çok soru ve takıldığımız pek çok nokta HTML Helper kullanımı ile alakalı oldu. HTML'nin basitliğinden ve yıllardır tecrübe ettiğimiz etiketler ile attributelerden uzaklaştık. Yerine HTML Helper metodlarına geçilen parametrelerle boğuşmaya başladık. Şahsen hala ASP.NET MVC'de HTML Helper ile oluşturacağım bir linke class attribute'u verirken zorlanmıyor değilim.

İşte bu noktada Tag Helpers - etiket yardımcıları ile biz geliştiricilerin yardımına biraz geçte olsa yetişilmiş oldu. Tag Helpers temelde bize kullanım kolaylığından başka yeni bir şey sunmuyor. Razor HTML yardımcıları ile yazabildiğimiz kodu, tag helpers ile daha markup diline yakın olarak yazabiliyoruz, View'larımız daha okunabilir oluyor. Dolayısıyla anlaması ve geliştirmesi daha kolay hale geliyor. ASP.NET 5 ile gelen etiket yardımcılarına ek olarak istersek kendi etiket yardımcılarımızı geliştirebiliyoruz, ki bu kısım bence konunun en heyecan veren yeri.

Bu yazıda öncelikle ASP.NET 5 ile gelen varsayılan etiket yardımcılarına değinip, sonrasında kendi etiket yardımcımızı nasıl yazacağımız ve kullanacağımız üzerinde durmaya çalışacağım.

 

ASP.NET 5 Varsayılan Etiket Yardımcıları

Aşağıdaki kod bloğunda etiket yardımcıları olmadan HTML yardımcıları yardımı ile basit bir view örneği görüyoruz. Buradaki HTML yardımcıları ile oluşturduğumuz üç elemana dikkat edelim. Bir textbox, bir checkbox ve bir link elemanı oluşturuyoruz.

 

@model ASP_NET_5_TagHelpers.Models.ToDoListItem

<label>Açıklama : </label>
@Html.TextBoxFor(m => m.Text)
<br />

<label>Tamamlandı mı ? : </label>
@Html.CheckBoxFor(m => m.IsCompleted, new { id = "todolistitem" + Model.ItemId })
<br />

@Html.ActionLink("Tag Helper Kullanılmış Sayfaya Git", "WithTagHelper", "Home")

 

 Şimdi aynı örneği ASP.NET 5 ile gelen varsayılan etiket yardımcıları ile yapalım. ASP.NET 5 ile gelen varsayılan etiket yardımcılarını kullanmak için yapmamız gereken tek şey @addTagHelper emri ile etiket yardımcılarının bulunduğu assembly'i referans göstermek. Böylece aşina olduğumuz HTML etiketlerine etiket yardımcıları ile gelen ek attibute'ları kullanarak view'ımızı hazırlayabiliyoruz. 

 

@model ASP_NET_5_TagHelpers.Models.ToDoListItem
@addTagHelper "*, Microsoft.AspNet.Mvc.TagHelpers"
    
<label>Açıklama : </label>
<input type="text" asp-for="Text" /><br>

<label>Tamamlandı mı ? : </label>
<input type="checkbox" asp-for="IsCompleted" id="@String.Format("todolistitem{0}", Model.ItemId)" /><br />

<a asp-controller="Home" asp-action="WithoutTagHelper">Tag Helper Kullanılmamış Sayfaya Git</a>

 Örnekte bulunan input elemanlarına tanımladığımız asp-for attributelarına dikkat edelim. Bunlar elemanın, modelin hangi özelliği ile eşleşeceğini belirtiyor. Link elemanına gelen asp-controller ve asp-action attributelarına dikkat edelim, bunlar da link elemanının hangi controller'ın hangi aksiyonu çalışacağını belirtiyoruz. İşler oldukça basitleşmiş ve okunabilir hale gelmiş değil mi ? 

Kendi Etiket Yardımcımızı Geliştirelim

 ASP.NET 5 ile gelen varsayılan etiket yardımcılarının yanı sıra kendi etiket yardımcımızı yazabilmemizi sağlayan sınıflar da mevcut. Microsoft.AspNet.Razor.Runtime.TagHelpers isim alanı altındaki TagHelper sınıfından türeteceğimiz sınıflar vasıtasıyla kendi etiket yardımcımızı geliştirebiliyoruz. Sınıfın public özellikleri view'da kullanacağımız elemanın attibutelarına karşılık geliyor. Process metodu içerisinde ise sayfamız istemciye gönderilirken nasıl render edilmesini istiyorsak öyle HTML elemanları tanımlayarak çıktımızı üretebiliriz.

Örneğin aşağıdaki Bootstrap input group örneğini ele alalım. 

<div class="input-group">
    <input type="text" class="form-control" placeholder="Recipient's username" aria-describedby="basic-addon2">
    <span class="input-group-addon" id="basic-addon2">@@example.com</span>
</div>

 Bu kod bloğunu, tekrar kullanılabilir bir etiket yardımcısına aşağıdaki gibi çevirebiliriz. InputGroupTagHelper sınıfının Id ve Domain özelliklerine dikkat edin. Bunları daha sonra view dosyamızda attribute olarak kullanacağız.

public class InputGroupTagHelper : TagHelper
{
	public string Id { set; get; }

	public string Domain { set; get; }

	public override void Process(TagHelperContext context, TagHelperOutput output)
	{
		// Outer Tag : 
		output.TagName = "div";
		output.Attributes.Add("class", "input-group");

		// Inner Input : 
		var name = new TagBuilder("input");
		name.MergeAttribute("type", "text");
		name.MergeAttribute("class", "form-control");
		name.MergeAttribute("placeholder", "Recipient's username");
		name.MergeAttribute("aria-describedby", this.Id);

		// Span : 
		var span = new TagBuilder("span");
		span.MergeAttribute("class", "input-group-addon");
		span.MergeAttribute("id", this.Id);
		span.InnerHtml = this.Domain;
		
		output.Content.SetContent(name.ToString() + span.ToString());
	}
}

Tanımladığımız etiket yardımcısını view dosyasında aşağıdaki gibi kullanabiliriz : 

@addTagHelper "*, ASP_NET_5_TagHelpers"

<input-group id="basic-addon2" domain="@@gmail.com"></input-group>
 

 

 

Sonuç

Bu yazımda ASP.NET 5 ile gelen tag helpers - etiket yardımcılarını incelemeye çalıştık. Şuan ASP.NET 5 Beta versiyonu olduğu için kod örneklerinde eklemeler ve çıkarmalar olabilir. Hatta bazı HTML elemanlarında varsayılan etiket yardımcılarının istenen şekilde çalışmadığını gördüm. Final sürümünde daha stabil olacaktır. Yazımda bahsettiğim örneklere aşağıdaki github linkinden ulaşabilirsiniz.

ASP.NET 5 TagHelpers Örnekleri

 

asp.net , , ,

ASP.NET5 ile DNVM, DNX ve DNU

16. Ağustos 2015

ASP.NET 5 ile yeni gelen özellikleri incelemek için Visual Studio 2015'te bir proje açtığımızda ilk karşılaştığımız yenilik farkında olalım veya olmayalım DNX, DNVM ve DNU oluyor. VS.NET 2015 bu araçları çalışma anında kullandığı için bize günlük hayatımızda bu araçları manuel olarak kullanma şansımız belki hiç olmayacak. Projemizi VS.NET ile açtığımız anda VS.NET ilk olarak yeni global.json ve project.json dosyalarını okuyup projemizin derleneceği ve çalışacağı ortamı bu ayarlara göre hazırlıyor. Biraz daha detaya inip bu kavramların ne olduğunu incelemeye çalışalım. Öncelikle  bu araçların aslında ASP.NET vNEXT ile açıklanan klr, kpm ve kvm araçlarının ASP.NET5 versiyonu için hazırlanan ve yeniden adlandırılan versiyonları. Aşağıdaki tabloda yapılan değişiklikler listeleniyor.

 

.NET Çalışma Ortamı (.NET Execution Environment DNX)

.NET uygulamalarını Windows, Linux ve Mac ortamlarında derleyebilmek ve çalıştırabilmek için gerekli bileşenleri ve araçları içeren SDK'lara DNX yani .NET Çalışma Ortamı diyoruz. ASP.NET 5 Projemiz içerisinde bulunan global.json dosyası içerisindeki version parametresi ile projemizin VS tarafından hangi SDK ile açılacağını ve build edileceğini belirliyoruz. Bu ayarı değiştirdiğimiz takdirde VS'yu restart etmemiz gerekiyor.

 

.NET Versiyon Yöneticisi (.NET Version Manager DNVM)

DNX kısaltması ile anılan .NET Çalışma Ortamlarının (.NET Execution Environment) yüklenmesi, güncellenmesi ve çalışması istenen ortamın belirlenmesini sağlayan komut satırı aracıdır. Komut satırına dnvm yazılarak araç çalıştırılabilir. Aşağıdaki gibi komut opsiyonlarının listelendiği bir ekran bizi karşılayacaktır. 

 

list komutu ile sistemde yüklü DNX'leri listeleyebilir, hangisinin aktif DNX olduğunu görebiliriz. upgrade komutu ile stabil kaynaktan son dnx versiyonu indirilebilir. 

List komutu çıktısında Versiyon olarak DNX versiyonunu, runtime başlığı altında framework versiyonu listeleniyor. .NET Framework, .NET Core ve Mono. 

Ya da özellikle belli versiyondaki bir DNX'i yüklemek istiyorsak install komutu ile vereceğimiz versiyonu stabil kaynaktan indirip kurabiliriz.

.NET Geliştirme Aracı (.NET Development Utility DNU)

.NET Geliştirme Aracı, yani DNU ise ASP.NET 5 projemizi derlerken bağımlı olduğumuz kütüphane paketlerini yöneten ve projemizi yayınlayan yardımcı uygulama. Projemiz içerisinde bağımlı olduğumuz kütüphaneleri topladığımız project.json dosyasına göre proje bağımlılıklarını yöneten DNU'nun çıktısını yine output penceresinden aşağıdaki gibi izleyebiliriz.

 

Sonuç olarak ASP.NET 5 ile projemizi derleyip kurulum yapacağımız ortama uygun paketlenmesini kolaylaştıran DNX, DNVM ve DNU'u incelemeye çalıştık. Bulut mimarinin ve Microsoft Azure'un çok önplanda olduğu günümüzde bu gelişmeler elbette kaçınılmazdı. Siz de benim gibi dnx version failed to install gibi bir hata ile karşılaştıysanız linki takip ederek çözüm uygulayabilirsiniz.

, , ,

"DNX SDK version 'dnx-clr-win-x86.1.0.0-beta5' failed to install" hatası ve çözümü

9. Ağustos 2015

Visual Studio 2015 ile ASP.NET 5'e gelen yeni özellikleri incelemek üzere ilk ASP.NET 5 projenizi açtığınız ve derleyip çalıştırmaya çalıştığınız anda tüm hevesinizi söndüren bu hatanın temelinde aslında .NET Framework'e gelen yeni bir özellik sebep oluyor.

 

DNX SDK version 'dnx-clr-win-x86.1.0.0-beta5' failed to install.

The solution will use DNX SDK version ‘dnx-clr-win-x86.1.0.0-beta5’ for this session.

 

Bu hata, .NET Framework Version Manager tarafından yüklenmeye çalışılan, ASP.NET 5'i içeren .NET Execution Environment (DNX) SDK'sının yüklenmesi sırasında alınan bir hata. Sebebi Windows 7'de Powershell 3.0 versiyonunun kurulu olmamasından kaynaklı. Bu hata ile ilgili detaylar Microsoft destek sayfasında mevcut.

PowerShell'in hangi versiyonuna sahip olduğumuzu görmek için powershell komut satırına aşağıdaki komutu yazıp görebiliriz.

$PSVersionTable

PowerShell 3.0 versiyonunu kurmak için Microsoft'un PowerShell 3.0 Download sayfasından güncellemeyi indirip kurulumu yaptıktan sonra komut satırında şunu görüyor olmalıyız : 

PowerShell'i 3.0 veya daha üst versiyona yükselttikten sonra projeyi yeniden açıp ve derleyince işlemin biraz uzun sürdüğünü ve output penceresini açarsanız ASP.NET 5'i kullanabilmek için ihtiyaç duyduğumuz DNX versiyonunun indirilip yüklendiğini göreceksiniz.

Komut satırını açıp dnvm list komutu ile makinanızda kurulu DNX versiyonlarını listelerseniz aşağıdakine benzer bir çıktı ile karşılaşırız. Dilersek yine dnvm komutlarını kullanarak ihtiyacınız olan DNX versiyonlarını makinamıza kurabiliriz.

 

, , ,

Site İçeriğini GZip İle Sıkıştırarak Site Performansını Arttırmak

23. Şubat 2014

Günümüzde web uygulaması geliştirirken, web uygulamasının hızlı açılması dikkate edilmesi gereken en önemli kriterlerden biridir. Anasayfanın bir kaç saniye geç açılması binlerce potansiyel ziyaretçinin rakip uygulamalara gitmesine sebep olabilir. Hızlı gelen içeriği ziyaretçilerin sevdiği kadar arama motorları da sever. Bir web uygulamasının yavaş çalışmasına pek çok sebep var iken, her bir sebebe göre ayrı çözümler vardır. Bu yazımda bu sebeplerden biri olan yoğun içeriğe dikkat çekmeye çalışarak çözüm yöntemi olarak GZip üzerinde durmaya çalışacağım.

GZip ile Sıkıştırılmamış Bir Site

Büyük bir dosyayı bir e-postaya ekleyeceğimiz zaman alacağımız ilk aksiyonlardan biri dosyayı sıkıştırmak olacağı gibi, yoğun içerikli bir siteyi de ziyaretçilerimize sunacağımız zaman da aynı aksiyonu almalıyız. Sıkıştırılmış bir dosyayı e-postamıza eklemek bizim bandwidth ve zamanımızdan tasarruf sağladığı gibi aynı zamanda alıcının da dosyayı indirme zamanı düşeceğinden onun da zamanını ve bandwidth'ini tasrarruflu kullanmış oluruz. Aynı mantık web uygulamamız için de geçerli. İçeriğin sıkıştırılması ile hem sunucu kaynaklarını hem de ziyaretçilerimizin kaynaklarını tasarruflu kullanarak her iki tarafın da kazanmasını sağlıyoruz.

checkgzipcompression.com gibi bir site'de GZip ile ziplanmamiş bir siteyi incelersek, sitenin sıkıştırılmamış hali ile neler kaçırdığımızı rahatça görebiliriz. Aşağıdaki örneğimizde sitemiz %80 oranında sıkıştırılabilecek iken hiç bir aksiyon alınmadığını görüyoruz.

Aynı siteyi Google Chrome Geliştirici araçları ile inceleyelim. F12'ye basark geliştirici araçlarını açıp Network tabına gelip Response altındaki sunucu başlıklarını incelersek siteminizin içeriğinin boyutu ve sıkıştırılma kullanılıp kullanılmadığını görebiliriz. Şayet sunucu içeriği sıkıştırmış olsaydı, burada Content-Encoding diye bir başlık görecektik. Site ziyaretçisi olarak kullandığımız tarayıcılar ziyeret ettiğimiz siteye bir talep gönderdiklerinde site içeriğini nasıl kabul edebilecekleri konusunda bazı bilgileri header bilgileri ile gönderirler. Accept-encoding header'ı ile tarayıcılar hangi sıkıştırma formatlarını (gzip, deflate gibi) kabul edebildiklerini sunucuya gönderirler. Sunucu bu header bilgisine göre eğer sıkıştırma formatlarından biri aktif ise içeriği sıkıştırarak ziyaretçiye gönderir. 

 

GZip İle Sıkıştırılmış Bir Site

Ziyaretçinin tarayıcısının sıkıştırma formatlarını kabul etmesi durumunda web sunucusu içeriği, tanımı yapılmış bir formatta sıkıştırıp ziyaretçiye gönderir. Ziyaretçinin tarayıcısı sıkıştırılmış içeriği açarak render eder. GZip sıkıştırılmış bir siteyi checkgzipcompression.com da incelersek aşağıdaki gibi yüksek oranda bir sıkıştırma ortalaması ile karşılaşabiliriz. HTML, kendini tekrar eden bir çok etiketten oluşan bir markup dili olduğu için sıkıştırma algoritmaları HTML üzerinde çok başarılı sonuç vermektedir.

Şayet Google developer tools ile aynı siteyi incelersek sıkıştırılmış içeriğin ve sıkıştırma formatının tarayıcıya nasıl bildirildiği konusunda fikir sahibi olabiliriz : 

 

IIS üzerinde GZip İçerik Sıkıştırma Formatının Açılması

Şuana kadar sıkıştırma formatlarının nasıl işlediğini, tarayıcı ile web sunucusunun uygun format üzerinde nasıl anlaştığını anlatmaya çalıştım. Peki GZip sıkıştırma formatını web sunucumuz üzerinde aktif hale getirmek için ne yapmalıyız ?

IIS üzerinde sitemizi bulup seçtiğimiz takdirde sitemiz ile alakalı pek çok ayara sağ taraftaki panelden erişebiliyoruz. Bu konfigurasyon ayarları arasında Sıkıştırma / Compression'ı seçersek yukarıdaki gibi bir ekran ile karşılaşırız. Bu iki ayarı açmamız halinde sitemizde sıkıştırma formatlarını aktif hale getirmiş oluyoruz.

Peki Web sunucumuzun IIS'ine direk erişimimiz yok ise sıkıştırma formatlarını nasıl aktif hale getiririz ? Bu sorunun ve pek çok konfigurasyon sorusunun çözümü web.config dosyasında saklı. <system.webServer> etiketi altında tanımlayacağımız urlCompression etiketi sayesinde IIS'e direk erişmeden sıkıştırma formatlarını aktif hale getirebiliriz : 

<system.webServer>

    <urlCompression doStaticCompression="true" doDynamicCompression="true" />

</system.webServer>

Ufak bir ayar ile içeriğimizde %70-80 oranında sıkıştırma sağlayarak bandwidth tasarrufu sağlayan sıkıştırma ayarları ile web uygulamalarımızı daha hızlı hale getirebiliriz. Her talepte içerik yeniden sıkıştırıldığı için sunucunun CPU kaynağı kullanılıyor. Bu sebepten de paylaşımlı sitelerde default ayarda kapalı olan sıkıştırma formatları çok büyük boyutta dinamik içeriğe sahip sitelerde tavsiye edilmiyor. 50 KB - 100KB arası büyüklüğe sahip içerikler için en iyi sonucu verdiği belirtiliyor.

, ,

IBundleOrderer İle Bundle İçerisindeki Dosyaların Sıralanması

28. Ocak 2013

Geçtiğimiz haftalarda incelediğim Bundling ve Minification yazısında bir dizin içerisindeki kaynak dosyalarımızı joker karakterler ile bir bundle haline getirip sayfamıza ekleyebileceğimizden bahsetmiştik. Bu dizin içerisindeki tüm dosyalar alfabetik sırada bundle içerisinde işlenir ve referans olarak verilen yerlerde bu sıralamada istemciye sunulur. Çoğu zaman bu tercih edilen bir durum değildir. Bazı temel script dosyalarımızın sayfamızda öncelikli olarak referans verilmesini isteriz. Bu temel script dosyalarını kullanan diğer script dosyalarımız ise sonrasında sayfamıza eklenir. İşte bu kurduğumuz hiyerarşik yapıyı oluşturacağımız bundle'lar içerisinde de yapabilmemiz için ya dosya isimlerini alfabetik olarak yarattığımız hiyerarşiye uyacak şekilde hazırlamamız gerekir ya da IBundleOrderer kullanarak bundle içerisindeki dosyalarımızı sıralayacak bir mekanizma oluşturabiliriz. 

Bu yazımda IBundleOrderer interface'ini inceleyerek, basit bir örnek ile bundle içerisindeki script dosyalarımızın hiyerarşisini web.config dosyası içerisinde tanımlayacağımız bir parametre ile yönetmeyi deneyeceğiz.

 

IBundleOrderer interface'i ve Bundle içerisindeki dosyaların sıralanması

Uygulamamız içerisinde oluşturduğumuz Bundle'ların özellikleri arasında Orderer adında bir özellik ile Bundle'ımıza dosyalarını sıralayabileceğimiz bir IBundleOrderer interface'ini uygulayan bir sınıf verebiliyoruz.

Bundle myBundle = new Bundle("~/bundles/SiteScripts", new JsMinify());
myBundle.IncludeDirectory("~/Scripts/SiteScripts", "*.js");
myBundle.Orderer = new MyBundleOrderer();
bundles.Add(myBundle);

Eğer IBundleOrderer interface'ine gözatarsak eğer OrderFiles metodu ile bundle içerisindeki dosyaları sıralayacak bir metod içeren bir interface olduğunu görüyoruz. Bundle oluşturulurken içerisindeki dosyaları parametre olarak gönderip, dönüş parametresi olarak da sıralanmış dosyaların listesini içeren bir kolleksiyon bekleniyor  : 

namespace System.Web.Optimization
{
    public interface IBundleOrderer
    {
        IEnumerable<System.IO.FileInfo> OrderFiles(BundleContext context, 
                                                IEnumerable<System.IO.FileInfo> files);
    }
}

Şimdi yukarıdaki örneğimizde kullandığımız ve IBundleOrderer interface'ini uygulayan sınıfımıza gelecek olursak : 

public class MyBundleOrderer : IBundleOrderer
    {
        public IEnumerable<System.IO.FileInfo> OrderFiles(BundleContext context, IEnumerable<FileInfo> files)
        {
            if (ConfigurationManager.AppSettings["HighPriorityScripts"] != null)
            {
                string[] highPriorityScripts = ConfigurationManager.AppSettings["HighPriorityScripts"].Split(',');
                List<FileInfo> listFiles = new List<FileInfo>(files);
                List<FileInfo> orderedFiles = new List<FileInfo>();

                foreach (string highPriorityFile in highPriorityScripts)
                {
                    FileInfo nextFileInfo = listFiles.Find(delegate(FileInfo arg) 
                                    {
                                        return arg.Name == highPriorityFile;
                                    }
                                  );
                    if (nextFileInfo != null)
                    {
                        orderedFiles.Add(nextFileInfo);
                    }
                }

                foreach (FileInfo lowPriorityFile in listFiles)
                {
                    if (!orderedFiles.Contains(lowPriorityFile))
                    {
                        orderedFiles.Add(lowPriorityFile);
                    }
                }

                return orderedFiles;
            }

            return files;
        }
    }
 
<!-- Virgülle ayrılmış script dosyaları -->
<add key="HighPriorityScripts" value="Z_HighPriorityScript.js,SmallJSFile.js" />

 

MyBundleOrderer sınıfı web.config'de yukarıdaki gibi tanımlayacağımız HighPriorityScripts parametresini alıp, öncelik verilecek script dosyalarını belirleyip dönüş yapılacak listeye öncelikli olarak bu dosyaları ekliyor. Sonrasında geriye kalan dosyalar dönüş listesine ekleniyor ve oluşturulan sıralı liste dönülüyor. Böylece bundle'ımız içerisindeki dosyalarımızı web.config dosyasındaki parametremiz ile önceliklendirerek yönetebilir hale gelmiş oluyoruz.

, , ,