WebUcu Günlükleri

Transactional Outbox Deseni

merhanersoy@gmail.com — Cum, 1 Eyl 2023 19:36:00 +0300

Legacy monolith uygulamalarda işlem bütünlüğünü sağlamak için kullandığımız en temel araç transactiondır. Bir işlemi, özellikle veritabanı işlemlerini aynı veritabanı transaction’ı içerisinde yaparız ki herhangi bir adımda alınacak hata durumunda rollback komutu çalıştırarak tüm işlemleri geri alabilelim. Eğer işler yolunda gider ve tüm adımlar başarıyla tamamlanırsa commit ile transaction’ı kapatırız. Veritabanında yapılacak işlemler söz konusu olduğunda iş karmaşıklaşmaya başlayıp compansation dediğimiz geri alma metodlarını düşünmemiz gerekmeye başlar. Örneğin bir muhasebe işlemi için önce veritabanı seviyesinde bazı tablolara kayıtlar girip bunu tamamladıktan sonra bir dizine dekont oluşturduğumuzu düşünelim. Veritabanındaki işlemleri aynı transaction içerisinde bütünlüğünü sağlayıp yönetebiliriz. Eğer sonrasında dekont oluşturma sırasında hata alırsak yaptığımız muhasebe kaydı ne olacak? Eğer veritabanı işlemleri için açtığımız transaction’ı açık tutup dekontun oluşturulmasının tamamlanmasını beklersek, bu veritabanı kaynaklarını kötü kullanmak olur. Yok eğer veritabanı transaction’ını commit edip dekont basımına geçersek, hata durumunda bu sefer muhasebe işleminin iptalini yapacak bir compansation metodu çalıştırmamız gerekir. Peki ya bu compansation metodu da hata alır ise ?

Mikroservis mimarisi hayatımıza yukarıdaki senaryoyu biraz daha bariz hale getiren bir trade-off ile birlikte geliyor. Uygulamalarımızı daha küçük mantıksal servisler haline getirip bunları birbiri ile konuşturmaya başlamamızla birlikte ilk karşımıza çıkan sorun “dağıtık mimaride işlem bütünlüğünü nasıl sağlayacağız ?” oluyor.

Bu noktada bu makalenin konusu olmayan ama çok ilişkili bir tasarım deseninden bahsetmek gerekiyor : Saga deseni. Saga deseni, dağıtık mimaride transaction bütünlüğünü sağlamayı hedefleyen bir desendir. Farklı servislerce tamamlanacak adımları olan bir iş geliştirdiğimizi düşünelim. Her mikroservis, kendi kapsamındaki işi tamamlayıp bir sonraki servise görevini yapması için talepte bulunmalıdır. Sıralı şekilde birbirine bağlı bu servislerden biri hata alması durumunda geriye doğru her servisin yaptığı işin tersi ya da compansation metodu çalışması gerekir. Bu şekilde saga içerisindeki her adımın bir işi yapan bir de yapılan işi geri alan metodu yazılarak saga adımları oluşturulur. Şimdilik daha fazla detaya inmeden saga tasarım desenini bu şekilde özetleyebiliriz.

Örnek ile Transactional Outbox Deseni

Örneğin aşağıdaki gibi bir senaryoda, dış bir servisten gelen emir Order servisine ulaşıyor, Order servisimiz de bir saga başlatıyor. Öncelikle kendi hesaplama ve veritabanı işlemlerini tamamlayıp emir mesajını saganın diğer adımlarına iletmek üzere mesaj kuyruğuna bırakıyor olsun. Burada servis kendi işlemlerini işlem bütünlüğü içerisinde yapıp mesajı kuyruğa bırakma aşamasında bir kesintiden dolayı sorun yaşaması halinde işlem kuyruğa iletilememiş olacak. Kendi yaptığı işlemleri geri alması halinde de işlem sanki hiç ulaşmamış gibi olacak. Yok eğer kendi yaptığı işlemleri geri almaz ise bu sefer kuyruk erişimindeki sorun giderilene kadar kuyruğa mesajı bırakacak kısmı sürekli tekrarlayan bir mekanizmaya ihtiyaç olacak.

Transactional Outbox Pattern işte bu sorunun çözümü için saga adımları arasındaki mesaj iletimini soyutlayarak her servis adımında atomik transaction içerisinde mesaj iletimi yapılmasını sağlamak için tasarlanmıştır. Emri alan Order servisi kendi işlemlerini yaptığı transaction içerisinde bir outbox tabloya iletilecek mesajı kaydeder ve kendi saga adımını gerçeklemiş olur. Eğer kendi transaction’ı içerisinde bir hata oluşur ise mesaj alınamadı hatasını ilk elden döner.

Outbox tablosunu düzenli aralıklarla tarayıp yeni emirleri kuyruğa bırakan ek bir genel servis (Outbox Message Relay) tasarlanmalıdır. Bu servis mesajı okuyup kuyruğa iletmek, iletemez ise statü güncellemek dışında bir şey ile ilgilenmemelidir. Böylece olası bir kesinti durumunda işlem saga adımını geçmiş ve diğer adıma iletilmek üzere beklemede olacaktır. Servisler kendi görevleri dışında kuyruk iletimi ile alakalı detaylardan soyutlanmış, bağımlılık azaltılmış olacaktır.

Outbox Message Relay Yöntemleri

Transactional Outbox Pattern yukarıda anlattığım gibi uygulandığında bir outbox tablomuz oluşmuş ve mesajlarımızı barındırıyor olacaktır. Bu durumda Outbox Message Relay servisimiz Outbox tablosunu belli aralıklarla sorgulayarak yeni mesaj olup olmadığını kontrol ederek gerekli aksiyonları alıyor olacaktır. Bu yönteme Polling Publisher deniyor.

Bir diğer yöntem ise Outbox tablomuza mesajı yazdığımız anda veritabanının transaction loguna bu işlem kaydedileceğinden, destekleyen veritabanlarınca bu kaydedilen logu dinleyecek bir yapı tarafından mesajlar kuyruğa bırakılabilir. Bu yönteme ise Transaction Log Tailing deniyor.

Kaynaklar

Visualizing Google Cloud Kitap İncelemesi

merhanersoy@gmail.com — Cum, 7 Tem 2023 18:21:00 +0300

