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

* Yazılım konusunda kendimi geliştirmek istiyorum, nereden başlamalıyım?
* Bilgisayar mühendisliği 2. sınıf öğrencisiyim, mobil uygulama yapmak istiyorum, nereden başlamalıyım?
* Programlama öğrenmek istiyorum, nereden başlamalıyım
* Üniversiteye yeni başladım turizm okuyorum ama bilgisayarlara ilgim var, yazılım öğrenmek istiyorum nereden başlamalıyım?

Hayatımın belli dönemlerinde bunlar gibi soruları çok alıyorum. Açıkcası cevaplamakta da en zorlandığım sorular bunlar oluyor. Bu dönem de benzer sorulara yine çok denk geldim ve önce kendime dönüp bu soruyu kendime sordum. Nereden başladım?

Önce kendime cevap verebilirsem belki etrafımdaki insanlara daha iyi yardımcı olabilirim. Yazılımla nasıl tanıştım, nasıl haşır neşir oldum kısaca üzerinden buradan da bir geçim ki, yıllar sonra okur okur eskiyi de tekrar tekrar anarım hem dedim.

Ortaokul dönemimde rock/metal 🤘 müzik dinlemeye başladım. Grupları, albümleri takip etmek zordu. Yazılı basın zaten yok gibiydi. Fanzinler ve düzensiz yayınlar ile takip etmeye yaşımızın yettiği kadar çalışıyorduk. İnternet ile yeni yeni tanışmaya başlıyordum. mIRC, ICQ falan derken internet ortamında bir dergi/fanzin yapmak istedim. Günümüzün havalı tabiri ile sanırım dergicilik kavramının dijitalleşmesi…

O zamanlar web sitesi yapmak için, Geocities herkesin ilk bulaştığı platformdu. Bazı sağladığı kolaylıklar ile statik HTML içerikler yaratmak ve düzenlemek oldukça kolaydı. HTML ve CSS ile tanışmam da bu vesile ile başlamış oldu. Albüm yorumları, grup tanıtımları, röportajlar falan derken içerik büyümeye başlamıştı. Album1.html, Album2.html, Roportaj1.html, Grup1.html…. falan filan. İçeriklerin artması, ergen tripleri ile sürekli görsellerin değişmesi, yeni düzenlemeler falan derken statik içerikleri kontrol etmek zorlaştı. Basit bir değişiklik için onlarca *.html dosyasında aynı değişikliği yapmak…Poffff.

Dinamik hale getirmek lazımdı ki, içerikleri yönetmek daha kolay olsun. ASP ve MS Access gibi şu an tarihin tozlu raflarında duran teknolojiler ile tanıştım. Kitaplar alıp, direkt oradaki kod örneklerini yazıp denemeler ile hızlıca bir şeyler çıkarmaya başladım. Açıkcası sadece resimlerine bakıp, dergi okumama yaklaşımı vardır ya; onun gibi. Sadece kodları yazıp, onları değiştirip, deneyerek istediğim şeyleri oluşturuyordum. Kodda if(true) ise, ben if(false) yapıp deniyordum. Hatalar yapıyordum, hata yapmaya çalışıyordum ki, neden öyle olmaması gerektiğini öğrenim. Ummadığım sonuçlar ya da hatalar olduğu zaman kitaplardaki açıklamaları okuyordum. Ziyaretçi defteri, hava durumu, ziyaretçi sayısı, download dosyaları vs… o dönemlerin alengirli parçaları ile biraz daha interaktif hale getiriyordum. Amacım sevdiğim müziği paylaşıp, benim gibi musiki insanlarına katkı sağlamaktı. Ama aslında kodlar ve yazılım müzik eşliğinde kanıma giriyormuş da haberim yokmuş.

Web sitem kendi kitlesi için, o dönemler için az biraz popüler olmuştu. IRC ortamlarında muhabbetler, yurt dışı albüm şirketlerinden gelen promo albümler, dergiler ile iletişim, konserlerde gruplar ile tanışıp muhabbetler, gelen güzel mesajlar… Bütün bunların arkasında çok farkında olmadan öğrenmeye başladığım yazılım teknolojileri vardı aslında. ASP ile başlayan PHP ile evrilen, MySQL ile çeşitlenen, HTML, CSS ve javascript ile süslenen bir alet çantam olmuştu. “Yazılım olayını öğrenmeyi” çok sevmeye başlamıştım. if…else… bir tutku haline gelmişti.

