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

Progressive Web Apps(PWA)’lar gelişen web teknolojileri ve web browser’lar ile değişik deneyimleri ve kazançları kullanıcılara sağlamak adına tercih edilebilecek bir uygulama modeli. PWA’lar için, Web uygulamalarının kullanıcı deneyim avantajları ve masaüstü(desktop) uygulamalarının performans kazanımları, tarayıcı çatısı altında birleşerek, işletim sistemi farklılıklarının da ortadan kalktığı bir uygulama modeli de diyebiliriz.

Biraz daha basite indirgeyerek, tarayıcıların işletim sistemi gibi ele alındığı ve tarayıcı API’larının yeteneklerini kullanarak işletim sistemlerinden bağımsız geliştirilen, tarayıcılara yüklenen web uygulamaları diyebiliriz. Mesela twitter.com, maps.google.com gibi hepimizin oldukça sık kullandığı web siteleri PWA uygulama modeli ile geliştirilen siteler(uygulamalar). Bu sayede Twitter, işletim sistemi özelinde ayrı uygulamalar geliştirmeden, tek bir kod alt yapısı ile masaüstü uygulama(-kısmen) deneyimini sunabiliyor.

PWA özelinde daha fazla ayrıntıya girmeden, Blazor WebAssembly uygulama modeli ile nasıl Progressive Web Apps(PWA) geliştirebiliriz kısaca buna bakmaya çalışacağız. ASP.NET Core çatısı altındaki Blazor uygulama modelinin, WebAssembly yaklaşımı ile bu tarz uygulamalar geliştirmek mümkün. Açıkçası Blazor WebAssembly’nin ne olduğunun çok fazla ayrıntısına girmeyeceğim, ama kısa bir bilgi olması adına; tarayıcıda .NET Runtime’ın WebAssembly üzerinde çalışabilmesini sağlayan bir framework diyebiliriz. JavaScript’e ek olarak C# kodları yazarak da, tarayıcıda çalışan önyüz uygulamalarını Blazor WebAssembly ile geliştirebiliyoruz.

PWA ve Blazor ile ilgili bu kısa girişten sonra küçük bir örnek ile bazı kavramları biraz daha somutlaştırmak istiyorum, hem de daha derinlere dalmak isteyenlere başlangıç noktası ve bazı anahtar kelimeler olur, yani umarım.

Yine belli bir senaryo çatısı altında, aşağıdaki başlıklar ile Blazor’u, Blazor WebAssembly ve PWA yaklaşımlarını biraz anlatmaya çalışacağım. Aslında hepsi ayrı yazı olacak şekilde ele alınacak konular ama bir bütünlük içerisinde, kullanımlarını ve neler yapabilirizi daha iyi anlamak için bir arada paylaşmak istedim. Umarım faydalı olur…

Senaryomuz; bir API kaynağından döviz kurlarının karşılığını alıp gösteren, network durumuna göre offline durumda da çalışabilen basit bir WEB(PWA) uygulaması olsun. (Offff, çok yaratıcıyım… 🤦🏻‍♂️😀)

Devam…

IntelliSense özelliği birçok gelişmiş IDE’nin olmazsa olmaz özelliği. –Ki artık öyle kullanım getirileri var ki, IntelliSense olmadan kod yazmak çok hoş karşılanan bir aktivite olmuyor. Üretkenlik, kalite ve hızlı geliştirme ihtiyaçları için yazılımcıların en sevdiği özellik belki de. Visual Studio’nun son sürümü(v16.7) ile birçok yazılımcı için hayat kurtaran bir IntelliSense özelliğine merhaba dedik. Açıkçası basit bir özellik olduğu için onu çok allayıp, pullayıp anlatmayacağım ama böyle bir özelliğin nasıl geliştirildiğini ve biz de benzer şekilde ihtiyaçlar için ne yapabiliriz buna değinmeye çalışacağım. Ama önce Visual Studio’da ne gelmiş bir bakalım…

Herkesin bildiği gibi DateTime veri tipini string olarak ifade etmek istediğimizde, çeşitli formatlar ile ifade şeklini ayarlayabiliyoruz. Ama bu formatlardan, hangisinin ne olduğunu hatırlamak bazen direkt mümkün olmuyor, hh/MM/yy mi? Ya da HHHH/MM/Y mi? gibi denemeler/yanılmalar ya da Google’a sormalar her yazılımcının yaptığı aktiviteler.