Google'da Developer Advocate olarak çalışan aynı zamanda GCP ile alakalı içerik sağlayan Priyanka Vergadia tarafından görselleştirilerek anlatılmış bir Google Cloud referans kitabı. Kapağında da yazdığı gibi giriş seviyesi bir kitap. Bulut teknolojisi tanımı ve avantajları ile başlayıp Google Bulut Platformu / Google Cloud Platform (GCP) detayları ile devam eden bir kitap. Temel bulut bilgisini verdikten sonra GCP ortamındaki kullanılabilecek tüm ürünleri temel seviyede inceleyen bir kitap. Bunu yaparken de aşağıdaki gibi bölümlere ayrılmış kategorilerde ürünü tanıtırken yazarın kendi çizimleri ile konuyu görselleştirdiği için ürünleri ile kullanım şekli ve amaçlarını anlamak oldukça kolay hale gelmiş. Bazen sadece çizimleri inceleyince ürünü kavrayabiliyorsunuz, açıklama metni tekrar haline geliyor. Yazar ayrıca kitapta kullandığı çizimleri şu github reposundan da paylaşmış. Eğitim içeriği sağlayıcılar ve sunumlar için oldukça faydalı bir kaynak olduğunu düşünüyorum.

Kitaptaki kategoriler :

Ch 1. Infrastructure

Ch 2. Storage

Ch 3. Database

Ch 4. Data Analytics

Ch 5. Application Development and Modernization

Ch 6. Networking

Ch 7. Data Science, Machine Learning and, Artificial Intelligence

Ch 8. Security

Kitaptaki çizimlere bir örnek :

Kitap bulut teknolojilerine giriş aşamasındaki ve GCP devam edecek ile teknik pozisyonlardaki kişileri hedef alıyor. O'Reilly'nin Head First serisindeki kitapları andırıyor. Benim gibi görselleştirilmiş içerik ile daha kolay anlayan kitlenin zevk alarak faydalanacağını düşünüyorum. Detay bilgi için konuları derinlemesine inceleyen kaynaklara bakmak lazım, bu kitap derin bilgi arayanlara uygun değil. Kitap daha çok yüzeysel bilgi vererek GCP ortamı ve ürünlerinin tamamını 240 sayfada kapsamaya çalışıyor. Bunu yaparken de vaka problem üzerinden çözümleri anlatmaya çalışıyor, sonrasında da ürünün nasıl çalıştığını anlatıyor. ilgi alanınıza göre bazı bölümleri daha hızlı geçebilir ya da atlayabilirsiniz. Machine Learning ve AI bölümü en ilgimi çeken bölümlerden oldu.

Ayrıca yazarın GitHub reposunda yer alan şu GCP cheat Sheet'i de oldukça faydalı : Google Cloud in 4 Words

İyi okumalar.

AZ-204: Developing Solutions For Microsoft Azure Sertifika Sınavı ve Hazırlığı

merhanersoy@gmail.com — Per, 21 Nis 2022 01:09:00 +0300

Microsoft'un bulut platformu Azure'a yönelik değişik rolleri kapsayan eğitimler gün geçtikçe çeşitlenmeye ve artmaya başladı. Bu çeşitlilik ve zenginlik bir şekilde beni tekrar cezbetti.
Geçtiğimiz yıllarda AZ-900 Azure Fundamentals eğitimi ve sonrasında sertifika sınavına katılmıştım. Hazırlık ve sınav sürecini, çok istememe rağmen, tembellikten bir türlü yazılı hale getirememiştim.
Bu sefer AZ-204 Developing Solutions For Microsoft Azure sertifika hazırlığım sırasında kendimi işin başından itibaren motive ederek yazmaya başladım :)

Çalıştığım şirket Intertech'in Microsoft Enterprise Skills Initiative (ESI) programına dahil olmasının faydalarından yararlandığım için eğitim ve sertifika sınavı voucher'larına erişimim oldukça kolay ve ücretsiz oldu.
Fakat bu programdan faydalanmasanız bile bir çoğu ücretsiz veya uygun ücretler karşılığında alternatif hazırlık materyalleri mevcut. Yazımda her üç seçenekten bir miktar bahsedeceğim.

Azure Eğitim Yolculuğu

Microsoft ESI programı dahilinde geliştiriciler için hazırladıkları eğitim ve sertifika yolculuğu aşağıdaki gibi planlanmış, diğer tüm roller için eğitim yolculuğu dökümanına buradan ulaşabilirsiniz.
ESI programı ile Microsoft, partner olan firmaların çalışanlarına oldukça sık tekrarlanan online olarak katılım sağlayabilecekleri eğitimler sağlıyor. Gördüğüm kadarıyla aradığınız bir eğitimi ayda iki defa açıldığını farkettim. Kendinze en uygun zamana eğitiminizi planlayabiliyorsunuz.

Microsoft'un Azure platformu için sağladığı üç seviye eğitim ve sertifika mevcut :

Fundamentals (*)
Associate (**)
Expert (***)

Not : **-900 kodlu olan eğitim ve sertifikalar, temel eğitim kategorisinde oluyor. Giriş seviye eğitim deyip küçümsememek lazım, sınavı hazırlanmadan girmek için uygun değil :)

Elbette tüm eğitimler geliştiriciler için uygun olsa da ben kendime yani bir uygulama geliştiriciye daha uygun olarak aşağıkdaki eğitim ve sertifikaları yolculuk olarak belirledim :

AZ-900 Azure Fundamentals
AZ-204 Developing Solutions For Microsoft Azure
AZ-303 Microsoft Azure Architect Technologies
AZ-304 Microsoft Azure Architect Design

Not : Microsoft eğitim ve sertifika isimlerini geçtiğimiz yıl güncelleyerek değiştirdi. AZ-301 sertifikası AZ-303 olarak güncellendi. Mart 2022'de de bu sertifikayı AZ-305 olarak güncellenecek.

Genel bilgileri ve kuşbakışı tabloyu ilettikten sonra şimdi gelelim AZ-204 sertifika sınavı hazırlık sürecine.

AZ-204 Sertifika Sınavına Hazırlık Aşaması

Öncelikle eski tecrübelerimden, AZ-900 sınavına hazırlanırken yoğun olarak Microsoft'un resmi dökümanını kullanmıştım. AZ-204 için de benzer şekilde oldukça derli toplu bir doküman var.

