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

Geçtiğimiz yıllarda Visual Studio‘nun online versiyonu; yani internet üzerinden, internet tarayıcılar üzerinden kullanabileceğimiz bir versiyonu üzerinde çalışıldığı duyurulmuştu. Artık her şeyin cloud tabanlı çözümlere evirilmesi, geliştirme yöntemlerinin de cloud’a evirilmesi ortaya çıkarıyordu. Birçok farklı yazılım geliştirme yöntemleri ve araçları da aslında var(dı). Herhangi bir bilgisayar üzerinden sadece internet bağlantısı ile tarayıcılar üzerinden yazılım geliştirebiliyoruz, yani kısmen… Microsoft bu olayı biraz daha öne taşımak için bir adım attı ve Visual Studio Online‘ı, açık ön izleme (public preview) şeklinde duyurdu. Duyduğum an hemen bir ön izleme de ben yapmak istedim.

“Visual Studio Online” vs. “Visual Studio Code”

Visual Studio Code(VS Code) ile haşır neşir olanlar için Visual Studio Online(VSO) farklı bir editör olarak gelmeyecektir, -ki zaten farklı da değil. Bildiğiniz üzere VS Code, Electron tabanlı (node.js, JavaScript) bir text-editor… Microsoft’un dokunmasıyla ortaya çıkan Monaco Editor ile Visual Studio Code şeklinde kullanıyoruz. Electron vs JS tabanlı olması, gerçek anlamda platform bağımsız bir çözüm olmasının en büyük özelliği. Bu sayede de internet tarayıcılar üzerinden de kolaylıkla çalışabiliyor. Özetle VSO ile VS Code üzerinde yapabildiğimiz birçok geliştirmeyi yapabiliyoruz. VS Code’un birçok özelliğini de kullanabiliyoruz. VS Code eklentileri, Live Share, Debug, Git…. gibi gibi birçok özelliği internet üzerinden tarayıcı ile kullanabiliyoruz…😉

Bütün bunlar aslında bir sanal makina üzerinde oluyor. Azure üzerinde yarattığımız bir “Instance” ile fiziksel geliştirme ortamımız oluşuyor. Ama bu ortama tabi ki ulaşmamız mümkün değil. “Sanal makina”, “Azure” diyince tahmin ettiğiniz gibi VSO ücretsiz değil… Azure üzerinde çeşitli kaynakları tükketiğimiz için, bu kaynak kullanımlarına göre çeşitli bir ücretlendirme politikası var. Ücretsiz değil yani; ama makul. Daha ön izleme dönemi olduğu için bu olaylar değişecek, farklı opsiyonlarda gelecektir diye düşünüyorum.

Geliştirme ortamı oluştururken, ilk aşamada 4-core, 8GB Ram ve 8-core, 16GB Ram şeklinde iki opsiyon var. Bu iki opsiyonda Linux işletim sistemi ile sunuluyor. Bu iki opsiyona göre ücretlendirme çeşitleniyor tabi ki. Burada “Suspend” şeklinde önemli bir özellik var. Geliştirme ortamı belli bir süre “idle” olarak kalırsa, otomatik olarak “suspend” duruma geçsin diye ayarlanabiliyor.

Yukarda da bahsettiğim gibi temel olarak VS Code ile yapabildiğimiz tüm geliştirme tecrübelerini VSO ile de gerçekleştirebiliyoruz. Temelinde bir text-editor olduğu için birçok yazılım dilini yazmak mümkün. Daha yoğun bir şekilde .NET Core ile uğraştığım için, ilk olarak hemen basit bir .NET Core konsol projesi denedim.

Bakalım nasıl oldu?

Terminalden direkt dotnet new console komutu ile bir konsol uygulaması yaratmak oldukça basit. Linux tabanlı bir geliştirme ortamı olduğu için, terminalden standart Linux komutlarını çalıştırmak ve bir geliştirme ortamında nelere, nasıl ihtiyacınız varsa yapmak mümkün.

Bu arada VSO’da default olarak gelen .NET Core versiyonu 2.1.x ama şimdilik 😉

Malum VS Code sadece text-editor olduğu için daha sağlıklı bir geliştirme tecrübesi için bazı eklentiler gerekli olabiliyor, VSO tarafında da aynı olduğu için C# eklentisini kurarak, IntelliSense, Highlight gibi olmazsa olmaz bazı özellikleri VSO’da da çok rahat bir şekilde kullabiliyoruz.

Debug adımı bir yazılım geliştirme sürecinin olmazsa olmaz adımı olduğu için, herhangi bir geliştirme ortamında Debug yapabiliyor olmak en önemli adım. VSO’da da Debug yapabiliyoruz… VSO ilk duyurulduğunda ilk aklıma gelen ihtiyaç bu olmuştu. Standart bir breakpoint koyduktan sonra kodu Debug edebiliyoruz.

Standart olarak F10, F10, F11… ve F5. 😀

