Arda Çetinkaya Yazılım ve arada kendim ile ilgili karaladıklarım…

Bir önceki yazıda Blazor ve ASP.NET Core ile ilgili bir şeyler karalamıştım. Blazor’ın ne olduğu, ASP.NET Core ile ilişkisi ve son durumunu özetlemeye çalışmıştım. Şimdi daha çok kod üzerinden biraz daha neler oluyor bakalım. Hem daha iyi anlaşılmasını sağlar belki, hem de kurcalamak, öğrenmek ve ilerleyen zamanlarda çözümler içerisinde katmak için heyecanlandırır belki de.

Yazıda paylaşacağım örnekler; .NET Core 3.0 Preview 4 ve Visual Studio 2019 üzerinde olacak. Deneyimlemek istiyorsanız bu versiyonları yüklemeniz daha sağlıklı olacaktır. Tabi ki Visual Studio Code da olur.

Öncelikle yeni bir ASP.NET Core Web projesi yarattığımızda, proje şablonu olarak Blazor(server-side)‘ı göreceğiz. Önceki versiyonlarda Razor Components‘dı… Bu proje şablonunu seçtiğimizde yandaki gibi bir proje yapısı oluşacaktır.

İlk defa deneyimleyecekler için *.razor uzantılı dosyalar dikkat çekecektir. Onlara direkt gelmeden önce, ilk olarak, standart ASP.NET Core uygulamalarındaki Startup.cs dosyasının içine bakalım. Bu arada bu yazıda bahsedeceğim konular Blazor(server-side) hosting modeli ile ilgili olacak.

Startup.cs

Herhangi bir ASP.NET Core Web uygulaması (MVC, Razor, Web API…) ile uğraştıysanız çok farklı bir şey görmeyeceksiniz aslında. Önemli olan kısımlar; ConfigureServices() kısmındaki .AddServerSideBlazor(); ve Configure() kısmındaki .MapBlazorHub();

.AddServerSideBlazor(); adından da çok net anlaşılacağı üzere Blazor’ın çalışma servislerinin uygulamamıza eklenmesini sağlıyor. Preview 3‘de AddRazorComponents olan metot Preview 4 ile asıl ismine kavuştu 😊 Bu satırı eklemeden Blazor uygulama modelini kullanmamız mümkün değil.

.MapBlazorHub(); da, Blazor’ın server-side modeli için tarayıcıdaki UI bileşenlerinin ASP.NET Core uygulaması ile SignalR üzerinden iletişim kurması için Hub oluşmasını sağlıyor.

Şimdi sıra geldi _Host.cshtml dosyamıza. Bu dosya uygulamanın statik olarak ilk oluşturulan içeriği diye düşünebilirsiniz. Zaten içeriğine baktığınızda çok tanıdık HTML içeriğini görüp, “aaaa bu mu, bildiğimiz HTML” diyeceksiniz. Ama burada önemli olan kısım RenderComponent()

Biraz daha derinlere inelim, ama çok değil. Blazor, temel olarak, bileşenler (components) ile oluşturulan küçük UI parçalarının çalışması/çalıştırılması üzerine ortaya çıkan bir uygulama modeli. Ön yüz tarafının parçalar halinde, bağımsız çalışması, kullanıcı etkileşimin ve UI durumlarının sağlıklı çalışmasını amaçlıyor. Angular, React…vs. tarzı diğer UI Framework’lerindeki gibi. Javascript(js) tabanlı UI Framework’lerine çok hâkim değilim ama onların da temel çıkış noktası, bileşen yani component kavramı…

Devam…

.NET Core 3 Preview 3 ile beraber, ASP.NET Core içindeki “Razor Components” kavramı ile tanışmıştık. Basitçe, istemci tarafında interaktif web ara yüzleri geliştirmek için yeni bir ön yüz(UI) modeli diye özetleyebilirim. Tarayıcıda(browser), yazdığımız C# kodlarının çalıştırılabilir olması temeline dayanan yeni bir yaklaşım(dı). -Dı diyorum çünkü biraz değişti…

Bu yazının çıkış noktası .NET Core 3.0 Preview 4‘ü indirmek için bu adresi ziyaret edebilirsiniz.