Bu doküman, online olarak aldığım eğitim içeriği ve takvimi ile çok benzer içeriğe sahip. Online eğitim aldığım için bu dökümanı takip etmedim. Sadece güvenlik ve yedekleme derslerinde tam anlayamadığım kısımları gözden geçirdim.

AZ-204 Developing Solutions For Microsoft Azure eğitimini 12 modül olarak hazırlanmış ve 5 tam gün sürüyor. Her gün yarı yarıya konu anlatımı, walkthrough ve lab çalışmalarından oluşuyor.
Eğitimi ESI platformu üzerinden İngilizce alabildiğiniz gibi BilgeAdam da aynı eğitim içeriğini Türkçe olarak veriyor.
Eğer sertifika amaçlı katılıyorsanız ve İngilizce'niz yeterli ise uluslarası versiyonu daha avantajlı olacaktır.

Eğitimin modülleri şu şekilde :

Module 01: Create Azure App Service Web Apps
Module 02: Implement Azure Functions
Module 03: Develop solutions that use blob storage
Module 04: Develop solutions that use Cosmos DB storage
Module 05: Implement IaaS solutions
Module 06: Implement user authentication and authorization
Module 07: Implement secure cloud solutions
Module 08: Implement API Management
Module 09: Develop event-based solutions
Module 10: Develop message-based solutions
Module 11: Monitor and optimize Azure solutions
Module 12: Integrate caching and content delivery within solutions

Eğitimde yapılan lab çalışmalarına bu linkten ulaşılabilir, Azure ortamına erişiminiz var ise lab çalışmalarını çalışma ortamınızda deneyebilirsiniz :

Eğitimi bitirdikten sonra aldığım notlar üzerinden yukarıda bahsettiğim online Microsoft dökümanı gözden geçirip eksik noktalarımı okuyarak tamamlamaya çalıştım.

Şayet Microsoft'un online eğitimine erişiminz yok ise Udemy'deki AZ-204 Developing for Microsoft Azure Exam Prep eğitimi benzer bir içeriği sunuyor. Konuları teorik bilgi üzerinden anlatmak yerine daha çok Azure Cloud Platform üzerinde pratik olarak anlatmayı tercih etmiş eğitmen.
Bu içeriğin faydası, eğitim tekrarının yanı sıra AZ-204 sertifika sınavının son kısmında yer alan lab sınav bölümüne aşina olmayı kolaylaştırması oldu benim için. Yazımın ilerleyen bölümünde bunla ilgili detay vermeye çalışacağım.
Kayıt olduğum online eğitimi aldıktan sonra kendimi eksik hissettiğim konuların bölümlerini bu pratik eğitim üzerinden takip edip deneme sınavını çözdüm.

Eğitim materyallerini bitirdikten sonra yine Scott Duffy'nin hazırladığı 4 ayrı deneme testini içeren AZ-204 Microsoft Azure Developer Practice Tests isimli eğitimi de alıp test materyalini çözdüm.

Microsoft ESI Exam Prep Eğitimi

Microsoft ESI platformu ile sertifika için gerekli tüm materyalleri hap haline getirip sunmuş. Online eğitimi aldıktan sonra sınav hazırlık eğitimi kategorisindeki Exam Prep eğitimini aldım. Bu eğitim 4 saatlik ve yine online bir eğitim. Bu eğitim Sınav hakkında genel bilgilendirme, sınav konularının özeti, örnek soru çözümleri içeriyor. Stream video olarak izliyorsunuz eğitimi, istediğiniz zaman pause edebiliyorsunuz, sorunuz olursa mesajlaşma panelinden canlı olarak sorunuzu iletip cevap alabiliyorsunuz.
Bu eğitimin faydası örnek soruları görmek ve AZ-204 sınavının lab kısmı hakkında bilgi edinmek oldu. Bu arada sınava online olarak kayıt olurken bu bahsettiğim eğitim de seçenek olarak sunuluyor. İsterseniz ücreti karşılığında alabiliyorsunuz.

AZ-204 Sertifika Sınav ile İlgili Tavsiyeler

İlk tavsiyem sınava dinlenmiş, sakin bir kafa ile girmeniz. Ben haftaiçi mesai sonrası girdim, sınavın ilk dakikalarında hatta ettiğimi anladım.
Sınav soruları çok uzun metinler içerebiliyor. Bu tarz soruları önce hızlıca tarayıp, seçeneklere gözatıp soruda ne isteniyor ve neden bahsediliyor anlayıp, sonrasında detaylı okumak vakit kazandırıyor. Aksi halde tekrar okumanız ya da sorunun belli bölümlerine tekrar dönmeniz gerekebiliyor.
Bazı sorular tek uzun metin olarak verilip, iki veya üç ayrı şekilde farklı çözümler sorulabiliyor. Yani vakayı okuyup, bu vakaya farklı çözümleri farklı sorular şeklinde cevaplıyorsunuz.
Bazı sorular, özellikle dockerfile soruları, komutları seçenekler arasından sürükleyip sıralama şeklinde olabiliyor. Doğru komutları doğru sırada seçip cevaplamanız gerekiyor. Sorudaki her detay bir komutu netleştiriyor.
Programlama soruları, Microsoft .NET framework'te ve çeşitli Microsoft SDK'larında çalışmış yazılımcılar için bi nebze kolay olabiliyor. Sorudaki kütüphaneyi hiç bilmeseniz bile SDK'lara aşinalık ile çözebiliyorsunuz soruları.
Azure CLI, PowerShell komutlarının hep kendine has bir dizilimi var, bu dizilime lab çalışmalarında ve eğitimlerde aşina olduğunuzda, bilmediğiniz komutları dahi tahmin edebiliyorsunuz.

Kendi tecrübeme göre dikkat etmek gereken konuları çıkarmaya çalıştım, umarım faydası olur :

Azure Storage tipleri ve hangi durumlarda ve birbirlerinden farklarına
Azure mesajlaşma çözümleri ve birbirinden farklarına
Kaynakların CLI, PowerShell ve .NET SDK kodları ile nasıl yaratılıp yönetileceğine
Docker komutları ve belli bir senaryo için image oluşturma scripti ve sıralamasına
Storage tierlarını anlamak ve birbirlerine avantajlarına
API Management ile sunulan API'lere kısıt koyma yöntemlerine

