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

Office 365 kullanımı arttıkça yeni ihtiyaçlar ve özellikler ortaya çıkıyor. Microsoft Graph da bu ihtiyaçların sağlanması için ortaya çıkmış bir API platformu olarak yaklaşık 2-3 sene önce karşımıza çıktı. İlk çıktığında fiziksel olarak Office 365 sınırları içinde lanse edilse de, geçen sene Microsoft 365 konsepti ile; Office 365, Windows 10 ve mobil-güvenlik servislerini bir arada geliştirebilmek için gelecek vaat etti. Geçen sene Build 2017’de belli oturumlarda gösterilen demolar ile güzel heyecanlar yaşatmıştı…

Graph API

Office 365 kullanıyorsanız, platformun bir çok özelliğine Microsoft Graph API’ları ile erişmek mümkün. Bu sayede geliştirdiğiniz çözümler ile Office 365 çözümlerini entegre etmek ya da Office 365 ürünlerine eklentiler geliştirmek mümkün. Office 365’deki e-mail, OneDrive, OneNote, kullanıcı grupları, Planner, takvim vs. ürünlerindeki çeşitli özellikleri Graph API’ları ile kullanmak bir çok kapı açıyor. Office 365 API’ları ile bunları yapmak mümkün olabiliyordu kısmen, ama artık tek bir platformda Microsoft Graph çatısı altında ihtiyaçları sağlamak daha doğru ve geçerli. Ben demiyorum, Microsoft diyor… 🙂

Microsoft Graph API’ları özetle;

  • Azure AD
  • Outlook(E-Mail, Takvim, Kişiler, vs.)
  • OneDrive
  • SharePoint
  • OneNote
  • Planner
  • Yammer
  • Excel
  • Microsoft Teams
  • Intune
  • Azure AD Identity Protection
  • Azure Security Center

ürünlerinin çeşitli özelliklerine API olarak erişmek için güzel bir platform olarak karşımıza. Bu platformdaki API’lar REST ile sunulan bir yapıya sahip. Dolayısıyla bir çok farklı geliştirme teknolojisi; .NET Framework, PHP, Python, Swift(iOS), Objective-C(iOS), Android, Ruby, Node.js gibi, bu API’ları kullanmak mümkün.

Graph API

Yukarda da dediğim gibi geliştirdiğimiz çözümlere bu ürünlerdeki özellikleri katmak ya da bu ürünlere eklentiler geliştirmek bir çok kapıyı açıyor.

Daha önce GitHubda bir PoC çalışması için bir şeyler karalamıştım. Bunun üzerinden kurcalayıp siz de farklı API’lar ile farklı ihtiyaçlarınızı karşılayabilirsiniz. Orda basit olarak bir Office 365’deki Outlook e-mail hesabına gelen e-mail’leri filtreleyip belli bir operasyon gerçekleştirmenin senaryosu vardı. Kurumsal bir çok firmada, belli süreçleri otomatikleştirmek için tercih edilen bir senaryo, tanıdık gelmiştir. 🙂 🙂

Microsoft Graph API’ları ile bunu gerçekleştirmek, gelen bir e-mail’i parse edip, içeriğine göre Planner’da bir görev yaratmak, daha sonra e-mail’in eklerini OneDrive’a kaydedip kendi geliştirdiğiniz ERP uygulamasında süreç başlatmak gibi senaryolar oldukça kolay. Diğer API’lar ile daha kompleks ihtiyaçları kolay bir şekilde gerçekleştirebiliyoruz.

Microsoft Graph farkındalığı ve API’lara giriş için umarım biraz olsun kıvılcım yakar. Şimdilik bu kadar. Merak ettiğiniz, takıldığınız noktalar olursa; biliyorsunuz… 😉

Bu arada daha derinlere girmek için aşağıdaki kaynakları şiddetle öneririm.

