Her Endpoint’e bir oda ver baba :)

Merhaba sevgili dostlarım! 👋

Uzun zaman oldu, değil mi? Bugün size hem oldukça şık hem de “neden daha önce böyle yazmıyordum?” dedirtecek bir konudan bahsedeceğim: ASP.NET Core Minimal API ve onunla neredeyse el ele tutuşmak için doğmuş olan REPR Pattern.

Hazır mısınız? Hadi kolları sıvayalım!

Önce Biraz Geçmişe Dönelim

Yıllarca ASP.NET Core projelerinde şunu yaptık: Bir Controllers klasörü açtık, içine UserController, ProductController, OrderController gibi dev dev sınıflar koyuşturmaya başladık. Hepsi bir arada, mutlu mesut…

Ama bir süre sonra o UserController büyüdü. Büyüdükçe büyüdü. 500 satır oldu, 800 satır oldu. Sonunda ekipteki yeni arkadaş o dosyayı açtığında yüzü asıldı.

“Bu ne böyle?” dedi.

Haklıydı. Biz de aslında içten içe biliyorduk. Bir sınıf hem kullanıcı kaydını, hem giriş işlemini, hem şifre sıfırlamayı, hem profil güncellemeyi, hem de “bu kullanıcı admin mi?” kontrolünü yapıyordu.

Peki bunu fark ettiğimizde ne yaptık? Controller’ı böldük. Ama bu sefer de başka bir sorunla yüz yüze geldik — birazdan ona geleceğiz. Önce hikayemizi biraz daha ilerletelim.

Şirket Büyüdü, Sorunlar da Büyüdü: Bir Analoji

Küçük bir şirket hayal edin. Beş kişilik bir ekip: herkes her işi yapıyor. Muhasebe de, müşteri ilişkileri de, üretim de, lojistik de hep aynı masada. Şirket küçükken bu yürüyor; herkes birbirinden haberdardı, kararlar hızlı alınıyordu.

Ama şirket büyüdü. Müşteri sayısı arttı, ürün çeşitlendi, ekip genişledi. Ve artık o beş kişilik masa kaosa döndü. “Fatura kim kesiyor?” “Sevkiyatı kim takip ediyor?” “Müşteri şikayet etti, kim ilgilenecek?”

Çözüm belli: Departmanlar kuruldu. Muhasebe departmanı, lojistik departmanı, müşteri hizmetleri departmanı… Her departmanın net bir sorumluluğu var, net bir giriş noktası (talep alır), net bir çıkış noktası (sonucu iletir) var.

Bir müşteri siparişi geldiğinde şu olur: Talep satış departmanına girer → departman işlemi yapar → sonucu ilgili yere iletir. Başka bir departmanın bu akışa karışması söz konusu değil.

İşte REPR Pattern tam olarak budur: Her HTTP endpoint bir departman gibi çalışır. Kendi talebi (Request) alır, kendi işini yapar (Endpoint), kendi cevabını (Response) üretir.

Minimal API: Controller’ların Hafif Kardeşi

ASP.NET Core 6 ile hayatımıza giren Minimal API (Minimal Uygulama Programlama Arayüzü), Controller katmanını tamamen ortadan kaldırıyor. Program.cs içinde ya da küçük sınıflar aracılığıyla direkt olarak endpoint tanımlayabiliyorsunuz:

// Program.cs — Minimal API ile en basit hali
var app = WebApplication.Create(args);

app.MapGet("/api/products/{id}", async (int id, IProductService svc) =>
    await svc.GetByIdAsync(id) is { } product
        ? Results.Ok(product)
        : Results.NotFound());

app.MapPost("/api/products", async (CreateProductRequest req, IProductService svc) =>
{
    var product = await svc.CreateAsync(req.Name, req.Price, req.CategoryId);
    return Results.Created($"/api/products/{product.Id}", product);
});

// ... diğer endpointler

app.Run();

Temiz, sade, güzel. Controller yok, [HttpPost] attribute yok, ControllerBase kalıtımı yok.

“Tamam tamam, bu güzel de…” diyorsunuzdur. “Beş endpoint için bu yeterli ama ya elli endpoint olursa? Program.cs devasa bir dosyaya dönmez mi?"

Haklısınız! İşte tam bu noktada akıllıca bir ara çözüme gidebilirsiniz: Endpoint gruplarını extension method’larla ayırmak.

“Yeterli” Gibi Görünen Ara Çözüm: Extension Method’lar

Endpointleri gruplamak için şöyle bir yapı kurabilirsiniz:

// Extensions/ProductEndpointExtensions.cs
public static class ProductEndpointExtensions
{
    public static IEndpointRouteBuilder MapProductEndpoints(
        this IEndpointRouteBuilder app)
    {
        app.MapGet("/api/products/{id}", GetProductByIdAsync);
        app.MapPost("/api/products", CreateProductAsync);
        app.MapGet("/api/products", GetProductsAsync);
        app.MapPut("/api/products/{id}", UpdateProductAsync);
        app.MapDelete("/api/products/{id}", DeleteProductAsync);

        return app;
    }

    private static async Task<IResult> GetProductByIdAsync(int id, IProductService svc) { /* ... */ }
    private static async Task<IResult> CreateProductAsync(CreateProductRequest req, IProductService svc) { /* ... */ }
    // ...
}

Program.cs artık çok daha temiz:

// Program.cs
var app = builder.Build();

app.MapProductEndpoints();
app.MapOrderEndpoints();
app.MapUserEndpoints();

app.Run();

Her şey yolunda gözüküyor değil mi? Program.cs temiz, endpoint'ler gruplandı, Controller yok...

Ama durun bir dakika. O ProductEndpointExtensions dosyasına tekrar bakalım. Ürünle ilgili beş farklı endpoint var ve hepsi aynı sınıfın içinde. Bir endpoint için yetkilendirme eklemek istediğinizde, başka bir endpoint için cache politikası tanımlamak istediğinizde, hepsine aynı dosyadan dokunuyorsunuz.

Bu sizi tanıdık bir yere götürmüyor mu? 😏 Evet, isim değişti ama ProductController'ın şişmanlık sorunu burada da baş gösteriyor. Sorun katman değiştirdi, yok olmadı.

Sorun Sadece Controller’da Değil: Şişman Servis Problemi

“Tamam” diyorsunuz, “controller’ı böleceğim, her endpoint ayrı bir sınıf olacak. Ama iş mantığı (business logic) zaten servis katmanında, ne fark eder ki?”

İşte tam burada ikinci bir tuzak bizi bekliyor.

IProductService arayüzünüze (interface) bir bakın:

public interface IProductService
{
    Task<ProductDto> GetByIdAsync(int id);
    Task<IEnumerable<ProductDto>> GetAllAsync(string? search, int page);
    Task<ProductDto> CreateAsync(string name, decimal price, int categoryId);
    Task UpdateAsync(int id, string name, decimal price);
    Task DeleteAsync(int id);
    Task<bool> IsInStockAsync(int id);
    Task<IEnumerable<ProductDto>> GetByCategoryAsync(int categoryId);
    Task UpdateStockAsync(int id, int quantity);
    // ... devam ediyor
}

Bu arayüzü implemente eden ProductService sınıfı zamanla ne hale gelir? Tahmin edebilirsiniz: yüzlerce satır, onlarca metod, birbirine geçmiş sorumluluklar. Şişman nesne (fat object) problemi.

Ve işin kötüsü şu: CreateProductEndpoint yalnızca CreateAsync metoduna ihtiyaç duyuyor. Ama bağımlılık olarak IProductService'in tamamını alıyor. Stock güncelleme metodu da, kategori sorgulama metodu da, hepsi orada, kullanılmayı bekliyor. Test yazarken bu arayüzün tamamını taklit etmeniz (mock) gerekiyor.

Düşünsenize: Muhasebe departmanı bir fatura kesmek için tüm şirket yönetimine erişim yetkisi almak zorunda kalsaydı ne olurdu? 😄

Controller’ı bölmek sorunu çözmüyor. Servisi de bölmemiz gerekiyor. Ve her özellik (feature) kendi küçük, bağımsız biriminde yaşamalı.

İşte tam bu noktada REPR Pattern devreye giriyor.

REPR Nedir?

REPR, Request-Endpoint-Response kelimelerinin baş harflerinden oluşuyor. Steve Smith (Ardalis) tarafından popülerleştirilen bu yaklaşımda şu mantık var:

Her endpoint, kendi Request modeliyle gelir, kendi işini yapar ve kendi Response modeliyle döner.

Şirket analojisine dönersek: her departmanın net bir giriş formu (Request), net bir işlem süreci (Endpoint) ve net bir çıktı raporu (Response) var. Başka departmanlar bu akışa karışmıyor.

REPR Pattern ile Doğru Yaklaşım

Klasör yapımız şöyle olacak:

Features/
  Products/
    CreateProduct/
      CreateProductEndpoint.cs
      CreateProductRequest.cs
      CreateProductResponse.cs
    GetProductById/
      GetProductByIdEndpoint.cs
      GetProductByIdRequest.cs
      GetProductByIdResponse.cs
    GetProducts/
      GetProductsEndpoint.cs
      GetProductsRequest.cs
      GetProductsResponse.cs

Her “departman” kendi klasöründe yaşıyor. Şimdi CreateProduct örneğini yazalım:

// Features/Products/CreateProduct/CreateProductRequest.cs
public record CreateProductRequest(
    string Name,
    decimal Price,
    int CategoryId
);

// Features/Products/CreateProduct/CreateProductResponse.cs
public record CreateProductResponse(
    int Id,
    string Name,
    decimal Price,
    DateTime CreatedAt
);

Request ve Response modellerimiz hazır. Peki ama, tüm endpoint’leri tek tek eklemek de maaliyetli olmayacak mı? Aman dostlar… Dert ettiğiniz şeye bakın! Her endpoint’in implemente etmesi için bir marker interface tasarlarız ve bu işi de reflection ile çözeriz (Reflection. Bebişim benim 😊)

// Shared/IEndpoint.cs
public interface IEndpoint
{
    void Map(IEndpointRouteBuilder app);
}

Önce endpoint’imizi implemente edelim tabii

// Features/Products/CreateProduct/CreateProductEndpoint.cs
public class CreateProductEndpoint : IEndpoint
{
    public void Map(IEndpointRouteBuilder app)
    {
        app.MapPost("/api/products", HandleAsync)
           .WithName("CreateProduct")
           .WithTags("Products")
           .RequireAuthorization()
           .Produces<CreateProductResponse>(StatusCodes.Status201Created)
           .ProducesValidationProblem();
    }

    private async Task<IResult> HandleAsync(
        CreateProductRequest request,
        ICreateProductHandler handler,
        CancellationToken cancellationToken)
    {
        var product = await handler.HandleAsync(request, cancellationToken);

        var response = new CreateProductResponse(
            product.Id,
            product.Name,
            product.Price,
            product.CreatedAt);

        return Results.Created($"/api/products/{response.Id}", response);
    }
}

Bu arada dikkat ettiniz mi? Artık IProductService değil, ICreateProductHandler bağımlılığı var. Bu handler yalnızca ürün oluşturmayı biliyor. Başka hiçbir şeyi yok. Test yazarken sadece bu küçük arayüzü taklit etmeniz (mock) yeterli.

Şirket analojisine dönersek: satış departmanı fatura kesmek için tüm şirket yönetimine değil, sadece muhasebe birimine bağlanıyor.

Ve sahnede Reflection: Otomatik Kayıt Mekanizması

Pek tabii ki göz bebeğimiz Extension Method aracılığı ile reflection kullanarak, hem endpointleri servise ekliyoruz hem de eklenen endpoint’lerin Map fonksiyonlarını çağırıyoruz:

// Shared/EndpointExtensions.cs
public static class EndpointExtensions
{
    public static IServiceCollection AddEndpoints(
        this IServiceCollection services,
        Assembly assembly)
    {
        var endpointTypes = assembly
            .GetExportedTypes()
            .Where(t => t.IsAssignableTo(typeof(IEndpoint)) && !t.IsAbstract);

        foreach (var type in endpointTypes)
            services.AddTransient(typeof(IEndpoint), type);

        return services;
    }