aşina olmak gerekiyor.

Ayrıca sınavın son bölümü, daha önce başka sınavlarda rastlamadığım pratik bilgiyi ölçmeye çalışan vaka şeklinde ilerliyor. 5-10 soruyu tek bir vaka içerisinde soruyorlar. Vakaya konu olan şirketin tarihçesinden mevcut sistem mimarisine, mevcut uygulamalara açılmış olay kayıtlarından istenen çözümlerin detayına kadar çok fazla materyal sunuluyor. Bu kısımda vaktinizi iyi değerlendirmeniz gerekiyor. Tüm materyali anlayıp sonra sorulara geçmek mantıklı ve mümkün değil, çünkü soruyu okuduğunuzda tekrar materyale dönüp detayları taramanız gerekiyor.
Bundan dolayı öncelikle elimizde ne tarz bilgiler var diye hızlı bir tarama yapmanız ama detaya inmemenizi öneririm. Tüm dökümana hızlıca bakıp, ilk soruyu okuyun, sonra bahsi geçen olay kaydı, istenen mimari ya da çözümle ilgili dökümana dönüp detayları okuyun, sonra soruyu çözün. Bu yöntem sınavın bu kısmında daha hızlı ilerlemenizi sağlayacaktır.

Sınav benim açımdan öyle vaktimin bol bol yettiği ve erken bitirebildiğim tipte bir sınav olmadı, son dakikalarda iki soruyu fazla düşünemeden kafadan atmak zorunda kaldım.
Çok fazla metin ağırlıklı ve zihninizin açık olması gereken tipte bir sınav. Sabah saatleri taze zihin ile daha başarılı olacağımı düşünüyorum.
Tüm soruları yanıtlamaya çalışın, üç yanlış bir doğruyu götürmüyor. Şıkları eleyip, en olası seçenekler arasından birini mutlaka seçin.
Emin olmadığınız soruları işaretlemek iyi bir tercih olabiliyor. Bir sorunun açıklama metni, bir diğer sorunun cevabı olabiliyor. Dönüp elinizdeki bilgi ile emin olmadığınız soruyu daha rahat cevaplayabiliyorsunuz.

Ayrıca şu kaynakta sınavlar hakkında detay bilgi ve soru çeşitleri ile ilgili çok güzel videolar mevcut.

AZ-204 Sertifika Sınavına Nasıl Girebilirim ?

Sınava hazırlıklarınızı yaptınız, örnek sınavları tamamladınız ve kendinizi hazır hissediyorsunuz. Artık sınavı alma vakti geldi. Bu noktada iki seçenek mevcut. İlk seçenek bir anlaşmalı test merkezine kayıt olup fiziki olarak test merkezinde sınava katılmak.
Bunun faydası evinizde sınava uygun ortamı hazırlamanıza gerek kalmadan sınava özel hazırlanmış ortamda sınava katılıyor olmak.
Diğer bir seçenek ise Pearson VUE üzerinden online olarak sınava girmek. Sınav ortamınızı ve ön hazırlıkları kendiniz hazırlayıp sınava giriyorsunuz, kamera ile izleniyorsunuz, sınava girme deneyimi birebir test merkezi ile aynı.
Kariyerimin ilk yıllarında sınav merkezlerinde sınava girmiştim. AZ-900 ve AZ-204'ü online olarak aldım. Sınava nasıl kayıt olunur, voucher'ınız var ise nasıl kullanılır bunların hepsi şu dökümanda detayları ile anlatılıyor.

Size uygun tarihi seçip sınava kaydolduktan sonra kayıtlı mailinize sınavla ilgili ön kontrol komutları geliyor. Buradaki örnek test uygulamasını çalıştırıp bir sorun yaşamadığınızdan emin olun. Sınav günü bu örnek uygulamanın asıl versiyonunu kullanıyor olacaksınız. hoş olmayan bir sürpriz yaşamamak için bu adım çok önemli.
Sınav günü geldiğinde yarım saat öncesinden sisteme girin. Sizden sınav ortamınızı ve kimlik bilgilerinizi kayıtlı telefonunuzdan resim olarak çekip göndermeniz beklenecek. Bilgisayarınızı elektronik aletlerden özellikle tv veya ek monitör gibi ekranlardan uzak bir masada konumlandırın. Işık seviyesi web cam'de rahat görülebileceğiniz seviyede olmalı.
Bilgisayarınızın ve oturacağınız sandalyenin dört bir yanından resmini çekip göndermeniz için bir link gönderiliyor. Kimliğinizin önünü ve arkasını çekip aynı uygulama vasıtasıyla yüklüyorsunuz.
Sonrasında telefonuzu masadan uzak bir yere koyup sınavın başlamasını bekliyorsunuz.
Sınav sırasında etrafınızda su, kalem kağıt, telefon gibi herhangi bir şey bulunmamalı. Ortamda herhangi bir ses bulunmamalı.
Sınav başlamadan hemen önce bir mesaj uygulaması açılıp, sizi izleyecek kişi sizinle bağlantı kuruyor, ortamınızı kontrol ediyor, bilgisayarınızı yavaşça 360 derece döndürerek ortamınızı görmek istiyor. bu istenenleri tamamladıktan sonra sınavınız için uygunluk veriyor.
Dış ortam seslerini kesmesi için kulaklık takmak istedim, fakat izin verilmedi.
Sınav sırasında kamera alanından çıkmamaya çalışın. Ben zorlandığım yerlerde bilgisayara eğildiğim için iki kere uyarı aldım, robotik bir şekilde kas ağrıları ile sınavı bitirmek zorunda kaldım :)
Sınav içeriği ve soru geçişleri ile ilgili bilgileri yukarıda paylaştığım için bu kısma değinmiyorum.
Sınavı tamamladığınız gibi sonuç hesaplanıp size bildiriliyor, aynı şekilde kayıtlı mail adresinize ve Microsoft sertifikasyon dashboard'ınıza anında ekleniyor.

Elimden geldiğinde detaylı bir şekilde tecrübelerimi not alıp paylaşmaya çalıştım.
Atladığım veya tam açıklayamadığım bir kısım var ise bana ulaşmaktan çekinmeyin, cevabı biliyorsam paylaşmak isterim :)