Şu dönem .NET Core 2.2-Preview-1 ile gelişmeye devam eden ASP.NET Core, direkt framework içinde yerleşik olarak gelen “Dependency Injection(DI)” yaklaşımı bir çok açıdan kolaylıklar sağlıyor. Belli yapıları, geliştirilen uygulamalara enjekte etmek, uygulama fonksiyonlarının bağımlılıklarını sağlıklı yönetmek ve “seperation of concerns” prensibine sadık kalabilmek için DI oldukça gerekli. ASP.NET Core ile bunun yerleşik olarak sunulması, bağımlılıkların karmaşaya dönüşmesine uygun olan web uygulamaları için oldukça faydalı ve kolay bir özellik.

Bu kısa girişten sonra asıl konumuza gelelim; View ya da PageModel’larda(Razor Pages) bir bağlılığı nasıl kullanırız? Yani bir başka değişle *.cshtml’lerde bağımlılıkları nasıl kullanırız…

Enjekte ediyoruz…

ASP.NET Core’da Razor sayfalarda ya da View’larda @inject yöntemi ile bağımlılıkları sayfaların ön yüz tarafında kolay bir şekilde enjekte edebiliyoruz. Bu şekilde bir sayfada gösterilecek “data”’yı ASP.NET Core uygulamasına bağladğımız bir servis ile gösterebiliyoruz. Ne amaçla kullanabileceğimizden bahsetmek daha anlaşılır olmasını sağlayacak sanırım. Razor sayfası ya da View’de bir HTML “unordered list(<ul>)” elemanının içeriğini doldurma ihtiyacımız olsun ya da bir <select> elemanını… Bunun için View’e enjekte ettiğimiz bir servisi kullanarak kolaylıkla doldurabiliriz. Bunu tabi ki “Model” ya da “ViewData” ile yapmak da mümkün.Ama şöyle bir senaryonuz olduğunu düşünün; “multi-culture” bir uygulamanız var ve dil özelliklerine göre Model ya da ViewData’dan gelen veriler dil seçeneğine göre göstermeniz gerekiyor. 1 şeklinde gelen veriyi; “Yes, Ja, Si, Evet” şeklinde göstermek gibi. Bunun için dil değerlerini ViewData’ya gömmek yerine enjekte edilen farklı bir servis ile UI tarafında göstermek daha doğru olacaktır. Bu şekilde “seperation of concerns” prensibi de sağlanmış olur.

Peki bunu nasıl yapıyoruz…

Öncelikle bir servis oluşturmamız gerekiyor. Servisi burada, public olarak metotları olan bir sınıfı olarak düşünün. Public bir sınıfın, public metotları ile veri sağlayan bir yapı…

    public class VisitorService
    {
        private IServiceProvider _provider;
        private NotifyDbContext _db;
        public VisitorService(IServiceProvider provider, IConfiguration configuration)
        {
            _provider = provider;
            _db = (NotifyDbContext)_provider.GetService(typeof(NotifyDbContext));
        }
        public int GetActiveVisitorCount() => _db.Connections.Where(c => c.Connected).Count();
    }

Bu servisi, ASP.NET Core uygulamasının servislerini tanımladığımız yerde uygulamaya eklememiz gerekiyor.

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddTransient<VisitorService>();
            ....
            ..
            .
        }

ASP.NET Core’un içinde yerleşik olarak gelen DI yaklaşımının kilit noktası burası. Burada önemli olan 3 farklı ekleme yöntemi var.

  • .AddTransient<TService>(): Her request için yeni bir instance yaratırılır ve kullanılır.
  • .AddSingleton<TService>(): İlk request ile yaratılan, tek bir instance kullanılır.
  • .AddScoped<TService>(): Belli bir kapsam(web request) içinde her request de yaratılan instance kullanılır.

Servis tanımlarını bu şekilde yaparak, TService tipinde oluşturulan servis nesnesinin yaşam süresini belirtiyoruz. Bunların ayrıntılarına çok girmeyeceğim şimdi. Bu şekilde yaşam süresini belirttiğimiz servis nasıl View’larımızda kullanırız buna hızlıca bakalım.