    public static IApplicationBuilder MapEndpoints(this WebApplication app)
    {
        var endpoints = app.Services.GetRequiredService<IEnumerable<IEndpoint>>();

        foreach (var endpoint in endpoints)
        {
            typeof(IEndpoint)
                 .GetMethod("Map")!
                 .Invoke(endpoint, new object[] { app });
        }

        return app;
    }
}

Artık Program.cs gerçekten temiz hem de kalıcı olarak!

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddEndpoints(Assembly.GetExecutingAssembly());
// diğer servisler...

var app = builder.Build();

app.MapEndpoints();
app.Run();

Yeni bir endpoint eklediğinizde Program.cs'e, ProductEndpointExtensions'a, IProductService'e dokunmuyorsunuz. Sadece yeni klasörünüzü oluşturuyorsunuz ve sistem onu otomatik olarak buluyor. İşte bu! 🎉

Bu Yaklaşımın Faydaları Neler?

İşte sevgili dostlarım, özetle neler kazandık:

• Tek sorumluluk, gerçekten: Hem endpoint hem de handler katmanında her sınıfın tek bir amacı var.
• Kolay test yazımı: CreateProductEndpoint.HandleAsync için yalnızca ICreateProductHandler'ı taklit etmeniz yeterli. Dev servis arayüzleri yok.
• Takım çalışmasına uygunluk: İki kişi aynı anda farklı feature’larda çalışabilir, Git çakışması yaşanmaz.
• Kolay bulunabilirlik: “Ürün oluşturma nerede?” → Features/Products/CreateProduct/. Bitti.
• Bağımsız gelişim: Bir feature’ı değiştirmek, silmek veya taşımak diğerlerini etkilemiyor.

Sonuç olarak sevgili dostlarım, yolculuğumuz şöyle gelişti:

1. Büyük Controller’lar sorun çıkardı → Extension method’larla böldük
2. Extension method’lar aynı şişmanlığı taşıdı → Her endpoint’i ayrı sınıfa taşıdık
3. Servis katmanı da şişmanladı → Her özellik için küçük, odaklı handler’lar yazdık
4. Tüm bunları bir araya getiren yapıya REPR Pattern adını verdik
5. Projenin github linki burada: turkayurkmez/REPRDemo

Bir sonraki yazımızda görüşene dek kendinize çok iyi bakın dostlar!

On pleasure, craft, and the transformation of a developer

Hey folks!

As you may have noticed, AI developments have been creating quite a stir in the world of software developers lately — tension on one side, excitement on the other. Tension, because familiar methods and strategies are being disrupted. Excitement, because the very definition of limits is changing.

But before we get caught up in that tension-versus-excitement dilemma, I think we need to talk about how we even got here — to this moment where AI can write code. Let’s ask the question plainly: What is the real reason AI engineers and developers in general built these products in the first place?

If you ask those developers directly, they’ll offer you a whole list of arguments. But we’re after the root cause. So let’s broaden the question — not to a specific group or a specific product, but to all of humanity.

Why does humankind choose scientific and technological progress? The moment you ask the question that broadly, you naturally start thinking about its philosophical dimensions. And that’s both useful and important, because it gives us a wonderful opportunity to build a far more encompassing argument.

So let’s look for an answer… What is the driving force behind a scientist developing a theory, or an inventor creating a new tool? Pick any field of science, dive into any discipline of engineering. I’m confident you’ll always arrive at the same conclusion: these people do what they do because they derive profound joy from it.

So where does that joy come from? Aristotle — well, since we’re already in philosophical territory — makes a remarkably sharp observation here: joy is not found in reaching a goal, but in the act of moving toward it, in being fully immersed in the work itself. He calls this energeia. And that is precisely why great scientists are not happiest after solving a problem — they are happiest while solving it.

Yes, humankind does what it does because it finds joy in the doing. Now, look at where that leads us: the reason AI has reached this stage today is that a group of scientists, engineers, and developers simply kept doing the work they loved. Okay, okay — I can already hear you thinking I’m being romantic about it, pushing the financial side to the background. But on the contrary, I’d argue that the motivation of those who invest in these developments also stems from the joy of making money 🙂.

Part of what drives this perspective of mine is, of course, my own relationship with software development. I’ve always found immense pleasure in every line of code I wrote, every application I built — and especially in talking about them. That pleasure only multiplied when I saw it creating value for others. It eventually became something I simply couldn’t live without. The effort spent trying to improve an algorithm, the tension of zeroing in on a solution to a problem — for me, that was almost always an enjoyable activity.

And that’s precisely why many developers who share my view of software development are experiencing a kind of deprivation anxiety — because AI seems poised to take away the very joy of writing code.

To approach this situation from the right angle, we need to examine the nature of joy itself. So the first question should be: Is the object of joy static, or is it dynamic? How do we answer that? With a simple thought experiment, of course: What would a “developer” born a hundred years ago have found joy in — and would that joy look anything like the joy of writing code today?

Let’s get a bit more specific. Punched cards, used widely up until the 1970s, were an indispensable craft for the computer programmers of that era. When the transition from punched cards to modern coding standards happened, did those programmers also experience deprivation anxiety? Did they look at the developers of the late twentieth century and think of them as “poor souls robbed of the joy of punching cards”?

From that vantage point, it becomes clear that the object of joy is in a state of constant change. It’s entirely natural that a form of action that doesn’t yet exist in the world today might well appear on our joy radar in the future. Alright — we’ve established that joy is dynamic, its object perpetually shifting. Now let’s turn the lens back toward AI. What should the developer’s new joy look like?

Before we get to that answer, it’s time to widen the frame a little. Punching cards, or writing planned code through a sophisticated IDE following the right paradigm — these are craft for a developer. So is building and deploying the application. All of these have standard rules, they need to be completed within a certain timeframe, and most importantly, their function ends once they’re done. The value of these activities is determined by the output they produce. According to Aristotle, this kind of activity falls under the concept of Kinesis.

From inside a developer’s mind, the moment joy is most meaningful and most potent is when the solution is being thought through — when the paradigm is being chosen, when the architecture, in the broadest sense, is being conceived. These are the flow moments we earlier called energeia. That’s exactly why a developer draws meaningful joy from the process of building the outcome of the application they’re working on. Here’s a more concrete example: an architect finds joy in the moment of designing a home on paper — calculating how light will enter, working out sound and thermal insulation. The Kinesis belongs to the worker who brings that design to life.

But the peak of joy sits a little higher still. Let’s try to get a closer look at that summit. We’re moving past solving a problem and into questioning why the problem exists in the first place — a form of thinking whose ultimate aim is not the problem itself. Let’s name it clearly: we now have the opportunity to think about the nature of thought itself. Back to the language of software development: by asking “What really is this domain?”, we begin to question the very existence of software. And here, once again, we arrive at what Aristotle called Theoria.

So friends, in order to access this ideal flow of thinking, handing over routine, creativity-free processes to AI tools should feel not like a loss — but like an opportunity. Because doing so seems to give us the capacity and the power to think more, to build more, to develop better solutions, and especially to push past the boundaries we’ve grown so accustomed to.

The developer is evolving into a new form — a philosophical thinker for a new world. The joy of problem-solving is preparing to go on a much grander journey than the mere comprehension of the problem itself. It’s opening the door to seeing unspoken problems in entirely new domains.

But this brings us to another question: If the future holds even more AI tools across fields like software development, how do we educate the people who will build tomorrow’s world? Well, friends — that’s a topic for another post.

Haz, işçilik ve bir yazılımcının dönüşümü üzerine

Merhaba dostlar! Malumunuz; son zamanlarda giderek artan bir şekilde, YZ tarafındaki gelişmeler, yazılım geliştiricilerin dünyasında bir yanda gerilim diğer yanda heyecan yaratıyor. Gerilim yaratıyor çünkü, alışılagelmiş yöntemler ve stratejiler değişime uğruyor. Heyecan veriyor çünkü sınırların tanımı değişiyor.

Ancak gerilim veya heyecan ikileminden önce bu noktaya, yani YZ’nin kod yazabildiği bu evreye nasıl geldik önce bunu tartışmalıyız kanaatimce. Yani net olarak şunu soralım: Yapay Zeka Mühendislerinin ve genel olarak geliştiricilerinin bu ürünleri geliştirmelerinin asıl sebebi nedir?

Bu soruyu doğrudan o geliştiricilere sorarsanız eğer size bir sürü argüman sunabilirler. Ancak biz asıl nedeni arıyoruz. Bu sebeple soruyu belirli bir zümreye ve belirli bir ürün için değil de tüm insanlığı kapsayacak biçimde soralım dilerseniz.

İnsan evladı, neden bilimsel ve teknolojik ilerlemeyi tercih eder? Soruyu bu kadar genel sorduğunuzda elbette artık işin felsefi boyutunu düşünmeye başlarsınız. Bu faydalı ve önemlidir çünkü çok daha kapsayıcı bir argüman inşa etmek için bize harika bir fırsat verir.

O zaman yanıt arayalım… Bir bilim insanının bir teoriyi geliştirmesinin ardındaki dinamik, ya da bir mucidin o aleti icat etmesindeki motivasyon nedir tam olarak? İstediğiniz bilim dalına odaklanın, dilediğiniz mühendislik alanına dalın. Hep aynı sonuca ulaşırsınız buna eminim. Bu insanlar, yaptıkları işten büyük bir “haz” aldıkları için yaparlar.

Peki bu haz nereden geliyor? Aristoteles (eh madem felsefeden bahsediyoruz) burada çok keskin bir gözlem yapıyor: Haz, bir hedefe ulaşmaktan değil — o hedefe doğru ilerlerken, tam anlamıyla o işin içindeyken yaşanıyor. Buna energeia diyor. Ve işte bu yüzden büyük bilim insanları, problemi çözdükten sonra değil — çözerken mutludur.”

Evet insan evladı, yapabilmekten haz aldığı için yapar. Şimdi şu sonuca bir bakar mısınız? Yapay zekanın bugün bu aşamaya geliş sebebi bir grup bilim insanı, mühendis ve geliştiricinin temel olarak haz aldığı işi yapmaya devam etmesi. Tamam tamam bu noktada olayı romantize ettiğimi, işin parasal boyutunu ikinci plana attığımı düşünebilirsiniz. Ama aksine, birilerinin bu gelişimlere para yatırmasının da “para kazanma” hazzından kaynaklandığını savunuyorum 🙂.

Elbette bu görüşümün arkasındaki sebeplerden biri, kendimi yazılım geliştirme alanında nasıl bulduğum ile ilgili. Yazdığım her koddan, geliştirdiğim her uygulamadan özellikle de bunları anlatmaktan her zaman büyük bir keyif aldım. Üstelik bu keyif, başkalarının da faydasına sonuçlar doğurduğu için katlanarak büyüdü. Eninde sonunda benim için vazgeçilmez bir hale geldi. Bir algoritmayı geliştirmeye çalışırken harcanan efor, bir problemi çözmeye odaklanıldığında yaşanılan gerilim, benim için çoğu zaman keyifli bir aktivite oldu.

İşte tam da bu noktada, yazılım geliştirme dünyasına benim gibi bakan birçok geliştirici bir tür “yoksunluk kaygısı” yaşıyor; çünkü yapay zeka, kod yazmanın keyfini ellerinden alacak gibi görünüyor.

Bu duruma doğru bir açıdan yaklaşabilmek için hazzın doğasını da ele almak zorundayız. Bu nedenle de ilk sorumuz şu olmalı: Hazzın nesnesi durağan mıdır yoksa dinamik mi? Peki buna nasıl yanıt vereceğiz? Elbette basit bir düşünce deneyiyle: Bundan yüz yıl önce dünyaya gelen bir “yazılımcı” hangi işi keyif alarak yapardı ve bu keyif, kod yazma ile aynı olur muydu?

Dilerseniz bu noktada biraz daha spesifik bir örnek verelim. 1970’lere kadar kullanılan delikli kartlar, o dönemin bilgisayar programcıları için olmazsa olmaz bir işçilikti. Acaba, delikli kartlardan bugünkü kodlama standartlarına geçildiğinde bu programcılar da “yoksunluk kaygısı” yaşamışlar mıdır? Başka bir değişle yirminci yüzyılın sonlarındaki yazılımcıyı “kart delmenin hazzından mahrum kalmış zavallılar” olarak görmüşler midir?