Devam…

“Kod” yazmak aslında çok eskiye dayanan bir iletişim yöntemi. Mağaralara, duvarlara, kitaplara belli işaretler ile bazı kavramları, bazı insanlara anlatmak için insanoğlunun çok eskiden beri çabaladığı bir iletişim yöntemi. Artık bilgisayar denen cihazı yarattığımız ve yaşantımızda önemli noktalara yerleştirdiğimiz için onunla iletişime girebilmemiz için de “kod” yazmak daha da önemli hale geldi. Bilgisayarların anlayabildiği diller ile onların çözümleyebileceği kompleks problemleri çözmek ve bazı ihtiyaçları gidermek artık insan hayatının önemli bir parçası haline geliyor…

Offff yeter, bu kadar felsefe yeter, konumuza geçelim. 😜 Son bir kaç zamandır “Infrastructure as Code(IaC)” kavramı ile ilgili ellerimi kirletiyorum. Daha önce sadece okuduklarım kadar bir hakimiyetim vardı kavrama. Artık biraz dokunmanın da zamanı geldi sanırım. Açıkcası IaC ile ilgili çok uzun uzun bir şeyler anlatacağım bir yazı olmayacak. Biraz daha, anahtar kelimelerin bol olacağı, “Infrastructure as Code(IaC) nedir?”, “Neden gerekir?” ve “Avantajları nedir?” gibi sorulara cevap olabilecek ve IaC kavramı ile tanışmak isteyenlere yol gösterebilecek bir yazı olacak. Hadi bakalım…

Nedir bu Infrastructure as Code(IaC)?

“Kod olarak altyapı” diye direkt chicken translate tadında çevirince çok çirkin oluyor. Ama anlamaya başlamak için birkaç ip ucu veriyor. Yazılım çözümlerinin çalıştığı altyapılar artık sadece elektronik birer kutu değil. Günümüzde hele hiç değil. Altyapılar da ihtiyaç çerçevesinde karmaşık bir hal alabiliyor. Yönetmesi zorlaşıyor. Yönetmeye gelene kadar kurması ve altyapıları ayağa kaldırmak zorlaşıyor. Bu zorlukların, zaman ve maddi açılardan götürüleri de oluyor. Günümüzde de önemli konular. Artık “kod” yazarak belli problemleri çözmeye başladığımız için bu problemleri de kod yazarak çözebilir miyiz diye ortaya çıkan bir kavram IaC. Özetle ve basitçe; IaC için altyapıların oluşturulması, kurulması, güncellenmesi, kopyalanması ve ayağı kaldırılması konularını güvenilr ve hızlı bir şekilde yapabilmek için reçete hazırlama diyebilirim. En azından ben bu şekilde bakarak biraz daha kolaylaştırmaya çalışıyorum. Bu reçetenin belli bir standart içinde oluşturulması için de Chef, Terraform, Puppet, Ansible, Google Cloud Deployment Manager, Azure Resource Manager, AWS CloudFormation gibi farklı teknolojiler mevcut.

Devam…

ASP.NET Core‘un en önemli özelliklerinden biri de “Middleware” yapısı. “Request-Response” modelinin ortasında özelleştirilmiş operasyonlar gerçekleştirip, request-response akışını yönetmek için oldukça etkili bir özellik. Gelen bir request‘in geçerliliğini kontrol etmek, response‘ları cache‘den oluşturmak gibi gibi birçok farklı ihtiyacı bu araya koyduğumuz yapılar ile ASP.NET Core‘da yapabiliyoruz.  

“Middleware”ler temelinde IApplicationBuilder arayüzünden türeyen bir sınıfa eklenti şeklinde eklenen metotların çalıştırılmasını sağlayan bir yapı. Web uygulamalarında da uygulamanın “request-response” yönetimini sağlayan sınıfın, yeni metodlar ile yapabileceklerinin artması ya da çeşitlenmesi şeklinde de basitçe düşünebiliriz. Çok daha ayrıntıya girmeden yavaştan konumuza geçelim…