*.cshtml sayfamızda @inject anahtarını kullanarak önce servisi sayfamız için tanımlıyoruz.

Burada @inject {Servisin sınıf adı} {Instance adı} şeklinde bir kalıp kullanmak gerekiyor.

Daha sonra *.cshtml sayfasının içinde istenilen yerde @{Instance adı}.ServisMetodu şeklinde ilgili servisin metoduna ulaşmak mümkün.

@using Microsoft.AspNetCore.Identity

@inject SignInManager<IdentityUser> SignInManager
@inject UserManager<IdentityUser> UserManager
@inject NotifyMe.Services.VisitorService VisitorService
@if (SignInManager.IsSignedIn(User))
{
    <a title="Active users count" asp-page="/Users">@VisitorService.GetActiveVisitorCount()</a>
    .....
    ..
    .
}

Bu kısa yazı ile hızlıca ASP.NET Core’da @inject ile bağımlılıkların *.cshtml tarafında nasıl yapılabileceğini görmüş olduk. Oldukça kolay ve hızlı bir şekilde belli ihtiyaçları hızlıca karşılamak bu sayede mümkün. Bunun farkındalığında olmak ve gerektiği yerde, olması gerektiği gibi kullanmak uygulamanızın kalitesini arttıracaktır; kesin bilgi, yayalım… 🙂 🙂

Güncelleme: Bu yazıyı yayınladıktan sonra Visual Studio Team Services(VSTS), Azure DevOps olarak bir isim değişikliğine uğradı. Yazıdaki bahsetmeye çalıştığım her konu hala geçerli.

Açık kaynak projelerin kod deposu olarak hayatımıza giren GitHub, yazılım teknolojilerinin olmazsa olmaz bir parçası oldu artık. Benzer şekilde Visual Studio Team Services(VSTS)’de uçtan uça bir kod geliştirme alt yapısı sunduğu ve bulut servisi olmasından dolayı da oldukça tercih edilen bir platform. Özellikle Team Foundation Server(TFS) ile bir şekilde haşır neşir olanların bir sonraki basamağı…Neyse şimdi VSTS’in ayrıntılarına girmeyelim, çıkamayız.

Bu yazıda basit bir senaryo ile GitHub’da kodlarını barındırdığımız bir projeyi, VSTS üzerindeki bir “build-relase” adımları ile Azure’da ki bir App Service’e dağıtımını yapacağız. Bir nevi Continuous Deployment(CD) sürecini basitçe bir VSTS üzerinde oluşturacağımız bir pipeline ile gerçekleştireceğiz. Anahtar kelimeleri de paylaştığıma göre başlayabilirim 🙂

Bu arada bu bahsetmiş olduğum senaryoyu bu yazıyı yazdığımdan daha kısa sürede gerçekleştirdim. Artık kullanılan sistem ve platformların etkin ve kolay olması bir çok ihtiyacta kurtarıcı oluyor. DevOps yaklaşımı anlamak, farklı sistemler ile bir uygulamayı nasıl belli platformlara dağıtabiliriz ön ayak olması için umarım faydalı olur.

Build…

Bu senaryoda GitHub’daki Notify.Me projemdeki kod repository’sini kullanacağım.(Belli bir PoC çalışması için yapılan, ASP.NET Core ile SignalR projesi) Zaten bir kod kaynağımız olduğu için ilk iş olarak VSTS’de Build adımını gerçekleştirmek. VSTS’deki menüdeki “Build and release” başlığından “Builds” menüsüne giriyoruz.

Haaaa; bu arada, bu yazıdaki ekran görüntüleri sizin VSTS hesabınızdan farklı ise, sağ üst köşedeki kullanıcınız üzerinden “Preview features”dan yeni görsel özellikleri açabilirsiniz.

“Builds” kısmında kod deposu olarak seçebileceğimiz seçenekleri göreceksiniz. Burada oldukça geniş bir kümeye sahibiz; Team Foundation Version Control(TFVC), GitHub, Bitbucket, Subversion. Yok yok… 🙂