Sınava girmek isteyen arkadaşlara şimdiden boş şans !

SonarCube Bulgu Çözümleri : IDisposible arayüzünün uygulanması

merhanersoy@gmail.com — Pzt, 15 Haz 2020 00:47:00 +0300

İki yılı aşkın süredir şirketimizin gündeminde olan Sonar Cube kod analis uygulaması vasıtasıyla projelerimizi kod analizine tabii tutup, kod kalitemizi yükseltmeye ve yüksek tutmaya çalışıyoruz. Bu kapsamda ekiplerimizde bazı bulgu çözümleri noktasında sorular ve destek talepleri gelebiliyor. Bir yazı dizisi ile bu destek talebi gelen bulgular ya da Sonar Cube kod analiz kuralları hakkında bir yazı dizisi yapmaya karar verdim.

Classes with "IDisposable" members should implement "IDisposable"

Bu yazımda ele alacağımız Sonar Cube kritik hata bulgusu : Classes with "IDisposable" members should implement "IDisposable"

Bu analiz kuralı kritik bulgu seviyesinde ve gayet önemli bir noktaya parmak basıyor. Uygulamamız içersinde kullandığımız kaynakları bırakmamamız durumunda sunucularımızda meydana gelebilecek performans sorunları ve sistem kaynaklarının kötüye kullanımına sebep olacak durumların önüne geçmeye çalışıyor.

Sonar bulgu açıklamasında örneğinin iletildiği gibi, projemizdeki bir sınıf eğer dispose edilmesi gereken bir kaynağı sınıfın bir üyesi olarak kullanıyor ise sınıfın IDisposible arayüzünü uygulayıp bu kaynağı Dispose metodunda elden çıkarması gerekir. Ya da bu kaynak sınıfın bir üyesi olarak değil de gerekli olan metod içerisinde yaratılıp using bloku içerisinde kullanılabilir.

Bu çözüm uygulanınca yeni bir sonar code smell’i yaratıyor olabiliriz : "IDisposable" should be implemented correctly

Bu code smell’i çözmek için de eğer sınıfımız başka sınıfları türetmiyor ise sınıfı mühürlemek yani sealed hale getirmek, aksi halde de aşağıdaki gibi geliştirme yapmak sorunu çözecektir. Yani bu yazımda biri kritik bulgu, biri de code smell olan iki ayrı kod analiz bulgusuna uygulanacak çözümü inceliyor olacağız.

Örnek Çözüm 1

public class ResourceHolder : IDisposable
{
        private FileStream fs;

        public void OpenResource(string path)
        {
            this.fs = new FileStream(path, FileMode.Open); 
        }

        public void CloseResource()
        {
            this.fs.Close();
        }

        public void Dispose() { 
		Dispose(true); 
		GC.SuppressFinalize(this); 
	} 

	protected virtual void Dispose(bool disposing) { 
		this.fs.Dispose(); 
	}
}

Örnek Çözüm 2

public sealed class ResourceHolder : IDisposable
{
        private FileStream fs;

        public void OpenResource(string path)
        {
            this.fs = new FileStream(path, FileMode.Open);
        }

        public void CloseResource()
        {
            this.fs.Close();
        }

        public void Dispose()
        {
            this.fs.Dispose();
        }
}

Örnek Çözüm 3

public class ResourceHolder
{
        public void OpenResource(string path)
        {
            using (FileStream fs = new FileStream(path, FileMode.Open))
            {
                // burada fs'i kullanalım
            }
        }
}

Sonuç

IDisposible arayüzü ve doğru kullanımı ile alakalı iki farklı sonar kod analis kuralını incelemiş ve üç farklı çözüm önerisi getirdik. Bu yazımın devamında benzer Sonar Cube Kod Analiz kurallarına değiniyor olacağız. Eğer siz de belli bir kural hakkında detay ve çözüm önerileri istiyorsanız bana ulaşıp haber vermeniz yeterli, kodu inceleyip beraber bir yazı ele alabiliriz.

WCF Client Kaynaklarının Elden Çıkarılması

merhanersoy@gmail.com — Paz, 16 Şub 2020 15:23:00 +0300

Blog yazılarıma verdiğim uzun bir aradan sonra ısınma amaçlı olarak, geçtiğimiz hafta uğraştığım bir sorun ve çözümü ile yazılarıma tekrar dönmek istiyorum. Yaklaşık 6 senedir kullandığımız bir WCF uygulamamızı windows service olarak host ediyoruz. Uygulama yıllardır gayet performanslı ve sorunsuz çalışrıken son 6 aydır gün aşırı farklı sebeplerden sorun oluşturmaya başladı. Bir süredir bakımını yaptığımız uygulamada son karşılaştığımız sorunlardan biri servise gelen taleplerin yoğun olduğu anlarda "Thread was being aborted" hatası ile taleplerin kesilmesi ve işlemlerin yarım kalması idi. İlk şüphelendiğimiz nokta, servise aynı sunucudan iki farklı talep oluştuğunda yeni açılan bağlantının önceki aktif bağlantıyı kopartıyor oluşu idi. Konu bir yandan tutarsız gözüküyor, bir yandan da sorunun sebebinin bu olduğunun tam bir kanıtını bulamıyorduk.

Stackoverflow'da yaptığımız araştırmalar sorunucunda sorunun genel bir programlama hatasından kaynaklandığını, istemci uygulamada oluşturulan istemci proxy nesnelerinin Close metodu ile kapatılmadan elden çıkarılmaması, yoğun anlarda uygulamanın "Thread was being aborted" hatası atmasına sebep olduğunu gördük. Gerçekten de servis çağrılarında sürekli yeni bir istemci nesne yaratıp, istek sonucu dönünce istemciki kapatmadan işlemi sonlandırıyordu uygulamamız. Doğru kullanım ise aşağıdaki gibi kullanılan kaynakları sağlıklı bir şekilde serbest bırakması :

var client = new WCFServiceProxy();
try
{
    client.DoSomeWork();
    client.Close();
}
catch (Exception e)
{
    // log...
    client.Abort();
    throw;
}

StackOverflow'da karşılaştığım sorun ve çözüm : “Thread was being aborted” in WCF Service Call