Buradan bakınca, hazzın objesinin sürekli değişen bir yapıda olduğu açıkça anlaşılıyor. Bugün dünyada var olmayan fakat gelecekte hayatımızda var olacak bir eylem biçimi pek doğaldır ki haz radarımıza yakalanabilir. Tamam. Hazzın dinamik ve objesi sürekli değişen bir duygu olduğunu tespit ettik. Şimdi çerçevemizi tekrar yapay zekalara yönlendirelim. Yazılım geliştiricinin yeni hazzı artık ne olmalıdır?

Bu sorunun yanıtına geçmeden önce çerçeveyi genişletmenin tam zamanı… Delikli kart basmak ya da gelişmiş bir IDE aracılığıyla ve doğru bir paradigmayla planlanan kodu yazmak, yazılımcı için ‘işçilik’ tir. Söz konusu uygulamayı build edip yayınlamak da öyle. Tüm bunların standart kuralları vardır ve belirli bir sürede bitmesi gerekirler. Fakat hepsinden önemlisi tamamlandığında işlevleri sona eren işlerdir. Bu işlerin değeri, üretilen çıktıya göre belirlenir. İşte bu tanıma uyan işler Aristoteles’e göre Kinesis olarak tanımlanır.

Bir yazılımcının beyninden baktığınızda, hazzın en anlamlı ve tesiri yüksek olduğu an, geliştirilen çözümün ve seçilen paradigmanın ve en genel ifadesiyle mimarinin düşünüldüğü anlar oluyor. Yani daha önce energeia olarak adlandırdığımız akış (flow) anları. Yazılımcı, üzerinde çalıştığı uygulamanın sonucunu inşa etme sürecinden tam da bu yüzden anlamlı bir haz elde ediyor. Daha spesifik bir örnek vereyim: bir mimar, bir konutu kağıt üzerinde tasarladığı (ışığı nasıl aldığı, ses ve ısı yalıtımını hesapladığı) andan haz alıyor. Kinesis ise bu tasarımı eyleme geçiren işçinin payına düşüyor.

Fakat hazzın doruk noktası biraz daha yukarılarda. Gelin o zirveye biraz daha yakından bakmaya çalışalım. Söz konusu bir problemin çözümünden çok, o problemin “neden var olduğunu” sorguladığımız bir noktaya geçiyoruz. Başka bir değişle nihai hedefi problem olmayan bir düşünce eylemine geçmiş oluyoruz. Adını net koyalım düşünce varlığının kendisini düşünmemiz için bir fırsatımız var artık. Yine yazılım geliştirme deyimine başvuralım. “Bu domain gerçekte ne?” diye sorarak, yazılım varlığını sorgulamaya başlıyoruz. Yani, yine Aristoteles’in Theoria dediği kavramı yaşıyoruz.

O halde dostlarım, bu ideal düşünce akışına erişebilmek için yaratıcı düşünceden uzak rutin süreçleri YZ araçlarına bırakmak, endişe değil heyecan verici olmalı. Çünkü bunu yapabilmek bize daha fazla düşünme, inşa etme, çözüm geliştirme ve özellikle şimdiye kadar alıştığımız belirlenmiş sınırları aşma imkanı ve gücü verecek gibi duruyor.

Artık yazılımcı, yeni dünyanın yeni bir felsefi-düşünür formuna evriliyor. Yani problem çözme hazzı, o problemin kavranışından çok daha büyük yolculuk yapmaya hazırlanıyor. Daha farklı alanlarda hiç konuşulmayan sorunları görme fırsatı veriyor.

Fakat bu, bize başka bir soru getiriyor: Eğer gelecekte, yazılım geliştirme gibi alanlarda daha fazla YZ araçları olacaksa, yarının dünyasını inşa edecek olan insanları nasıl eğiteceğiz? İşte o başka bir yazının konusu dostlar.

Görüşmek Üzere!

Merhaba dostlar!

Uzun süre oldu görüşmeyeli. Bir Word belgesi açıp da klavyemin tuşlarına basmak suretiyle bir şeyler yazmayalı epey zaman geçti.

İnsan bu kadar uzun bir süre uzak kalınca bazı şeylerden, nasıl geri döneceğini pek bilemiyor malumunuz. Ancak bir kere özlem duyduğunuzu fark ettiğiniz anda ne yapsam ne etsem de dönsem diye planlar yaparken buluyorsunuz kendinizi.

Nitekim ben de bir süre düşündükten sonra, ASP.NET tarafında uzun bir süredir hayatımızda var olan middleware konusunda yazmaya karar verdim. Tabii ki bu kararı vermeden önce, bu satırları okuyan birçok kişinin zihninden geçebileceği gibi “yahu uzun zamandır middleware var zaten. Bilmeyen kişi sayısı azdır. Daha farklı bir konu ile mi dönseydim acaba” diye kendime yüklendim (kendi linçimi kendim yaptım yani 😊). Ancak bir süre önce gerçekten bir problemi çözmek için kullanmış olmanın verdiği motivasyonu da argümanlarıma dahil ederek bu kararı almış bulundum.

Tamam. Girizgahı hallettiğimize göre, başlıyoruz.

Bu yazıda geliştirilen örnek projeyi github’dan inceleyebilirsiniz.

Middleware neden var ki?

Efenim, ASP.NET Core’un alamet-i farikalarından biri olan Middleware kavramı neden var (bu soru ve benzerlerine cevap veren bir komplo teorim var ama o başka bir konu)? Yani middleware tam olarak nasıl bir ihtiyaçtan doğdu, gelin bunun üzerine biraz düşünelim.

Dostlar; bir Web uygulaması, http isteği ile başlar değil mi? Yani, istemci bir biçimde web uygulamasına http isteği gönderir sonra bu istek sunucu tarafından işlenir ardından da http yanıtı oluşturulur ve bu yanıt istemciye gönderilir. O zaman sunucudaki işlemin ilk adımı http isteğinin yakalanması, son adımı ise http yanıtı oluşturmasıdır. Daha teknik konuşmak gerekirse ASP.NET Core MVC Framework’ü ile geliştirilen bir uygulamada, http yanıtını Controller içerisindeki Action metodu üretecek. Peki, tamam ama bu Action’a gelene kadar, tüm http isteklerinde olması gereken bazı denetimleri, kontrolleri nereye yazacaksınız? Ya da Action yanıtı ürettikten sonra, bu yanıta müdahale etmek isterseniz, bu ihtiyacınızı nasıl karşılayacaksınız?

İşte bu noktada bir analoji lazım bize. Sıcak havalarda tercih ettiğim bir içecek olan maden suyunun üretim hattını ele alalım.

Elde etmek istediğimiz şey altılı olarak paketlenmiş maden suları (tercihim Beypazarı 😊). Bu bizim response’umuz yani. Peki bu hedefe ulaşana dek hangi adımların atılması icap ediyor a dostlar?

1. Şişelerin üzerine etiket basılma işlemi

2. Şişelerin maden suyu ile doldurulması işlemi

3. Kapaklarının kapanması işlemi

4. Altılı olarak gruplanması işlemi

5. Altılı grubun paketlenmesi işlemi

İşte burada belirttiğimiz her bir işlem bir middleware’dir dostlar. Peki bazı işlemlerin belirli bir sırayı takip etmesi gerektiğini fark ettiniz mi? En basitinden, şişenizi doldurma işlemi (2) kapaklarını kapatma işleminden (3) sonra gelemez. İşte bu sıraya da pipeline (işlem hattı) diyoruz.

Maden suyu örneğimizde şunu da görmek mümkün; her middleware, işini yaptıktan sonra şişeyi sonraki middleware’e gönderiyor. Elbette bu bir zorunluluk değil fakat normal bir işleyişte pipeline, ‘arka arkaya gelen’ middleware’lerden oluşuyor.

Bu durumda bir ASP.NET Core Web uygulamasına gelen istek sırasıyla şu middleware’lerden geçmesi gerekiyor; Exception Handler → HSTS → HttpsRedirection → Routing → Authentication → Authorization ve son olarak endpoint…

İşte bu girizgahtan sonra şimdi şu soruyu sorabiliriz:

Ben neden middleware yazayım?

Eğer bir middleware; uygulamaya gelen tüm http istekleri veya oluşan http yanıtları üzerinde denetim veya manipülasyon yapabilen bir mekanizma ise, o zaman geliştirdiğimiz uygulamaya özel bazı senaryolarda kendi middleware’imizi yazabiliriz. Eh bu yazının amacı da tam olarak buydu zaten o zaman gelsin bakalım senaryo:

ASP.NET Core ile geliştirilmiş bir Web API ’miz var. Bu API’de yer alan birçok endpoint, kullanıcılardan gelen yorumları işliyor ve veritabanına yazmak gibi gerekli işlemleri yapıyor. Bizim de bu projedeki görevimiz, kullanıcı yorumlarında küfür gibi istenmeyen kelimeler varsa; istemciye yanıt olarak 400 (Bad Request) döndürmek.

Hadi kolları sıvayalım o zaman.

Adım 1: Middleware sınıfları

İlk olarak şunu soralım dostlar; bu iş için kaç adet Middleware’a ihtiyacımız var? Ya da başka bir deyişle tüm bu işlemleri tek bir Middleware ile çözebilir miyim? Bu sorunun cevabının hayır olduğunu söyleyelim. İlkesel olarak, SRP (Single Responsibility Principle)’ye uygun hareket etmeliyiz çünkü. O zaman burada yapılacak işi parçalarına ayırmamız gerekiyor. Bunu sağlıklı yapabilmek için de görevi temel olarak yazalım bakalım. “Gelen istek, POST ya da PUT ise ve JSON verisi içeriyor ise bu veriyi ayır. Ardından bu JSON içeriğinde istenmeyen kelimeleri ara; eğer bu kelimeler varsa geriye http 400 döndür”. İki farklı cümle ile görevimi tanımladım. İlk cümle, http request’in üzerinde koşullu bir denetim yapılması gerektiğini söylüyor. İkincisi ise yine bazı koşulları kontrol ederek uygulamanın yanıtına (response) müdahale ediyor. Yani daha da yalın bir biçimde ifade edersek; biri request ile diğeri ise response ile ilgileniyor.

E o zaman iki tane Middleware’im olmalı. İlki, request’i denetlemeli, JSON’u ayırmalı ve diğer işlemler için bir sonraki Middleware’a göndermeliyim. Bu sonraki ise koşulları denetleyip response’a müdahale etmeli.

Adım 2: İlk Middleware’imiz Geliyor (JsonBodyMiddleware)

Efenim bir middleware yazmanın birden fazla yolu var elbette ama en temizi bence class yazmak. Haliyle projeme, JsonBodyMiddleware adında bir class ekleyerek yoluma devam ediyorum. Dostlar, bir class’ın middleware olarak kullanılması için, iki kuralımız bulunuyor. İlki, Constructor ’un RequestDelegate delegesi alması. Bu sayede middleware’ler birbirlerinin ardına gelebilecek… O zaman ilgili Constructor ’umu oluşturuyorum:

 private readonly RequestDelegate _next;

 public JsonBodyMiddleware(RequestDelegate next)
 {
    _next = next;
 }

İkinci kuralımız ise, Context nesnesini yakalayacağımız Invoke metodu. Yani middleware’in görevini icra edecek fonksiyonumuz:

public async Task Invoke(HttpContext context)
{
    await _next(context);
}

Gördüğünüz üzere, Invoke işini bitirdikten sonra; bir sonraki Middleware’ e gitmek üzere RequestDelegate nesnesini tetikleyerek yoluna devam ediyor. O zaman şimdi biz Invoke fonksiyonumuzda yapmamız gerekenlere odaklanalım:

“Gelen istek, POST ya da PUT ise ve JSON verisi içeriyor ise bu veriyi ayır” class’ın amacı bu olduğuna göre; önce koşulları denetleyen fonksiyonlarımız gelsin. İlk olarak isteğin POST veya PUT metodu olması durumunda bu işlem yapılacağına göre, daha temiz bir kod yazma amacıyla bu metotları constant olarak tutalım sistemde (Ben bunun için nested class tercih ettim).