Biz GitHub’ı seçiyoruz tabi ki. GitHub’ı seçince, GitHub hesabımız ile VSTS’i ilişkilendirmek için Login olmamız ve sonrasında gerekli izinleri vermemiz gerekiyor. Ekranların yönlendirmesi ile kolayca bunları yaptıktan sonra, GitHub’daki hangi projemizi derlemek istiyorsak onu seçiyoruz. Projemizde farklı branch’ler varsa, derleme işlemi için onu da belirtiyoruz.

Daha sonra gerek duyduğumuz derleme şablonunu seçiyoruz. Bu şablonlar derleme aşaması için genel kullanımlarda gerek duyulan adımların oluşturulduğu hazır şablonlar. Bu şablonlardan birini seçmek yerine direkt olarak boş bir şablon oluşturup, adımları kendiniz ekleyebilirsiniz.

Notify.Me bir ASP.NET Core 2.x uygulaması olduğu için, burda ASP.NET Core şablonunu seçiyorum. Daha sonra seçtiğim derleme şablonuna göre belli adımlar karşımıza çıkıyor. Bu ekranda, bu adımların ayarlarını düzenlemek yetiyor. Hangi komutların çalışacağı, hangi projelerin build olacağını gibi ayarlar…

Açıkcası burada ekranlar oldukça kolay ve güzel oluşturulmuş diye düşünüyorum. Takıldığınız bir adım olursa onun çeşitli label’ları ile adım hakkında bilgi ve hatta ayrıntılı ek bilginin linki oluyor.

Bu senaryoda seçtiğim GitHub repository’sinde hangi projeyi build edeceğimi ayarlıyorum, ayrıca Restore ve Test görevlerini de disable ediyorum. İstediğimiz adımları enable/disable edip “Build Pipeline”nında çeşitli durumları deneyebiliriz. Komple de kaldırabiliriz tabi ki. Hatta isterseniz farklı görevler(task) ekleyerek build aksiyonlarını zenginleştirebilirsiniz. VSTS’in mevcut taskları dışında, Visual Studio Marketplace’den de farklı task’ları kullanabilirsiniz. Tek tek bunlardan bahsetmeyeceğim, -ki edemem zaten,zamanımız yetmez 🙂 Ama oldukça zengin bir görev kümesi mevcut.

“Build” işleminin nasıl tetikleneceğini de derleme ayarlarındaki “Triggers” altından ayarlamak mümkün. GitHub’daki projeye her bir commit‘de build adımını tetikleyebiliyorum bu şekilde. Sadece belli branch’lere yapılan commit’leri ya da GitHub’daki “Pull Request”lere göre de tetiklemek mümkün.

Read More

İnsanoğlunun zaman ilerledikçe bazı aksiyonları almakta ve değişikliklere adapte olmakta zorlanması gibi, “yaşlanmak” dediğimiz gerçekler, yazılım uygulamaları ve çözümleri içinde geçerli. Yazılım çözümlerinin çok yaygın olduğu bir çağda yaşadığımız ve etrafımızın yazılımlar ile çevrili olmasından dolayı bu “yaşlanan” yazılım çözümleri ile daha sık karşılaşıyoruz.

Yaşlanan yazılım uygulamaları için genellikle yazılım dünyası insanları olarak “Legacy” tabirini kullanırız bildiğiniz gibi. Biraz daha net anlamı anlamak için; “Günün şartlarına uymayan uygulamalar ve çözümlere “Legacy” uygulamalar diyoruz” diyebilirim. 10 yıl önce, hatta daha da önce geliştirilen ve hala kullanılan, ama artık negatif yönlerinin ağır bastığı, belli ihtiyaçları karşılamasının zor olduğu “Legacy” uygulamalar eminim bir çok kişinin karşısına çıkıyordur.