Hadi DateTime neyse ama bir Regex olayı var ki; kendi adıma aramın pekiyi olduğunu söylemem. Regex ifadeleri yazmak başlı başına ayrı bir mücadele.

Yazılımcıların bu mücadelesini kolaylaştırmak için Visual Studio 16.7 sürümü ile IntelliSense özelliklerinde DateTime formatları ve Regex ifadeleri için ipuçları geldi. “Eeee zaten var ki” diyenleri duyar gibi oluyorum. ReSharper gibi eklentiler ile hem cüzdanları hem de Visual Studio’yu yorarak benzer özelliklerden faydalanabiliyorduk.💰🥴

Ama artık onlara gerek yok…

Peki nasıl yapılıyor?

Devam…

Azure Kubernetes Service(AKS), Kubernetes platformunun Azure üzerindeki yansıması. Malum artık Kubernetes son birkaç yılın oldukça tercih edilen bir platformu. Günümüzün uygulama geliştirme ihtiyaçları ile paralel gelişen, “microservices”, “container” gibi yaklaşımlar ile hızlı değişiklikleri kolay gerçekleştirmeyi sağlayan bir platform olması, günümüzdeki belli kalitedeki çözümlerin temel taşlarından biri olmasını sağladı. O zaman biz de şimdi Azure üzerindeki servisler ile, Kubernetes’den nasıl faydalanabiliriz buna bir bakalım.

Azure Kubernetes Service üzerinde, Azure DevOps ile uygulamalarımızı nasıl dağıtırızı, temel noktaları ile anlatmaya çalışacağım. Hem Kubernetes’i anlamak, hem de Azure servisleri ile tanışmak için güzel bir başlangıç olur umarım. Birkaç anahtar kelime ile de bazı konular için kapı açan bir yazı olur umarım. Yol biraz uzun, çok zaman kaybetmeden başlayalım hemen…

Azure Kubernetes Service dedin de, bu ne alaka…

İlk adımımız Azure Kubernetes Service(AKS) tarafında host edilecek, yönetilecek Docker Container’larımızı saklayacağımız Azure Container Registery(ACR)’i oluşturmak. Bu depodan Container’lar alınıp, imaj şeklinde AKS tarafında çalışacak.

ACR’ı oluşturmak portal üzerinden oldukça basit, aşağıdakine benzer şekilde temel bilgiler ile geliştirme ve test amaçlı ACR’ı oluşturabiliriz.

Azure Kubernetes Service’i kuralım bakalım…

Şimdi sıra geldi Azure Kubernetes Service(AKS) ortamını oluşturmaya. Portal’de tepedeki kutucuğa direkt kubernetes diye yazarak servislere yöneliyoruz. Tabi ki daha henüz hiçbir AKS ortamımız olmadığı için “Add” deyip, “Add Kubernetes Cluster” ekliyoruz.

Devam…

Hep böyle uzun aralar oluyor, hiç sevmiyorum… Ayıp bana. Neyse, uzun bir aradan sonra yeni bir yazı ile ASP.NET Core tarafındaki sıcak konulardan birine, gRPC servislerine farklı bir açıdan yine bakalım. Yine bakalım diyorum çünkü daha önce “gRPC, .NET Core ve “streaming”” başlıklı yazıda az biraz .NET Core ve gRPC’den bahsetmeye çalışmıştım.

gRPC, Google tarafından geliştirilen bir “Remote Procedure Call” framework’ü… Aktarım protokolü olarak HTTP/2 üzerinde yüksek performanslı bir yapısının olması, platform ve dil bağımsız olması da birçok kompleks çözüm için tercih edilmesinin en önemli sebeblerinden. “Protocol Buffers” ile oluşturalan kontratlar ile servis tanımlarını net belirtme ve bu tanımların “binary serialization” ile hızlı çözümlenmesi de “microservices” dünyası için oldukça değerli.