VS Code’daki debug deneyimi aynen internet tarayıcısı üzerinden de yapılabiliyoruz. Tabi şimdi deneyimlediğimiz proje basit bir konsol projesi, “Hello World” diyoruz o kadar… Peki ya biraz daha kompleks proje tipleri? İnternet tarayıcıda, bir web uygulaması geliştirebiliyor muyuz? 🤔

Açıkcası bunun için hiçbir engel yok. dotnet new razor şeklinde basit bir ASP.NET Core uygulaması oluşturup, teknik olarak debug yapabiliyoruz(?) ya da çalıştırabiliyoruz(?) yani kısmen… VSO’da bir web uygulaması geliştirip, çalıştırdığımız zaman ilgili port’ları geliştirme ortamımız için yönlendirip, erişebilir bir duruma getirebiliyoruz. Açıkcası ilk çalıştırdığım zaman ulaşabildim ancak sonraki denemelerimde çözemediğim bir şekilde olmadı. Preview diye çok üzerinde durmadım ama özetle web geliştirmelerini VSO üzerinden yapmak ve çalıştırmak mümkün.

Özetle temel geliştirme ihtiyaçlarını çok rahat ve sorunsuz bir şekilde gerçekleştirebiliyoruz diyebilirim. Benzer şekilde Python, JavaScript vs. gibi farklı dillerde kodlar yazmak mümkün. VS Code eklentileri ile geliştirme ortamınızı da ciddi bir şekilde güçlendirmek mümkün. Azure eklentileri, Google eklentileri vs. ile geliştirilen projeleri çok hızlı bir şekilde yayına almak oldukça kolay. Geliştirme ortamlarının olmazsa olmazı Git, geliştirme ortamlarının özelleştirilmesi vs. gibi birçok VS Code özelliğini direkt internet tarayıcısı üzerinden kullanabiliyoruz.

Visual Studio Online, çok yakın zamanda değil belki ama orta ve uzun vadede geliştirme alışkanlıklarına ve cihazlarına ciddi anlamda yön verebilecek bir gelişme diye düşünüyorum, bu yüzden kısa bir giriş ile biraz merak uyandırıp ilginizi çekmek istedim. Mutlaka bir ara göz atın ve kullanmaya başlayın derim…

Komut satırı uygulama modeli(console/terminal) her yazılımcının oldukça aşina olduğu bir yazılım modelidir sanırım. Yazılım ile uğraşan herkesin bir şekilde belki de başlangıç noktası… Basit bir “Hello World” çıktısını konsola yazdırmak çeşitli yazılım dillerini öğrenmek için olmazsa olmaz 🙂

node –help

Son kullanıcı ihtiyaçları açısından ve kullanıcı etkileşimi açısından artık çok tercih edilmese de, basit ve hızlı bazı görevlerin gerçekleştirilmesinde tercih ediyoruz hala. Geliştiricilerin, belli “proof of concept” çalışmaları, denemeleri ve geliştirme araçlarının çeşitli özellikleri açısından daha aşina olduğu bir model. Konsol ya da terminallere yazdığımız komutlarla bir çok uygulama ile bir çok temel işlemi yapabiliyoruz. Eminim bir çoğumuzun oldukça aşina olduğu bazı araçların, konsollarda çalıştırdığımız komut satırı fonksiyonları gündelik hayatımızın bir parçasıdır.

dotnet build –help

Bu basit girişten sonra çok da uzatmadan gelelim konumuza…

Bir çok geliştirme araçının komut satırı komutlarının çıktılarının benzerliği ya da bazı komutların standart olması dikkatinizi çektmiştir sanırım. Bir çok uygulamanın komut satırı arayüzlerinde(command-line interface, CLI) –help, –info komutlarının standart olması gibi.

Command Line API

.NET Core ile birlikte bir çok API ya da kütüphane de ortaya çıkıyor, ve bu kütüphaneler bir çok temel işlemi kolayca gerçekleştirmemizi sağlıyor. Bunlardan biri de Command Line API ve System.CommandLine… Bu API ile yukarıda bahsetmiş olduğum konsol uygulamalarının ya da komut satırı uygulamalarının temel işlemleri çok daha kolay bir şekilde yapabiliyoruz.

Şimdi küçük bir uygulama ile Command Line API’ı biraz daha yakından tanıyalım. Bu API’ın temel sınıfı CommandLineBuilder, bütün olay bu sınıf çevresinde dönüyor. Adından da anlaşılacağı gibi komut satırı akışımızı bu sınıf ile hallediyoruz. Basit bir şekilde aşağıdaki gibi bir Main() metodumuz olsun.

    class Program
    {
        private static Task<int> Main(string[] args)
        {
            ReportCommand rcmd = new ReportCommand("report");
            PrintCommand pcmd = new PrintCommand("print");

            Parser parser = new CommandLineBuilder(new Command("konsol"))
                .AddCommand(rcmd)
                .AddCommand(pcmd)
                .UseHelp()
                .UseDefaults()
                .Build();

            return parser.InvokeAsync(args);
        }
    }