Değişiklik kısmına, biraz daha başa dönerek gideceğim, bu yüzden önce Blazor isminden biraz bahsetmem gerekecek. “Blazor”, Microsoft’un geliştirdiği bir ön yüz(UI) framework’ü. C#, Razor syntax‘ı ve HTML ile tarayıcılarda SPA(Single Page Application) modeli ile geliştirme yapmamızı sağlayan bir framework. C# kasları güçlü olup, javascript(JS) tarafında o kadar güçlü olmayan ve ASP.NET uygulama geliştirme modeline hakim olanlar için oldukça cazip bir framework diyebilirim. Daha iyi anlaşılması için biraz daha basite indirgeyip, C# kodlarının tarayıcılarda çalışmasını sağlayan bir framework olarak başlayabiliriz. JS ihtiyaçlarını C# ile yazabilmek gibi…

Temelinde Blazor, “Web Assembly(Wasm)” kavramının gücü ile olabilen, Wasm’nin tarayıcılarda binary olarak belli yapıların çalışabilmesi sağlaması yaklaşımından ortaya çıkan bir framework. Wasm’ın genel olarak daha yeteri kadar olgunlaşmaması ve kabul görmemesinden dolayı Blazor’da deneysel olarak paylaşılmıştı, daha çok yolumuz var bilinci ile geliştiriliyordu.

Devam…

.NET Core 3.0‘un RTM olarak yayınlanmasına yaklaşıyoruz. Büyük bir ihtimal Mayıs’taki Build etkinliğinde ya da ondan hemen sonra Haziran gibi yayınlanır diye düşünüyorum. Artık göreceğiz… Ciddi anlamda birçok yenilik ve performans iyileştirmeleri ile olgunlaşmaya devam ediyor. Bunlar dışında birçok değişiklik de v3.0’da karşımıza çıkıyor. Açıkçası yeni özelliklerden şu an çok bahsetmek istemiyorum hem kendi dokümantasyonları olsun hem internetteki birçok güzel kaynak olsun bunları takip etmek mümkün, -ki zaten üşenmiyor da değilim… 🙂 Şaka bir yana bir ara derleyip, toplamam lazım ki ben de günceliyim kendimi. Baya güzel özellikler geliyor çünkü. Neyse…

Malum .NET Core 3.0 ile beraber ASP.NET Core 3.0‘da yayınlanıyor. Orada da var güzellikler, ama dediğim gibi bu yeniliklerden de bahsetmeyeceğim(şimdi) daha çok değişikliklerden bahsetmeye çalışacağım. Çünkü ciddi anlamda önceki versiyonlarda(2.x) olan bazı temel özellikler değişiyor. Bu değişiklikler “breaking-changes” olarak adlandırabileceğimiz derecede, yani derlenebilen uygulamamızı .NET Core/ASP.NET Core 3.0’a yükselttiğimizde derlenemez hale gelebilmektedir, -duruma göre. Bunu hazırlık olsun diye, mevcut v2.2 projelerimizi preview versiyonlarını deneyimlerken yaşadığım için de ekstra paylaşmak istedim.

Shared Framework kullanımı değişiyor…


Şimdi biraz başa gidelim… .NET Core’un versiyon bazında tek başına çalışmasını sağlayan uygulama tipleri hayatımıza girmişti hatırlarsanız. Bunu sağlamak ve bazı geliştirmeler için kullandığımız tüm referansları tek bir çatı altında, aynı versiyonlar ile birleştirmek için ASP.NET tarafında Microsoft.AspNetCore.App şeklinde bir “package reference” proje dosyamızın içinde vardı, daha doğrusu olabiliyordu. Bu sayede aynı versiyon bileşenlerin kullanılması, versiyon karmaşıklığının olmaması sağlanıyordu.

Benzer şekilde bir de Microsoft.AspNetCore.All var. Bu da biraz daha kapsamlı olarak ek birkaç *.dll ile web uygulamalarında ihtiyacımız olabilecek referansları barındırıyordu. Bu sayede projemize ek bir referans eklemeden web projesinde olabilecek ihtiyaçları karşılayabiliyorduk. Microsoft.EntityFrameworkCore.Sqlite ya da Microsoft.Extensions.Configuration.AzureKeyVault gibi…

Devam…

Geleneksel(standart), iş hayatında olan herkesin bildiği yönetici(!!!) diye bir unvan var. Organizasyon ve kuruma göre içinin doluluk şekli doğal olarak çeşitlilik gösterir ama bir şekilde çoğunluğun ulaşmak istediği unvandır. Özellikle ülkemizde maddi bir karşılık olarak da konumlandırıldığı ya da algılandığı için, günümüz şartlarında iş hayatında yönetici(?) olmak bir hedef olarak düşünülebiliyor.

Uzun süredir yazılım sektörü insanıyım, daha çooook uzun sürelerde umarım böyle devam edecek. Diğer sektörleri profesyonel anlamda bilmiyorum ama yazılım hatta IT sektörünün birçok sektöre göre daha yeni ve çok hızlı değiştiğini, geliştiğini düşünüyorum. Diğer sektörlerdeki dijitalleşme ihtiyacı da bundan olsa gerek…