Google’ın back-end tarafındaki birçok servisinin bu framework üzerinde kurulmuş olması ve bir çok büyük organizasyonun gRPC yaklaşımını tercih etmesi ile de gRPC‘nin, kendini zaten ispatlamış bir teknoloji olduğunun ispatı.

Şu an gRPC‘nin en büyük handikapı tarayıcılar(browser) tarafında kullanılabilen varsayılan API’lar olmaması. Yani tarayıcılar üzerinden gRPC servis çağrılarının yapılabilmesi için ekstra bir yapıya gereksinim var. gRPC-Web‘de bu ihtiyaç için ortaya çıkmış bir protokol. Basitçe özetlemek gerekirse, ara bir JS katmanı ile tarayıcıların gRPC çağrıları yapılması sağlanıyor.

.NET Core 3.0 ile .NET tarafında gRPC ile tanışmıştık ama gRPC-Web tarafının daha karışılığı tam olarak yoktu. Geçtiğimiz hafta .NET için de gRPC-Web, resmi olarak yayınlandı. Yani ASP.NET Core gRPC servislerini de artık tarayıcılardan da çağırabiliyoruz. Bir servisin, bir tarayıcıdan çağrılabiliyor olması çok büyük bir olay değil belki… “Bu mu yani, öhhhhh???” gibi ifadeler ile yaklaşabiliriz ama WebAssembly, Blazor, SPA(Single-Page Application) uygulama modelleri geliştikçe ve gRPC servislerinin kullanımı arttıkça, dönüp baktığımızda önemli bir gelişme diyeceğiz.

Geçtiğimiz haftalarda hatırlarsanız ASP.NET Core Blazor WebAssembly uygulama modeli de yayınlanmıştı. C# ile WebAssembly alt yapısı ile, direkt tarayıcılarda çalışan .NET uygulamaları geliştirmek mümkün hale gelmişti. gRPC-Web de bu açıdan daha bir anlamlı duruma gelmiş oluyor.

Önceki gRPC yazımda çok basit bir örnek yapmıştım. O örneği biraz genişleterek, yeni bir Blazor WebAssembly uygulamasından geliştirdiğimiz gRPC servisini çağırmaya bakalım. Dolayısıyla önceki yazıyı okumadıysanız önce ona bir bakmakta fayda olacaktır.

Devam…

“Uzaktan çalışmak” yazılım sektörü için uzun zamandır var olan ve etkin bir şekilde de değerlendirilen bir çalışma modeli aslında. Sadece değerlendiren şirket sayısı oldukça az. Gelişen teknoloji, çeşitlenen iş modelleri ve şirketlerin cazibesini arttırmak için artış gösterse de, yine de sahip olduğumuz imkânlara göre çok tercih edilmiyor(du).

Bu yaşadığımız abuk dönemle beraber farkındalığı ve tercih edilme durumu da arttı. İnsanoğlu olarak içinde bulunduğumuz çağa ayak uyduramadık sanırım, bulunduğumuz “çağ” da, Covid-19’u bize göstererek, seve seve bazı kavramlara ayak uydurmamız için ittiriyor belki de, kim bilir… 🤔

Yazılımcılar için, herkesin ağzında pelesenk olmuş bir ifade vardır; “Yazılımcılar her yerden çalışabilir” gibi. Bu farkındalık ve teknik imkânlar olmasına rağmen, mutlaka ofis ortamında çalışılması şirketlerin zorladığı bir yaklaşım. “Yooo” diyenleri buradan duyuyorum ama çoğunluk açısından örnek veriyorum… Hemen atlamayalım, lütfen.😀

Mutlaka ofis ortamında olmanın; çeşitli çalışma şartları/kuralları gibi kâğıt üstünde geçerli olan zorunluluklar da olabileceği için bu döneme kadar “uzaktan çalışmak” modeline uzaktık.

Şartların zorlaması ile yakınlaştığımız bu “uzaktan çalışmak” modelini gerçekten ne kadar sağlıklı ve doğru, kendimce bir şeyler karalamak istedim…

“Uzaktan çalışmak”, sektör ve iş modellerine göre çeşitlilik gösteren, getirilerinin ve götürülerinin olduğu bir model. Bu yüzden sektör ve iş modellerine göre bir genelleme yapmak doğru olmaz diye düşünüyorum. Sektörlerden, iş modellerinden bağımsız olarak, bu tarz çalışma modelinin, temelinde olduğu ve dokunduğu için “insan” açısından sorgular oldum son birkaç zamandır.