Bu senaryo için ReportCommand ve PrintCommand diye, report ve print adıyla iki örnek komut oluşturdum(birazdan ayrıntılarına gireceğim) ve bu komutları CommandLineBuilder()’a konsol adı altında çalıştırılacak komutlar olarak ekliyoruz.

Kütüphanenin sağladığı bazı kolaylıkları da CommandLineBuilder() ile birleştirip uygulamamızı hazır hale getiriyoruz.

dotnet run -- --help 
dotnet run -- --version

yazarak projemizi çalıştırdığımız zaman aşağıdaki gibi bir çıktı karşımıza çıkacak. Dikkat ederseniz ki bu çıktıyı oluşturmak için herhangi bir Console.WriteLine() şeklinde kod yazmadık.

Bu help çıktısı, bize 2 tane komutun(report,print) olduğunu, bu ikisinin de bir tane argüman aldığını söylüyor.Şimdi de report komutu için olan help kısmına bakalım.

dotnet run — report –help

Bu çıktıya göre de report komutunun argüman olarak alabileceği seçenekleri ve option olarak -pid ya da –product-id adıyla bir değer alabileceğini görüyoruz.

Biraz daha netleşmesi için yukarda birazdan ayrıntılarına gireceğim dediğim komutlardan ReportCommand sınıfına bakalım. Bu System.CommandLine kütüphanesini kullanarak bizim yazdığımız özel bir sınıf. System.CommandLine API amacı daha güvenilir ve gerçekten amaça yönelik fonksiyonlara odaklanmak olduğu için, gerçekten ne yapmak istiyorsak onu yazıp, bu kütüphanenin özellikleri ile de çıktıları üretebiliyoruz. Neyse biz ReportCommand’a dönelim.

Read More

Sigur

/ Leave a comment /~ 2 dakikada okuyabilirsiniz.

9 senedir bana hayat arkadaşı olan tüylü bir yaratık var hayatımda. Kimileri kedi diyor ama ben Sigur diyorum ona, kedi değil yani. Nevi şahsına münhasır bir yaratık…

9 senedir benim hayatımdaydı, ben hayatta olduğum sürece de hayatımda olacak bir şekilde. Ama ben, onun adına için aynı şeyi söylemeyeceğim sanırım. Haber vermeden sonsuzluğa doğru gitti. Haber verdi ama yediremediğim için kabullenmedim belki, bilemeyeceğim sanırım.

Çok koydu gitmesi… “Kodum mu oturturum” denir ya; harbi oturttu. Kaldım öyle. Bilfiil 9 sene hayatımda çok büyük yere sahipti. Dostum, sırdaşım olmuştu. Bana bakışları ile anlatıyordu her şeyi; hayatta anlamadığım, kafamın basmadığı konuları sakin sakin anlatıyordu. Benim de bakışlarımdan anlıyordu beni. Sinir olduğum durumlar karşısında sakinleştiriyordu. Hissettiklerimi anlayıp hemen arka da çıkıyordu. Espri yeteneği de şahaneydi, güldürüp mutlu ediyordu hep. Ama sadece bana yapıyordu bunları… Gizli bir amacı var gibiydi. Asla bilemeyeceğiz sanırım. Arada klasik kedi atraksiyonları ile herkese şirin gözükmeye çalışıyor, kedi gibi ses çıkartıp (gerçi tam beceremiyordu) kimliğini gizliyordu galiba. “Bakışları garip bir kedi” dediklerinde bana dönüp göz kırpıyordu, “Merak etme kimse anlamaz, mıyevvv” diyordu…

Bir şekilde oturttuğu yerden ayağa kalkıp yola devam edeceğim. Gitmeden önce bana bıraktığı mutluluklar, anılar ve tabi ki tüyler yolda erzak olarak bana eşlik edecek. Yaşamda, hayatımıza giren her canlının bir rolü var derler ya; sanırım doğru. O rolünü çok güzel oynadı, hissettirdiği duygular ile çok şey kattı hayatıma. Ben de umarım ona karşı olan rolümde başarılı olabilmişimdir.

Sigur;

Bana yaşattığın her hissiyat, her tecrübe için çok ama çok teşekkür ederim. Kattığın mutluluk, sevgi, hüzün, komiklikler, kahkahalar, göz yaşları için ayağa kalkıp, önümü ilikleyip, alkışlıyorum seni Sigur… Hepsi çok güzel ve çok özeldi. Sadece bana da katmadın, hayatımda olan birçok kişiye de dokundun sanırım. Herkesi bir şekilde mutlu ettin. Teşekkür ederim…

Umarım beni mutlu ettiğin kadar ben de seni mutlu ve huzurlu hissettirebilmişimdir bu dünyada. Gittiğin yerde huzurlu ve mutlu olacağına eminim. Beyefendiliğin ile oralarda da çok sevilecek ve mutlu olacaksın, adım gibi biliyorum.

Hoşça kal…

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

Read More

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

Read More

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

Read More

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.

Read More