Bulduğumuz çözüm sorunu çözecek fakat ilerde bu yanlış kullanımın önüne geçmeyi sağlamayacaktı. Yazılımcı servis kullanımı sonrası yarattığı istemciyi kapatmayı unuttuğu takdirde ileriki zamanlarda tekrar sorun ortaya çıkacak. Bundan dolayı istemci proxy'nin yaratılmasını sağlayan bir yardımcı sınıfımız olduğu gibi, bu yaratılan istemcinin olması gerektiği gibi kapatılmasından da sorumlu olmalı idi. Yani tek bir noktada istemci sınıfını yaratıp, hayat döngüsünü yöneterek, kullanan yazılımcıdan encapsule etmeliydik.

WCF istemci proxy sınıfını using ile kullanıp gerektiğinde elden çıkarılmasının sağlanması da bir opsiyon fakat bu çözümde yine yazılımcının unutması halinde soruna sebep olabilecek bir durum. Ayrıca Marc Gravell'in şu makalesinde bahsettiği üzere framework'te bulunan bazı sorunlardan dolayı ClientBase sınıfının her zaman düzgün dispose edilemiyor. Marc Gravell makalesinde extension metodlar ile istediğim tarz çözüme bir örnek vermiş. Ancak ben "Indisposable: WCF Gotcha #1" makalesindeki gibi bir çözüm ile proxy istemcisinin yaratılmasını ve sonlandırılmasını sağlayacak komple bir çözümü tercih etmeyi daha uygun görüyorum.

İstemciyi yaratıp kullanan bir örnek :