İş hayatı, yaşantımızın çok büyük bir parçası. Ne kadar böyle olmaması gerekir diye düşünsem de, bulunduğumuz çağın yine bizi “seve seve” sürüklediği bir yer. Zamanımızın çok büyük bir kısmını geçirdiğimiz bir hayat…

Peki bu hayatta “uzaktan çalışmak” ne kadar katkı sağlıyor?

Sabahları ofise geldiğimizde, sabah kahvesini beraber içmek, gündem ile ilgili şakalar/kakalar yapmak, dünkü maç hakkında konuşmak, akşam öğrenilen değişik bir tarifi anlatmak…

Öğlen yemeğe çıkmak, nereye gideceğiz diye kafa yormak… Açık unutulan bilgisayarlardan, tüm ekibe tatlı ısmarlamak, Play Station da iki maç yapmak… Arkadaşlara şaka yapmak, herkesin yüzünde tebessüm yaratan şakaların kurbanı olmak…

Toplantılarda fikirlerimizi anlatmak, savunmak… Kakara-kikiri ile arada başlayan fikirlerin paylaşılarak olgunlaşması, yeni kapıların açması… Yüz ifadelerini anlamaya çalışmak, üzüntüleri paylaşmak, mutlulukları yaymak…

Tartışmak, sinirlenmek… Sinirli olduğumuzu bütün gün yüz ifademiz ile belli etmek. Sinirli ya da mutsuz olan arkadaşımızı görmek, anlamaya çalışmak ve sonra beraber gülebilmek…

Bunlar gibi bir sürü örnek verilebilir. İnsana dokunan bu durumlardan “uzaktan çalışarak” uzak kalıyoruz. Belki birçoğumuz için çok aranan ya da tercih edilen durumlar da değiller. Ama benim için sanırım değerli konular.
Sonuçta mekanik birer dişli değiliz, hele robot hiç değiliz. Yani henüz… 🤖

Uzaktan çalışmanın, iş yapma açısından getirileri sektör ve iş modeline göre yüksek olabiliyor. Odaklanarak çalışmak, zaman yönetimi, rahat ortam gibi iş kalitesini arttıran yönlerini görmezden gelmek mümkün değil. Bu artı yönlerine, gözlerimizi kapatıp bu getirilerini değerlendirmemek de yine çağa ayak uyduramamak gibi bir şey. Uzaktan çalışmanın getirdiklerinin farkına vardığımız gibi, götürdüklerinin de farkına varıp, orta yolu bulmaya çalışmak belki önümüzdeki mücadelelerden biri olacak.

Çalışanın kendi çalışma ortamlarını yaratması ve kendi “çalışma” disiplinini oluşturmasını sağlamak işverenlerin kafa yormaya başlayacağı bir konu olmalı diye düşünüyorum. Sektöre yön veren büyük firmaların, proje ve proje ekiplerine göre uygulamaları belki daha çok gündeme gelecek… Hem insanın yaşam kalitesini, hem de iş hayatındaki mutluluğunu arttırmak için, çalışmalar, “sözde” değil, gerçekten belli çalışmalara göre ölçülebilir şekilde gerçekleşir umarım.

Neyse… Daha fazla uzatmadan, ara sıra düşünmek için kafamda biraz dursun. Çıkarsa bir şeyler yine paylaşırım zaten.

*Ulan yoksa yaşlanıyor muyum? Abovvvv….

Bu arada bulunduğumuz bu Covid-19 dönemine göre değil, genel olarak her dönem ki “uzaktan çalışmak” modeli hakkındaki sesli düşünmem olarak yaklaşırsanız sevinirim. Çünkü şimdiden, “uzaktan çalışmak çok iyi yeahhh, ne saçmalıyorsun” diyenleri duyar gibiyim. Uzaktan çalışmanın yanlış bir model olduğu çıkarımının yapılmasını istemem. Sadece, gerçekten yanlış bir model olmaması için bazı yaklaşımları kendimce sorguluyorum…

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