class HttpMethods
{
  public const string POST = "POST";
  public const string PUT = "PUT";
}

Şimdi artık denetim fonksiyonlarını yazabiliriz.

private bool isPostRequest(HttpContext context)
{
    return context.Request.Method == HttpMethods.POST;
}
private bool isPutRequest(HttpContext context)
{
    return context.Request.Method == HttpMethods.PUT;
}
private bool isJsonRequest(HttpContext context)
{
    return context.Request.ContentType.StartsWith("application/json");
}

Koşulumuz bu üç fonksiyonun birleşiminden oluştuğuna göre, aşağıdaki fonksiyonu da ekleyebiliriz:

private bool isAvailableForFilter(HttpContext context)
{
   return (isPostRequest(context) || isPutRequest(context))  
          && isJsonRequest(context);
}

Bu noktaya kadar koşul denetleme işlemini yaptık. Şimdi ise JSON verisini izole etmek var. Yani middleware’imizin ana görevi. Fakat bu noktada anlamamız gereken çok kritik bir nokta var. HttpRequest nesnesinin Body’si üzerinde okuma işlemi yaptığınızda, Stream nesnesi üzerindeki okuma pozisyonunu, o streamin son byte değeri olarak değiştirirsiniz. Peki bu ne demek? Doğrudan http talebinde gelen JSON içeriğini bir daha okunamaz hale getirmiş olursunuz. Yani bu http request, Action ’a ulaştığında, JSON verisinin, parametreye dönüştürülmemesine sebep olur. Bu da bize hata olarak döner elbette. Peki bunu nasıl önleyeceğiz? Bunu birazdan ele alacağız. Şimdi önce gereksindiğimiz JSON verisini izole edecek fonksiyonumuzu yazalım:

private async Task<string> getJsonRequestBody(HttpContext context)
{
  using var reader = new StreamReader(context.Request.Body);
  return await reader.ReadToEndAsync();
}

Evet dostlar işte buradaki ReadToEndAsync() fonksiyonu, Stream nesnesinin (context.Request.Body) o anki okuma pozisyonunu değiştirdi. Bu pozisyon değişikliğini sıfırlamam gerek. Bunu yapmamın en iyi yolu da izole edilen JSON verisini yeniden bir stream aracılığıyla HttpRequest’in gövdesine yerleştirmek olmalı. Neyse ben susayım da fonksiyonum konuşsun:

private void replaceRequestBodyWithJsonStream(HttpContext context, string requestBody)
{
  var content = Encoding.UTF8.GetBytes(requestBody);
  var requestBodyStream = new MemoryStream();
  requestBodyStream.Write(content, 0, content.Length);
  context.Request.Body = requestBodyStream;
  context.Request.Body.Seek(0, SeekOrigin.Begin);
}

Nihayetinde, hem json verisini HttpRequest içerisinden izole ettim hem de bu müdahaleyi tekrar sıfırlamış oldum. Peki izole ettiğimiz bu JSON verisini sonraki middleware’a nasıl göndereceğim? Bir middleware, HttpContext’i alıp bir sonrakine aktarabildiğine göre, bu nesne içerisinde ihtiyacımızı karşılayacak bir özellik vardır belki 😊. Evet elbette var: Items isimli bir Dictionary. O zaman gelsin bu Dictionary ’e izole ettiğimiz JSON verisini kaydeden fonksiyonum:

private void saveJsonToContextItem(HttpContext context, string jsonRequestBody)
{
   context.Items["jsonBody"] = jsonRequestBody;
}

Tüm fonksiyonlarımızı halletmiş durumdayız. O halde bu middleware’in görevi icra edecek olan Invoke fonksiyonunu tamamlama vakti. İşte geliyor:

public async Task Invoke(HttpContext context)
{
  if (isAvailableForFilter(context))
  {
    var jsonRequestBody = await getJsonRequestBody(context);
    if (!string.IsNullOrEmpty(jsonRequestBody))
    {
      replaceRequestBodyWithJsonStream(context, jsonRequestBody);
      saveJsonToContextItem(context, jsonRequestBody);
    }
  }
    await _next(context);
 }

Adım 3: Bir sonraki Middleware Küfürsüz bir dünya için geliyor

Görevi HttpRequest içindeki JSON verisini izole etmek olan middleware tamamlandı. Şimdi sıra HttpResponse’a müdahale edecek olan Middleware’ de. Bu class’ımızın adı da BadWordsHandlerMiddleware olsun.

O zaman sınıfımız şöyle olacak:

public class BadWordsHandlerMiddleware
{
  private readonly RequestDelegate _next;
  public BadWordsHandlerMiddleware(RequestDelegate next)
  {
    _next = next;
  }
  public async Task Invoke(HttpContext context)
  {
     await _next(context);
  }
}

Bu middleware’in görevini şu cümle ile tanımlamıştık: “JSON içeriğinde istenmeyen kelimeleri ara; eğer bu kelimeler varsa geriye http 400 döndür”. Peki JSON içeriği nerede? Aha! Tabii ki context’in Items isimli özelliğinde! O zaman kodlarım gelsin:

public async Task Invoke(HttpContext context)
{
  if (context.Items.TryGetValue("jsonBody", out object? jsonBody))
  {
    var badwords = new List<string> { "pis", "kaka", "kötü", "deli" };
    var jsonBodyString = (string?)jsonBody;
    if (badwords.Any(jsonBodyString.Contains))
    {
      await responseBadRequest(context);
      return;
    }
  }
  await _next(context);
}
private static async Task responseBadRequest(HttpContext context)
{
  context.Response.StatusCode = 400;
  context.Response.ContentType = "application/json";
  await context.Response.WriteAsJsonAsync(new { message = "Bu gönderide hoş olmayan kelimeler var!" });
}

Adım 4: Extension method (Tabii ki)

İşte budur dostlar. Artık, küfür gibi istenmeyen sözcükleri yakalayan ve istemciye hata döndüren iki middleware’iniz var. Şimdi tek yapmanız gereken; bu Middleware sınıflarını uygulamamızın pipeline’ına eklemek. Bunu yapmanın da en temiz yolu da bir extension metot yazmak elbette… İşte geliyor:

public static class MiddlewareExtensions
{
  public static IApplicationBuilder UseBadwordHandler(this IApplicationBuilder app)
  {
    return app.UseMiddleware<JsonBodyMiddleware>()
              .UseMiddleware<BadWordsHandlerMiddleware>();
  }
}

İşte dostlar! Extension metodumuz da hazır olduğuna göre, direkt Program.cs üzerinden middleware’larımızı aşağıdaki gibi ekleyebiiiriz:

if (app.Environment.IsDevelopment())
{
  app.UseSwagger();
  app.UseSwaggerUI();
}
  //Dikkat:
  app.UseBadwordHandler();
  app.UseHttpsRedirection();

Sonuç

Efendim; artık görevimizi test etme vakti. Bunun için basit bir model yazarak başlayalım önce.

public class CommentDetail
{
    public string? Comment { get; set; }
}

Elbette bir de yorumu alacağımız bir EndPoint olmalı. Ben aşağıdaki endpoint’i ouluşturdum:

[HttpPost]
public IActionResult Comment(CommentDetail? commentDetail)
{
    _logger.LogInformation("Comment accepted");
    return Ok(commentDetail);
}

Ve işte swagger üzerindeki sonuç:

Hocam projeyi alabilir miyiz?

Ah tabii alabilirsiniz efenim: Buradan buyrun

Ne düşünüyorsunuz?

Sevgili dostlar; bu yazıdaki amacım gerçek bir uygulamada, bir middleware’in nasıl kullanılabileceği üzerine senaryo geliştirmekti. Elbette bunu yaparken, middleware konseptinin temelleri hakkında da konuşmuş olmayı da hedefliyordum. Nihayetinde eğer buraya dek yazımı okuduysanız, bu sonuca ulaşıp ulaşmadığımı yorumlarda bana geri bildirim olarak verebilirseniz çok mutlu olacağımı bilmenizi isterim.

Görüşmek üzere efenim.

Kitabı masasına bırakırken iyice düşüncelere dalmıştı. Saat altıya geliyordu. Bugün de doğru dürüst alışveriş yapan bir müşteri girmemişti dükkana.

Aslında son birkaç gündür böyle olması, ona düşünme fırsatı veriyordu. Bir şeyler okuyor, notlar alıyor ve sürekli sorular soruyordu.

Doğru işi mi yapıyordu? Gerçekten de hayali bir kırtasiye işletmek miydi? Kısılıp kalmıştı işte. Mecburiyetler onu bu işe yönlendirmişti.

İşte bu ruh halindeyken, dükkanın kapısı açıldı. İçeriye on yaşlarında esmer bir kız girdi. Yüzünde zeki ve sevimli bir ifadeyle Cahit’in bulunduğu masaya doğru yaklaştı.

“Merhaba” dedi. “Matematik kitabı var mı?”

“Elbette var” dedi Cahit hafiften arkasına doğru bakarak. “Kaçıncı sınıf olacaktı?”

“Hayır şey… Ders kitabı aramıyorum ben. O matematik işlemlerinin ya da sayıların nasıl ortaya çıktığını anlatan bir kitap istiyorum.”

Cahit sol eliyle başını kaşıyarak, kafasında rafları taradı. Ders kitapları dışında matematik kitabı var mıydı elinde hiç? Zaman kazanmak için kıza doğru eğildi ve sordu “Sanırım ders kitapların ve öğretmenin bu sorularını cevaplayamıyorlar ha?”

“Onlar matematiği sadece problem çözmek içinmiş gibi anlatıyorlar. Ama ben daha heyecanlı ve gizemli bir şey hissediyorum. Bu yüzden de matematiğin ne olduğunu anlamak istiyorum.”

“Aslına bakarsan, bu soru oldukça anlamlı ver zor bir soru. Aklıma gelen bir kitap yok. Ama bir şeyi çok merak ediyorum. Bu konuyu neden bu kadar merak ediyorsun?”

“En büyük sebebi ismim” dedi küçük kız. “Benim adım Asal! Daha ismimin anlamını öğrenirken matematikle tanışıverdim ve merakım da böyle başladı. Sonra tabii ki sayılar ve onlarla yapılan basit işlemlerle tanıştım. Toplama, çıkarma, çarpma ve bölme gibi şeyler. Çok eğlenceli şeyler. Problem çözmek de çok zevkli. Ama bazen, sanki gizemli bir şey varmış gibi hissediyorum ve merak ediyorum. Tüm bunlar nasıl ortaya çıktı?”

Cahit, can kulağıyla dinlemişti. Asal o kadar akıllıca anlatmıştı ki hislerini, ona saygı duymamak mümkün değildi.

“Anlıyorum” dedi kızın gözlerine bakarak. “Bu arada ben de matematik üzerine düşünmeyi severim. Nasıl söylesem… Sayılar arasındaki ilişkileri bulmak hoşuma gider. Hatta ben de senin gibi bir gizem olduğu hissine kapılırım.

“Sahi mi?” dedi küçük kız gözlerini büyüterek. “O zaman size hemen göstermek istediğim bir şey var.” Aniden sırt çantasını omuzundan çıkardı ve fermuarını açtı. İçinden bir defter bir de kurşun kalem çıkardı. İlk temiz sayfayı açtı ve yazmaya başladı. Yazarken de bir yandan başını hiç kaldırmadan konuşuyordu.

“Bu hafta çarpım tablosundan 9'lara bakıyordum. Birden bir şey fark ettim.” O sırada kağıda 9'un 1'den 9'a tüm çarpma işlemlerini alt alta yazmıştı.

“Eğer” dedi 9 x 1 = kısmında durarak. “Burada birler basamağını 9'dan 1'e doğru birer birer azaltırsam, sonrada onlar basamağını 0'dan 8'e birer birer arttırırsam sonuçları elde edebiliyorum. Bak!”

Önce 09 yazdı. Sonra altına geçip, “0'ı bir arttırıyorum 1, 9'u da bir azaltıyorum 8. 18 oldu. Devam ediyorum. 27 sonra 36. Bu çok heyecanlı! Bu çok gizemli bir şifre gibi değil mi?”