Şartlı “middleware” kullanımı…

Eklediğimiz middleware‘lerin farklı şartlarda/durumlarda geçerli olmasını ya da olmamasını çok kolay bir şekilde ASP.NET Core‘da sağlayabiliyoruz. Bu ne demek hızlıca bakalım… 

Biraz daha anlaşılır olması için, basit bir senaryo örneği oluşturalım. Bir “middleware” geliştirdiğimizi düşünün, web uygulamasına gelen request‘in header bilgisindeki bir değeri kontrol etsin; “GET www.abc.com/v1/user/” eğer bu request‘in header‘ında key:abc123 varsa geçerli bir request olsun, yoksa da 401 dönsün… Çok tanıdık ve standart bir senaryo. Bu senaryoyu biraz daha kompleks hale getirelim. Eğer yeni geliştirdiğimiz v2 versiyonuna bir request gelirse de ek olarak farklı bir kontrol daha yapılsın. 

Şimdi “Ama bu çok kolay zaten, ne var ki bunda” dediğinizi duyar gibiyim.😉 Geliştirdiğimiz “middleware” içerisinde bir if-else kontrolü ile akışı kontrol eder ve ihtiyaca göre istenilen operasyonları gerçekleştirebiliriz. 

if(v1==true)
{
    ......
    ...
    ..
} else if(v2==true) {
    ......
    ...
}

Ne yazık ki yazılım geliştirme için bu basitlik yeterli değil, daha da basit olmalı. 🤔 Geliştirdiğimiz bu “middleware“i farklı projelerinde de kullandığımızı ve projelere göre farklı adreslerin olabileceği (/v1/user değil, versiyon1/user/ mesela) ya da farklı ek özelliklerin gerektiğini düşünün… 

UseWhen() 

Az önce yukarıda “middleware” yapısının, eklenti(extension) metodlar ile oluştuğunu belirtmiştim. ASP.NET Core içerisinde olan UseWhen() metodu da yine bir extension metot ve bununla diğer “middleware”‘leri belli şartlara göre uygulamamızda geçerli olacak şekilde kullanabiliyoruz. 

            app.UseExceptionHandlingMiddleware();

            app.UseWhen(context => context.Request.Path.StartsWithSegments("/v1"), appBuilder =>
            {
                appBuilder.UseMiddleware<ApplicationAuth>();
            });

            app.UseHttpsRedirection();
            app.UseStaticFiles();

Yukarıdaki örnekte eğer request yapılan adres “/v1” şeklinde bir içerikle başlıyorsa, ApplicationAuth diye bir “middleware” kullanılsın şeklinde bir tanım var. Eğer request yapılan adres “/v1” şeklinde başlamıyorsa araya eklediğimiz “middleware” etkili olmayacaktır. Ve alttaki diğer “middleware”‘ler etkili olacaktır. 

Bu sayede ApplicationAuthmiddleware“‘in içindeki kodu temiz ve sade tutarak, kütüphane şeklinde birden fazla projede kullanabilir hale getirebiliyoruz. 

MapWhen() 

Benzer bir yapıyla da bir “middleware”‘den sonra “request-response” arasındaki akış devam etmesin ve farklı bir şekilde sonuçlansın istenebilir. Bunun içinde MapWhen() extension metodu yardımımıza koşuyor. 

            app.UseExceptionHandlingMiddleware();

            app.MapWhen(context => context.Request.Path.StartsWithSegments("/v1/user/"), appBuilder =>
            {
                appBuilder.UseMiddleware<ActiveEndPointCheck>();
            });

            app.UseHttpsRedirection();
            app.UseStaticFiles();

Yukarıdaki örnekte de MapWhen() ile, request yapılan adres “/v1/user/” şeklinde başlıyorsa, ActiveEndPointCheck “middleware”‘i etkin olacak ama sonrasındaki diğer “middleware”‘ler etkin olmayacaktır. Bu yüzden MapWhen()’nin kullanımına ekstra dikkat etmek gerekiyor.  