“Legacy” uygulamalar günün şartlarına uymamaları, adaptasyon güçlükleri yaşatmalarından dolayı oldukça zorlayıcı uygulamalar olabilir. Günün şartlarına uymamaları derken, atıl kalan donanımlar, desteklenmeyen işletim sistemleri, veri saklama sistemleri, değişim ihtiyaçları, performans durumları, kullanım şekillerinin çeşitliliği vs. bir çok başlık sayabilirim ama şimdi bunlara girmiyoruz.

Windows NT’den nerelere geldik 🙂

Windows NT üzerinde çalışan, PHP 3.0 ile geliştirilmiş, WEB bileşenleri sadece Internet Explorer’da düzgün çalışan, RDBMS olarak SQL Server 7.0 kullanan bir uygulamanın günümüzde hala yoğun bir şekilde kullanıldığını düşünün…Günümüze gelene kadar alt yapı olarak geliştirmelerin ve upgrade’lerin riskleri, iş ihtiyaçlarının en önemli olduğu algısı ve en önemlisi de insan faktörü yüzünden uygulama bu zamanın şartlarına uymayan bir çözüm olarak karşımızda…

Çok uç bileşenler ile bir örnekleri oldu ama benzer senaryolar var.

Bu tarz uygulamalar ne kadar zorlayıcı da olsa, günün IT çalışanları tarafından “offf poff” şeklinde yaklaşılıp, ne kadar çok negatif şey söylense de (bu arada hepsi genelde doğrudur), unutulmaması gereken çok önemli bir nokta var; “Değer”.

“Legacy” dediğimiz uygulamalar, sistemler öyle önemli bir değer yaratmışlar ki hala günümüze denk yaşayabilmişlerdir demek ki. 10, 15, 20 yıldır ayakta olan uygulamaları düşünün; ilk kullanıldıkları dönemlerden beri insanlara ve belli iş modellerine o kadar çok değer katıyorlar ki, hala o değeri koruma mücadelesinde içindeler… Biraz daha toparlamak gerekirse “Legacy” diye adlandırdığımız uygulamalar, ne kadar çok negatif bileşenle günümüze gelse de sahip oldukları “değer” çok önemlidir… Ve bu değer uygulamaların en güçlü özelliğidir.

Bir uygulamanın “Legacy” olarak adlandırılmaması, 10 yıl sonra da günün ihtiyaçlarını kolaylıkla karşılayabilmesi, bir 10 yıl sonra kattığı değerin üstüne yeni değerleri koyabilmesi için neler yapılması lazım, nasıl geliştirilmesi lazım falan filan bunlardan şimdi bahsetmeyeceğim… Derya deniz konular çünkü…15-20 yıl önce bir uygulamayı değişime hazır bir şekilde geliştirmek, bulunduğu zamanın ihtiyaçlarına uygun geliştirmek pek mümkün değildi belki, ama günümüzdeki yaklaşımlar yazılımların ömürlerini biraz daha kaliteli kılmayı sağlıyor. Arada karalarım ama bir şeyler.

Read More

Kısa olsun… Uzun uzun yazmaya hiç gerek yok bu sefer. Geçenlerde yoğun bir “stored procedure(SP)” kullanımı olan sistemde, geliştirilen SP‘lerde hangi tabloların kullanıldığını öğrenme ihtiyacım oldu. Yoğun iş kuralları içeren, büyük sayıdaki SP’lerde nerelere dokunulmuş öğrenmek için güzel bir yaklaşım olabilir. Kenarda, köşede dursun diye hemen yazasım geldi…Buyrun kullanın, istediğiniz gibi de geliştirin benim bu Gist’i… 🙂

