“Kod” yazmak aslında çok eskiye dayanan bir iletişim yöntemi. Mağaralara, duvarlara, kitaplara belli işaretler ile bazı kavramları, bazı insanlara anlatmak için insanoğlunun çok eskiden beri çabaladığı bir iletişim yöntemi. Artık bilgisayar denen cihazı yarattığımız ve yaşantımızda önemli noktalara yerleştirdiğimiz için onunla iletişime girebilmemiz için de “kod” yazmak daha da önemli hale geldi. Bilgisayarların anlayabildiği diller ile onların çözümleyebileceği kompleks problemleri çözmek ve bazı ihtiyaçları gidermek artık insan hayatının önemli bir parçası haline geliyor…
Offff yeter, bu kadar felsefe yeter, konumuza geçelim. 😜 Son bir kaç zamandır “Infrastructure as Code(IaC)” kavramı ile ilgili ellerimi kirletiyorum. Daha önce sadece okuduklarım kadar bir hakimiyetim vardı kavrama. Artık biraz dokunmanın da zamanı geldi sanırım. Açıkcası IaC ile ilgili çok uzun uzun bir şeyler anlatacağım bir yazı olmayacak. Biraz daha, anahtar kelimelerin bol olacağı, “Infrastructure as Code(IaC) nedir?”, “Neden gerekir?” ve “Avantajları nedir?” gibi sorulara cevap olabilecek ve IaC kavramı ile tanışmak isteyenlere yol gösterebilecek bir yazı olacak. Hadi bakalım…
Nedir bu Infrastructure as Code(IaC)?
“Kod olarak altyapı” diye direkt chicken translate tadında çevirince çok çirkin oluyor. Ama anlamaya başlamak için birkaç ip ucu veriyor. Yazılım çözümlerinin çalıştığı altyapılar artık sadece elektronik birer kutu değil. Günümüzde hele hiç değil. Altyapılar da ihtiyaç çerçevesinde karmaşık bir hal alabiliyor. Yönetmesi zorlaşıyor. Yönetmeye gelene kadar kurması ve altyapıları ayağa kaldırmak zorlaşıyor. Bu zorlukların, zaman ve maddi açılardan götürüleri de oluyor. Günümüzde de önemli konular. Artık “kod” yazarak belli problemleri çözmeye başladığımız için bu problemleri de kod yazarak çözebilir miyiz diye ortaya çıkan bir kavram IaC. Özetle ve basitçe; IaC için altyapıların oluşturulması, kurulması, güncellenmesi, kopyalanması ve ayağı kaldırılması konularını güvenilr ve hızlı bir şekilde yapabilmek için reçete hazırlama diyebilirim. En azından ben bu şekilde bakarak biraz daha kolaylaştırmaya çalışıyorum. Bu reçetenin belli bir standart içinde oluşturulması için de Chef, Terraform, Puppet, Ansible, Google Cloud Deployment Manager, Azure Resource Manager, AWS CloudFormation gibi farklı teknolojiler mevcut.
ASP.NET Core‘un en önemli özelliklerinden biri de “Middleware” yapısı. “Request-Response” modelinin ortasında özelleştirilmiş operasyonlar gerçekleştirip, request-response akışını yönetmek için oldukça etkili bir özellik. Gelen bir request‘in geçerliliğini kontrol etmek, response‘ları cache‘den oluşturmak gibi gibi birçok farklı ihtiyacı bu araya koyduğumuz yapılar ile ASP.NET Core‘da yapabiliyoruz.
“Middleware”ler temelinde IApplicationBuilder arayüzünden türeyen bir sınıfa eklenti şeklinde eklenen metotların çalıştırılmasını sağlayan bir yapı. Web uygulamalarında da uygulamanın “request-response” yönetimini sağlayan sınıfın, yeni metodlar ile yapabileceklerinin artması ya da çeşitlenmesi şeklinde de basitçe düşünebiliriz. Çok daha ayrıntıya girmeden yavaştan konumuza geçelim…
Şartlı “middleware” kullanımı…
Eklediğimiz “middleware“‘lerin farklı şartlarda/durumlarda geçerli olmasını ya da olmamasını çok kolay bir şekilde ASP.NET Core‘da sağlayabiliyoruz. Bu ne demek hızlıca bakalım…
Biraz daha anlaşılır olması için, basit bir senaryo örneği oluşturalım. Bir “middleware” geliştirdiğimizi düşünün, web uygulamasına gelen request‘in header bilgisindeki bir değeri kontrol etsin; “GET www.abc.com/v1/user/” eğer bu request‘in header‘ında key:abc123 varsa geçerli bir request olsun, yoksa da 401 dönsün… Çok tanıdık ve standart bir senaryo. Bu senaryoyu biraz daha kompleks hale getirelim. Eğer yeni geliştirdiğimiz v2 versiyonuna bir request gelirse de ek olarak farklı bir kontrol daha yapılsın.
Şimdi “Ama bu çok kolay zaten, ne var ki bunda” dediğinizi duyar gibiyim.😉 Geliştirdiğimiz “middleware” içerisinde bir if-else kontrolü ile akışı kontrol eder ve ihtiyaca göre istenilen operasyonları gerçekleştirebiliriz.
Ne yazık ki yazılım geliştirme için bu basitlik yeterli değil, daha da basit olmalı. 🤔 Geliştirdiğimiz bu “middleware“i farklı projelerinde de kullandığımızı ve projelere göre farklı adreslerin olabileceği (/v1/user değil, versiyon1/user/ mesela) ya da farklı ek özelliklerin gerektiğini düşünün…
UseWhen()
Az önce yukarıda “middleware” yapısının, eklenti(extension) metodlar ile oluştuğunu belirtmiştim. ASP.NET Core içerisinde olan UseWhen() metodu da yine bir extension metot ve bununla diğer “middleware”‘leri belli şartlara göre uygulamamızda geçerli olacak şekilde kullanabiliyoruz.
Yukarıdaki örnekte eğer request yapılan adres “/v1” şeklinde bir içerikle başlıyorsa, ApplicationAuth diye bir “middleware” kullanılsın şeklinde bir tanım var. Eğer request yapılan adres “/v1” şeklinde başlamıyorsa araya eklediğimiz “middleware” etkili olmayacaktır. Ve alttaki diğer “middleware”‘ler etkili olacaktır.
Bu sayede ApplicationAuth “middleware“‘in içindeki kodu temiz ve sade tutarak, kütüphane şeklinde birden fazla projede kullanabilir hale getirebiliyoruz.
MapWhen()
Benzer bir yapıyla da bir “middleware”‘den sonra “request-response” arasındaki akış devam etmesin ve farklı bir şekilde sonuçlansın istenebilir. Bunun içinde MapWhen() extension metodu yardımımıza koşuyor.
Yukarıdaki örnekte de MapWhen() ile, request yapılan adres “/v1/user/” şeklinde başlıyorsa, ActiveEndPointCheck “middleware”‘i etkin olacak ama sonrasındaki diğer “middleware”‘ler etkin olmayacaktır. Bu yüzden MapWhen()’nin kullanımına ekstra dikkat etmek gerekiyor.
Hem MapWhen() hem de UseWhen() parametre olarak Func<HttpContext, bool> şeklinde bir boolean dönen delege bir metot bekliyor. boolean dönen her hangi bir ifade ile de metotlar için geçerlilik oluşturabiliyoruz.
ASP.NET Core içinde gelen bu iki extension metotu GitHub’dan da kontrol edebilir, kendi projelerinizde de benzer yaklaşımları uygulamak için ilham alabilirsiniz. 😀
“Middleware”‘ler kullanım yöntemleri ile de ASP.NET Core çözümlerine oldukça değer katıyor. Basit ama etkili bu iki metot benim ihtiyacımı hızlıca çözümlememde çok yardımcı oldu, aynı hızla ben de paylaşmak istedim. Umarım size de yardımcı olur.
gRPC ile Raspberry Pi için bir şeyler kurcalarken tanışmıştım. .NET Core tarafında da destekleniyor olması bir çok kişinin daha tanışmasına vesile oldu sanırım. Nedir, ne değildir bunlara çok ayrıntılı girmeyeceğim; ama özet olması için, Google tarafından geliştirilen, HTTP/2 protokolü üzerinde çalışan bir Remote Procedure Call(RPC) framework’ü diyebilirim.
gRPC – Remote Procedure Call
En önemli artısı yazılım dili bağımsız olması ve yüksek bir performansa sahip olması. protobuf(Protocol Buffers) olarak adlandıralan yapısal verileri serialize(binary olarak) eden bir mekanizması oluğundan performansı ihtiyaçlara göre oldukça iyi. Bir çok yazılım dili desteğinde, C# ve .NET Core da mevcut. .NET Core tarafında gRPC servislerini ASP.NET Core çatısı altında oldukça kolay bir şekilde geliştirebiliyoruz. gRPC servislerinde, belli bir kontrat ile veriler yapısal iletildiği için, .NET Framework yapılarındaki servis kavramlarına denk olarak anılıyor, .NET Core’da. Ancak özellikle belirtmek isterim ki gRPC, WCF ya da *.wsdl yapılarının .NET Core’da ki karşılığı kesinlikle değil.
Gelelim konumuza… “gRPC nedir?”, “.NET Core’daki gRPC nedir?” gibi sorularıdan çok, “Peki neden?” sorusu üzerinden gidip, “.NET Core’da neden gRPC var?”, “Neden kullanalım ki?” diyerek, beğendiğim bir özelliğinden, .NET Core çatısı altında bahsetmek istiyorum…
Streaming…
Remote Procedure Call diye havalı olarak söylediğimiz kavramın, en basit ve çok kullandığımız yalın ifadesi “servis” bildiğiniz gibi. En çok karşımıza çıkan “Request-Response” mesajlaşma modeli gibi, gerçek zamanlı mesajlaşma modeli(a.k.a streaming) de servislerin olmazsa olmazı.
İşte bu streaming ihtiyaçları için, .NET Core’daki gRPC desteği dikkat çeken, güzel bir özellik. Belli bir kontrat yapısı ile verilerin akışını sağlayan servisleri ASP.NET Core tarafında bu şekilde kolaylıkla, genel standartlara uygun bir şekilde geliştirebiliyoruz.
100 soruluk bir sınav yapmış olalım. Sınav kağıdımızı teslim edelim ve soruların cevabını bekleyelim. Sınav kağıdımız tamamen okunana kadar, sorduğumuz soruların cevaplarını öğrenmek pek mümkün olmaz.
Servis çağrımlarında da böyle durumlar olabiliyor; standart bir request-response modelinde, 1000 tane veriyi işleme sokulsun diye bir servise gönderdiğimizde, 1000 tane verinin de tamamen işlenmesi sonrasında sonuçları alabiliyoruz. Servise gönderdiğimizde sonuç olarak, direkt işlenen verileri sırayla gönderse iyi olmaz mıydı…
Bu örneğe benzer bir senaryomuz olsun. 1+2, 5*10, 6/3 şeklinde matematik işlemlerini toplu bir şekilde sorulabileceği bir servisimiz olsun. Servis de bu işlemlerin sonuçlarını yaptıkça dönsün…
Çok konuştuk biraz da kodlar üzerinden gidelim. Öncelikle *.proto dosyamızda servis kontratına bir bakalım.
GitHub‘ın kullanımı gün geçtikçe artıyor. GitHub kullanımının artması ile beraber de ihtiyaçlar ortaya çıkıyor. İhtiyaçlar da ortaya çıktıkça, GitHub bunlara çözüm üretiyor doğal olarak. Çok daha fazla uzatmadan bu çözümlerden biri olan, GitHub Actions‘dan; giriş olması adına kısaca bahsetmeye çalışacağım.
GitHub Actions ile, kodları yönetmek, paylaşmak ve dağıtmak gibi aksiyonlar için iş akışları oluşturabiliyoruz. Bir nevi, kodların çeşitli kavramlarla etkileşime girmesini sağlayabiliyoruz. Kodların derlenmesi, paketlenip dağıtılması, çeşitli platformlarda çalıştırılması, durum güncellemeleri ve bildirimlerin oluşturulması, issue yönetimi gibi gibi değişik birçok aksiyonu GitHub Actions ile gerçekleştirebiliyoruz.
Şimdi bütün bunlar, aslında yeni yaklaşımlar değil, bir çoğunuz için tanıdık gelecektir belki de. Her özel kod deposunda, çeşitli script/bash gibi yapılar ile bunları gerçekleştirmek bir şekilde mümkün(!). GitHub‘ın kullanımı arttığı için, bu tarz ihtiyaçların onun da üstünde gerçekleştiriliyor olması, GitHub’ı daha da cazip hale getiriyor, getirmeye başlıyor. Çok dağılmadan basit bir GitHub Action oluşturalım ve bakalım neymiş.
Her repository’nin menüsünde “Actions” başlığını dikkatinizi çekecektir.
Bu başlığa girdiğimizde aşağıdakine benzer bir ekran ile karşılaşacağız.
Burada hazır bazı aksiyonları başlangıç olması adına bulabiliyoruz. İhtiyacınız olan aksiyonu bulup “Set up this workflow” demek ve gerekli ayarları yapmak oldukça kolay. Aksiyon olayını anlamak için biz sağ tarafdaki “Set up a workflow yourself” diyelim ve aksiyonlarımızı yaratmak için editörü açalım.
Örnek olarak ben çok basit bir senaryo üzerinden anlatmaya çalışacağım. Mesela herhangi bir kod push olduğu zaman, kodumuzu derlensin…
GitHub üzerinde de aksiyonlar *.yml dosyası olarak tanımlanıyor. YML dosyaları konfigürasyon dosyaları için tercih edilen bir standart haline geldi diyebiliriz sanırım arık. Bu YML dosyalarını GitHub üzerinden kolay bir şekilde, komutlar ve özelliklerini gösteren basit bir IntelliSense desteği ile düzenleyebiliyoruz.
Örnek olarak üzerinden gideceğim aksiyon içeriği aşağıdaki gibi, adım adım parçalarına bakalım…
Geçtiğimiz yıllarda Visual Studio‘nun online versiyonu; yani internet üzerinden, internet tarayıcılar üzerinden kullanabileceğimiz bir versiyonu üzerinde çalışıldığı duyurulmuştu. Artık her şeyin cloud tabanlı çözümlere evirilmesi, geliştirme yöntemlerinin de cloud’a evirilmesi ortaya çıkarıyordu. Birçok farklı yazılım geliştirme yöntemleri ve araçları da aslında var(dı). Herhangi bir bilgisayar üzerinden sadece internet bağlantısı ile tarayıcılar üzerinden yazılım geliştirebiliyoruz, yani kısmen… Microsoft bu olayı biraz daha öne taşımak için bir adım attı ve Visual Studio Online‘ı, açık ön izleme (public preview) şeklinde duyurdu. Duyduğum an hemen bir ön izleme de ben yapmak istedim.
“Visual Studio Online” vs. “Visual Studio Code”
Visual Studio Code(VS Code) ile haşır neşir olanlar için Visual Studio Online(VSO) farklı bir editör olarak gelmeyecektir, -ki zaten farklı da değil. Bildiğiniz üzere VS Code, Electron tabanlı (node.js, JavaScript) bir text-editor… Microsoft’un dokunmasıyla ortaya çıkan Monaco Editor ile Visual Studio Code şeklinde kullanıyoruz. Electron vs JS tabanlı olması, gerçek anlamda platform bağımsız bir çözüm olmasının en büyük özelliği. Bu sayede de internet tarayıcılar üzerinden de kolaylıkla çalışabiliyor. Özetle VSO ile VS Code üzerinde yapabildiğimiz birçok geliştirmeyi yapabiliyoruz. VS Code’un birçok özelliğini de kullanabiliyoruz. VS Code eklentileri, Live Share, Debug, Git…. gibi gibi birçok özelliği internet üzerinden tarayıcı ile kullanabiliyoruz…😉
Bütün bunlar aslında bir sanal makina üzerinde oluyor. Azure üzerinde yarattığımız bir “Instance” ile fiziksel geliştirme ortamımız oluşuyor. Ama bu ortama tabi ki ulaşmamız mümkün değil. “Sanal makina”, “Azure” diyince tahmin ettiğiniz gibi VSO ücretsiz değil… Azure üzerinde çeşitli kaynakları tükketiğimiz için, bu kaynak kullanımlarına göre çeşitli bir ücretlendirme politikası var. Ücretsiz değil yani; ama makul. Daha ön izleme dönemi olduğu için bu olaylar değişecek, farklı opsiyonlarda gelecektir diye düşünüyorum.
Geliştirme ortamı oluştururken, ilk aşamada 4-core, 8GB Ram ve 8-core, 16GB Ram şeklinde iki opsiyon var. Bu iki opsiyonda Linux işletim sistemi ile sunuluyor. Bu iki opsiyona göre ücretlendirme çeşitleniyor tabi ki. Burada “Suspend” şeklinde önemli bir özellik var. Geliştirme ortamı belli bir süre “idle” olarak kalırsa, otomatik olarak “suspend” duruma geçsin diye ayarlanabiliyor.
Yukarda da bahsettiğim gibi temel olarak VS Code ile yapabildiğimiz tüm geliştirme tecrübelerini VSO ile de gerçekleştirebiliyoruz. Temelinde bir text-editor olduğu için birçok yazılım dilini yazmak mümkün. Daha yoğun bir şekilde .NET Core ile uğraştığım için, ilk olarak hemen basit bir .NET Core konsol projesi denedim.
Bakalım nasıl oldu?
Terminalden direkt dotnet new console komutu ile bir konsol uygulaması yaratmak oldukça basit. Linux tabanlı bir geliştirme ortamı olduğu için, terminalden standart Linux komutlarını çalıştırmak ve bir geliştirme ortamında nelere, nasıl ihtiyacınız varsa yapmak mümkün.
Bu arada VSO’da default olarak gelen .NET Core versiyonu 2.1.x ama şimdilik 😉
Malum VS Code sadece text-editor olduğu için daha sağlıklı bir geliştirme tecrübesi için bazı eklentiler gerekli olabiliyor, VSO tarafında da aynı olduğu için C# eklentisini kurarak, IntelliSense, Highlight gibi olmazsa olmaz bazı özellikleri VSO’da da çok rahat bir şekilde kullabiliyoruz.
Debug adımı bir yazılım geliştirme sürecinin olmazsa olmaz adımı olduğu için, herhangi bir geliştirme ortamında Debug yapabiliyor olmak en önemli adım. VSO’da da Debug yapabiliyoruz… VSO ilk duyurulduğunda ilk aklıma gelen ihtiyaç bu olmuştu. Standart bir breakpoint koyduktan sonra kodu Debug edebiliyoruz.
Standart olarak F10, F10, F11… ve F5. 😀
VS Code’daki debug deneyimi aynen internet tarayıcısı üzerinden de yapılabiliyoruz. Tabi şimdi deneyimlediğimiz proje basit bir konsol projesi, “Hello World” diyoruz o kadar… Peki ya biraz daha kompleks proje tipleri? İnternet tarayıcıda, bir web uygulaması geliştirebiliyor muyuz? 🤔
Açıkcası bunun için hiçbir engel yok. dotnet new razor şeklinde basit bir ASP.NET Core uygulaması oluşturup, teknik olarak debug yapabiliyoruz(?) ya da çalıştırabiliyoruz(?) yani kısmen… VSO’da bir web uygulaması geliştirip, çalıştırdığımız zaman ilgili port’ları geliştirme ortamımız için yönlendirip, erişebilir bir duruma getirebiliyoruz. Açıkcası ilk çalıştırdığım zaman ulaşabildim ancak sonraki denemelerimde çözemediğim bir şekilde olmadı. Preview diye çok üzerinde durmadım ama özetle web geliştirmelerini VSO üzerinden yapmak ve çalıştırmak mümkün.
Özetle temel geliştirme ihtiyaçlarını çok rahat ve sorunsuz bir şekilde gerçekleştirebiliyoruz diyebilirim. Benzer şekilde Python, JavaScript vs. gibi farklı dillerde kodlar yazmak mümkün. VS Code eklentileri ile geliştirme ortamınızı da ciddi bir şekilde güçlendirmek mümkün. Azure eklentileri, Google eklentileri vs. ile geliştirilen projeleri çok hızlı bir şekilde yayına almak oldukça kolay. Geliştirme ortamlarının olmazsa olmazı Git, geliştirme ortamlarının özelleştirilmesi vs. gibi birçok VS Code özelliğini direkt internet tarayıcısı üzerinden kullanabiliyoruz.
Visual Studio Online, çok yakın zamanda değil belki ama orta ve uzun vadede geliştirme alışkanlıklarına ve cihazlarına ciddi anlamda yön verebilecek bir gelişme diye düşünüyorum, bu yüzden kısa bir giriş ile biraz merak uyandırıp ilginizi çekmek istedim. Mutlaka bir ara göz atın ve kullanmaya başlayın derim…
Komut satırı uygulama modeli(console/terminal) her yazılımcının oldukça aşina olduğu bir yazılım modelidir sanırım. Yazılım ile uğraşan herkesin bir şekilde belki de başlangıç noktası… Basit bir “Hello World” çıktısını konsola yazdırmak çeşitli yazılım dillerini öğrenmek için olmazsa olmaz 🙂
node –help
Son kullanıcı ihtiyaçları açısından ve kullanıcı etkileşimi açısından artık çok tercih edilmese de, basit ve hızlı bazı görevlerin gerçekleştirilmesinde tercih ediyoruz hala. Geliştiricilerin, belli “proof of concept” çalışmaları, denemeleri ve geliştirme araçlarının çeşitli özellikleri açısından daha aşina olduğu bir model. Konsol ya da terminallere yazdığımız komutlarla bir çok uygulama ile bir çok temel işlemi yapabiliyoruz. Eminim bir çoğumuzun oldukça aşina olduğu bazı araçların, konsollarda çalıştırdığımız komut satırı fonksiyonları gündelik hayatımızın bir parçasıdır.
dotnet build –help
Bu basit girişten sonra çok da uzatmadan gelelim konumuza…
Bir çok geliştirme araçının komut satırı komutlarının çıktılarının benzerliği ya da bazı komutların standart olması dikkatinizi çektmiştir sanırım. Bir çok uygulamanın komut satırı arayüzlerinde(command-line interface, CLI) –help, –info komutlarının standart olması gibi.
Command Line API
.NET Core ile birlikte bir çok API ya da kütüphane de ortaya çıkıyor, ve bu kütüphaneler bir çok temel işlemi kolayca gerçekleştirmemizi sağlıyor. Bunlardan biri de Command Line API ve System.CommandLine… Bu API ile yukarıda bahsetmiş olduğum konsol uygulamalarının ya da komut satırı uygulamalarının temel işlemleri çok daha kolay bir şekilde yapabiliyoruz.
Şimdi küçük bir uygulama ile Command Line API’ı biraz daha yakından tanıyalım. Bu API’ın temel sınıfı CommandLineBuilder, bütün olay bu sınıf çevresinde dönüyor. Adından da anlaşılacağı gibi komut satırı akışımızı bu sınıf ile hallediyoruz. Basit bir şekilde aşağıdaki gibi bir Main() metodumuz olsun.
class Program
{
private static Task<int> Main(string[] args)
{
ReportCommand rcmd = new ReportCommand("report");
PrintCommand pcmd = new PrintCommand("print");
Parser parser = new CommandLineBuilder(new Command("konsol"))
.AddCommand(rcmd)
.AddCommand(pcmd)
.UseHelp()
.UseDefaults()
.Build();
return parser.InvokeAsync(args);
}
}
Bu senaryo için ReportCommand ve PrintCommand diye, report ve print adıyla iki örnek komut oluşturdum(birazdan ayrıntılarına gireceğim) ve bu komutları CommandLineBuilder()’a konsol adı altında çalıştırılacak komutlar olarak ekliyoruz.
Kütüphanenin sağladığı bazı kolaylıkları da CommandLineBuilder() ile birleştirip uygulamamızı hazır hale getiriyoruz.
dotnet run -- --help
dotnet run -- --version
yazarak projemizi çalıştırdığımız zaman aşağıdaki gibi bir çıktı karşımıza çıkacak. Dikkat ederseniz ki bu çıktıyı oluşturmak için herhangi bir Console.WriteLine() şeklinde kod yazmadık.
Bu help çıktısı, bize 2 tane komutun(report,print) olduğunu, bu ikisinin de bir tane argüman aldığını söylüyor.Şimdi de report komutu için olan help kısmına bakalım.
dotnet run — report –help
Bu çıktıya göre de report komutunun argüman olarak alabileceği seçenekleri ve option olarak -pid ya da –product-id adıyla bir değer alabileceğini görüyoruz.
Biraz daha netleşmesi için yukarda birazdan ayrıntılarına gireceğim dediğim komutlardan ReportCommand sınıfına bakalım. Bu System.CommandLine kütüphanesini kullanarak bizim yazdığımız özel bir sınıf. System.CommandLine API amacı daha güvenilir ve gerçekten amaça yönelik fonksiyonlara odaklanmak olduğu için, gerçekten ne yapmak istiyorsak onu yazıp, bu kütüphanenin özellikleri ile de çıktıları üretebiliyoruz. Neyse biz ReportCommand’a dönelim.
9 senedir bana hayat arkadaşı olan tüylü bir yaratık var hayatımda. Kimileri kedi diyor ama ben Sigur diyorum ona, kedi değil yani. Nevi şahsına münhasır bir yaratık…
9 senedir benim hayatımdaydı, ben hayatta olduğum sürece de hayatımda olacak bir şekilde. Ama ben, onun adına için aynı şeyi söylemeyeceğim sanırım. Haber vermeden sonsuzluğa doğru gitti. Haber verdi ama yediremediğim için kabullenmedim belki, bilemeyeceğim sanırım.
Çok koydu gitmesi… “Kodum mu oturturum” denir ya; harbi oturttu. Kaldım öyle. Bilfiil 9 sene hayatımda çok büyük yere sahipti. Dostum, sırdaşım olmuştu. Bana bakışları ile anlatıyordu her şeyi; hayatta anlamadığım, kafamın basmadığı konuları sakin sakin anlatıyordu. Benim de bakışlarımdan anlıyordu beni. Sinir olduğum durumlar karşısında sakinleştiriyordu. Hissettiklerimi anlayıp hemen arka da çıkıyordu. Espri yeteneği de şahaneydi, güldürüp mutlu ediyordu hep. Ama sadece bana yapıyordu bunları… Gizli bir amacı var gibiydi. Asla bilemeyeceğiz sanırım. Arada klasik kedi atraksiyonları ile herkese şirin gözükmeye çalışıyor, kedi gibi ses çıkartıp (gerçi tam beceremiyordu) kimliğini gizliyordu galiba. “Bakışları garip bir kedi” dediklerinde bana dönüp göz kırpıyordu, “Merak etme kimse anlamaz, mıyevvv” diyordu…
Bir şekilde oturttuğu yerden ayağa kalkıp yola devam edeceğim. Gitmeden önce bana bıraktığı mutluluklar, anılar ve tabi ki tüyler yolda erzak olarak bana eşlik edecek. Yaşamda, hayatımıza giren her canlının bir rolü var derler ya; sanırım doğru. O rolünü çok güzel oynadı, hissettirdiği duygular ile çok şey kattı hayatıma. Ben de umarım ona karşı olan rolümde başarılı olabilmişimdir.
Sigur;
Bana yaşattığın her hissiyat, her tecrübe için çok ama çok teşekkür ederim. Kattığın mutluluk, sevgi, hüzün, komiklikler, kahkahalar, göz yaşları için ayağa kalkıp, önümü ilikleyip, alkışlıyorum seni Sigur… Hepsi çok güzel ve çok özeldi. Sadece bana da katmadın, hayatımda olan birçok kişiye de dokundun sanırım. Herkesi bir şekilde mutlu ettin. Teşekkür ederim…
Umarım beni mutlu ettiğin kadar ben de seni mutlu ve huzurlu hissettirebilmişimdir bu dünyada. Gittiğin yerde huzurlu ve mutlu olacağına eminim. Beyefendiliğin ile oralarda da çok sevilecek ve mutlu olacaksın, adım gibi biliyorum.