Hem MapWhen() hem de UseWhen() parametre olarak Func<HttpContext, bool> şeklinde bir boolean dönen delege bir metot bekliyor. boolean dönen her hangi bir ifade ile de metotlar için geçerlilik oluşturabiliyoruz.

            app.UseWhen(context => DateTime.Now.Date.Month==2, appBuilder =>
            {
                appBuilder.UseMiddleware<CampaignControl>();
            });

ASP.NET Core içinde gelen bu iki extension metotu GitHub’dan da kontrol edebilir, kendi projelerinizde de benzer yaklaşımları uygulamak için ilham alabilirsiniz. 😀

“Middleware”‘ler kullanım yöntemleri ile de ASP.NET Core çözümlerine oldukça değer katıyor. Basit ama etkili bu iki metot benim ihtiyacımı hızlıca çözümlememde çok yardımcı oldu, aynı hızla ben de paylaşmak istedim. Umarım size de yardımcı olur. 

gRPC ile Raspberry Pi için bir şeyler kurcalarken tanışmıştım. .NET Core tarafında da destekleniyor olması bir çok kişinin daha tanışmasına vesile oldu sanırım. Nedir, ne değildir bunlara çok ayrıntılı girmeyeceğim; ama özet olması için, Google tarafından geliştirilen, HTTP/2 protokolü üzerinde çalışan bir Remote Procedure Call(RPC) framework’ü diyebilirim.

gRPC
gRPC – Remote Procedure Call

En önemli artısı yazılım dili bağımsız olması ve yüksek bir performansa sahip olması. protobuf(Protocol Buffers) olarak adlandıralan yapısal verileri serialize(binary olarak) eden bir mekanizması oluğundan performansı ihtiyaçlara göre oldukça iyi. Bir çok yazılım dili desteğinde, C# ve .NET Core da mevcut. .NET Core tarafında gRPC servislerini ASP.NET Core çatısı altında oldukça kolay bir şekilde geliştirebiliyoruz. gRPC servislerinde, belli bir kontrat ile veriler yapısal iletildiği için, .NET Framework yapılarındaki servis kavramlarına denk olarak anılıyor, .NET Core’da. Ancak özellikle belirtmek isterim ki gRPC, WCF ya da *.wsdl yapılarının .NET Core’da ki karşılığı kesinlikle değil.

Gelelim konumuza… “gRPC nedir?”, “.NET Core’daki gRPC nedir?” gibi sorularıdan çok, “Peki neden?” sorusu üzerinden gidip, “.NET Core’da neden gRPC var?”, “Neden kullanalım ki?” diyerek, beğendiğim bir özelliğinden, .NET Core çatısı altında bahsetmek istiyorum…

Streaming…

Remote Procedure Call diye havalı olarak söylediğimiz kavramın, en basit ve çok kullandığımız yalın ifadesi “servis” bildiğiniz gibi. En çok karşımıza çıkan “Request-Response” mesajlaşma modeli gibi, gerçek zamanlı mesajlaşma modeli(a.k.a streaming) de servislerin olmazsa olmazı.

İşte bu streaming ihtiyaçları için, .NET Core’daki gRPC desteği dikkat çeken, güzel bir özellik. Belli bir kontrat yapısı ile verilerin akışını sağlayan servisleri ASP.NET Core tarafında bu şekilde kolaylıkla, genel standartlara uygun bir şekilde geliştirebiliyoruz.

100 soruluk bir sınav yapmış olalım. Sınav kağıdımızı teslim edelim ve soruların cevabını bekleyelim. Sınav kağıdımız tamamen okunana kadar, sorduğumuz soruların cevaplarını öğrenmek pek mümkün olmaz.

Servis çağrımlarında da böyle durumlar olabiliyor; standart bir request-response modelinde, 1000 tane veriyi işleme sokulsun diye bir servise gönderdiğimizde, 1000 tane verinin de tamamen işlenmesi sonrasında sonuçları alabiliyoruz. Servise gönderdiğimizde sonuç olarak, direkt işlenen verileri sırayla gönderse iyi olmaz mıydı…