Microsoft’un resmi olarak paylaşmadığı ve kullanmayı tavsiye etmediği ama zaman zaman çok yardımcı olan bazı veri tabanı nesneleri; saklı yordamlar(stored procedure,SP) SQL Server bünyesinde bizlere çaktırılmadan sunuluyor. Benim zamanında çok faydalandığım bu SP’ler ile yakın zamanda tekrardan haşır neşir olma durumum oldu. Hemen kısaca paylaşacak birşeyler de çıkmış oldu böylece 🙂 Dokümante edilmeyen bu SP’ler daha çok Microsoft’un kendi iç uygulamalarında ya da kendi ihtiyaçları doğrultusunda geliştirilmiş SP’ler. SP’lerin çoğunun içeriğini göremiyoruz ve bu SP’ler herhangi bir güncelleme ya da versiyon değişikliğinde değişmiş olabilir. Microsoft’un hizmet olarak sunmadığı ve desteklemediği bu SP’leri bu bilinç ile kullanabiliyoruz. Ama üretim ortamlarında kullanılması Microsoft’un desteklemediği bir durum.

Bahsetmiş olduğum bu dokümante edilmeyen SP’ler, bir çoğumuzun sistem nesneleri diye bildiği sys. şeması altında. sp_MS% ile başlayan bu SP’ler isimlerinden kısmen yaptıklarını anlatır durumda. Tüm SQL Server seviyesinde gerçekleştirmek istediğiniz bir çok operasyonu bu SP’ler sayesinde yapabiliyorsunuz. Mesela SQL Server’daki tüm veri tabanlarında bazı değişiklikler yapmak, bir veri tabanındaki tüm tablodaki INDEX’leri tekrardan oluşturmak, veri tabanındaki tüm tabloların isimlerini değiştirmek ya da spesifik kolon eklemek gibi gibi işlemleri bu SP’ler sayesinde yapabiliyoruz.

Mesela veri tabanındaki tüm tablolara standart bir kolon eklemeniz gerekecek. Veri tabanındaki tablo sayınız 200 civarında diyelim. Örnek senaryoda 200 adet olan tablo içeren veri tabanımızdaki tüm tablolara FirstName ve LastName diye 2 kolon ekleyelim. Bu işlemi tek bir SP yardımı ile çok kolay bir şekilde yapabiliyoruz. Bu senaryo için kullanacağımız SP, sp_MSforeachtable olsun…

  EXEC sp_MSforeachtable N'ALTER TABLE ? 
                                ADD [FirstName] VARCHAR(100),
                                    [LastName] VARCHAR(100)';

Mesela tüm tablolardaki son 5 kaydı görmek istediğimizde de aşağıdaki gibi bir SP kullanabiliriz. Dikkat ederseniz SP’ye parametre olarak isteğimiz her türlü SQL sorgusunu şablon olarak verebiliyoruz. ? anahtar simgesini kullanarak SP’nin tüm tablolar için çalıştığında ? yerine tablo isminin geldiğini söyleyebilirim. Aşağıda da tüm tablolar için çalışacak bir SELECT sorgusu örneğine bakalım…

  EXEC sp_MSforeachtable N'SELECT TOP 5 * FROM ? with (nolock) ORDER BY ID desc'

Örnek olması için sadece tablo seviyesindeki  işlemleri yapabilmek için SP’yi paylaştım ancak bir çok farklı SP mevcut. Dediğim gibi bazı SP’lerin içeriğini görebiliyoruz ama bazıları açılmıyor. SP parametreleri ile SP’lerin nasıl çalıştığını deneyerek biraz debelenmek gerekiyor.

Dokümante edilmeyen bu SP’lerin varlığından haberdar olmak bazı operasyonlar için uğraşmayı kolaylaştırıyor. Fikir vermesi adına umarım faydalı olmuştur… Şimdilik bu kadar.

Not: Bu arada bu yazıyı yazarken MS SQL Server 2017‘yi macOS üzerinde Docker üstünde çalıştırdım. Ayrıca SQL Operations Studio ile SQL sorgularını çalıştırdım.