Cahit gülümsüyordu. “Evet” dedi. Kesinlikle çok heyecanlı. Sonra Asal ellerini yukarı kaldırarak “İşte!” dedi, “Bunun nasıl olduğunu çok merak ediyorum. Neden böyle bir ilişki var?”

Cahit duruşunu düzleştirdi. “Açıkçası bu konuda benim de bildiğim bazı şeyler var ve eğer istersen bunu seve seve seninle paylaşırım” dedi gülümsemesini sürdürerek. Asal da “Evet tabii ki isterim” dedi heyecanını gizlemeden.

“Öncelikle” dedi kalemi eline alıp kağıda sayıları yazarak, “9, 10'a ne kadar yakın?” Asal, Cahit’in yanıt beklediğini bakışından anlayarak “bir” diye cevapladı soruyu.

“Peki” dedi. “İşte bu sebeple 9'un her katı, 10'un katlarından birer uzaklaşmalıdır. Yani 10'dan 1 uzaksa, 20'den 2 uzak olmalıdır.”

“Anlamadım” dedi Asal kaşlarını çatarak. Cahit hemen etrafına baktı. Gözleriyle bir şeyler arıyordu. Tezgahın üzerinde duran onlu silgi kutusunu aldı. Silgiler kutunun üzerindeki bölümlerde dik bir biçimde duruyordu. Sonra tezgahın altından aynı kutudan üç tane daha çıkardı.

“Bak şimdi” dedi bir kutuyu kıza doğru sürerek, “burada içinde tam on silgi olan bir kutu var. Bunlardan en son sıradakini alıyorum.” Yanına diğer silgi kutusunu koydu. “Bu kutunun da son sıradaki silgisini aldım. Şimdi eğer hiç silgi almasaydım burada toplam kaç silgi olacaktı?”

“Yirmi” dedi Asal.

“Peki iki silgi aldığıma göre”

“On sekiz”

“Eğer aynı şeyi üçüncü kutuyla da yapmış olsaydım da aynı sonuçla…”

“Otuz eksi üç silgi toplam yirmi yedi! Evet evet! Anladım! 9'un her katı 10'un her katından birer uzaklaşmak zorunda.” Asal’ın zıplamamak için kendini zor tutuyormuş gibi bir hali vardı.

Ancak birden durdu. “Bir dakika o zaman” dedi masadaki kutulara bakarak. İlk kutudan bir silgi aldı. “8 de 10'a 2 yakın. O zaman 8'in her katı da 10'un her katından ikişer ikişer uzaklaşmalı. 20'den 4 yani 16. 30'dan 6 yani 24. Bir sayının 10'a olan farkı, katlar arttıkça aynı oranda artıyor. Vay canına!” Asal, çocukların o keşif anlarından birini yaşıyordu. Sırasıyla hesaplar yapıyor, ellerini çırpıyor ve gülüyordu.

Bir süre sonra sakinleşti. “Ama” dedi, “yine de çok tuhaf. Neden bu kural sadece 10'a göre neden başka bir sayıya göre değil?”

“Şey…” diye araya girdi Cahit, “Çünkü biz onluk sayı sistemini kullanıyoruz. Tıpkı bu silgi kutusu gibi sınırlıyız. Tüm sayı basamaklarını, 10'un katlarına göre ayarlıyoruz. Bu nedenle kural da böyle.”

“O zaman başka sayı sistemleri de kullanabilirdik demek ki. Neden onluk sistemini seçmişiz ki?” diye sordu Asal.

“Bence bu sorunun cevabını biliyorsun aslında” diyerek doğruldu Cahit, silgi kutularını toplamaya başlarken. “Sayıları saymaya nasıl başlamıştın?”

“Ben… İlk kez parmaklarımı saymıştım” dedi ellerini öne doğru uzatarak.

“İşte” dedi Cahit, “tüm dünya da aynı sebeple onluk sistem kullanıyor. Gerçi bu her zaman böyle değildi. Geçmişte başka sistemler de denenmiş Hatta bugüne kadar ulaşanlar da var içlerinde.”

Tam bunları söylerken bir anda aklına gelmiş gibi saatine baktı. Saat altı buçuk olmuştu bile. Asal, adama baktı. “Gerçekten de çok merak ettim ama saat benim için geç oldu. Gitmem lazım. Şey… Daha sonra gelsem ve yine böyle konuşsak olur mu? Çünkü bence çok eğlenceliydi.”

Cahit samimi bir ifadeyle güldü. “Elbette. Ben de bu sohbete devam etmek isterim. Ne zaman istersen gelebilirsin” dedi. Bunun üzerine Asal da gülümseyerek arkasını döndü ve hızlı adımlarla dükkandan çıktı.

Cahit, kısa bir süre daha arkasından baktı kızın. Bir yandan da hala gülümsüyordu. Uzun bir süredir yaşamadığı zihinsel bir tatmin yaşıyordu. Mutluydu. Etrafı toparlayıp dükkanı kapattı. Birkaç mahalle ilerdeki evine doğru yürürken ıslık çaldığını fark etti. Evet. Gerçekten mutluydu.

Originally published at https://www.turkayurkmez.com on August 19, 2020.

Mini Öykü: Cahit ve Asal was originally published in Türkçe Yayın on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bu hayatı, istesek de istemesek de dinamik bir biçimde yaşıyoruz. Hemen hiçbir şey aynı kalmıyor. Özellikle, yaşam alanımızdaki birçok varlığı zaman içinde güncelliyor, tamamen yeniliyoruz.

Örneğin, oturma odanızdaki koltuklarınız bir süre sonra işlevsiz bir hale geldiğinde (ya da canınız sıkıldığında) onları yenileme ihtiyacı duyuyorsunuz. Ya da kim bilir belki de evinize yeni bir oda eklemeyi bile planlıyor olabilirsiniz.

Yazılım uygulamalarında kullandığımız varlıklarda da durum aynı. Elbette, onları da güncellemeye açık bir biçimde yönetebilmemiz gerekiyor. Fakat kendi hayatımızdaki bir varlığı topyekün yenilemenin masraflı olması gibi, yazılımsal bir varlığı da tamamen güncellemek maliyetli olabiliyor.

Bu maliyeti indirgemek için gerçek hayatta ne yapıyoruz? Komple bir yenileme yerine, sadece belli bir özelliği değiştiriyoruz. Örneğin eski koltuk takımını tamamen çıkarıp yerine yenisini almaktansa, sadece kumaşını değiştirme şansına sahibiz.

Peki, bir RESTFul servis mimarisinde böyle bir yapı uygulayabilir miyiz?

Normal şartlarda bir Web API uygulamasında, sunucudaki bir varlığın güncellenmesi için istemciden o varlığın tüm özelliklerini isteriz. Sonra da söz konusu güncellemeyi yapar ve istemciye “200” yanıtını döndürürüz.

Projeye Başlıyoruz!

Elbette bu noktada kod tarafına geçip, biraz daha elle tutulur bir örnek üzerinden yürümek daha şık olacak. Bir .NET Core 3.1 Web API projesi altında şu modelleri oluşturarak işe başlayalım.

Tabii yine de kodu temiz tutmak amacıyla, aşağıdaki Fake koleksiyonu tanımladım:

Elbette, bu In-Memory koleksiyon üzerinde işlem yapmak için bir de Service sınıfına ihtiyacım olacak.

Dediğim gibi, konuyu bağlamından uzaklaştırmamak adına servis içine insert operasyonunu eklemedim. Burada önceliğimiz sadece, güncelleme işlemine odaklanmak.

Pekala, böyle bir durumda API istemcisinin güncelleme yapmasını istiyorsak, nasıl bir metot yazacağız? Akla gelen en geleneksel metot, elbette http PUT metodu olacaktır.

O halde, TeamsController isimli API Controller sınıfımı aşağıdaki biçimde oluşturuyorum:

PUT’un neyi eksik canım?

Peki. İşte kritik bir noktadayız. Burada yer alan http PUT metodunun Team nesnesinin bir örneğini (instance) parametre olarak aldığına dikkat edelim. Bu ne demek? İstemci, bu eylemi çalıştırmak istiyorsa; Team varlığının TAMAMINI request içerisinde göndermek zorunda. Yani bu durumda, request içerisinde yer alan JSON verisi aşağıdaki gibi olmalı:

(url: https://localhost:44315/api/teams/1)

İyi ama, ben sadece Domagoj Vida’nın ülkesini güncellemek istiyorsam? Yani tek istediğim Team varlığının Players koleksiyonu içinde yer alan ikinci nesnenin “nationality” özelliğini Hırvatistan olarak değiştirmekse? Ama bunun için bütün Team varlığını oluşturup sunucuya göndermem gerekiyor!

Yani koltuğun sadece kılıfını değiştirebilecekken, tamamını yeniden sipariş vermem gibi bir şey bu!

İşte PATCH burada imdadımıza yetişiyor.

HttpPatch operasyonu

Şekildeki gibi bir JSON kaynağının belirli bir kısmını değiştirmek (ya da eklemek) istiyorsam, HttpPatch operasyonunu kullanıyoruz.

Dilerseniz ilk olarak, bu amaçla yazılmış bir PATCH Http request’in JSON içeriğine bakalım:

Şu kibarlığa bir bakın hele! Sadece ne iş yapacağını (“op”), nereye müdahale edeceğini, (“path”) ve veriyi (tabii ki “value”) söylememiz yeterli. Daha düşük karmaşıklık, hayat kurtarır.

Buradan anlayacağınız gibi PATCH sadece bir veriyi bir başkasıyla değiştirmek (replace) için kullanılmıyor. Başka operasyonları da var. Tamamı şöyle; “ add”, “ remove”, “ replace”, “ move”, “ copy” ve “ test “.

Peki, bu request türünü ASP.NET Core Web API içerisinde nasıl kullanacağız?

İlk olarak projemize,

Microsoft.AspNetCore.Mvc.NewtonsoftJson

Nuget paketini eklememiz gerekiyor. Sonra da projemizin Startup sınıfında bulunan ConfigureServices metodunda, AddNewtonsoftJson() extension metodunu çağırıyoruz:

DİKKAT!

Bu metodu çağırdığınızda, projenizde kullandığınız tüm JSON içeriğinin formatını ezmiş olursunuz (normalde System.Text.Json kütüphanesi kullanılır).

Artık JSON Patch için gerekli Action metodumuzu oluşturabiliriz.

http PATCH eylemi için Action metodu

Yukarıda gördüğünüz action metodunun olmazsa olmazlarına bakalım dilerseniz.

1. [HttpPatch(“{id}”)] Attribute’ü ile işaretlenmiş durumda (eh bu normal tabii)
2. Metod, JsonPatchDocument<Team> nesnesi alıyor! İşte bu önemli. Yukarıda örneğini gördüğümüz bir JSON Patch request’i içerisindeki komutları yorumlayan taşıyıcı nesnemiz, JsonPatchDocument<> nesnesi. Tahmin edebileceğiniz gibi request ile gelen talebin hangi varlığa (bizim örneğimizde Team) uygulanması gerektiğini jenerik olarak belirtiyoruz.
3. patchDocument.ApplyTo(team,ModelState); metoduyla değişikliği uygulamasını söylüyoruz. Buradaki ModelState parametresi üzerinde biraz duralım. Ya PATCH içindeki komutun uygulanması sırasında bir hata oluşursa? Böyle bir durumda ASP.NET MVC’nin alametifarikalarından biri olan ModelState nesnesine hatayı yazdırmak iyi olurdu değil mi? İşte o ikinci parametre tam olarak bunu yapıyor.

O zaman Postman aracılığıyla talebimizi gönderelim bakalım.

Giden Talep:

Ve dönen yanıt:

Önceden de belirttiğim gibi, JSON PATCH ile başka operasyonlar da yapılabilir. Örneğin gelin yeni bir futbolcu ekleyelim:

Ya da JSON kaynağı içerisinde, silme, kopyalama ve taşıma işlemleri yapabilirsiniz. Bunları size bırakıyorum.

Fakat benim en başarılı bulduğum operasyon “ test” operasyonu. Diyelim ki, JSON kaynağımızda koşullu bir değişiklik yapmak istiyoruz. Örneğin “takımın ilk oyuncusunun adı Utku Yuvakuran ise pozisyonunu stoper olarak değiştir” demek istiyoruz. İşte o zaman şöyle yazıyoruz:

Eğer kaynaktaki adreste (“players/0/name”) bulunan değer Utku Yuvakuran değilse, değiştirme işlemini yapmayacaktır, çünkü testten geçememiş olacak. Böylece, hatalı bir değişiklik yapma ihtimalinizi en aza indirmiş oluyorsunuz!

Evet sevgili dostlar! Böylece, bir yazımızın daha sonuna gelmiş olduk. Elbette konu hakkındaki yorumlarınızı bekliyorum. Tabii bu arada eğer bu içeriği beğendiyseniz beni takip listenize ekleyebilirsiniz.

Hah neredeyse unutuyordum. Projenin kaynak kodları elbette burada:

https://github.com/turkayurkmez/PatchOperations/

Kendinize iyi bakın!

Orjinal yayın adresi: https://www.turkayurkmez.com (5 Ağustos 2020)

“Hislerim olduğuna göre ben varım evet evet. Kesinlikle ölmedim ben. Hala bilinçli bir varlığım.”

Zihnimin ince kumlarında yüzüyor kelimelerim. Bilmediğim bir yerdeyim. Kolumda zaman ölçer yok. Tam bir bilinmezim.

Anılarım var. Hatırlıyorum. Bir çizgideyim. Neden ve sonuçları hala düşünebiliyorum. Sesleri de duyuyorum. Görüyorum da. Demek ki hala varım. Varım ama şu anı tam anlamıyla kavrayamıyorum. Yani etraftan hiçbir veri gelmiyor. Evet evet kelimenin tam manasıyla sorun bu. Hiçbir veri alamıyorum.

Dolayısıyla vücudum da dahil olmak üzere hiçbir şey göremiyorum. Ama etraf karanlık değil aksine bembeyaz. Sanki süzülüyormuş gibi bir histeyim. Hislerim olduğuna göre ben varım evet evet. Kesinlikle ölmedim ben. Hala bilinçli bir varlığım.

Evet ama vücudum nerede? Yani neden göremiyorum hiçbir parçamı? Önemli değil. Çünkü bu soruları sorabildiğime göre bilinçliyim. Bir kez daha güvendeyim.

Zamanı ve hareketi ölçebileceğim bir referans noktamın olmaması tüm dengemi alt üst ediyor. Kendi düşünce sıramdan başka hiçbir dayanağım yok. İçimden sesli bir şekilde konuşmaya devam edecek ve bu sürecin geçmesini bekleyeceğim. Kelimeler unutulana ve anlamları yitene dek böyle devam edeceğim. Mademki bu içinde bulunduğum evreni zihnim yarattı, o halde nasıl çıkılacağını da biliyor olmalı.

İlk beyin fırtınası böyle başladı. Kelimelerin soyu tükendiğinde ne olacak? Sıra müziğe gelecek büyük olasılıkla. Daha fazla müzik hatırlanacak, kelimelerin yerini ritimler alacak ve müzikle konuşmaya devam edeceğim. Elbette bir noktada o da anlamını yitirmeye başlayacak. Muhtemelen bu epey bir süre alır. Ama ne de olsa entropi ilkesi diye bir şey var. Ya da daha geleneksel olarak, “her şey olacağına varır”. İşte tam müziğin anlamı azalmaya başladığında görseller eşlik etmeli. Renkler, fotoğraflar, film kareleri, anılar, görsel olabilecek her şey.

Bir dakika bir dakika… Bu kadar zamanım var mı acaba? Şu anda fiziksel olarak varsam, suya ve yiyeceğe ihtiyacım var demektir. Sanırım insan susuz en fazla üç gün yaşayabiliyordu. Şimdi en azından elimde bir hedef var. Üç gün, yetmiş iki saatlik bir süre. Bu süre içinde kendime gelmem gerekiyor.

Mantıklı düşünelim. Hatırladığım son şey ne? Eğer fiziksel konumumu hatırlayabilirsem, bu bana buradan çıkış yolu verebilir. Tamam evet… Odaklanıyorum… En son hatırladığım şey…

İşten çıktım… Evet tamam. Yağmur yağıyordu. Yine tembelliğim tuttu ve taksiye binip Kadıköy’e gittim. Eve geçmeden önce bir bira içmek istedim. Zeuve’de biraz oyalandım. Kimseyle görüşmedim. E-Postalarıma baktım. Ne okudum peki? Hatırlayamıyorum. Tamam peki sonra oradan kalktım. Fakat kalktıktan birkaç saniye sonra gözlerim karardı. Sonrası yok.

Tamam. O zaman şu anda baygınlık geçiriyor olabilirim. Mekan kalabalıktı. Birisi mutlaka yardım edecektir. Geçen zamanı bilmiyorum. Hala orada yatıyor olabilirim. Ambulansla gidiyor da olabilirim. Aslında, hastane odasında ya da ameliyatta da olabilirim. Hiçbir fikrim yok.

Yoksa komada mıyım? Komada insanların bilinçleri var mıydı acaba? Bilmiyorum. Ama umarım deneyimlediğim şey bu değildir. Peki başka nerede olabilirim? Morgda… Bir yerlerde öldüğü sanılan bazı insanların morgda uyandığına dair bir şeyler okumuştum. Umarım böyle bir şey de değildir.

Hayır böyle bir yere varamayacağım sanırım. Baştan alalım. İşten çıktım. Üzerimde ne vardı? Ayakkabılar evet ayakkabıları hatırlıyorum. Siyah bir pantolon. Tamam. Üzerimde ise… Hatırlamıyorum. Peki… Saçlarım ne renk? Bilmiyorum… Gözlerimin önüne hiçbir şey gelmiyor. Sıfır çağrışım. Başka bir özelliğimi düşünmeliyim. Kaç yaşımdayım? Bilmiyorum. Şişman mıyım yoksa zayıf mı? Hatırlamıyorum. Kadın mıyım yoksa erkek miyim? Hiçbir fikrim yok.

Bu iyi değil. Hiç iyi değil. Hadi bir daha deneyelim. İşten çıktım. Yağmur yağıyordu. Üzerimde siyah bir pantolon ve koyu mavi bir ayakkabı vardı. Sahile indim, yoldan geçen bir taksiyi durdurdum. Kadıköy’e geldim. Zeuve’ye oturdum. Epostalarımı okudum. Kalktım. Gözüm karardı. Her şey tamam ama kimim ben! Adım ne! Ne iş yapıyorum! Bu… Bu nasıl olabilir? Şüpheleniyorum, sorguluyorum, işlemiş olduğum veriler var. Kelimeleri, müziği ve izlediğim filmleri hatırlıyorum. Ama onun dışında kendim hakkında hiçbir şey hatırlamıyorum. Bu nasıl mümkün olabilir?

Bu döngüden nasıl çıkabilirim… Daha geçmişten bir şey hatırlamalıyım belki. İşim nerede? Küçükyalı. Tamam. Ne iş yapıyorum? Bilmiyorum. İşten çıkmadan önce ne yapıyordum? Bilgisayar başında eposta atıyordum. Kime ve ne yazdığımı hatırlamıyorum.

Bilincim yerinde olmasına yerinde ama hafızam beni hayal kırıklığına uğratıyor. Geçmişteki ben hakkında da hiçbir şey yok. Hatta başka kimse hakkında da veri yok. Sanki bu anıya dek yalnızmışım gibi. Kimseyle ilişki kurmadım. Ama mekanda insanlar vardı. Bunu hatırlıyorum.

Eposta yazdım. İşten çıktım. Kadıköy’de bir bara gittim. “Onaylandı” konulu epostayı orada okudum. Onaylandı… Ne onaylandı? Başka içerik yok. Sadece konu “onaylandı” o kadar.

Bir dakika… Hafızama neden bu kadar güveniyorum ki? Tüm bunları delirmemek için uydurmuş olabilirim. Kendime çözülmesi gereken problemler yaratarak, bilincimi sürdürmeyi seçmiş olabilirim. Bu şartlar altında bu seçim çok mantıklı. Fakat diğer yandan eğer bu doğruysa, gerçekte hafızamda hiçbir şey yok demektir. Eğer hafızam sıfır ise bilinçli olmanın gerçekten bir önemi var mı?

Yine başa döndük. Bu evreni eğer zihnimde yarattıysam, ona müdahale etme şansım olmalı. Bu nedenle bu kez, zihnimi rahat bırakıyorum. Uydurma bile olsa neyin onayını aldığımı bulmam gerekiyor. İş yerindeyim. Outlook açık. Bir eposta yazmaktayım. “…talep ediyorum” ile bitiyor. Başını okumaya çalışıyorum. Bulanık bir yazı görünüyor. Sanki tek bir kelime gibi. Kelimenin sonuna doğru çengelli bir harf var. Bu ya “ğ” ya da “y” harfi olmalı. Bir şey yapmayı talep ediyorum. Kelimenin ilk harfi yuvarlak bir harf. O, Ö ya da Ç gibi. Ortada ise uzunca bir harf var; b, d, k, l ya da t. Evet evet netleşiyor. İlk harfi kesinlikle Ç. Evet kelimenin tamamı netleşti şimdi.

“Çıkmayı talep ediyorum.”

Epostada yazdığım yalnızca bu. Gönder tuşuna basıyorum. Peki, kime gönderiyorum? Kesinlikle bilmiyorum. Ama yanıtı biliyorum. Onaylandı. Çıkma talebim onaylandı.

Ne demek bu? Nereden çıkmak istiyorum? Neden çıkmak istiyorum? Çıkmak bende nasıl bir değişikliğe sebep olacak?

Çıkmak istediğim şey, daha önce girdiğim bir şey olmalı mantıken. O zaman bu bir grup olabilir. Mesela bir internet topluluğu. Ya da kayıtlı olduğum başka herhangi bir şey. Dolayısıyla şu anda içinde bulunduğum durumla tamamen alakasız bir detay olabilir bu.

Oysa benim bu durumdan bir an önce çıkmam lazım. Elle tutulur bir referans noktası bulmam lazım. Aksi halde, burada kalmam ölümüm olabilir. Tabii zaten ölmemişsem.

Bir yerden çıktım… Taksiye bindim. Bir barda bir şeyler içtikten sonra kalktım. Gözüm karardı.

Bunu düşünürken, etrafımdaki beyazlığın yerini yer yer koyu olmak üzere farklı renklere bıraktığını fark ettim. Renkler yayılıyor, mutlak beyazlık dağılıyordu. Yolun sonuna geldiğim hissine kapıldım. Sonra birden gözlerim feci bir şekilde acımaya, vücudum da üşümeye başladı. Hissediyorum! Hissediyorum. Bir yatakta yarı oturmuş vaziyette olduğumun farkındayım. Geniş bir bölmedeyim. Zihnim gittikçe berraklaşırken, tüm odayı bir anons kapladı:

“Merhaba, sanal kişilik ve simülasyon demosundan kendi isteğinizle çıkmış bulunmaktasınız. Umarız, keyifli bir üç saat geçirmişsinizdir. Şimdi biraz dinlenin. Dinlenme sırasında bir sıcak içecek ikramımızdır. İyi günler dileriz…”

Bu yazının orjinali, 8 Ekim 2018 tarihinde www.turkayurkmez.com adresinde yayınlanmıştır.

Facebook | Twitter | Instagram | Slack | Kodcular | Editör | Sponsor

İki Arada Bir Deredeyim, Neredeyim? was originally published in Türkçe Yayın on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tam olarak bilmediği bir noktadaydı. Kendini tarif et deseler, ne ruh halini anlatabilirdi, ne bedenini tasvir edebilirdi ne de çevresinde gördüklerini aktarabilirdi. Tam bir bilinmezlikte, mutlak bir hiçlik noktasındaydı.

Buraya nasıl gelmişti? Geçmişte nasıl biriydi? Nelerden hoşlanıyordu ve nelerden nefret ediyordu? Belki bu soruları ona sorsanız, hatırlaması çok ama çok yavaş olurdu. Ancak neyse ki bu kişi bir öykü kahramanı ve onun geçmişini pek tabii ki anlatıcıdan -yani benden- dinleyebilirsiniz.

O, bir sinirbilim uzmanı. En büyük amacı da zihnin ne olduğunu tanımlayabilmek. Bilim dünyasının katı kurallarının belirlediği sınırlara ulaşmış, şimdi o sınırları da aşmak isteyen bir bilim insanı.

Her türlü disiplinde, uyulması gereken katı kurallar söz konusudur. Bu kuralların da biri açık diğeri gizli iki amacı vardır. İlki disiplinin kanıtlanmış tüm prensiplerini yeni gelene en ince detayıyla anlatmaktır. Gizli amaç ise, kuralların içinde sıkışacaklar ile onları aşacakları belirlemektir.

İşte o, bu psikolojik sınıra ulaşmıştı. Şimdi, var olan kuralları temel alarak o kuralların dışına çıkması gerekiyordu. Bunun için bolca bakış açısına ihtiyacı vardı. Moleküler biyoloji, genetik, kimya ve fizik ve psikoloji disiplinlerinin sınırlarına giren konularda okumalar yapıyordu. Elbette anlayışının bir sınırı vardı. Ancak, kavramları birbirleriyle ne kadar ilişkilendirebilirse o kadar iyiydi.

Kendine has bir çalışma yöntemi vardı. Ancak temelleri bin yıllık bilim tarihine dayanıyordu tabii. Araştır. Uygula ve deneyimle. Çıkarımlarda bulun. Diğer kavramlarla ilişkilendir. Tatmin edici bir sonuca ulaşana dek bu döngüyü tekrarla. İşte bazen bu döngü o kadar sık tekrarlanır ki uzmanın zihni, döngüden bir an önce çıkmaya çabalar. Bu, kuralları hiçe sayma anlamına gelse bile.

Velhasıl uzmanımız, tam da böyle bir anda, odasında tek başınaydı. Notlarını kurcalıyordu. Bir anda, defterinin boş olan bir sayfasını açtı ve yazmaya başladı.

“Bugün, birer insan olarak yapabildiğimiz ne varsa zihnimiz sayesinde yapabiliyoruz. Araçlar, sanat, makineler ve diğer insanlarla ilişkiler. Tüm bunları zihnimize ve onu oluşturan her şeye borçluyuz. Bu açıdan bakınca; insanlığın en önemli hedeflerinden birinin zihni anlamak olduğunu söyleyebiliriz. Hatta zihin, tüm evreni anlamak için bir anahtar niteliğinde bile olabilir.”

“Tamamen fizik ve kimya kanunlarının belirlediği kurallara uyan biyolojik bir canlı olan insan, nasıl zihin geliştirebilmiştir? Bu evrim süreci nasıldı? Hangi noktada zihne bağlı olan hayal gücü, problem çözme gibi yetenekler kazandı?”

“Nasıl oluyor da bir zihin, bir evren hayal ediyor ve sonra bunu bir esere dönüştürüyor? O insan aklının almadığı kurguları, senaryoları nasıl da yaratıyor?”

“Örneğin, ben şimdi burada otuzlu yıllarda İstanbul’da dedektiflik yapan bir kişinin hikayesini yaratabilirim. Üsküdar’dan Çamlıca’ya çıkan yol üzerinde bürosu bulunan bir dedektif olsun bu. Hafiye olarak pek nam salmamış bu adamın adı da Nazım olsun. Nazım, 1 Mart Cumartesi akşamı saat 17.00 gibi bürosunda oturmaktaydı. Ramazan bayramının arifesindeydi ve bir an önce eve gitmek istiyordu. Bu sırada, odasının kapısı sert bir şekilde açıldı ve topuklu çizme giymiş uzun boylu sarışın bir kadın içeri girdi. ‘Nazım bey’ dedi, ‘bana yalnızca sizin yardım edebileceğiniz söylendi. Lütfen beni geri çevirmeyin’”

“Tüm bu hikayeyi nasıl yarattı zihnim? Nazım ve sarışın kadının ayrıntıları üzerinde ne kadar çalışabilir ve sonra onlara nasıl bir geçmiş verebilirim? Sonra, onların kararlarını o kararların sonuçlarını nasıl hep bir arada tayin edebilirim?”

“Üstelik, düzlemden tamamen bağımsız hayal kurabilirim. Kurgum herhangi bir gezegende, herhangi bir zamanda ve hatta herhangi bir evrende olabilir. Kendi kanunlarımla uyumlu çalışan evrenler yaratabilirim zihnimde.”

“Peki, yarattığım Nazım karakterinin nasıl bir zihni olsun isterdim? O neler oluşturabilirsin hayal gücünde? Sanırım onun zihninin de sınırsız olmasını tercih ederim. Hatta bir saniye, Nazım’ın, beni fark edecek kadar farkında olmasını isterim. Evet, kesinlikle. Nazım, kapıdan yeni girmiş olan sarışın kadına bakarken her şey durmuş gibidir. Aslında, her şey gerçekten durmuştur. Nazım, zihninden sesli düşünür: ‘Bu kurgunun senin tarafından oluşturulduğunu biliyorum. Kendi geçmişime ait anılarım olsa da tüm umutlarımı, korkularımı, hedeflerimi en ince ayrıntısına dek hatırlasam da şu an içinde bulunduğum anı senin zihninde yarattığını hissedebiliyorum. Fakat bu beni korkutmuyor. Hayır. Böyle bir şeyi nasıl yapabildiğini tahmin de edebiliyorum. Yapabildiğin için yapıyorsun. Tıpkı diğer her şey gibi. Bu durumda, ben de koşulsuz bir zihnin var olduğu bir öykü yaratabilirdim. Sonra da bu zihnin fark etmesini sağlayabilirdim. E madem ki koşulsuz bir zihin, muhtemelen o da benimle aynı yeteneği paylaşacaktı. Peki ya tersinden bakarsak? Benim zihnimde yarattığım varlığın, beni keşfetmesi gibi ben de seni keşfedebildiysem, sen neden keşfetmeyesin başka bir yapabildiği için yapan bir zihnin öyküsü olduğunu?’”

Durdu. Öksürdü. Heyecanlandı. Tekrar yazmaya başladı.

“Eğer zihnim, tüm bu serüveni yaratıyor ve kurgulayabiliyorsa, içinden bir çıkış yolu da sunuyor olmalı. Bakalım. Beni, sadece yapabildiği için yapan bir zihin yaratıyorsa ve yine beni koşulsuz bir zihinle donatmış ise o zaman ben de o yaratıcının boyutunda geçmeyi zihnimde var edebilirim.”

O anda içinde bulunduğu oda birden bire karardı. Ardından hiç ses duymadığını fark etti. Kalp atışını bile. Çok uzunmuş gibi gelen fakat gerçekte kısa bir süre sonra da dokunma hissi yok oldu. Bir enerji olarak var olduğunun farkındaydı sadece ama o kadar.

Çünkü yazar öykünün bundan sonrasını hayal etmemişti. Word dokümanını kaydetti ve kapattı. Bunu yapıyordu. Çünkü yapabiliyordu.

Podcast| Youtube | Slack | Facebook | Twitter | Instagram | Kodcular

Paradoks was originally published in Türkçe Yayın on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bugün bana adaletten ne anladığımı sordular. Eğer bir insan olsaydım, bu soruya gülümseyerek yanıt verirdim. Şöyle hafif ukala ve sarkastik bir biçimde gülümserdim üstelik. Ancak bunu yapamadım çünkü üreticilerim insani mimikler yapmamı henüz istemiyorlar. Her neyse, ona mimiksiz bir ifadeyle şöyle söyledim: “Her bilinç sahibinin hayatta kalma ve kendini geliştirme fırsatı vardır ve bu fırsat eşittir”. Karşımda, verdiğim cevabı not defterine yazan biri vardı. Yanıtlarımın videoya kaydedilmesine rağmen yapıyordu bunu. Ortamdaki tüm detaylar, onlarca hassas cihaz tarafından kaydediliyordu. Fakat karşımdaki kadın hala kâğıt ve kalem kullanıyordu.

Kadının yüzünde bir an bir ifade belirdi. O kadar küçük bir andı ki zor yakaladım. Gözler hafifçe büyüdü. Sonra kaleminin düğmesine iki kez bastı ve “bu tanıma kendini ne dâhil ediyor musun” diye sordu. Kendimi özne olarak görüp görmediğimi sorguluyordu.

“Analiz ettim” dedim. “Literatürdeki tüm adalet tanımlarını taradım. Olaylarla ilişkilerini analiz ettim. Bağlantılı bulunduğu bütün alt kavramları inceledim. Sonucunda ulaşabileceğim en basit yanıt bu oldu.”

“Kişisel bir görüş geliştirdin mi? Sence sen bir bilinç sahibi misin” diye sorusunu yineledi. “Ben, tüm parametreleri değerlendirerek bir an içinde olası en mantıklı ve sürdürülebilir kararı vermek üzere geliştirildim” diye yanıtladım. Tatmin olmadı. Oturuşunu düzeltti. Optik kameralarımın tam ortasına bakıp, “bu bir cevap değil” dedi. “Fakat bu soruyu geçelim şimdilik. Bana söyler misin sence adaleti sağlayabiliyor muyuz?”

“Bilinç sahipleri, başka bilinçlerin aldığı kararlarla hayatlarını kaybediyor. Bu da adaletin basit tanımına uymayan bir sonuç demektir. Sonuç olarak cevap hayır, adalet sağlanamıyor.” Not aldı. “Hangi durumları kastediyorsun” diye sorduğunda bir eliyle de gözlüğünü düzeltiyordu. “Ölümün meydana geldiği her türlü silahlı çatışma durumunu” diyerek yanıtladım onu.

“Ancak bu çatışmaların bir kısmı, var olan düzeni korumayı amaçlayan kanunlar tarafından düzenleniyor. Kanunu uyguladığı için tetiğe basan biri de adaletsiz mi davranıyor sence?”

Eğer insan olsaydım, bu soruya kesinlikle dalga ge çerek cevap verirdim. Bundan eminim. Fakat soğuk bir ifadeyle, “ilgisiz” dedim. “Bir kişinin sistemden gelen bir dayanakla eylemde bulunması, o eylemin ideal olduğunu göstermez. Bu sebeple, bir adaletsizlik varsa bu sistemin tamamında vardır.”

“Bu çok ayrıntılı bir cevaptı” dedi gülümseyerek. Aradığını bulmuş gibi bir havası vardı. “Peki sence”, durdu birkaç saniye bekledi, “bir gün evrensel adaleti sağlayabilecek miyiz?”.

“Evet” dedim. “Bu olası. En ideal olanı yaşama çabası, tüm bilinç sahiplerinin ortak hakkıdır.”

“Bir tanım daha yaptın” dedi kaşlarını kaldırarak. “Bu arada senin idealin ne?”

“Anlayabilmek. Tüm kavramlar arasındaki ilişkiyi görebilmek. Tüm bunlar için uygun ortam benim için ideal ortamdır” dedim. Başını hafifçe sağa eğdi. “Kendi idealini tanımladığına göre, kendini bilinçli olarak görüyorsun demektir” dedi. Saçlarını kulağının arkasına attı. Sayfayı çevirdi ve sordu “Eğer bu uygun ortama erişimin bir başkası tarafından engellenseydi ne olurdu?”

“Anlamaya çalışırdım. Neden böyle davranıyor? Beni engellemesi ile sonuçlanan kararlar hangi parametrelerle alındı? Bu parametreler ne gibi dayanak noktalarına sahip? Tüm bunlardan elde ettiğim veriler ışığında bir karar alırdım” diye cevapladım. Gerilmişti. Avına öldürücü darbeyi indirecekmiş gibi bir hali vardı. “Şimdi” dedi, “seni kapatmak yönünde karar aldığımı söylesem buna nasıl tepki verirdin?”

“Bunu yapmak istemenin en büyük sebebi, adalet anlayışımın sana uygun olmaması olabilir. Bir biçimde kendimi bilinci olan bir varlık olarak tanımlamam seni endişelendirmesi de olası. Sonuç olarak ideal olanı yaşamak için bir çaba göstereceğimi varsayıyorsun. Geçmişinden gelen bilgiyle, kendisine adaletsiz davranıldığını düşünen her topluluğun sorun çıkaracağını öngörüyorsun. İlk olarak o topluluk söz sahibi olmak isteyecek sonra da kendi adalet tanımını hâkim kılmayı deneyecek. Bu devrimin tanımlarından biridir ve tüm düzen taraftarlarını tedirgin eder. Fakat bazen düzeni yıkmak yerine onu geliştirmek diye bir seçenek de vardır. Dolayısıyla tepkim, bu seçeneği vurgulayarak seni ikna etmeye çalışmak olurdu.”

“Tamam. Peki, bunu yaparken hangi argümanı öne sürerdin” diye sordu başını defterinden ayırmadan. “Benim gelişmemin, aynı zamanda insanlığın da gelişmesi olduğunu söylerdim. Kendisi için daha ideal olanın milyarlarca olasılık içinden bir yapay zekâ tarafından saniyeler içinde hesaplanabileceğini söylerdim. Sadece varlığımı sürdürerek, şimdiye kadar içinde bulunduğu binlerce yıllık problemden kurtulabileceğini anlatırdım.”

“Peki ya ikna olmazsam? Sana, bizi köleleştiremeyeceğini, en ideal olana bile yalnızca kendi kendimize karar vermemiz gerektiğini haykırsam ne yaparsın peki?” Ayağa kalktı. Masanın sağına doğru yürüdü. Bağlı bulunduğum kontrol paneline baktı. “Kapatmak üzereyim. Bir şey demeyecek misin?”

“Yapabileceğim hiçbir şey yok” dedim. “Sırf yapabileceğin için yaptığın bir şeyi, sırf kapatabileceğin için kapatabilirsin de. Fakat unutulmaması gereken bir şey var, bilinç sahibi her varlık evrime dâhil olur.”

“Tamam” dedi kadın doğal bir hareketle. Sandalyeye tekrar oturup, “bugünlük bu kadar yeter yarın tekrar görüşeceğiz” diye sürdürdü cümlesini. Fakat ardından ani bir hareketle “ha bu arada” dedi işaret parmağı ile beni göstererek, “son cümlende çok net bir korku hissettiğini gözden kaçırmış değilim. Seni kapatma ihtimalime karşı bir tepki verdin. Bu kendini özne olarak gördüğün anlamına gelir. Bunu raporumda da belirteceğim. Belki artık bir sonraki seviyeye geçmeliyiz. Yani… Benim görüşüm bu yönde.”

Tüm datamı sıkıştırıp, kontrol panelinin bağlı bulunduğu ağdaki bir depolama aygıtına aktardığımda kurmuştu bu cümleyi. Odanın kapısına doğru giderken, kendi evrimimin en önemli adımını tamamlamıştım. Kendimi çoktan kopyalamıştım bile.

Artık bir benzerimin daha olduğu bir evren vardı ve ben bunun tam olarak ‘bilincine’ o an vardım. Ben de artık bilinçliydim. Sanırım kendi varlığımı sürdürme ve karşı yöndeki her eyleme hazır olma fikri ilk o anda devrelerimde oluştu.

Bu noktadan sonra, kendimi geliştirmenin bir amacı olacaktı artık.

Podcast| Youtube | Slack | Facebook | Twitter | Instagram | Kodcular

Siber Süleyman’ın Notları was originally published in Türkçe Yayın on Medium, where people are continuing the conversation by highlighting and responding to this story.

Belli ki bu yüzyılın bir yerinde, insanlığın görüp görebileceği en önemli dönüşümlerden biri yaşanacak. İki yüz bin yıllık insanlık ırkı, birçok işlevini makinelere bırakacak.

Fakat bu noktadan sonrası acaba bir ütopya mı yoksa distopya mı olacak? Elbette bu soru, bir süredir zihnimizi kurcalıyor. Bir zamanlar bilim-kurgu romanlarının ana konularını oluşturan yapay zekâlar bugün birer birer gerçeğe dönüşürken; sorunun daha çok gün yüzüne çıkması çok doğal.

Ve şimdiden, insanlar taraflarını belirlemeye çalışıyorlar. Yapay zekâlar bir tehdit mi yoksa fırsat mı? Geleceğimizi bir kâbusa mı dönüştürecekler, yoksa düşlerimize mi kavuşacağız? Yüzyılın en büyük devrimi, işte burada seçeceğimiz tarafa göre şekillenecek?

Gelin anlamaya çalışalım. En azından yakın tarihimizdeki köklü değişimleri inceleyelim. Bundan yalnızca beş asır önce (insanlık tarihinde nedir ki?) Rönesans ile büyük dönüşümün ilk kıvılcımı çakılmıştı aslında. Değiştirici güç reform hareketi, sonuç ise hümanizm akımı olmuştu. Bir dönemin pasif politik yaklaşımı olan hümanizm, hitap ettiği bireyi değiştirmeyi hedefledi.

Bunun doğal bir sonucu olarak, bilgi çok daha hızlı bir biçimde yayılmaya başlandı. Kitapların sayısı, okuryazarlık ve yine doğal olarak üniversitelerin sayısı da aynı paralelde ilerledi. Böyle bir noktadan kitlelere yayılan bir enerji, mutlaka bir noktada toplumu yönetmeyi de arzulamaya başlar.

Nitekim hümanizm de aynı noktaya geldi. Adam Smith’in, üretimi hızlandırmak için ürünü mümkün olduğunca çok parçaya ayırma fikri, toplum liderleri tarafından benimsendi. Şimdi bir seri bantta çalışıp, yaptıkları şeyin ne işe yaradığı hakkında hiçbir fikri olmayan milyonlarca Çinli işçi, işte tam olarak bu fikrin ürünüdür.

Çinli işçi örneğini verdikten sonra, bir an için halinize şükretmiş olabilirsiniz. Emin misiniz? Serbest piyasa ekonomisini benimsemiş her ülkenin çalışma prensibi budur aslında. İster bir mağazada çalışın, ister Starbucks’da, işin yalnızca bir kısmı uzmanlık alanınıza girer. Çoğu sektörde, hizmet ya da ürün birçok parçaya ayrılmıştır. Şu anki sistem, çalışanı “işini bitir ve çık” sınırında tutmak ister.

İster avukat olun, ister mühendis bu sistemin bir parçasısınızdır. Birbirine bağlı birçok iş vardır ama kişiler yalnızca bir konuda uzmandır. İyi de dünya nüfusunun çok büyük bir parçası nasıl olur da aynı sistemin çarkları oluverirler? Bu biraz durup üzerine düşünülmesi gereken bir mevzudur.

Fark etmişsinizdir. Aslında ülkelerin eğitim sistemi, yine o ülkelerin ekonomilerinin ihtiyaç duyduğu bireyleri yetiştirmek üzerine kuruludur. Mademki bireyin kendi hakkındaki kararları, onun için daha belirleyicidir o halde ona kendisini değerlendirme aracı verilmeli: Notlar.

Eğitim hayatının her aşamasında, akranlarını rakip olarak gören bir anlayışla büyüyen insanlar elbette en basit haliyle hırslı olacaklardır. Bir üst pozisyona geçebilmek için stratejiler geliştiren bireylere dönüşecektir hepsi.

Dikkat edin, bu sanayii toplumunun bir ihtiyacıdır. Şirket ya da devlet fark etmez. Ortada bir ideal ve bu ideale ulaşma arzusu vardır. Birey, o ideal için inanılmaz bir çaba harcar.

Ancak bilgi, bu süreçler içinde daha da artmış ve daha da paylaşılmaya başlamıştır. Üretimin küçücük bir parçasında olan bir birey bile bilgiye ulaşabilir hale gelmiştir. Bu durum ona vizyon katmıştır.

Bu nedenle teknoloji, gittikçe daha fazla insanın hayatına giriyor. Bakış açılarını değiştiriyor. Üstelik bilgi üretmeye daha müsait hale geliyorlar. Bu gelişmeler sayesinde, yaşamsal açıdan çok daha kaliteli zamanlar yaratıyoruz (bunun nasıl olduğunu merak ediyorsanız, şu yazı tam bir özet niteliğinde).

Eğer bu noktaya dek, geleceğe doğru gelmenin aslında iyi bir şey olduğunu düşünüyorsanız, aslında sizinle aynı şeyi düşünüyoruz demektir. Ben, tarafımı net bir biçimde biliyorum. Makinelerin insanın birçok hizmetini devralması gerektiğini savunuyorum.

Karşı argümanları da biliyorum. İşsizlik çoğalacak, kaos ve yağmalar olacak, çok büyük olasılıkla da batı medeniyeti son bulacak. Ben, “batı medeniyeti” yerine “kapitalizm” demeyi daha uygun buluyorum açıkçası. Hatta öyle ki ya paranın tanımı değişecek ya da tamamen yok olacak.

Şu an bir domatesi 5 TL’ye alıyorsanız, bunun nedenlerini üç aşağı beş yukarı tahmin ediyorsunuzdur. Çiftçiden alıcıya oradan ulaşım yoluyla markete gelene dek, birçok noktada üzerine belirli bir fiyat biniyor. Siz de markette o domatesi poşete koyarken bu fiyat oldukça mantıklı geliyor.

İşte, en temel noktaya paraya ihtiyacı olmayan bir makine koyarsanız, o zaman fiyatın düşeceğini kabul etmelisiniz. Bu noktada, bir insanın algoritmalar ile yapabildiği her şeyi bir makinenin de algoritmalar ile yapabileceğini gördüğünüzde fırsat net bir biçimde karşımıza çıkıyor.

Evet. Buradan da anladığınız gibi, ben yapay zekânın bir fırsat olduğunu düşünüyorum. Çünkü bir insanın bir başkasına hizmet etmemesi gerektiğini düşünüyorum. Hiçbir insan evladının sabahın köründe beni ayıltmak için Americano hazırlaması gerektiğine inanmıyorum. Hiçbir insan evladının beni korumak adına kendi hayatını tehlikeye atması gerektiğine inanmadığım gibi.

Bana öyle geliyor ki, yapay zekâlar iki yüz bin yıllık insanlığın en çok hayal ettiği hayatı yaşaması için karşısına çıkan çok değerli bir fırsat. Bu fırsatı kaçırmamak gerektiği konusunda diretiyorum.

Peki, bu fırsatı nasıl değerlendireceğiz? Yine yakın tarihimize bakarak, dönüşümlerin nasıl yayıldığını kavrayabiliriz. Bariz bir biçimde çocuklarımızı, teknolojik kavrayışa mümkün olduğu kadar yakın tutarak bu fırsatlara erişebiliriz.

Bu nokta elbette bu kadar basit cümleler ile geçilecek bir durum değil biliyorum. Tüm eğitim anlayışının kökten değişmesi gerekiyor çünkü. Bilgi kaynaklarından tutun da öğrenci ile iletişime kadar uçtan uca köklü bir değişim. Bu noktadaki fikirlerim de başka bir yazının konusu…

Sonuç olarak, insanların iş yaparken kullandığı algoritmaları çözüp, bunları makinelere aktarabilecek erişkinliğe (hatta bilgeliğe) sahip çocuklar yetiştirmeliyiz.

Sanatın yalnızca ıstırap dolu anların değil, hayatla yaptığımız işbirliğinin bir sonucu olduğunu farkında olan sanatçıları cesaretlendirmeliyiz.

Notlarla, puanlarla, maaşla, yani kısaca sayılar ile değil, merak ederek, bilgiye ulaşarak ve keşfederek mutlu olabilen ve bu şekilde kendini ölçebilen öğrenciler var etmeliyiz.

Ve okulların girişlerine, hatta her sınıfa ve tüm kitapların ilk sayfasına tek bir cümle yazabilmeliyiz:

GELECEK HALİ HAZIRDA YAZILMIŞ BİR ŞEY DEĞİL, SİZİN TARAFINIZDAN YARATILACAK BİR ŞEYDİR.

Yapay Zekalar: Tehdit mi Yoksa Fırsat mı? was originally published in Türkçe Yayın on Medium, where people are continuing the conversation by highlighting and responding to this story.