Bu örneğe benzer bir senaryomuz olsun. 1+2, 5*10, 6/3 şeklinde matematik işlemlerini toplu bir şekilde sorulabileceği bir servisimiz olsun. Servis de bu işlemlerin sonuçlarını yaptıkça dönsün…

Çok konuştuk biraz da kodlar üzerinden gidelim. Öncelikle *.proto dosyamızda servis kontratına bir bakalım.

syntax = "proto3";
option csharp_namespace = "gRPC.Server";

package Quiz;
service Maths {
  rpc AskQuestion (QuestionRequest) returns (stream AnswerReply);
}

message QuestionRequest {
  repeated string texts = 1;
}

message AnswerReply {
  string question = 1;
  double answer=2;
}
Devam…

GitHub‘ın kullanımı gün geçtikçe artıyor. GitHub kullanımının artması ile beraber de ihtiyaçlar ortaya çıkıyor. İhtiyaçlar da ortaya çıktıkça, GitHub bunlara çözüm üretiyor doğal olarak. Çok daha fazla uzatmadan bu çözümlerden biri olan, GitHub Actions‘dan; giriş olması adına kısaca bahsetmeye çalışacağım.

GitHub Actions ile, kodları yönetmek, paylaşmak ve dağıtmak gibi aksiyonlar için iş akışları oluşturabiliyoruz. Bir nevi, kodların çeşitli kavramlarla etkileşime girmesini sağlayabiliyoruz. Kodların derlenmesi, paketlenip dağıtılması, çeşitli platformlarda çalıştırılması, durum güncellemeleri ve bildirimlerin oluşturulması, issue yönetimi gibi gibi değişik birçok aksiyonu GitHub Actions ile gerçekleştirebiliyoruz.

Şimdi bütün bunlar, aslında yeni yaklaşımlar değil, bir çoğunuz için tanıdık gelecektir belki de. Her özel kod deposunda, çeşitli script/bash gibi yapılar ile bunları gerçekleştirmek bir şekilde mümkün(!). GitHub‘ın kullanımı arttığı için, bu tarz ihtiyaçların onun da üstünde gerçekleştiriliyor olması, GitHub’ı daha da cazip hale getiriyor, getirmeye başlıyor. Çok dağılmadan basit bir GitHub Action oluşturalım ve bakalım neymiş.

Her repository’nin menüsünde “Actions” başlığını dikkatinizi çekecektir.

Bu başlığa girdiğimizde aşağıdakine benzer bir ekran ile karşılaşacağız.

Burada hazır bazı aksiyonları başlangıç olması adına bulabiliyoruz. İhtiyacınız olan aksiyonu bulup “Set up this workflow” demek ve gerekli ayarları yapmak oldukça kolay. Aksiyon olayını anlamak için biz sağ tarafdaki “Set up a workflow yourself” diyelim ve aksiyonlarımızı yaratmak için editörü açalım.

Editör

Örnek olarak ben çok basit bir senaryo üzerinden anlatmaya çalışacağım. Mesela herhangi bir kod push olduğu zaman, kodumuzu derlensin…

IntelliSense

GitHub üzerinde de aksiyonlar *.yml dosyası olarak tanımlanıyor. YML dosyaları konfigürasyon dosyaları için tercih edilen bir standart haline geldi diyebiliriz sanırım arık. Bu YML dosyalarını GitHub üzerinden kolay bir şekilde, komutlar ve özelliklerini gösteren basit bir IntelliSense desteği ile düzenleyebiliyoruz.

Örnek olarak üzerinden gideceğim aksiyon içeriği aşağıdaki gibi, adım adım parçalarına bakalım…

name: Build
on:
   push:
     paths:
     - 'src/**'
 jobs:
   build:
     runs-on: ubuntu-latest
     steps:
	- uses: actions/checkout@v1
	- name: Setup .NET Core
	  uses: actions/setup-dotnet@v1
	  with:
	    dotnet-version: 3.0.100
	- name: Build with dotnet
	  run: dotnet build src/Blazor.Console/Blazor.Console.csproj --configuration Release 
Devam…