Machine Learning” nedir sorusuna verilebilecek bir çok cevap var aslında. Günümüzdeki popülerliğinden dolayı dışarı çıkıp sorsak eminim herkesin söyleyecek bir şeyi olacaktır. Yapay zeka, robotlar, otomasyon, tahmin etme gibi gibi günümüzün bir çok konseptiyle ilişkili olduğundan hepimizin bir fikri olacaktır. Ve bu söylenen şeylerin büyük bir kısmı da doğru(?) olarak nitelendirilebilir. Açıkcası profesyonel olarak uğraştığım bir konu değil; araştırma-öğrenme şeklinde takip ettiğim, belli PoC(Proof of Concept) çalışmaları yaptığım bir konu. Dolayısıyla “dışarı çıkıp sorsak” kısmında, benim de söyleyecek bazı şeylerim oluştu ve ben de kendimce paylaşmak istedim, buyrun efenim… 🙂

Peki gerçekten nedir bu “Machine Learning”?

Çok basit ve yalın olması için, “Machine Learning” ’in bilgisayar sistemlerinin bir öğrenme süreci olduğunu söyleyebilirim. Verilerin, bilgiye dönüşmesi için bilgisayar sistemlerinin gücünün kullanıldığı teknik bir süreç… Açıkcası ne olduğu sorusundan çok, nasıl olduğu sorusunun, “Machine Learning” ‘in anlaşılması ve öğrenilmesi için daha önemli olduğunu düşünüyorum. “Nasıl?” sorusunun cevabı tabi ki çok geniş ve ayrıntılı. Ben sadece giriş tadında olması için bazı fikirlerimi paylaşmaya çalışacağım.

Peki nasıl öğreniyor bu sistemler?

Verilerdeki belli kalıpların bulunması, “Machine Learning” sürecinin temeli. Verilerdeki kalıpların bulunması ve bunların üzerinde çeşitli algoritmalar çalıştırılması ile sistemler öğrenebilir hale gelmeye başlıyor. Bu süreç aslına bakarsanız iteratif yani kendini tekrarlayan bir süreç. Sistemlerin öğrenebildiğinin doğrulanması ve geçerli olduğunun kabul edilmesi gerekiyor. Bu sayede öğrenme hızı ve şeklide gelişiyor doğal olarak. Bu doğrulamayı ve kabulu de, aslında biz ya da bizim oluşturduğumuz sistematik süreçler yapıyor. Bilgisayar sistemlerinin öğrenme yaklaşımı çeşitli “tahmin etme” yaklaşımları ile somutlaşıyor. Bizim için en önemli çıktı bu şekilde oluşuyor aslında. Bu tahminlere göre, belli durumlarda da tanımlı aksiyonlar gerçekleştiriliyor. Bu sayede bir çok kolaylık insanoğlu için sağlanıyor. (Yapay zekanın temeli de bu aslında.)

Biraz daha anlaşılır olması için hepimizin geçtiği bir süreçten bir örnek verebilirim. Açıkcası okuma-yazma öğrenme süreci bütün bu “Machine Learning” konseptinin anlaşılması için güzel bir giriş noktası bence. Hepimiz okuma yazmayı; hatırlarsınız belli çizgiler çizerek harfleri öğrenerek başladık. Daha sonra harflerin bir araya geldiği kalıpları bulup, bu kalıpların tekrarlanmasını çıkartıp kelimeleri tanımlayabilir hale gelmiştik. Kelimelerin anlamlarını da çıkartıp, benzer kelimelerin anlamlarının ne olabileceğini tahmin edip, yeni kelimelerin anlamını çıkarmıştık. Bu sürecin sürekli tekrarlanması ile kelime dağarcığımız gelişmiş ve okumayı da böyle böyle çözmüştük. Çok geçmiş zaman kullandım ama temel olarak öğrenme süreci hala böyle aslında. 🙂

“Machine Learning” de direkt olarak böyle aslında. Verilerdeki kalıpları bulup, bu kalıplara anlam yüklememiz ve bu anlamları, artan verilerde yine bulup bilgisayar sistemlerinin belli tahminler yaparak veri kalıplarını öğrenme süreci ve bilgi üretme de direkt böyle oluyor.

Read More