Service<IWCFServiceProxy>.Use(client=>
{
  client.DoSomeWork();
}

Use extension metodu :

public delegate void UseServiceDelegate<T>(T proxy);

public static class Service<T>
{
    public static ChannelFactory<T> _channelFactory = new ChannelFactory<T>(""); 

    public static void Use(UseServiceDelegate<T> codeBlock)
    {
        IClientChannel proxy = (IClientChannel)_channelFactory.CreateChannel();
        bool success = false;
        try
        {
            codeBlock((T)proxy);
            proxy.Close();
            success = true;
        }
        finally
        {
            if (!success)
            {
                proxy.Abort();
            }
        }
    }
}

Yukarıdaki metodda görüldüğü gibi UseServiceDelegate delegate'i ile yazılımcının servis çağrısı, Use extension metodu içerisinde oluşturulan istemci sınıfı kullanarak çalıştırılıp, delegate tamamlanınca istemci olması gerektiği gibi kapatılıyor. Bizim kendi örneğimizde olduğu gibi WCF istemcisine geçilen ek konfigurasyon değerleri var ise, ki bu konfigurasyonları uygulamanın config dosyası yerine kodda geçmeyi uygun gördük, metod içersinde tanımlanabilir. Böylece istemci sınıfın yaratılması ve kapatılması ile ilgili tüm detayları kullanıcı yazılımcıdan saklamış ve kod çoklanmasının da önüne geçmiş oluyoruz.

Bulut Uygulamaları İçin Dayanıklılık (Resiliency) Tasarım Desenleri

merhanersoy@gmail.com — Pzt, 20 May 2019 21:45:00 +0300

Dayanıklılık, zor durumlar ile başa çıkabilme, ayağa kalkabilme ve tekrar devam edebilmektir. Yazılım dünyasında dayanıklılık ise bir uygulamanın hata durumlarına düştüğünde durumu yönetebilmesi, tekrar çalışır hale gelebilmesi ve sorunlu durumdan tamamen kullanılmaz hale gelmeden kurtulabilmesi diyebiliriz. Uygulamanın devamlılığını sağlayabilmesi, geliştiricileri olarak bizlerin sorumluluğudur. Ayrıca bu tarz durumlarda yine sorunu çözebilmek için gecesi gündüzüne karışanlar gene biz yazılım geliştiriciler oluyoruz. Dolayısıyla uygulama geliştirirken dayanıklılık konusu da tasarımımızın bir parçası olmalı, gerekli yerlerde mimarimize bu tarz sorunlu durumlarda hayatımızı kolaylaştıracak müdahaleler yapmalıyız. MSDN'in bu linkteki makaleler zincirini okurken kendi adıma aldığım kısa notlar olarak yazdığım bu yazıdaki çoğu görsel kaynak da yine aynı makalelerden alınmıştır.

Bulkhead Tasarım Deseni

Bulkhead, gemilerde kullanılan, geminin gövdesini odalara ayırarak tehlikeli durumlara karşı gemiyi koruma yöntemidir. Bu sayede ayrık odalardan birinde meydana gelecek kaza ve su sızıntısı, geminin tamamının su almasını engeller.

Uygulama içerisinde özellikle yoğun kullanılan servisleri ayrı uygulama havuzları (pool) ile çalıştırarak kaynakların paylaşılması sağlanır. Bir serviste oluşacak sistem yoğunluğu ya da hatalar silsilesi, sadece bir havuzu etkileyeceğinden, uygulama altındaki diğer servisler etkilenmeden çalışmaya devam edebilirler. Bazı senaryolarda uygulamanın mimarisinin anlaşılmasının zorlaştırabilir, bu gibi durumlarda faydası ile karşılaştırarak tercih edilebilir.

Devre Kesici (Circuit Breaker) Tasarım Deseni

Uygulamalarımız bazen hata durumuna düşer ve bu hata durumlarından çıkması, müdahale süresi vakit alabilir. Bu tarz bir durumda, uygulama gelen istekleri karşılayamaz ve sürekli hatalar verir. Belki arka planda yarım işlemler bırakır. Ya da uygulama zaman aşımına düşme durumlarında istemci uygulamaya hata mesajının dönmesi vakit alabilir. Biriken yeni talepler gitgide daha fazla soruna sebep olabilir. İşte bu tarz sorunlu anlarda uygulamanın bu durumu, tamamıyla hata durumuna düşmeden, kolay bir şekilde atlatabilmesi için tasarlanmış devre kesici - circuit breaker tasarım desenini kullanabilir.

Bu tasarım desenine göre uygulamamız üç ayrı durumda bulunabilir.

Kapalı Durum (Closed) : Kapalı elektrik devresi gibi düşünebiliriz. Uygulamamız gelen isteklere cevap verebilir durumdadır ve gelen istekleri işler, cevap döner. Hata alınması durumunda bir sayaç değeri arttırılarak tutulur.

Yarı Açık Durum (Half-Open) : Uygulama gelen isteklerin bazılarını işler, bazılarına ise hızlıca hata mesajı döner. İşlenen istekler hata alırsa sayaç arttırılmaya devam eder.

Açık durum (Open) : Uygulama stabil durumda değildir. Gelen isteklere belli bir zaman aşımı süresine kadar hata döner ve istekleri işlemeye çalışmaz.

Bu tasarım deseni dış kaynaklara erişilen durumlarda tercih edilebilir. Uygulama içi kaynakların kullanıldığı durumlarda ek bir mekanizma olacağından yük getirebilir.

Telafi İşlem Tasarım Deseni

Başlattığımız bir işlemin hata alması durumunda işlemin rollback edilmesi geliştirme sırasında sıklıkla çalıştığımız bir senaryodur. Eğer çalıştığımız sistem, birbirine bağlı microservice veya entegre uygulamalardan oluşuyor ise rollback mekanizması sıkı kurallara sahip ve tutarlı olamayabilir. Her yapılan işlemin tersini veya hata durumunda yapılacak işlemleri içeren bir metodunun olması gerekir. Bazen parçalı işlemlerden bir kısmı gerçekleştirilip, bir aşamasında hata alındığında, uygulamaya bağlı olarak, her zaman işlemler tersine çevrilmeyebilir. Yerine alternatif işlemler yapıldığı durumlar da olabilir. Mesela birden fazla noktaya uçuş planladığımız bir uçuş planının bir kısmı gerçekleştirilirken, bir aşamasında hata alındığını düşünelim. Bu hata alınan aşamada alınmış olan biletleri iptal etmek yerine belki kullanıcı onayı ile farklı bir tarihteki uçuş ile veya farklı bir sağlayıcıdan girilecek bir tarife ile alternatif bir çözüm bulunabilir. Bu mekanizma geliştirilen uygulama özelinde bir senaryo tasarlanarak incelenmelidir. Bu tasarımlar sırasında rollback veya telafi işlemin gerçekleştirilmesi sırasında alınabilecek hatalar da göz önünde bulundurulmalı.

Aslında benim fikrim bu konu dayanıklılık konusu dışında zaten tasarım aşamasında düşünülmesi gereken senaryolardan biri. Sistem hataları olması durumunda uygulamanın dayanıklılığından ziyade müşteri deneyimini iyileştirmeye yönelik bir çalışma. Ayrıca hatalı ya da yarım kalıp tamamlanamayacak işlemler konusunda nasıl aksiyon alınacağının yönetimi yine bu tarz çalışmalarda düşünülmesi gereken başlıklardan.

Uygulama Sağlığı İzleme Noktaları (Health Monitoring Endpoints)

Uygulamalarımız arka planda bir çok kaynağı kullanıyor ve bu kaynaklara erişimde sunucu bazlı sorunlarla karşılaşıyor olabiliriz. Uygulamamız bulutta veya sunucuda çalıştığı durumlarda her an elimizin altında olmadığından sunucularda olabilecek sorunları sorun iletilmeden fark edebilmek çok önemli. Bu tarz sistem kaynaklarına erişim ve network seviyesindeki gecikmeleri izleyebilmek için uygulamalara bu kontrolleri yapan birer erişim noktası tanımlanıp, belli aralıklarla uygulamanın sağlığı ve gelen isteklere cevap süreleri kontrol edilir. Hatta uygulamanın başka servislere entegrasyon noktaları ve cevap süreleri de kontroller içerisine alınıp, tüm erişim ve performans takibi yapılabilir.

Kısaca şu kaynakların erişimi ve cevap sürelerini izlemek faydalı olacaktır :

Var ise disk erişimi
Var ise ağ dizini erişimi
Veritabanı erişimi
CDN'de tutulan script veya css gibi kaynaklar var ise bunlara erişim
Dış entegrasyon servislerine erişim
Sertifika validasyonları

Lider Seçim Deseni

Uygulamalarımızda toplu olarak ve birbiri ile koordineli olarak çalışması gereken işlemler yer aldığında bir thread veya instance tarafından işlenen işin bir diğer thread veya instance tarafından ezilmesini engellemek ve eldeki tüm kaynakları koordine edecek bir lidere ihtiyaç duyarız. Bu liderin kaynaklar içerisinden seçilip, liderin bir sorun yaşaması halinde ya da lidere erişilemez hale geldiği bir durumda yeni bir liderin seçilebilmesini sağlayan bir tasarıma ihtiyaç olur. Liderin diğer kaynaklar gibi işi yapması gerekmeyebilir. Liderin tek işi koordinasyon ve diğer kaynakların birbiri ile çakışmaması olabilir. Liderin sistem için bir darboğaz oluşturmaması gerekir. Eğer tüm kaynaklar aynı kodu çalıştırıyor ise tüm kaynaklar lider olabilme potansiyeline sahip demektir, bu durumda birden fazla lider seçimi yapılmaması dikkat edilecek önemli noktalardan bir tanesidir.

Aşağıdaki örneğe bakarsak, işlemleri yapan üç ayrı instance görüyoruz. Üçü de aynı liderlik metodunu çağırıyor, 1 nolu instance metodu ilk çağırdığı için liderlik rolünü alıyor ve metodu locklıyor. 2 ve 3 nolu instance'lar liderlik rolünü alamıyor, ama belli aralıklarla liderlik rolünü metodunu çağırmaya devam ediyorlar.

Liderliği elde eden 1 nolu instance elindeki işleri diğer 2 ve 3 nolu instance'lara paylaştırıyor. Bu arada liderin sağlıklı olduğunu ve işini yapabildiğini kontrol edebilmek için lider belli zaman aralığında liderlik vasfını yeniliyor. Eğer liderde bir sorun var ise lock kalkıyor, yapılan işlemler geri alınıyor. Diğer instancelar'dan biri lider olup koordinasyonu sağlıyor.

Mesaj Kuyruğu Tabanlı Yük Dengeleme

Enterprise uygulamalarda yük yönetimi ve servisler arası bağımlılığı azaltma amaçlı olarak sıklıkla kuyruk tabanlı çözümler kullanırız. Uygulamamıza gelen mesaj sayısı zamana göre değişebiliyor ve zaman zaman uygulamanın karşılayabileceği seviyelerin üzerine çıkıyor ise kuyruk çözümü derdimize çare olacaktır. İşlenmek üzere uygulamamıza gelen mesajlar mesaj kuyruğunda, uygulamamız müsait oldukça uygulamamıza beslenerek yük kontrolü sağlanabilir. Yada mesajlar, kuyruk tarafından tüketici uygulamalarımıza yük durumlarına göre paylaştırılabilir. Özellikle veritabanı gibi tek bir kaynağı işleyen fonksiyonlarda aynı anda birden fazla işlem kaynağa erişimde düğüm oluşturup uygulamamızı cevap veremez hale getirebilir. Bu tarz durumlar için çözüm işlenecek mesajları kuyrukta biriktirip, peyderpey alıp işlemektir.

Tekrar Deneme

Uygulamamızın çalışması sırasında sıklıkla hatalar ile karşılaşırız. Kimi hatalar ağ kesintileri veya servis yoğunluklarından kaynaklı olup, geçici olabildiği gibi kimileri ise uygulamada bulunan mantık hatalarından kaynaklı kalıcı hatalar olabilir. Hatalara, tipine göre tekrar deneme mekanizmasının kurulması uygulamanın dayanıklılığını arttırıcı önlemlerden biridir. Hata durumlarında alınabilecek aksiyonları temelde aşağıdaki gibi düşünebiliriz.

İptal : Oluşan hata kalıcı bir hatadır, aralıklarla tekrar tekrar işlemin denenmesi işlemi başarılı yapmaz. Bu tarz durumlarda işlem iptal edilip, loglanarak raporlanmalıdır.
Tekrar Deneme : Oluşan hata, nadir oluşan geçici bir sistem aksaklığından dolayı oluşmuştur. Bu tarz hataları tekrar denemek işlemi başarılı sonlandırabilir.
Ertelemeli Tekrar Deneme : Oluşan hata, yine nadir oluşan geçici bir sistem aksaklığından dolayı oluşmuştur. Fakat tekrar deneme işlemi art arda denemelerde tekrar tekrar hata alınıyor ise bekleme süresi arttırılarak tekrar deneme yapılır, hatta belli sayıda denemeden sonra limit aşımından işlemler iptal edilir. Böylece sistemde hata alan işlemlerden dolayı bir yük yaratılmaz.

Tekrar deneme tasarımları yapılırken, agresif ertelemeler vermek sistemi negatif yönde etkileyebilir. O yüzden uygun bekleme sürelerinin belirlenmesi çok kritiktir. Ayrıca yukarıda bahsettiğimiz Devre Kesici Tasarım Deseni mekanizma içerisine dahil edilerek daha kontrollü bir tekrar deneme mekanizması tasarlanabilir. Yeniden denenecek işlemlerin her defasında yarım kalmış kayıtlar yaratma olasılığı olduğundan dolayı denemeler atomik ve hata durumunda kendi kendini geri alabiliyor olmalı (rollback). İşlem her yeni denemede sanki sıfırdan sisteme giriyor gibi çalışabilmeli ve hata durumunda sistemde kalıntı bırakmamalı.

Tekrar deneme mekanizmasını kurgularken, tekrar denenecek hataların iyi analiz edilmesi gerekir. Her hatanın tekrar denemeye sokulması sistemde beklenmedik sonuçlar doğurabilir. Hata logları iyi analiz edildikten sonra tekrar deneme mekanizması kurulup, mekanizma için güvenli, yani tekrar denemeye müsait hatalar tespit edildikten sonra kullanıma alınması daha uygun olacaktır.

Örneğin yukarıdaki servis çağrısı, ilk denemede HTTP 500 hatası alıyor. Belli bir süre beklenip mekanizma tarafından tekrar deneneniyor, tekrar HTTP 500 hatası alıyor.

Önceki beklemeden daha uzun bir süre beklenip, tekrar deneniyor ve bu sefer HTTP 200 cevabı alıp işlemi başarıyla tamamlıyor.

Scheduler, Agent, Supervisor Tasarım Deseni

Yukarıda öğrendiğimiz tasarım desenlerinin topluca birlikte kullanıldığı bir desen olan Scheduler Agent Supervisor tasarım deseni, bir işlemi gerçekleştirmek için gerekli olan birbirine bağlı işlerden oluşan iş akışının yönetimine odaklanıyor. Bu tasarım deseni isminden de anlaşılacağı üzere desen üç parçadan oluşuyor.

Scheduler : İş akışı içerisindeki işleri organize edip çalıştıran, aralarındaki orkestrasyonu yapan yapı.

Agent : Her bir işi çalıştıran yapı, scheduler tarafından yönlendirilen yapı aynı zamanda. İş eğer hata alırsa, yarım işlemleri geri alan yapıyı da içeriyor olmalı.

Supervisor : Scheduler tarafından çalıştırılan işlerin durumlarını takip eden, gerekli durumlarda tekrar çalıştırılması için scheduler'ı tetikleyen yapı.

Agent'ların hata alması veya timeout olması durumunda supervisor'lar devreye girip işi geri alıyor. Fakat supervisor'ın hata alması veya cevap vermemesi durumunda scheduler, bu işi komple hatalı duruma çekip iptal etmelidir. İptale çekilen iş için yeni bir supervisor ile iş tekrar denenmesi halinde, önceki supervisor agent'a veya scheduler'a tekrar müdahale edememelidir. Lider seçimi tasarım deseni burada supervisor seçimi ve çalışması için uygun yöntem. Karmaşık bir yapıya sahip bir sistem olduğu için yapının tüm hata senaryolarını içeren bir testi yapılmalı.

50 Soruda Yapay Zeka - Kitap İncelemesi

merhanersoy@gmail.com — Cum, 3 May 2019 14:58:00 +0300

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

merhanersoy@gmail.com — Paz, 9 Ara 2018 03:36:00 +0300

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

merhanersoy@gmail.com — Pzt, 19 Kas 2018 02:36:00 +0300

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.

Building Evolutionary Architectures: Support Constant Change - Kitap İncelemesi

merhanersoy@gmail.com — Paz, 3 Haz 2018 19:09:00 +0300

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.