Yeni ve hızlı gelişen bir sektör olduğundan her iş hayatının temel parçası olan “insan” özelliklerinin, geleneksel iş hayatından biraz daha farklı olması gerekiyor. Yazılım sektöründe, iş hayatındaki temel yapıların; organizasyon kültürü, iletişim, yetkinlikler, unvan …vs. diğer iş sektörlerinden farklılaştığını görüyorum(z). Bunların her biri için ayrı ayrı, uzun uzun yazıp, konuşulabilir ama yazıya “yönetici” diye girdiğimden, unvanlar ile ilgili bir şeyler karalamak istiyorum. Hem profesyonel hayatımın bununla alakalı kısmı ile ilgili çok soru geliyor, hem de bulunduğum “geek” ortamlarda, bazen bu konular konuşulduğu için yazasım, düşüncelerimi paylaşım geldi.

Devam…

Çeviklik çağımızın gerektirdiği en önemli özelliklerden biri. Hızlı bir şekilde değişimlerin olduğu bir çağda, bu değişimlere aynı hızda uyum sağlayabilmek oldukça değerli. Ülkedeki IT sektöründe de son 6-7 senedir etkilerini ve çevikleşme ihtiyaçını yaşıyoruz. Bir çok küçük, orta, büyük ölçekli kurum “Agile” yaklaşımlar ile çeviklik kazanma içerisinde.

Ama açıkcası “Agile” yaklaşımları uygulama, çeviklik(Agility) kazanma son bir kaç yıldır düşündüğümden daha farklı bir yola giriyor. Kurumsal dünyanın da radarına daha sık girmesi bunun bir etkisi olabilir. Belli bir metodoloji ile sürdürebilirliği sağlayan kurumlar çevik metotlar ile tanışınca biraz bocalıyor gibi. Çevik metotlar birer kurallar kitabı olarak algılanıp, metotların uygulanma şekilleri de çok katı kurallar olarak yorumlanabiliyor. Bu kurallara uymak, uymaya çalışmak ihtiyaçlara çözüm sağlamaktan daha önemli bir hal alabiliyor. Bu kurallara(!) uyma derecesi ya da kural çıktıları başarı ölçümleri için birer kriter olabiliyor. Çözüm sağlanmıyor ama kuralların(!) çıktısı doğru(?) oluyorsa, çevik metot bir başarı olarak yorumlanabiliyor.

Bütün bunları çeviklik ve çevik metotlar ile ilgili düşündüğüm ve anladığım konular ile komple çelişen yanlışlar olarak görüyorum. Bunları, meslektaştalarım ile konuşmalarım, belli ortamlardaki gelen sorular ve tecrübelerim ile görüyorum, duyuyorum. Belki gerçekten de çeviklik böyle bir şeydir de, ben komple yanlış anlamışımdır. Ama gerçekten böyle yaklaşımlarsa sanırım bazı şeyleri yanlış yapıyoruz…

IT sektöründe çevik olmak, bir “spor yapmak” eylemi gibi. Düzenli bir şekilde spor yaptığımız zaman, kaslarımız daha esnek ve daha güçlü olur. Sadece kaslarımız değil, tüm vücut yapımız, hatta genel sağlımız belli gelişmeler içinde olur. Spor yapma alışkanlığımızı ne kadar sürdürürsek de kazandığımız bu özellikler o kadar gelişir, çevikliğimiz artar. Yaşam kalitemiz belli çerçevede artar. Ama spor yapmazsak da yaşarız, yine belli bir çerçevede yaşam kalitemiz olur. Sadece belli ihtiyaçlarımızda zaman zaman zorlanırız. Hayatın dinamikliğinde daha çok yorulabiliriz falan…

Bu durumun, IT dünyasında da, çevik metotlar için geçerli bir durum diye düşünüyorum. Eğer çevik metotları tercih edersek, sektörün bazı dinamikliklerine ve bu dinamikliklerin getirdiği değişimlere daha kaliteli çözümler sağlayabiliriz. Çevik metotları uygulamazsak da yine belli çerçevede çözümler sağlayabiliriz. Belki daha zor, belki daha kolay; bu iş modelinin dayandığı temel taşlara göre olan değişen bir durum. Bazı iş modelleri için çevik metotların katkısı daha çok olabilir, bazı iş modellerinde ise gerek olmayabilir, hatta yıkıcı etkisi olabilir.

Devam…