Bir iş uygulaması geliştirilirken, ilk etapta görünür görevler odak noktası olur. Tablolar oluşturulur, ilişkiler tanımlanır, giriş formları tasarlanır ve iş süreçleri otomatikleştirilir. İlk kullanıcılar çözümü kullanmaya başladığında, projenin büyük bir kısmı tamamlanmış gibi görünür. Ancak uygulamaya geçildiğinde, uzun vadede daha zorlu bir aşama başlar. İş amaçlı kullanılan bir uygulama, bakımdan geçirilmeli, genişletilmeli ve yeni gereksinimlere uyarlanmalıdır. Değişiklikler belgelenmeli, yeni sürümler dağıtılmalı ve mevcut veriler güvenli bir şekilde aktarılmalıdır. Buna ek olarak, farklı kullanıcı hakları, veri yedeklemeleri, hata analizleri ve çözümün yerel olarak, kendi sunucusunda mı yoksa bulutta mı çalıştırılacağı sorusu da gündeme gelir.
Birçok geliştirme platformu, öncelikle asıl uygulamanın oluşturulmasına odaklanır. Güncellemeler, dokümantasyon, dağıtım ve işletim için daha sonra ek araçlar ve özel prosedürler eklenir. Zamanla, birbirinden ayrı birçok bileşenden oluşan ve ancak büyük bir çaba sarf edilerek bir arada tutulabilen bir teknik ortam ortaya çıkar. Bu nedenle SchallOS, daha kapsamlı bir yaklaşım benimsemektedir. Platform, bir iş uygulamasını yalnızca oluşturulma aşamasında değil, tüm yaşam döngüsü boyunca desteklemeyi amaçlamaktadır: geliştirmeden dokümantasyon ve devreye almaya, güncellemelerden sürekli işletime kadar.
FileMaker geçişinden kendi platformuna geçiş
SchallOS’un başlangıç noktası, mevcut FileMaker çözümlerinin taşınmasıydı. FileMaker, on yıllar boyunca özel veritabanı uygulamaları için güçlü bir ortam olduğunu kanıtlamıştır. Özellikle veri modeli, düzen ve program mantığı arasındaki sıkı bağlantı, hızlı ve uygulamaya yönelik bir geliştirme sürecini mümkün kılmaktadır.
Ancak, zamanla gelişmiş bir FileMaker çözümü, tablolar ve görünür maskelerden çok daha fazlasını içerir. Bu çözüm, hesaplamalar, komut dosyaları, kullanıcı hakları, baskı düzenleri, arayüzler ve çok sayıda özel işletme durumunu barındırır. Kullanışlı bir halef platform, bu bağlantıları devralabilmeli ve daha sonra bunları bağımsız bir şekilde sürdürebilmelidir.
Bu görevden yola çıkarak SchallOS, adım adım bağımsız bir platforma dönüştü. Mevcut FileMaker çözümlerinin SchallOS’a taşınabilmesi ve aynı zamanda yeni uygulamaların doğrudan SchallOS’ta geliştirilebilmesi amaçlanmaktadır. Tam bir geçişin ardından, FileMaker’nin üretim ortamında kullanılması artık gerekli olmayacaktır.
Geliştirme, çalışma süresi ve işletim birbirinden ayrı kalır
SchallOS geliştirme platformu, net görevleri olan çeşitli bölümlerden oluşmaktadır.
- SchallOS Stüdyosu geliştirme ortamıdır. Burada veri yapıları, düzenler, formüller, işlevler, diller ve sürümler oluşturulur. Mevcut FileMaker çözümleri için geçiş yardımcısı da Studio’nun bir parçasıdır.
- SchallOS Çalışma Zamanı Yayınlanmış uygulamaları çalıştırır. Kullanıcı arayüzünü ve gerekli program mantığını sağlar, ancak tüm geliştirme araçlarını otomatik olarak etkinleştirmez.
- SchallOS Control Dağıtım hedeflerini, veritabanı bağlantılarını, çalışma zamanı profillerini, güncellemeleri ve teknik denetimleri yönetir.
- SchallOS Cloud Uygulamaları merkezi olarak yönetilen bir çevrimiçi hizmet olarak sunar. Bu süreçte ayrı bir bulut formatı oluşturulmaz. Yerel, sunucu tabanlı ve bulut tabanlı kurulumlar aynı temel çözüm mimarisini kullanır.
Bu ayrım, geliştirme, uygulama ve yönetimin kontrolsüz bir şekilde birbirine karışmasını önler. Aynı zamanda, tüm alanlar teknik açıdan birbiriyle uyumlu kalır.
Çeşitli işletme modelleri için bir çözüm
Bir iş uygulaması küçük ölçekte başlayıp daha sonra büyüyebilir. Başlangıçta tek bir yerel iş istasyonu yeterli olabilir. Daha sonra yeni çalışanlar, merkezi bir sunucu veya birden fazla şube eklenebilir. Bu nedenle SchallOS, farklı çalışma biçimleri için aynı temel çözümü sunabilmelidir: tarayıcıda yerel olarak, Windows veya macOS uygulaması olarak, SQLite veya PostgreSQL ile ve bulutta bir SaaS çözümü olarak.
Her işletim şekli aynı teknik özelliklere sahip değildir. Yerel bir veritabanının gereksinimleri, merkezi bir çok kullanıcılı sisteminkinden farklıdır. Ancak asıl önemli olan, düzenlerin, işlevlerin ve veri modelinin her hedef için tamamen yeniden geliştirilmesine gerek olmamasıdır.
Yaşam döngüsü, mimarinin bir parçasıdır
SchallOS’ta dokümantasyon, olay günlükleri ve güncellemeler, hazır bir uygulamaya sonradan eklenmez. Bunlar temel mimarinin bir parçasıdır. Yapı ve üretim verileri ayrı olarak yönetilir. Geliştirme değişiklikleri kaydedilebilir ve sürümler halinde birleştirilebilir. Güncellemeler kontrol edilebilir, dağıtılabilir ve sorun olması durumunda kontrollü bir şekilde geri alınabilir. Entegre yapay zeka, yalnızca formüller ve işlevlerde değil, aynı zamanda dokümantasyon ve müşteri iletişimi konusunda da destek sağlar.
Böylelikle SchallOS, klasik projelerde genellikle ayrı ele alınan alanları birbirine bağlamaktadır. Bir uygulamanın geliştirilmesi artık teknik sürecin sonu değil, uzun vadeli olarak planlanmış bir yaşam döngüsünün ilk aşamasıdır.
SSC ve SSD: Taşınabilir yapı ve veri konteynerleri
Birçok veritabanı uygulaması, yapıyı, kullanıcı arayüzünü, program mantığını ve üretim verilerini birbiriyle sıkı sıkıya bağlantılı tek bir birim içinde depolar. Bu durum başlangıçta kullanışlı olsa da, ilerleyen dönemlerdeki güncellemeleri, geçişleri ve farklı çalışma biçimlerini zorlaştırır. Birden fazla müşteri, daha büyük veri havuzları veya özel genişletmeler devreye girdiğinde, uygulama dosyasının tamamını değiştirmek hızla sorunlu hale gelir.
Bu nedenle SchallOS, bir çözümün tanımını iş verilerinden temel olarak ayırır. Bir uygulama, özünde birbiriyle ilişkili iki konteynerden oluşur: yapı için SSC ve üretim verileri için SSD.
Her iki konteyner birlikte eksiksiz bir çözüm oluşturur, ancak farklı görevleri yerine getirir. SSC, uygulamanın nasıl yapılandırıldığını ve nasıl çalıştığını açıklar. SSD ise kullanım sırasında ortaya çıkan içerikleri barındırır.
SSC, uygulamayı açıklamaktadır
SSC dosyası, bir SchallOS çözümünün taşınabilir yapı konteyneridir. İçinde, diğerlerinin yanı sıra şunlar bulunur:
- Tablo ve alan tanımları
- İlişkiler
- Düzenler ve düzen nesneleri
- Formüller ve özel fonksiyonlar
- İşlevsel konteyner
- Tetikleyiciler ve Gezinme
- Dil ve çeviri bilgileri
- Belgeleme
- Sürüm ve yayın bilgileri
Dolayısıyla SSC, müşterileri, ürünleri, siparişleri veya faturaları doğrudan içermez. Hangi veri yapılarının mevcut olduğunu, bunların nasıl gösterileceğini ve bunlarla hangi işlevlerin çalıştığını belirler. Bir çözümün anlamsal içeriği de bu kapsama dahildir. Bir alan, teknik adının yanı sıra işlevsel bir açıklama, çeviriler, doğrulama kuralları ve yapay zeka katmanı için ipuçları içerebilir. Bu sayede yapı sadece makine tarafından okunabilir hale gelmekle kalmaz, aynı zamanda geliştiriciler, dokümantasyon ve geçiş süreçleri için de daha anlaşılır hale gelir.
Böylelikle SSC, belirli bir veri setinden bağımsız olarak geliştirilip yayınlanabilen taşınabilir bir uygulama modeli oluşturmaktadır.
SSD, iş verilerini içerir
SSD dosyası, çözümün veri konteyneridir. Günlük işleyişte ortaya çıkan veri kayıtlarını içerir; örneğin müşteriler, teklifler, siparişler, faturalar, stok hareketleri veya randevular. Ayrıca, bu dosyada iş alanına özgü geçmiş kayıtları ve veri olayları da depolanabilir. Bunlar arasında durum değişiklikleri, onaylar, içe aktarmalar veya özellikle önemli alanlarda yapılan değişiklikler yer alır. SSD terimi burada fiziksel bir veri taşıyıcısını değil, uygulamanın mantıksal veri katmanını ifade eder. Bu verilerin teknik olarak nasıl depolanacağı, seçilen dağıtım ve veritabanı adaptörüne bağlıdır.
Yerel tek kullanıcılı bir sistem için IndexedDB kullanılabilir. Bir masaüstü uygulaması SQLite ile çalışabilirken, daha büyük çok kullanıcılı uygulamalar PostgreSQL’i kullanır. Teknik depolama yöntemi farklı olsa da, SSD her durumda işlevsel veri konteyneri olarak kalır.
İki konteynerin birbirine ait olduğu açıkça belli olmalıdır
Yapı ve verilerin birbirinden ayrılması, herhangi bir konteynerin birbiriyle rastgele birleştirilmesine yol açmamalıdır. SchallOS, bir SSC ile bir SSD’nin gerçekten aynı çözüme ait olup olmadığını ve sürüm numaralarının birbiriyle uyumlu olup olmadığını kontrol edebilmelidir. Bunun için çözüm kimlikleri, konteyner kimlikleri, yapı sürümleri, kontrol toplamları ve imzalar kullanılabilir. Böylece, başlatma veya güncelleme öncesinde kombinasyonun geçerli olup olmadığı ve gerekli veri taşıma işlemlerinin halihazırda gerçekleştirilip gerçekleştirilmediği tespit edilebilir.
Bu kontrol, örneğin başka bir uygulamanın yapı konteynerinin yanlışlıkla üretim ortamındaki bir veri setiyle açılmasını önler. Ayrıca, SSD henüz bunun için gerekli veri yapısına hazır hale getirilmemiş olsa bile yeni bir SSC sürümünün etkinleştirilmesini de engeller.
Farklı işletme biçimleri arasında taşınabilirlik
SSC/SSD ayrımı, bir uygulamanın farklı ortamlarda çalıştırılabilmesi için gerekli temeli oluşturur. Düzenler, formüller ve işlev mantığı, her veritabanı adaptörü için yeniden geliştirilmesine gerek kalmaz.
Bir çözüm, başlangıçta yerel olarak IndexedDB ile başlatılabilir, daha sonra SQLite’a aktarılabilir ve kullanıcı sayısı arttıkça PostgreSQL’e geçilebilir. Aynı şekilde, bir bulut ortamına geçiş de mümkündür.
Böyle bir geçiş, kontrollü bir teknik işlem olarak kalır. Farklı veritabanlarının kendine özgü imkânları ve kısıtlamaları vardır. Bu nedenle veriler, bir düğmeye basılarak başka bir sisteme aktarılmaz. Aktarım, kontrol ve gerekirse geri alma işlemleri açıkça gerçekleştirilmelidir.
Ancak mimari, veri depolama yapısında bir değişiklik olması durumunda, uygulamanın tamamının yeniden geliştirilmesini otomatik olarak gerektirmeyecek şekilde tasarlanmıştır.
Müşteri verilerinin değiştirilmesine gerek kalmadan yapılan güncellemeler
Bu ayrımın en önemli avantajlarından biri, yeni sürümlerde ortaya çıkıyor. Değişiklikler genellikle mizanpajları, formülleri, işlevleri veya veri modelini etkiliyor. Bu süreçte mevcut iş verilerinin korunması gerekiyor.
Bu nedenle bir geliştirici, müşterinin SSD’si kullanım yerinde kalmaya devam ederken yeni bir SSC sürümünü yayınlayabilir. Yeni alanlar veya tablolar gerekiyorsa, bunlar tanımlanmış geçiş adımları aracılığıyla eklenir. Güncelleme öncesinde mevcut durum yedeklenebilir. Ardından yapı, veri geçişi ve işlevsellik kontrol edilir. Ancak SSC ve SSD yeniden tutarlı bir duruma geldiğinde güncelleme tamamlanmış sayılır.
Bu güncelleme özelliği yalnızca SchallOS için tasarlanmamıştır. SchallOS ile geliştirilen müşteri çözümleri için de kullanılabilir.
Müşteriye özel varyantların izlenebilirliği korunur
Müşteriye özel iş yazılımları, farklı müşterilerde genellikle farklı şekillerde gelişir. Bir müşteri kendine özgü alanlara ihtiyaç duyarken, bir diğeri ek düzenlere veya özel bir arayüze ihtiyaç duyabilir. Net bir yapı olmadan, bu durum hızla birbirinden farklı tam kopyaların ortaya çıkmasına neden olur ve bu kopyaların birlikte yönetilmesi oldukça zorlaşır. Oysa SSC’de genel ürün bileşenleri ve müşteriye özel genişletmeler, izlenebilir bir şekilde sürümlenebilir ve belgelenebilir.
Mimari, hangi uyarlamanın genel ürüne dahil edilmesi gerektiği konusunda geliştiricinin yerine karar vermez. Ancak, bir değişikliğin kaynağının ve bağımlılıklarının görünür kalmasını sağlar.
Geliştirme günlükleri ve sürümlerle birlikte, ileride yapılacak güncellemelerde hangi bileşenlerin değiştirilmesi, eklenmesi veya korunması gerektiği daha iyi anlaşılabilir.
Çok dillilik, taşınabilir yapının bir parçasıdır
Dil katmanı da SSC’ye entegre edilmiştir. Adlar yalnızca tek tek düzen nesnelerinde sabit olarak depolanmaz; bunun yerine, birden fazla dil versiyonuna sahip anlamsal girdilere başvurabilir.
Böylelikle, „Fatura Numarası“ gibi bir alan, her dil için tamamen yeni bir düzen oluşturmaya gerek kalmadan farklı dillerde görüntülenebilir. Taşınan bir FileMaker çözümü, taşıma işlemi sırasında otomatik olarak çok dilli hale getirilebilir ve çevrilebilir.
Otomatik çeviri, uzmanlık denetiminin yerini tutmaz. Özellikle hukuki ve sektöre özgü terimler mutlaka kontrol edilmelidir. Ancak sistemin mimarisi, çok dilliliğin başından itibaren çözümün bir parçası olmasını sağlar ve daha sonra her bir maskeye zahmetli bir şekilde eklenmesi gerekmez.
Uzun vadeli bakımın temeli
SSC ve SSD, ilk bakışta uygulama ve verilerin basit bir ayrımı gibi görünür. Oysa aslında taşınabilirlik, güncellemeler, farklı veritabanı adaptörleri, ayrı yedeklemeler ve çeşitli işletim modellerinin temelini oluştururlar.
SSC, bir çözümün ne olduğunu ve nasıl işlediğini açıklar. SSD ise, çözümün kullanımı sırasında ortaya çıkan ve ilgili şirket için kalıcı olarak saklanması gereken unsurları içerir.
Bu net ayrım sayesinde, uygulama her yeni sürümde tüm veri tabanının değiştirilmesine gerek kalmadan geliştirilmeye devam edebilir. Aynı zamanda, teknik veri yönetimi büyüyebilir veya değişebilir; bunun için mizanpajların ve iş mantığının tamamen yeniden oluşturulması gerekmez.
SchallOS Studio: Entegre geliştirme ortamı
SchallOS Studio, platformun yeni iş uygulamalarının geliştirildiği ve mevcut FileMaker çözümlerinin taşındığı veya daha da geliştirildiği bölümüdür. Burada tablolar, alanlar, ilişkiler, düzenler, formüller, işlevler, diller ve sürümler ortak bir ortamda yönetilir.
FileMaker geliştiricileri için temel çalışma şekli tanıdık gelmelidir. Değişiklikler yalnızca soyut kaynak kodu dosyalarında yapılmaz; uygulamanın görünür bileşenleriyle bağlantılı kalır. Bir geliştirici, bir düzeni düzenleyebilir, bir alanı seçip özelliklerini değiştirebilir ve bu değişikliğin uygulamaya nasıl yansıdığını anında kontrol edebilir.
Buna rağmen SchallOS, FileMaker’yi tamamen kopyalamaya çalışmıyor. Özellikle kendini kanıtlamış temel fikirler benimsenmektedir: hızlı geliştirme, anında geri bildirim ve veri modeli, kullanıcı arayüzü ile iş mantığı arasında sıkı bir bağlantı. Buna karşılık, teknik altyapı yeniden düzenlenerek taşınabilir yapılar, yapay zeka destekli programlama, dokümantasyon ve kontrollü sürümler üzerine odaklanmaktadır.
Düzenler, nesneler ve özellikler
SchallOS Studio’nun önemli bir bileşeni, Düzen modudur. Bu modda, bir çözümün giriş formları, listeler, diyalog pencereleri, gezinme alanları ve diğer kullanıcı arayüzleri oluşturulur.
Olası mizanpaj nesneleri arasında alanlar, metinler, düğmeler, liste nesneleri, sekme alanları, açılır pencereler, kapsayıcılar ve gezinme öğeleri yer alır. Nesneler seçilebilir, konumlandırılabilir ve bir denetleyici aracılığıyla yapılandırılabilir.
Bir düzen nesnesi, yalnızca boyut, konum ve görünüm bilgilerini içermez. Ayrıca veri kaynakları, tetikleyiciler, formüller, işlevler ve anlamsal etiketlerle de bağlantılı olabilir. Örneğin, bir alan nesnesi veri modelindeki bir alana işaret eder, dile bağlı bir etiket alabilir ve alana girildiğinde veya çıkıldığında belirli işlevleri tetikleyebilir.
Her nesne SSC'nin bir parçası olduğu için, düzen değişiklikleri sürümlenebilir, belgelenebilir ve daha sonra bir güncelleme yoluyla hedefli bir şekilde dağıtılabilir. Böylece kullanıcı arayüzü, izole bir grafik katmanı olarak kalmaz, aksine tüm uygulamanın yapılandırılmış bir parçası olur.
Veri modeli ve anlamsal açıklamalar
Tablolar, alanlar ve ilişkiler de SchallOS Studio'da oluşturulur ve düzenlenir. Yeni uygulamalar burada baştan sona oluşturulabilir. FileMaker geçişinde, geçiş asistanı mevcut yapıları mümkün olduğunca devralır ve daha sonra bunların üzerinde çalışılabilmesi için hazır hale getirir.
SchallOS’ta bir alan, yalnızca teknik bir ad ve veri türünden ibaret değildir. Ayrıca, işlevsel bir açıklama, doğrulama kuralları, varsayılan değerler, çeviriler ve belgeleme notları da içerebilir.
Bu bilgiler çeşitli amaçlara hizmet eder. Diğer geliştiricilerin çözümü anlamasını kolaylaştırır, otomatik dokümantasyonu destekler ve entegre yapay zekaya daha iyi bir bağlam sağlar. Platform, örneğin bir alanın adının „Durum“ olduğunu tespit etmekle kalmaz, bunun bir sipariş durumu, ödeme durumu mu yoksa dahili işleme durumu mu olduğunu da anlayabilir.
Tablolar arasındaki ilişkiler de tanımlanabilir ve işlevsel bağlamları içinde belgelenebilir. Böylelikle, bilginin daha azı sadece orijinal geliştiricinin zihninde gizli kalır.
Gerçek zamanlı hesaplamalı formüller
SchallOS’un kendine özgü bir formül ortamı vardır. Formüller formül düzenleyicisinde oluşturulur ve düzenleme sırasında gerçek zamanlı olarak hesaplanır. Böylece, bir ifadede yapılan değişiklikler uygun test değerleri veya mevcut veri kümesiyle anında kontrol edilebilir.
Formül dili, iş uygulamalarında ihtiyaç duyulan tipik hesaplamaları destekler. Bunlar arasında matematiksel işlemler, metin işleme, tarih ve saat hesaplamaları, mantıksal koşullar, alan referansları, değişkenler ve iç içe geçmiş ifadeler yer alır.
Mevcut komut yelpazesi, ilk etapta on yıllar boyunca gelişen FileMaker işlev setinden daha sınırlıdır. SchallOS’un, FileMaker’nin geçmişteki her komutunu aynen kopyalaması gerekmez. Daha önemli olan, açık bir şekilde yapılandırılmış ve genişletilebilir bir formül ortamıdır.
Belirli çözümler veya geçişler için gerekli olması durumunda, daha sonra ek komutlar eklenebilir. Bu süreçte, entegre yapay zeka da mevcut bir hesaplamayı aktarmaya veya eksik bir işlevi SchallOS mimarisine uygun şekilde geliştirmeye yardımcı olabilir.
Yeniden kullanılabilir hesaplamalar için özel işlevler
Entegre komutların yanı sıra, SchallOS Özel İşlevleri de destekler. Bu işlevler parametreleri alır, tanımlanmış bir hesaplamayı gerçekleştirir ve bir sonuç döndürür. Böylelikle, tekrarlanan kurallar merkezi bir noktadan yönetilebilir. Buna örnek olarak fiyat hesaplamaları, süre belirlemeleri, biçimlendirmeler, numara aralıklarının kontrolü veya içe aktarılan değerlerin işlenmesi verilebilir.
Özel işlevler de gerçek zamanlı olarak hesaplanır ve formül düzenleyicisinde anında test edilebilir. Bir işlev daha sonra düzeltilir veya genişletilirse, bu işlevi kullanan tüm formüller bundan yararlanır.
Ayrıca, kendi fonksiyonlarınız tanımlanabilir ve belgelenebilir. Böylelikle parametreler, dönüş değeri, örnekler ve bilinen hata durumları anlaşılır bir şekilde takip edilebilir. Bir çözümün fonksiyon koleksiyonu, sayısız kopyalanmış tekil hesaplamalardan oluşmak yerine, yeniden kullanılabilir bir kütüphaneye dönüşür.
Daha karmaşık süreçler için işlevsel konteynerler
SchallOS’ta daha kapsamlı iş süreçleri işlev konteynerleri aracılığıyla düzenlenir. Örneğin, veri kayıtları oluşturabilir, değerleri kontrol edebilir, diyalogları yönetebilir, belgeler oluşturabilir veya harici arayüzlere erişebilirsiniz. Bir işlev konteyneri yalnızca çalıştırılabilir kodu içermez. Buna ek olarak, işlevsel bir açıklama, giriş parametreleri, dönüş değerleri, bağımlılıklar, izin verilen yetenekler ve açıkça hariç tutulan işlemler de dahildir.
Birden fazla düzen nesnesi aynı işlev kapsayıcısını kullanabilir. Böylelikle, fatura oluşturma işlevi her düğme veya düzen için yeniden oluşturulmasına gerek kalmaz.
Taşınan çözümlerde, mevcut FileMaker komut dosyaları arka planda bir öğrenme ve referans katmanı olarak korunabilir. Bunlar, orijinal amacın ve mevcut iş akışının anlaşılmasına yardımcı olur. Ancak yeni çalıştırılabilir kod, SchallOS mimarisine uygun olarak oluşturulur.
Aynı ortamda geçiş ve yeni geliştirme
SchallOS Studio, yalnızca mevcut FileMaker çözümleri için bir hedef değildir. Yeni uygulamalar tamamen bu platform içinde geliştirilebilir.
Bir geçiş işlemi sırasında, sihirbaz öncelikle mevcut tabloları, alanları, ilişkileri, düzenleri ve diğer tanınabilir bileşenleri devralır. Ardından, geliştiriciler içe aktarılan yapıyı kontrol edebilir, temizleyebilir ve adım adım yeni işlev mimarisine aktarabilirler.
Bunun amacı, önceki tüm özelliklerin aynen kopyalanmasını sağlamak değildir. Tarihsel süreçte gelişen dolambaçlı yollar gözden geçirilebilir ve daha net yapılarla değiştirilebilir. Aynı zamanda, mevcut çözümün teknik bilgisi de korunur.
Yeni ve taşınan uygulamalar daha sonra aynı araçları, konteynerleri ve yayınlama yöntemlerini kullanır.
Değişiklikler, kontrollü sürümler haline gelir
Stüdyoda yapılan bir değişiklik, otomatik olarak üretken bir güncellemeye dönüşmez. Geliştirme aşamasında, tamamlanmamış düzenler, geçici formüller veya henüz test edilmemiş işlevler bulunabilir.
Bu nedenle, birbiriyle ilişkili değişiklikler Değişiklik Oturumları’nda kaydedilebilir ve daha sonra bir sürüme atanabilir. Ancak inceleme ve onay sürecinden sonra bu değişiklikler, yayınlanmış bir SSC sürümü haline gelir.
Bir sürüm, yeni yapının yanı sıra gerekli veri taşıma işlemleri, sürüm bilgileri, bağımlılıklar, kontrol adımları ve belgeleri de içerebilir. Bu sayede, asıl geliştirme süreci, üretim ortamındaki çalışma zamanı örneklerine yapılan dağıtımdan net bir şekilde ayrılmış olur.
Böylece SchallOS Studio, yalnızca bir uygulamanın tasarlandığı ve programlandığı bir ortam olmakla kalmaz. Görsel geliştirme, veri modeli, formüller, işlevler, dokümantasyon ve yayınlama süreçlerini tek bir ortamda bir araya getirir.
Geliştirici ile görünür uygulama arasındaki tanıdık yakınlık korunur. Aynı zamanda, çözümlerin taşınabilir, izlenebilir ve uzun vadede bakımının yapılabileceği bir teknik temel oluşturulur.
Formüllerin ve fonksiyonların ortaya çıktığı yerde yapay zeka
Yapay zeka, birçok geliştirme ortamında şu ana kadar özellikle ek bir sohbet penceresi aracılığıyla sunulmaktadır. Geliştirici bir sorunu açıklar, kaynak kodunu veya formülleri sohbete kopyalar ve ardından sonucu tekrar projeye aktarır. Bu süreçte dil modelinde genellikle tablolar, alanlar, ilişkiler ve uygulamanın işlevsel anlamı hakkında önemli bilgiler eksik kalır.
Bu nedenle SchallOS, yapay zekayı geliştirme araçlarına doğrudan entegre eder. Yapay zeka, formüllerin, özel işlevlerin ve işlev kapsayıcılarının düzenlendiği yerlerde kullanıma hazırdır. Böylelikle yapay zeka, yalnızca tek bir soruyu değil, çözümün o anki bağlamını da kavrar.
Formül düzenleyicide yapay zeka, örneğin düzenlenmiş ifadeyi, kullanılabilir alanları ve beklenen sonuç türünü bilir. Bir işlev kapsayıcısı içinde ise buna ek olarak, söz konusu kapsayıcının açıklamasına, parametrelerine, yeteneklerine ve bağımlılıklarına da erişebilir.
Böylece yapay zeka, ayrı bir yardımcı program haline gelmez, aksine asıl geliştirme ortamının bir parçası olur.
Formül düzenleyicisinde destek
Formüller, bir iş uygulamasındaki pek çok işlemi yönetir. Fiyatları hesaplar, koşulları kontrol eder, süreleri belirler veya mizanpaj nesnelerinin görünümünü etkiler. Entegre yapay zeka, formül düzenleyicisinde aşağıdakiler dahil olmak üzere çeşitli işlemler gerçekleştirebilir:
- mevcut bir formülü açıklamak
- olası hataları incelemek
- Koşulları tamamla
- bir ifadeyi basitleştirmek
- bir FileMaker formülünü aktarmak
- ya da teknik bir açıklamadan yola çıkarak yeni bir hesaplama oluşturmak.
Örneğin, bir geliştirici, çerçeve sözleşmesi bulunmadığı takdirde belirli bir net değerin üzerindeki siparişlerin ek bir onay gerektirdiğini belirtebilir. Yapay zeka, çözümde mevcut alanlardan yararlanarak bundan bir formül oluşturabilir. Sonuç, normal bir formül olarak görünür durumda kalır. Bu formül okunabilir, değiştirilebilir ve gerçek zamanlı olarak hesaplanabilir. Böylece yapay zeka, davranışını anlamak zor olan gizli bir süreç oluşturmaz.
Gerekli bir komut eksikse, yapay zeka bu durumda da uygun bir özel işlev veya formül ortamı uzantısı oluşturulmasına yardımcı olabilir. Böylelikle, başlangıçta daha sınırlı olan SchallOS’un komut yelpazesi genişletilebilir hale gelir.
İş gereksinimlerine dayalı özel fonksiyonlar
Tekrarlanan hesaplamalar, Özel İşlevler olarak merkezi bir şekilde yönetilebilir. Yapay zeka, bir açıklamadan yola çıkarak benzersiz parametrelere, dönüş değerine ve belgelenmiş davranışa sahip bir işlev oluşturabilir.
Böyle bir işlev, örneğin indirim sürelerini hesaplayabilir, numara aralıklarını kontrol edebilir veya içe aktarılan değerleri tek tip hale getirebilir. Asıl çıktının yanı sıra test değerleri, örnekler ve olası hata durumları da oluşturulabilir.
Bu sadece ilk programlamayı kolaylaştırmakla kalmaz. Daha sonraki bir değişiklik durumunda, yapay zeka fonksiyonun ne anlama geldiğini ve hangi noktalarda kullanıldığını anlayabilir.
Böylece, anonim bir hesaplama, çözümün belgelenmiş ve yeniden kullanılabilir bir bileşeni haline gelir.
Açıklanan program mantığı olarak işlev konteyneri
SchallOS'ta daha karmaşık işlemler işlev konteynerleri aracılığıyla düzenlenir. Bir işlev konteyneri, örneğin veri kayıtları oluşturabilir, girdileri doğrulayabilir, diyalog pencerelerini yönetebilir, belgeler oluşturabilir veya harici arayüzleri çağırabilir. Bunun temelini yapılandırılmış bir açıklama oluşturur. Bu açıklama şunları belirleyebilir:
- fonksiyonun hangi görevi yerine getirdiğini
- hangi parametrelerin aktarıldığı
- hangi sonucun beklendiği
- hangi tablolara ve alanlara erişim izni verilir
- başka hangi işlevlerin kullanıldığı
- ve hangi işlemlerin açıkça hariç tutulduğu.
Bu yönergeler temelinde, yapay zeka işlev konteynerinin çalıştırılabilir kodunu programlar. Böylelikle geliştirici, iş akışını artık yalnızca çok sayıda tek tek komut dosyası adımından oluşturmak zorunda kalmaz. Görevi, daha çok istenen işlevin, sınırlarının ve ardından yapılacak kontrolün kesin bir şekilde tanımlanmasına kayar.
Bununla birlikte, üretilen kod görünür durumda kalır. Bu kod okunabilir, test edilebilir, düzenlenebilir ve farklı sürümler arasında karşılaştırılabilir. Eski sürümler de saklanabilir ve gerektiğinde geri yüklenebilir. Böylece yapay zeka, programlamayı üstlenir, ancak teknik sorumluluğu üstlenmez.
FileMaker komut dosyaları öğrenme katmanı olarak
Taşınan FileMaker çözümlerinde, mevcut komut dosyaları genellikle yıllar boyunca gelişen iş mantığının büyük bir kısmını içerir. Bu komut dosyaları, hangi alanların değiştirildiğini, hangi koşulların kontrol edildiğini ve hangi diğer işlemlerin çağrıldığını gösterir.
Bu komut dosyaları, SchallOS’ta kalıcı olarak çalıştırılabilir bir çalışma zamanı katmanı olarak devralınmaz. Aksi takdirde, önceki birçok teknik bağımlılık ve dolambaçlı yol sadece yeni sisteme aktarılmış olurdu. Bunun yerine, orijinal FileMaker komut dosyası ilgili işlev konteynerinin arka planında korunabilir. Bu komut dosyası, yapay zeka için öğrenme, referans ve kavrama katmanı işlevi görür.
Yapay zeka, buradan mevcut iş akışının işlevsel amacını çıkarabilir. Ardından, SchallOS mimarisine uygun şekilde yeni kodu programlar. Sık layout değişiklikleri, global alanlar veya bağlama bağlı yardımcı komut dosyaları gibi eski tasarımların bu süreçte aynen devralınması gerekmez. Bunlar, yalnızca asıl iş süreci için gerçekten gerekli oldukları takdirde devam ettirilir.
Bununla birlikte, orijinal komut dosyası bir bilgi kaynağı olarak korunur. Daha sonraki sorgulamalarda, FileMaker çözümünde bir işlemin başlangıçta nasıl çözüldüğü anlaşılabilir.
Yetenekler ve sınırlar açıkça tanımlanmaktadır
Bir işlev konteyneri, yalnızca genel bir açıklamaya dayalı olarak uygulamanın herhangi bir bölümüne erişebilmemelidir. Bu nedenle, izin verilen yetkiler ve istisnalar açıkça belirlenebilir.
Örneğin, bir işlev belirli bir tablodaki kayıtları okuyup değiştirebilir, ancak aynı anda silme işlemleri gerçekleştiremez veya sistem yapılandırmalarında değişiklik yapamaz. Oluşturulan kod, izin verilmeyen bir yeteneği kullanıyorsa, SchallOS bunu algılayabilir ve kodun yürütülmesini veya yayınlanmasını engelleyebilir.
Bir işlev konteynerinin açıklaması bu nedenle sadece belgeleme amacıyla kullanılmaz. Bu açıklama, test ve güvenlik modelinin bir parçası haline gelir. Özellikle yapay zeka tarafından üretilen kodlarda bu sınırlama önemlidir. Dil modeline net bir hareket alanı tanınırken, platform ise üretilen işlevin bu çerçeve içinde kalıp kalmadığını denetler.
Doğru bağlam, sonuçları iyileştirir
AI tarafından üretilen bir fonksiyonun kalitesi, yalnızca kullanılan dil modelinin büyüklüğüne bağlı değildir. Asıl belirleyici olan, modelin gerekli bilgileri alıp almadığıdır. SchallOS, bağlamı çeşitli düzeylerden bir araya getirebilir:
- güncel soru
- açık düzenleyicide
- seçilen alana veya işlev kapsayıcısına
- ilgili tablolar ve ilişkiler
- mevcut formüller ve fonksiyonlar
- anlamsal açıklamalar
- Belgeler ve Değişiklik Geçmişi
- ayrıca geçiş işlemlerinde orijinal FileMaker komut dosyasına.
Bu sayede yapay zeka, genel bir sohbet ortamında tek başına yapılan bir sorguya kıyasla çok daha doğru sonuçlar verebilir.
Aynı zamanda, her görev için çözümün tamamının sunulması gerekmez. Bağlam, söz konusu işlev için gerçekten gerekli olan bilgilerle sınırlandırılabilir.
Kalıcı bağ yerine değiştirilebilir modeller
AI katmanı, tek bir modele veya sağlayıcıya kalıcı olarak bağımlı olmamalıdır. Farklı görevler, kalite, hız, maliyet ve veri koruma açısından farklı gereksinimler ortaya çıkarır.
Karmaşık bir geçiş süreci, özellikle yüksek performanslı bir model gerektirebilir. Basit bir açıklama veya formül uyarlaması ise daha küçük bir modelle gerçekleştirilebilir. Hassas veya kapalı ortamlar için uzun vadede yerel olarak çalıştırılan modeller de kullanılabilir.
Bu nedenle kalıcı bilgi tabanı dil modelinde değil, SchallOS çözümünde yer alır: açıklamalarda, yapılarda, komut dosyası referanslarında, kodda, testlerde ve belgelerde. Yapay zeka modeli ise bu bağlamdan çalıştırılabilir kod veya anlaşılır öneriler üreten, değiştirilebilir bir araç olarak kalır.
Anlaşılır, yapay zeka destekli geliştirme
SchallOS, iş uygulamaları üzerinde doğrudan çalışmayı yapay zeka destekli programlama ile birleştirir. Formüller doğrudan açıklanabilir ve oluşturulabilir. Özel işlevler, yeniden kullanılabilir iş alanına özgü şartnamelerden ortaya çıkar. İşlev konteynerleri, anlamsal açıklamaları görünür ve doğrulanabilir kodla birleştirir.
Taşınan çözümlerde, FileMaker komut dosyaları ek bir öğrenme katmanı olarak korunur. Bu komut dosyaları, önceki teknik bağımlılıkları kalıcı olarak sürdürmeden mevcut iş süreçlerini anlamaya yardımcı olur.
Bu durum, geliştiricinin rolünün ortadan kalkacağı anlamına gelmez. Rolü değişir. Kesin gereksinimler, mantıklı bir mimari, testler ve teknik denetim, her bir program adımının manuel olarak girilmesinden daha önemli hale gelir. Özellikle iş açısından kritik yazılımlar söz konusu olduğunda, bu sorumluluk vazgeçilmez olmaya devam eder.
Yerel yapay zeka sistemlerinin kullanımına ilişkin güncel anket
Uygulamanın bir parçası olarak dokümantasyon ve olay günlükleri
Bir iş uygulamasının dokümantasyonu genellikle geliştirme süreci tamamlandıktan sonra yazılır. Zaman baskısı altında, çalışmalar ilk etapta yeni alanlara, düzenlere, formüllere ve işlevlere odaklanır. Değişikliklerin açıklaması ise daha sonra eklenecektir.
Ancak zaman geçtikçe, başlangıçtaki kararları anlamak zorlaşır. Çoğu zaman, belirli bir işlevin neden eklendiği, hangi nesnelerin etkilendiği ve hangi özel durumların dikkate alınması gerektiği artık tam olarak bilinmez. Bu nedenle SchallOS, dokümantasyonu sonradan eklenmiş bir ek görev olarak görmez. İlgili değişiklikler, geliştirme aşamasında olaylar olarak kaydedilir ve çözümün ilgili bileşenleriyle ilişkilendirilir.
Bu bilgilerden daha sonra teknik belgeler, sürüm notları, müşteri raporları veya performans kayıtları oluşturulabilir. Böylece belgeler, yalnızca hatıralara veya elle tutulan notlara değil, fiilen yapılan değişikliklere dayanır.
Birden fazla düzeyde yaşanan olaylar
Bir SchallOS çözümü, yalnızca tek bir genel protokole sahip değildir. Platform, kendine özgü görevleri olan farklı olay düzeylerini birbirinden ayırır.
- Bu Yapı Protokolü SSC’deki değişiklikleri kaydeder. Bunlar arasında örneğin yeni tablolar ve alanlar, uyarlanmış düzenler, değiştirilmiş formüller veya yeni işlev kapsayıcıları yer alır.
- Bu Veri Olay Günlüğü SSD’ye aittir. Burada, aktif kullanım sırasında mesleki açıdan önemli işlemler kaydedilir; örneğin durum değişiklikleri, onaylar, iptaller veya önemli veri kayıtlarındaki değişiklikler.
- Buna ek olarak İşletme olayları Runtime ve SchallOS Control'den. Bunlar arasında dağıtımlar, güncellemeler, denetimler, yedeklemeler ve geri alma işlemleri yer almaktadır.
Bu alanlar ayrı kalır, ancak birbirleriyle ilişkilendirilebilir. Bir geliştirme günlüğü, müşteri kayıtlarında yapılan günlük değişiklikler nedeniyle karmaşık hale gelmemelidir. Buna karşılık, dahili teknik ayrıntılar, bir faturanın veya siparişin işsel geçmişine otomatik olarak dahil edilmemelidir.
Yapı protokolü, çözümün gelişimini göstermektedir
Tablolarda, alanlarda, düzenlerde, formüllerde ve işlev kapsayıcılarında yapılan değişiklikler, yapılandırılmış olaylar olarak kaydedilebilir. Bir kayıt, hangi nesnenin değiştirildiğini, önceki durumun ne olduğunu ve yeni durumun ne olduğunu belirtebilir. Ayrıca geliştirici, tarih, teknik gerekçe, ilgili iş emri ve planlanan sürüm bilgisi de kaydedilebilir.
Örneğin, siparişler için yeni bir onay süreci eklenirse, bu durum muhtemelen birkaç teknik değişikliğe yol açabilir. Bir durum alanı oluşturulur, bir düzen genişletilir, bir formül uyarlanır ve yeni bir işlev konteyneri programlanır.
Yapı protokolü bu tekil olayları kaydeder. Aynı zamanda, bunlar ortak bir teknik görev altında birleştirilebilir. Böylelikle, birden fazla teknik değişikliğin bir araya gelerek yeni bir iş sürecini oluşturduğu açıkça görülür.
Değişiklik Oturumları, birbiriyle ilişkili çalışmaları bir araya getirir
Bir geliştirme görevi genellikle birçok küçük adımdan oluşur. Tek tek değişikliklerin sadece kronolojik bir listesi, asıl bağlamı yeterince yansıtmaz.
Bu nedenle SchallOS, birbiriyle ilişkili çalışmaları “Değişim Oturumları” altında bir araya getirebilir. Bir “Değişim Oturumu”, somut bir görevi, genişletmeyi veya hata düzeltmesini tanımlar ve bunlarla ilgili tüm olayları toplar. Örneğin şunları içerebilir:
- mesleki görev tanımı
- İlgili tablolar ve düzenler
- değiştirilen formüller ve işlevler
- gerçekleştirilen testler
- çözülmemiş konular
- ve bir müşteriye veya siparişe atanması.
Birden fazla Değişiklik Oturumu daha sonra bir sürüme atanabilir. Bu sayede, geliştirme görevi, teknik değişiklikler ve yayınlanan sürüm arasında izlenebilir bir bağlantı kurulur.
Yapay zeka, teknik olayları anlaşılır bir şekilde sunuyor
Dokümantasyon katmanı, SchallOS’un entegre yapay zekasına bağlıdır. Bu sayede, kaydedilen olaylar farklı hedef gruplar için otomatik olarak düzenlenebilir.
Teknik bir geliştirici raporu, bir müşteri bildirisinden farklı bilgilere ihtiyaç duyar. Geliştirici somut alan adlarını, işlev kapsayıcılarını ve veri taşıma işlemlerini görmek isterken, müşterinin ilgilendiği başlıca husus, hangi işlevin eklendiği ve bunun ne gibi faydalar sağladığıdır. Bu nedenle yapay zeka, aynı olayları farklı biçimlerde özetleyebilir:
- şirket içi teknik dokümantasyon olarak
- anlaşılır bir müşteri bilgisi olarak
- Sürüm Notları olarak
- proje raporu olarak
- ya da bir fatura için ödeme belgesi olarak.
Metinler, genel bir açıklamadan serbestçe oluşturulmaz. Bunlar, Değişiklik Oturumları’ndan, anlamsal nesne açıklamalarından ve fiili yapı değişikliklerinden türetilir.
Oluşturulan metin, kaynaklarıyla bağlantılı kalır. Geliştirici, bir ifadenin hangi olaylara dayandığını kontrol edebilir ve metni kullanmadan önce düzeltebilir veya onaylayabilir.
Geliştiriciler ve müşteriler için performans raporları
Özel yazılım geliştiricileri için dokümantasyon, ekonomik açıdan da önemlidir. Hizmetler müşteriye anlaşılır bir şekilde açıklanmalı ve genellikle süre veya iş paketi bazında faturalandırılmalıdır.
Uygulamada, bu tür hizmet kayıtları genellikle fatura kesilmeden hemen önce düzenlenir. Bunun için e-postalar, notlar ve hatırlatıcılar taranmalıdır.
SchallOS, fiilen kaydedilen geliştirme olaylarını bir müşteriye, projeye veya siparişe atayabilir. Yapay zeka, bunlardan bir hizmet raporu için uygun girişler oluşturur. Örneğin, birden fazla teknik değişiklik anlaşılır bir hizmet olarak özetlenebilir:
Sipariş yönetimine, durum kontrolü, kullanıcı hakları ve giriş formunun özelleştirilmesini içeren iki aşamalı bir onay süreci eklenmesi.
Temelindeki teknik işlemler hâlâ görülebilir durumdadır. Müşteri açıklaması yalnızca anlaşılır bir özet niteliğindedir. Nihai seçim geliştiriciye aittir. Her teknik olay otomatik olarak faturalandırılabilir değildir ve şirket içi denemeler veya düzeltmelerin faturada tek tek belirtilmesi gerekmez.
Veri düzeyindeki olaylar
Üretim ortamında da öngörülen tüm veri olayları günlüğe kaydedilebilir. Bunlar arasında veri kayıtlarının oluşturulması ve değiştirilmesi, durum değişiklikleri, onaylar, içe aktarmalar, dışa aktarmalar veya otomatik olarak yürütülen süreçler yer alır. Bir kayıt şunları içerebilir:
- Hangi kullanıcı veya işlem bu eylemi tetiklemiştir?
- hangi veri kaydı etkilendi
- hangi değerler değiştirildi
- hangi işlevin yürütüldüğü
- ve işlemin başarıyla tamamlanıp tamamlanmadığını.
Kullanılan çözüm, hangi olayların ne kadar ayrıntılı olarak kaydedileceğini belirler. Küçük bir metin düzeltmesi, halihazırda onaylanmış bir faturada yapılan değişiklikle aynı öneme sahip değildir. Veri olay günlüğü, bu sayede SSD’nin iş geçmişini oluşturur. Destek hizmetlerini, hata analizini ve önemli iş süreçlerinin izlenebilirliğini destekler.
Bu tür bir protokol, denetim gereklilikleri için de bir temel oluşturabilir. Ancak bununla tüm yasal veya sektöre özgü gerekliliklerin karşılanıp karşılanmadığı, her bir uygulama durumu için ayrı ayrı incelenmelidir.
Belgeler, sürümler ve güncellemeleri de kapsar
Kaydedilen geliştirme olayları aynı zamanda sürüm ve güncelleme sürecine de dahil edilir. Yeni bir sürüm yayınlandığında, SchallOS hangi işlevlerin eklendiğini, hangi hataların giderildiğini ve hangi veri yapılarının değiştirildiğini otomatik olarak derleyebilir. Bu sayede teknik değişiklik listeleri, kullanıcı notları ve geçiş bilgileri oluşturulur.
Kurulumdan sonra, belirli bir çalışma zamanı örneğine hangi sürümün yüklendiği ve bu sürümde hangi değişikliklerin yer aldığı net bir şekilde takip edilebilir.
Yedeklemeler, testler veya olası bir geri alma işlemi gibi operasyonel olaylar da belgelenir. Böylelikle daha sonra sadece neyin geliştirildiği değil, aynı zamanda bir değişikliğin ne zaman ve hangi sonuçla üretim ortamına devreye alındığı da tespit edilebilir.
Giderek genişleyen bir bilgi tabanı
Olay günlüğü, anlamsal açıklamalar ve yapay zeka desteğinin bir araya gelmesi, uzun vadede çözümün tamamına ilişkin bir bilgi tabanı oluşturur. Daha sonra bir değişiklik yapıldığında, sadece mevcut kod incelenmez. Bir işlevin ne zaman devreye alındığı, bunun ardındaki iş gerekçesi ve o dönemde hangi diğer alanların etkilendiği de net bir şekilde görülebilir.
Özellikle uzun yıllar boyunca gelişen iş uygulamalarında bu bilgi hayati önem taşır. Görünüşte gereksiz gibi görünen bir özel durumun önemli bir tarihsel nedeni olabilir. Dokümantasyon olmazsa, daha sonraki bir revizyon sırasında bu durumun yanlışlıkla kaldırılma riski vardır. Bu nedenle SchallOS, sadece teknik durumları değil, aynı zamanda geliştirme geçmişini ve bununla ilgili kararları da korur.
Böylece dokümantasyon, uygulamanın aktif bir parçası haline gelir. Sistemde gerçekten gerçekleşen olaylara dayalı olarak geliştirme, müşteri iletişimi, faturalandırma, destek, sürüm yayınları ve uzun vadeli bakım süreçlerini destekler.
Platform ve uygulamalar için sistem genelinde bir güncelleme süreci
İşletme yazılımları nadiren uzun süre değişmeden kalır. Yeni gereksinimler, yasal değişiklikler, hata düzeltmeleri ve teknik gelişmeler düzenli olarak yeni sürümlerin ortaya çıkmasına neden olur. Bu süreçte, yalnızca dosyaları değiştirmek yeterli değildir. Her güncellemeden önce, hangi sürümün geçerli olduğu, veri yapılarının uyarlanması gerekip gerekmediği ve bir hata durumunda önceki durumun nasıl geri yüklenebileceği kontrol edilmelidir.
Birçok özel uygulamada bu tür süreçler ancak sonradan ortaya çıkar. Güncellemeler daha sonra manuel talimatlar, yedek kopyalar ve müşteriye özel komut dosyaları aracılığıyla dağıtılır. Her yeni kurulumla birlikte, farklı sürümlerin ve özel çözümlerin ortaya çıkma riski artar.
Bu nedenle SchallOS, güncellemeleri sistem genelinde bir platform işlevi olarak ele alır. Hem SchallOS’un kendisi hem de platform üzerinden geliştirilen müşteri çözümleri, aynı temel iş akışı üzerinden güncellenir.
Bir geliştirici, yeni bir uygulama için öncelikle kendi güncelleme sürecini tasarlamak zorunda kalmaz. Sürümleme, denetim, dağıtım ve günlük kaydı, başından itibaren ortak mimarinin bir parçasıdır.
SSC ve SSD’nin birbirinden ayrılması, üretken verileri korur
Güncellenebilirlik, yapı ve verilerin birbirinden ayrılmasıyla doğrudan ilgilidir. SSC, uygulamanın mizanpajlarını, formüllerini, işlev kapsayıcılarını, dil tanımlarını ve veri modelini içerir. SSD ise ilgili şirketin üretken iş verilerini içerir.
Bu nedenle, yeni bir sürümde tüm uygulama ve içindeki tüm müşteri verileri değiştirilmez. Bunun yerine, mevcut SSD kullanım yerinde kalırken yeni bir SSC yayınlanabilir.
Yeni yapı ek alanlar, tablolar veya değiştirilmiş veri formatları gerektiriyorsa, bunun için açıkça tanımlanmış geçiş adımları uygulanır. Üretim ortamındaki veriler, yeni yapıya kontrollü bir şekilde uyarlanır ve fark edilmeden başka bir veri setiyle değiştirilmez.
Bu net ayrım, her güncellemede tüm iş verilerini yeni bir tam dosyaya aktarmak zorunda kalmadan uygulamaların uzun yıllar boyunca geliştirilmesine olanak tanır.
Geliştirme aşamasından sürüm yayınlanmasına kadar
SchallOS Studio’daki her değişiklik, hemen üretime uygun olmayabilir. Geliştirme aşamasında, geçici düzenler, eksik işlevler veya henüz test edilmemiş formüller bulunabilir.
Bu nedenle, birbiriyle ilişkili değişiklikler öncelikle Değişiklik Oturumlarında kaydedilir ve planlanmış bir sürüme atanır. Ancak inceleme ve onay sürecinden sonra bu değişiklikler yayınlanmış bir sürüm haline gelir. Bir sürüm, diğerlerinin yanı sıra şunları içerebilir:
- belirgin bir sürüm numarası
- güncellenmiş SSC
- Gerekli SSD geçişleri
- teknik gereklilikler
- Çalışma zamanı veya adaptörlere bağlılıklar
- Denetim ve test aşamaları
- Sürüm Notları
- ve olası bir geri alma işlemi için bilgiler.
Bunun için temel, dokümantasyon katmanı sağlar. Kaydedilen geliştirme olaylarından, teknik değişiklik listeleri ve anlaşılır kullanıcı talimatları otomatik olarak oluşturulabilir.
Dolayısıyla bir sürüm, yalnızca değiştirilmiş dosyalardan ibaret değildir. Aynı zamanda nelerin değiştirildiğini, hangi ön koşulların geçerli olduğunu ve kurulumun nasıl kontrol edilmesi gerektiğini de açıklar.
SchallOS Control, dağıtımı yönetir
SchallOS Control, güncellemelerin operasyonel yönetimini üstlenir. Bu sistemde hangi örneklerin mevcut olduğu, hangi sürümlerin install aşamasına getirildiği ve hangi güncellemelerin hazır olduğu görülebilir. Kurulumdan önce Control, diğerlerinin yanı sıra şunları kontrol edebilir:
- Hedef kurumun ulaşılabilir olup olmadığı
- Hangi Runtime ve SSC sürümünün kullanıldığı
- Hangi veritabanı adaptörü etkin?
- uygun bir yedekleme oluşturulup oluşturulamayacağı
- ve sürümün tüm koşullarının karşılanıp karşılanmadığını.
Bu sayede, teknik açıdan uygun olmayan veya hazırlıkları tam olarak tamamlanmamış bir kurulumda güncellemenin gerçekleştirilmesi engellenir.
Ayrıca, bir sürümün tüm sistemlere aynı anda dağıtılması gerekmez. Öncelikle bir test ortamında veya seçilen kurulumlarda kullanılabilir. Ancak başarılı bir şekilde test edildikten sonra daha geniş çaplı bir şekilde devreye alınır.
Bunun için farklı güncelleme kanalları belirlenebilir; örneğin, kararlı üretim sürümleri, ön sürümler, dahili testler veya müşteriye özel sürümler.
İmzalar ve benzersiz sürüm numaraları
Güncelleme paketlerine kontrol toplamları ve dijital imzalar eklenebilir. Bu sayede SchallOS Control, bir paketin eksiksiz olup olmadığını, belirtilen kaynaktan gelip gelmediğini ve yayınlandığından bu yana değiştirilip değiştirilmediğini tespit eder.
Ayrıca, sürümün gerçekten ilgili çözüme ait olup olmadığı da kontrol edilir. Yeni bir SSC, yanlışlıkla başka bir uygulamanın SSD’sine bağlanmamalıdır.
Benzersiz çözüm kimlikleri, yapı sürümleri ve veri modeli sürümleri, install aşamalı durumun izlenebilirliğini sağlar. Gerekli ara adımlar da tespit edilebilir. Örneğin, önceden gerekli bir veri taşıma işleminin gerçekleştirilmesi gerekiyorsa, bir kurulum çok eski bir sürümden doğrudan en son sürüme geçemez.
Yedekleme, Taşıma ve Doğrulama
Yapısal bir güncelleme yapılmadan önce mevcut durum yedeklenir. Yedeklemenin somut şekli, kullanılan veritabanı adaptörüne göre değişir. Yerel bir IndexedDB veya SQLite kurulumu, bir PostgreSQL sunucusundan farklı yöntemler gerektirir.
Ardından güncelleme paketi kontrol edilir, yeni install yapısı oluşturulur ve gerekirse veri taşıma işlemi gerçekleştirilir. Etkinleştirme işleminin ardından doğrulama aşaması gelir. Bu aşamada SchallOS, örneğin aşağıdakileri kontrol edebilir:
- beklenen tüm tablolar ve alanların mevcut olup olmadığı,
- veri aktarımının tam olarak gerçekleştirilip gerçekleştirilmediği,
- veri satırlarının sayısı ve kontrol toplamlarının doğru olup olmadığı,
- ve önemli işlevlerin düzgün bir şekilde yerine getirilip getirilmediğini.
Ancak bu testler başarıyla tamamlandığında güncelleme install aşamasına geçmiş sayılır. Dolayısıyla, sadece dosya aktarımı yeterli değildir. Önemli olan, yapı, veriler ve çalışma zamanının daha sonra yeniden tutarlı ve işlevsel bir durum oluşturmasıdır.
Güncellemelerin başarısız olması durumunda geri alma
Dikkatli bir hazırlık sürecine rağmen, bir güncelleme başarısız olabilir. Beklenmedik eski veriler, hatalı bir taşıma işlemi veya göz ardı edilen bir bağımlılık, yeni sürümün güvenli bir şekilde etkinleştirilememesine neden olabilir. Bu tür durumlar için güncelleme sürecine bir geri alma işlemi dahildir. Bu işlemde, önceki SSC sürümü, yedeklenmiş SSD durumu ve önceki yapılandırma geri yüklenir.
Ancak her güncelleme istediği kadar geriye alınamaz. Kurulumdan sonra değiştirilen kurallara göre yeni üretim verileri işlenmişse, tamamen eski duruma dönmek sorun yaratabilir. Bu nedenle bir sürümde, geri alma işleminin hangi koşullarda mümkün olduğu belirtilmelidir.
Bazı durumlarda, eski bir veri setini geri yüklemek yerine düzeltici bir takip güncellemesi yapmak daha mantıklıdır. Platform, teknik altyapıyı sağlar; ancak somut karar, söz konusu değişikliğe ve bunun iş açısından önemine bağlıdır.
SchallOS’un kendisi de bu iş akışını kullanıyor
Güncelleme süreci sadece müşteri çözümleri için tasarlanmamıştır. SchallOS Studio, Runtime, Control ve diğer platform bileşenleri de aynı temel mekanizmalar aracılığıyla güncellenir. Yeni platform sürümleri, formül ortamına yönelik genişletmeler, yapay zeka katmanında iyileştirmeler, yeni veritabanı adaptörleri veya güvenlik düzeltmeleri içerebilir. Burada da sürüm numaraları, bağımlılıklar, imzalar ve doğrulamalar gereklidir.
Böylelikle altyapı, platformun devam eden işletimi sırasında bizzat kullanılır ve sürekli olarak test edilir. SchallOS ile geliştirilen uygulamalar da aynı süreçlerden yararlanır.
Böylece geliştirici, yalnızca teorik olarak öngörülen bir güncelleme işlevi değil, aynı zamanda tüm sistemin işletilmesi ve daha da geliştirilmesine yönelik bir süreç elde eder.
Gelecek sürümler için planlanan bir yol
Güncelleme sürecinin gücü, yalnızca yeni dosyaların otomatik olarak dağıtılmasından ibaret değildir. Asıl önemli olan, geliştirme, dokümantasyon, yedekleme, taşıma, test ve geri alma işlemlerinin tek bir ortak süreç içinde birbirine bağlanmasıdır.
SchallOS'un kendisi ve bununla geliştirilen uygulamalar aynı temel altyapıyı kullanır. SSC ve SSD'nin birbirinden ayrılması, yapının daha da gelişebilmesini sağlarken, üretim verilerinin korunmasını ve kontrollü bir şekilde uyarlanmasını garanti eder.
ShallOS ile geliştirilen bir çözüm, bu sayede en başından itibaren gelecekteki sürümler için planlanmış bir yol haritasına sahiptir. Özellikle uzun yıllar boyunca kullanılacak iş yazılımlarında bu güncelleme özelliği, ek bir işlev değil, uzun vadeli bakım ve güvenilir çalışmanın temel bir ön koşuludur.
Çeşitli işletim modelleri için Runtime, Control ve Cloud
Bir geliştirme ortamı, kapsamlı olanaklara sahip olmalıdır. Geliştiriciler, yapıları değiştirebilmeli, düzenleri tasarlayabilmeli, formülleri düzenleyebilmeli ve yeni işlevler yayınlayabilmelidir. Buna karşın, tamamlanmış bir iş uygulamasının günlük işletiminde bu araçlara genellikle ihtiyaç duyulmaz.
Bu nedenle SchallOS, geliştirme, yürütme ve yönetim işlevlerini farklı birimlere ayırır. SchallOS Studio, geliştirme işlevini yerine getirir. SchallOS Runtime, yayınlanmış uygulamaları yürütür. SchallOS Control, teknik dağıtımını yönetir. SchallOS Cloud ise merkezi olarak işletilen bir çevrimiçi hizmet olarak aynı temel mimariyi sunar.
Bu süreçte birbirinden bağımsız uygulamalar ortaya çıkmaz. Tüm alanlar aynı SSC ve SSD yapılarıyla çalışır. Çalışma şekli, dağıtım, veritabanı adaptörü ve çalışma zamanı profili aracılığıyla belirlenir.
SchallOS Runtime, yayınlanmış çözümleri çalıştırır
SchallOS Runtime, bir uygulamanın SSC’sini ilgili SSD ile birleştirir ve burada tanımlanan düzenleri, formülleri ve işlevleri kullanıma sunar. Çalışma zamanı özellikleri arasında, düzenlerin görüntülenmesi ve kullanımı, veri kayıtlarının okunması ve düzenlenmesi, formüllerin ve özel işlevlerin hesaplanması, işlev kapsayıcılarının yürütülmesi, gezinme ve diyalog kontrolü, çok dilli destek ve öngörülen veritabanı adaptörüne bağlantı yer alır.
Ancak Runtime, SchallOS Studio’nun tüm araçlarını otomatik olarak içermez. Yeni SSC/SSD çözüm çiftleri oluşturamaz ve FileMaker çözümleri için bir geçiş asistanına sahip değildir.
Böylelikle, teslim edilen müşteri uygulaması, asıl geliştirme ortamından açıkça ayrılmış olur.
Profiller, bir çalışma zamanının yeteneklerini belirler
Her kurulum aynı işlev yelpazesine ihtiyaç duymaz. Yalnızca son kullanıcıya yönelik bir uygulama, muhtemelen yalnızca yayınlanmış düzenleri ve iş süreçlerini yürütmekle yetinebilir. Kurum içi bir kurulum ise ek yönetim veya tanılama işlevlerine ihtiyaç duyabilir.
SchallOS bu amaçla çalışma zamanı ve yetenek profillerini kullanır. Bu profiller, belirli bir örneğin hangi teknik yeteneklere sahip olduğunu belirler.
Bir profil, örneğin, düzen modunun kullanılabilir olup olmadığını, verilerin içe veya dışa aktarılabileceğini, yönetim diyalog pencerelerinin görüntülenebileceğini, yerel ayarların değiştirilebileceğini veya belirli arayüzlerin kullanılabileceğini belirleyebilir.
Bu profiller, asıl çözüm içindeki kullanıcı haklarını tamamlar. Kullanıcı hakları, bir kişinin iş açısından neler yapabileceğini belirler. Buna karşılık, çalışma zamanı profili ise söz konusu kurulumun temel olarak hangi teknik imkânları sunduğunu belirler.
Böylelikle, her bir varyant için ayrı bir program sürümü geliştirmek zorunda kalınmadan, aynı çalışma zamanı altyapısı farklı müşteri grupları ve kullanım senaryoları için kullanılabilir.
Yerel tek kullanıcı sistemlerinden sunucu işletimine kadar
Bir SchallOS çözümü, çeşitli çalışma modlarında sunulabilir. Örneğin, yerel bir tek kullanıcı sistemi için SSD, IndexedDB’ye kaydedilebilir. install yapılandırmalı bir masaüstü uygulaması ise SQLite’ı kullanabilir. Daha büyük çok kullanıcılı çözümler için ise PostgreSQL gibi merkezi bir veritabanı öngörülmüştür.
Çalışma modelleri farklı özelliklere sahiptir. IndexedDB özellikle yerel tarayıcı uygulamaları için uygundur. SQLite, yerel uygulamalar ve yönetilebilir kurulumlar için kendini kanıtlamış bir temeldir. PostgreSQL ise profesyonel sunucu yönetimi gerektiren merkezi çok kullanıcılı sistemler için idealdir.
SchallOS, bu teknolojileri birbirinin yerine tamamen geçebilecek depolama alanları olarak değerlendirmemektedir. Adaptörün değiştirilmesi, kontrollü bir veri aktarımı, doğrulama ve gerekirse geri alma işlemini gerektirir. Ortak SSC/SSD mimarisi, düzenlerin, formüllerin ve iş mantığının her veritabanı adaptörü için tamamen yeniden geliştirilmesine gerek kalmamasını sağlar.
Masaüstü uygulamaları ve tarayıcı kullanımı
SchallOS çözümleri, hem tarayıcıda hem de Windows ve macOS için 1TP12 uyumlu uygulamalar olarak çalıştırılabilmelidir. Bir masaüstü çalışma ortamı, ilgili işletim sistemine daha sıkı bir şekilde entegre olabilir, yerel dosyaları kontrollü bir şekilde kullanabilir ve uygun yapılandırma durumunda zaman zaman çevrimdışı çalışabilir. Verilerini yerel olarak IndexedDB veya SQLite ile depolayabilir ya da merkezi bir PostgreSQL veritabanına erişebilir.
Uygulama, tarayıcıda kendi SchallOS Runtime'ı tarafından görüntülenir. Bunun için ne FileMaker Sunucusu ne de FileMaker WebDirect gereklidir. Dolayısıyla, taşınan bir FileMaker çözümü, aktarımdan sonra artık arka planda bir FileMaker dosyası üzerinde çalışmaz. Düzenler, formüller ve işlev mantığı, SchallOS mimarisi içinde yürütülür.
SchallOS Control, örnekleri yönetir
SchallOS Control, platformun operasyonel kontrol merkezini oluşturur. Burada, hangi çözümün hangi hedef sistemde çalıştırılacağı ve hangi teknik gerekliliklerin geçerli olduğu yönetilir. Control, diğerlerinin yanı sıra şunları görüntüleyebilir:
- hangi SSC/SSD çiftlerinin sağlandığı
- installiert adlı çalışma zamanı sürümü hangisidir?
- hangi veritabanı adaptörünün kullanıldığı
- Hangi yetkinlik profili geçerlidir?
- hangi güncellemeler mevcut
- ve bir örneğin en son ne zaman kontrol edildiği.
Bir dağıtım hedefi, örneğin yerel bir Windows uygulaması, bir macOS çalışma ortamı, kendi PostgreSQL sunucusu, bir test ortamı veya bir bulut örneği olabilir.
Sunucu adresleri, veritabanı erişim bilgileri, lisanslar veya yerel cihaz bağlamaları gibi işletme bilgileri taşınabilir SSC’ye dahil edilmez. Bu bilgiler, ilgili örneğin korumalı yapılandırmasında yönetilir.
İmzalı çözümler ve kontrollü dağıtım
Taşınabilir çözüm kapsayıcıları, her uygulamanın keyfi olarak değiştirilebileceği veya öngörülmemiş sistemlerde başlatılabileceği anlamına gelmemelidir. Bu nedenle, yayınlanan SSC/SSD paketleri çözüm kimlikleri, kontrol toplamları, imzalar ve örnek bilgileriyle ilişkilendirilebilir. Çalışma zamanı, başlatma sırasında SSC’nin değiştirilmemiş ve geçerli bir şekilde imzalanmış olup olmadığını, SSD’nin doğru çözüme ait olup olmadığını, her iki sürümün birbiriyle uyumlu olup olmadığını ve geçerli bir dağıtım profilinin mevcut olup olmadığını kontrol edebilir.
Lisans modeline bağlı olarak, bir dağıtım bir örneğe, bir sunucuya, bir cihaza veya belirli bir kullanıcı grubuna bağlanabilir. SchallOS Control, sunucu değişikliği, yeniden etkinleştirme veya bir kurulumun geri yüklenmesi gibi gerekli değişiklikleri de yönetir.
SchallOS Cloud, SaaS işletim modeli olarak
SchallOS Cloud, uygulamaları merkezi olarak işletilen bir çevrimiçi hizmet olarak sunar. Ancak bu bulut, kendine özgü veya farklı bir çözüm formatı kullanmaz. SchallOS Studio’da geliştirilen bir uygulama, bir bulut örneğine atanabilir ve tarayıcı üzerinden kullanıma sunulabilir. Çalışma ortamı, veritabanı, yedeklemeler, izleme ve güncellemeler merkezi olarak yönetilir. Bu sayede, geliştiriciler ve müşteriler için, uygulamanın ayrı bir bulut platformu için yeniden geliştirilmesine gerek kalmadan bir SaaS modeli ortaya çıkmaktadır.
Temel taşınabilirlik korunur. Veri hacmi, işlevler ve teknik koşullar elverdiği sürece, bir çözüm daha sonra kendi sunucusuna veya desteklenen başka bir işletim ortamına aktarılabilir. Bu geçiş, kontrollü bir geçiş olarak gerçekleşir; ancak uygulamanın tamamen yeniden geliştirilmesini gerektirmez.
Bir çözüm, gereksinimlerinizle birlikte büyüyebilir
Yeni bir uygulama ilk olarak yerel olarak geliştirilebilir ve küçük bir veri setiyle test edilebilir. Daha sonra uygulama, dahili bir çalışma zamanı ortamı olarak devreye alınabilir, SQLite veya PostgreSQL'e geçilebilir ve nihayetinde bir sunucu veya bulut çözümü olarak yayınlanabilir. Tablolar, düzenler, formüller, işlev kapsayıcıları, çeviriler ve dokümantasyon bu süreç boyunca aynı çözüm yapısının bir parçası olarak kalır.
Her prototip, herhangi bir uyarlama yapılmadan büyük ölçekli bir kurumsal uygulamaya dönüşmez. Çoklu kullanıcı desteği, güvenlik, performans ve yedekleme konularının dikkatli bir şekilde planlanması gerekir. Ancak bu platform, büyümenin kaçınılmaz olarak tam bir teknoloji değişikliğini gerektirmesini önler.
Böylece Runtime, Control ve Cloud, ortak bir mimari içinde farklı işletim modellerini bir araya getirir. Uygulama tek seferde geliştirilir ve ardından ilgili kullanım amacına uygun şekilde – yerel olarak, kendi sunucusunda veya bulutta SaaS olarak – kontrollü bir şekilde kullanıma sunulur.
Tabii ki. Bu bölümü yapay zeka bölümünün hemen arkasına ya da 4. bölüme ek olarak eklerdim. Bu bölüm önemli bir fikri ele alıyor: Yapay zeka belirli bir sağlayıcıya bağlı değildir; aksine, veritabanı adaptörleri gibi değiştirilebilir bir altyapı olarak ele alınır.
Üretici bağımlılığı yerine AI adaptörü
SchallOS, asıl yapay zeka katmanını kullanılan dil modellerinden bilinçli olarak ayırır. Platform, tek bir sağlayıcıyla veya belirli bir çalışma ortamıyla sınırlı kalmaz. Bunun yerine, çeşitli yapay zeka adaptörleri kurulabilir ve merkezi olarak yönetilebilir.
Bu adaptörler, SchallOS ile kullanılan dil modelleri arasında bağlantı sağlar. Böylelikle, bir isteğin yerel bir modele mi yoksa bir bulut hizmetine mi gönderildiğine bakılmaksızın, asıl geliştirme ortamı bundan bağımsız kalır.
Böylece yapay zeka, IndexedDB, SQLite veya PostgreSQL için kullanılan veritabanı adaptörleri gibi, platformun değiştirilebilir bir bileşeni haline geliyor.
SchallOS Control’da merkezi yönetim
AI’nın kurulumu, SchallOS Control üzerinden merkezi olarak gerçekleştirilir. Burada istenilen sayıda AI adaptörü oluşturulabilir ve yönetilebilir. Hem yerel modeller hem de bulut hizmetleri desteklenmektedir.
Yerel modeller, örneğin Ollama veya LM Studio aracılığıyla entegre edilebilir. Birçok geliştirme görevi için, tamamen kendi bilgisayarınızda çalıştırılan kompakt bir yerel model yeterlidir.
Ayrıca, ChatGPT, Claude veya diğer uyumlu hizmetler gibi bulut modelleri de kurulabilir. Her adaptörün kendi yapılandırması vardır; örneğin erişim bilgileri, uç noktalar, model adları veya diğer teknik ayarlar. Bu sayede, bir SchallOS kurulumundaki tüm mevcut yapay zeka sistemleri hakkında merkezi bir genel bakış elde edilir.
Bir kez ayarlandıktan sonra her yerden erişilebilir
Bu mimarinin en büyük avantajlarından biri, bir kez kurulmuş bir AI adaptörünün sadece tek bir yerde kullanılmamasıdır. Bir adaptör SchallOS Control’da kurulduğunda, tüm platformda kullanılabilir hale gelir. Örneğin şu şekillerde kullanılabilir:
- formül düzenleyicisinde
- işlev kapsayıcıları içinde
- otomatik dokümantasyon için
- FileMaker çözümlerinin taşınması sırasında
- Adapter Studio'da
- ya da gelecekteki yapay zeka destekli geliştirme araçlarında.
Bu nedenle, geliştiricinin erişim bilgilerini veya modelleri birden fazla kez yapılandırması gerekmez. Yönetim merkezi olarak gerçekleştirilirken, tek tek bileşenler yalnızca istenen adaptörü seçer.
Her bir görev için uygun model
Her geliştirme görevi aynı hesaplama gücünü gerektirmez. Bir formülün kısa bir açıklaması için genellikle küçük bir yerel model yeterlidir. Buna karşılık, kapsamlı veri taşıma işlemleri veya karmaşık programlama görevleri, daha yüksek performanslı bir bulut modelinden faydalanabilir.
Bu nedenle SchallOS, kullanım amacına göre farklı adaptörlerin seçilmesine olanak tanır. Örneğin bir geliştirici, basit dokümantasyonların her zaman yerel olarak oluşturulmasını, özellikle kapsamlı görevlerin ise harici bir modele aktarılmasını belirleyebilir. Böylelikle hız, veri güvenliği ve maliyetler arasında daha iyi bir denge sağlanabilir.
Gelecekteki modellere açık
Yapay zeka alanındaki gelişmeler olağanüstü bir hızla ilerliyor. Yeni modeller kısa aralıklarla ortaya çıkarken, mevcut sistemler de sürekli olarak iyileştiriliyor. Bu nedenle SchallOS, tek bir sağlayıcıya kalıcı olarak bağlı kalmıyor. Önemli olan belirli bir modelin adı değil, standartlaştırılmış adaptör arayüzüdür.
Böylelikle, daha sonra yeni yerel veya bulut tabanlı yapay zeka sistemleri, asıl geliştirme ortamını değiştirmek zorunda kalınmadan eklenebilir. Bu açıklık, SchallOS’un temel mimarisine uygundur. Veritabanı adaptörlerinde olduğu gibi, yapay zeka adaptörleri de değiştirilebilir olmaya devam etmelidir; bu sırada Studio, Runtime ve asıl uygulama değişmeden çalışmaya devam edebilmelidir.
Böylelikle yapay zeka, önümüzdeki yıllarda piyasada hangi modellerin veya sağlayıcıların öne çıkacağına bakılmaksızın, platformun kalıcı bir parçası haline gelecektir.
FileMaker geçişinden bağımsız yazılım platformuna
SchallOS, FileMaker ile uzun yıllara dayanan işbirliğinden doğmuştur. Platformun temel fikirlerinin çoğu, yıllar boyunca işletme gereksinimleri doğrultusunda birlikte gelişen özel veritabanı ve ERP çözümleriyle edinilen deneyimlere dayanmaktadır.
FileMaker, hızlı geliştirme konusunda özel avantajlara sahiptir. Veri modeli, mizanpajlar ve program mantığı birbirine yakındır; değişiklikler anında görünür hale gelir ve ilk çalışır durumdaki çözümler nispeten hızlı bir şekilde oluşturulabilir.
Geliştirici, veriler ve kullanıcı arayüzü arasındaki bu yakınlık, SchallOS’ta da korunacaktır. Ancak teknik altyapı yeniden oluşturulacaktır. SchallOS, kendine özgü bir çalışma zamanı ortamı, kendine özgü yapı ve veri konteynerleri, yapay zeka destekli bir işlev katmanı ile dokümantasyon, dağıtım ve güncellemeler için kendine özgü bir altyapı kullanmaktadır.
Böylece FileMaker, mevcut çözümler için önemli bir başlangıç noktası ve olası bir kaynak olmaya devam ediyor. Ancak ilerideki işletim için artık gerekli değildir.
Göç, bir düzen içe aktarımından daha fazlasıdır
Geliştirilmiş bir FileMaker çözümü sadece tablolardan, alanlardan ve görünür maskelerden ibaret değildir. İşletme bilgisinin büyük bir kısmı formüller, komut dosyaları, tetikleyiciler, ilişkiler, değer listeleri ve sayısız özel durum şeklinde saklanır.
Etkili bir geçiş süreci, bu ilişkileri tam olarak kavramalı ve bunları yeni bir mimariye aktarmalıdır. Tablolar, alanlar, ilişkiler ve düzenler bu süreçte büyük ölçüde yapılandırılmış olarak devralınabilir. Formüller ve özel işlevler, SchallOS formül ortamına aktarılır veya uyarlanır.
FileMaker komut dosyaları söz konusu olduğunda, öncelikle bunların teknik işlevlerinin anlaşılması ön plandadır. Bu komut dosyaları, yeni işlev konteynerlerinin arka planında bir öğrenme ve referans katmanı olarak korunabilir. Ancak yürütülebilir kod, yapay zeka tarafından SchallOS mimarisine uygun şekilde yeniden programlanacaktır. Böylelikle yeni sistem içinde FileMaker çalışma ortamı oluşmayacaktır. Mevcut çözüm, aşamalı olarak bağımsız bir SchallOS uygulamasına dönüşecektir.
Geçişten sonra bağımsız çalışma
Tam bir geçişin ardından ne FileMaker Pro’ya, ne de FileMaker Server’a veya WebDirect’e ihtiyaç duyulur. Yeni uygulama, SchallOS Runtime'ı, SSC'yi yapı konteyneri olarak ve SSD'yi üretim verileri için kullanır. Formüller, işlev konteynerleri, çok dillilik, dokümantasyon, olay günlükleri ve güncellemeler SchallOS platformu tarafından sağlanır.
İhtiyaçlara göre, çözüm yerel olarak, Windows veya macOS uygulaması olarak, kendi sunucunuzda ya da SchallOS Cloud’da bir SaaS hizmeti olarak çalıştırılabilir.
Böylece, tek bir özel çalışma zamanı ortamına bağımlılık ortadan kalkar. Teknik bağımlılıklar bu sayede tamamen ortadan kalkmaz – her modern yazılımın işletim sistemlerine, veritabanlarına ve sunucu hizmetlerine ihtiyacı vardır. Ancak yapı, iş mantığı ve veriler taşınabilir kalır ve belgelenmiş adaptörler ve dağıtım yolları aracılığıyla çalıştırılabilir.
FileMaker geliştiricileri için yeni fırsatlar
FileMaker geliştiricileri için SchallOS, mevcut çalışma yönteminden tamamen kopuş anlamına gelmemelidir. Veri modelleri, mizanpaj tasarımı ve operasyonel süreçler hakkındaki bilgiler hâlâ değerlidir.
Özellikle program mantığının uygulanışında değişiklikler oluyor. Uzun komut dizilerinin yerini, anlamsal olarak tanımlanmış işlev kapsayıcıları alıyor. Yapay zeka, tanımlanmış görevler, parametreler ve sınırlar temelinde çalıştırılabilir kodu programlıyor. Geliştirici, sonucu kontrol ediyor ve mimari ile teknik doğruluktan sorumlu olmaya devam ediyor.
Geliştirme geçmişi de daha fazla dikkate alınmaktadır. Değişiklikler otomatik olarak kaydedilebilir, belgelenebilir ve sürümler halinde birleştirilebilir. SchallOS’un kendisinin güncellenmesinde kullanılan aynı güncelleme süreci, müşterilerin kendi çözümleri için de kullanılabilir.
Böylece iş, tek tek program adımlarının manuel olarak girilmesinden, iş süreçlerinin hassas bir şekilde tanımlanması, kontrol edilmesi ve yapılandırılmasına doğru kısmen kaymaktadır.
Sadece taşınan uygulamalar için değil
FileMaker geçişi, SchallOS’un önemli bir bileşeni olmaya devam etmekle birlikte, tek kullanım amacı değildir. Yeni uygulamalar tamamen SchallOS Studio’da geliştirilebilir.
Uzun vadede başka kaynak sistemler de desteklenebilir. Ancak bu tür bir genişletme, her bir durum için ayrı analiz ve geçiş süreçleri gerektirir. Farklı geliştirme platformlarının kendine özgü yaklaşımları vardır ve bunlar, yüzeysel bir evrensel içe aktarma işlemiyle makul bir şekilde yansıtılamaz.
FileMaker geçişinden elde edilen deneyimler, bunun için bir temel oluşturmaktadır. Ancak SchallOS’un asıl amacı, bağımsız iş uygulamalarının geliştirilmesi ve işletilmesidir.
2026 sonbaharında başlaması planlanıyor
SchallOS’un halka açık lansmanı 2026 sonbaharında gerçekleştirilmesi planlanmaktadır. O zamana kadar, platformun temel bileşenleri birleştirilmeye, test edilmeye ve ilk operasyonel kullanım senaryolarına hazırlanmaya devam edilecektir. Uzun vadede planlanan her işlev, lansman sırasında tam olarak geliştirilmiş olmayacaktır. Önemli olan, üzerine diğer veritabanı adaptörlerinin, yapay zeka işlevlerinin, geçiş seçeneklerinin ve işletim modellerinin kontrollü bir şekilde inşa edilebileceği sağlam bir çekirdek oluşturmaktır.
Öncelikle, gofilemaker.de’nin gFM-NEXT ERP yazılımı yeni SchallOS platformunda muhtemelen Eylül 2026'da yayınlanacak. Bu nedenle, SchallOS geliştirme platformunun 2026 sonbaharında biraz daha geç bir tarihte devreye girmesi, geliştirme sürecinin sonunu değil, pratik kullanımın başlangıcını işaret etmelidir.
Bir uygulamanın tam yaşam döngüsü
SchallOS, mevcut FileMaker çözümlerinin modern bir ortama nasıl aktarılabileceği sorusuyla yola çıktı. Bunun sonucunda, sadece geçiş ve geliştirmeyi değil, aynı zamanda dokümantasyon, dağıtım, veri yönetimi, güncellemeler ve uzun vadeli işletimi de dikkate alan bir platform ortaya çıktı. Studio, Runtime, Control ve Cloud, ortak bir mimari içinde birbirinden net bir şekilde ayrılmış görevleri üstleniyor. Bu nedenle amaç, FileMaker’yi sadece başka bir geliştirme aracıyla değiştirmek değildir. SchallOS, geliştirici, veriler ve kullanıcı arayüzü arasındaki kanıtlanmış yakınlığı, taşınabilir konteynerler, yapay zeka destekli programlama ve kesintisiz bir işletim modeliyle birleştirmeyi hedeflemektedir.
FileMaker-DNA, başlangıç noktasını oluşturmaktadır. Hedef, mevcut ve yeni iş uygulamalarının uzun vadede geliştirilebileceği, işletilebileceği ve sürdürülebileceği bağımsız bir platform oluşturmaktır.
Sıkça sorulan sorular
- SchallOS tam olarak nedir ve klasik bir veritabanı uygulamasından ne farkı vardır?
SchallOS, özel iş yazılımlarının geliştirilmesi, çalıştırılması ve yönetilmesine yönelik bir platformdur. Platform, tablolar, düzenler ve işlevlerin yanı sıra yapay zeka destekli programlama, dokümantasyon, olay günlükleri, dağıtım ve güncellemeleri de kapsamaktadır. SchallOS Studio, geliştirme için kullanılır; Runtime, hazır uygulamaları çalıştırır; Control, kurulumları yönetir ve Cloud, çözümleri SaaS olarak sunar. Böylelikle platform, bir uygulamanın oluşturulmasından uzun vadeli işletilmesine kadar tüm süreci destekler. - SchallOS hangi geliştiriciler ve şirketler için tasarlanmıştır?
SchallOS, özellikle FileMaker geliştiricilerine, yazılım şirketlerine ve özel iş uygulamaları geliştiricilerine yöneliktir. Mevcut FileMaker çözümlerine sahip şirketler de uygulamalarını kademeli olarak bağımsız bir ortama taşıma imkânına sahip olurlar. Ayrıca, yeni çözümler tamamen SchallOS üzerinde geliştirilebilir. Genel müdürler ve teknik karar vericiler için en ilgi çekici nokta, geliştirme, işletim, dokümantasyon, güncellemeler ve çeşitli dağıtım biçimlerinin tek bir ortak platform içinde organize edilmesidir. - SchallOS esas olarak FileMaker’nin yerine mi geçiyor?
FileMaker, önemli bir başlangıç noktasıdır, ancak SchallOS’un kalıcı teknik temeli değildir. Görsel geliştirme ve veriler, düzenler ile işlevler arasındaki sıkı bağlantı gibi kendini kanıtlamış fikirler benimsenmektedir. Ancak çalışma zamanı ortamı, veri depolama, işlev mantığı ve güncelleme altyapısı bağımsız olarak oluşturulmaktadır. SchallOS, mevcut FileMaker çözümlerini taşıyabilir, ancak yeni uygulamalar için de uygundur. Tam bir taşıma işlemi tamamlandıktan sonra, FileMaker'nin üretim ortamında kullanılması artık gerekli değildir. - Mevcut FileMaker çözümüm tamamen otomatik olarak taşınabilir mi?
Tablolar, alanlar, ilişkiler, düzenler ve diğer tanımlanmış yapılar büyük ölçüde otomatik olarak aktarılabilir. Ancak karmaşık iş mantığı söz konusu olduğunda ek bir kontrol gereklidir. FileMaker komut dosyaları genellikle düzen değişiklikleri, küresel değişkenler, eklentiler veya geçmişte ortaya çıkan özel durumlar içerir. Yapay zeka bu süreçleri analiz edebilir ve bunlardan yeni işlev konteynerleri oluşturabilir. Yine de kapsamlı bir çözümün bir geliştirici tarafından kontrol edilmesi ve gerekirse düzeltilmesi gerekir. Taşıma işlemi manuel iş yükünü önemli ölçüde azaltır, ancak uygulamanın teknik olarak anlaşılmasının yerini almaz. - Geçiş işleminden sonra mevcut FileMaker komut dosyalarına ne olacak?
Komut dosyaları, yeni işlev konteynerlerinin arka planında öğrenme ve referans katmanı olarak korunabilir. Ancak bunlar, değiştirilmeden çalıştırılmaz. Yapay zeka, bir komut dosyasının hangi işlevsel görevi yerine getirdiğini, hangi alanları kullandığını ve hangi koşulların kontrol edildiğini analiz eder. Ardından, SchallOS mimarisine uygun şekilde yeni çalıştırılabilir kodu programlar. Orijinal komut dosyası, tarihsel bir bilgi kaynağı olarak korunur ve ileride ortaya çıkabilecek sorular veya genişletmeler durumunda yine dikkate alınabilir. - SSC ve SSD nedir ve bir çözüm neden iki konteyner gerektirir?
SSC, tablolar, alanlar, düzenler, formüller, işlev kapsayıcıları, diller ve dokümantasyon gibi uygulamanın yapısını içerir. SSD ise müşteriler, ürünler, siparişler veya faturalar gibi üretim verilerini içerir. Her iki kapsayıcı birbiriyle bağlantılıdır, ancak farklı işlevlere sahiptir. Bu ayrım, tüm veri tabanını değiştirmek zorunda kalmadan yeni yapı sürümleri oluşturulmasına olanak tanır. Ayrıca, uygulamayı tamamen yeniden geliştirmek zorunda kalmadan veri yönetimi, yedeklemeler ve işletim modelleri değiştirilebilir. - Yapı ile verilerin birbirinden ayrılması ne gibi avantajlar sağlar?
Bu sayede güncellemeler, yedeklemeler ve veritabanı taşıma işlemleri çok daha kontrollü bir şekilde gerçekleştirilebilir. Müşteri verilerini içeren SSD korunurken yeni bir SSC yayınlanabilir. Gerekli yapı değişiklikleri, tanımlanmış veri taşıma işlemleri aracılığıyla gerçekleştirilir. Ayrıca SSC, gizli iş verileri olmadan analiz edilebilir veya başka bir geliştiriciye devredilebilir. IndexedDB’den SQLite, PostgreSQL veya buluta geçiş de, düzenlerin ve işlev mantığının yeniden oluşturulmasına gerek kalmadığı için kolaylaştırılır. - Aynı çözüm yerel olarak, bir sunucuda ve bulutta çalıştırılabilir mi?
Temel olarak evet. Bir SchallOS çözümü, tarayıcıda yerel olarak, Windows veya macOS uygulaması olarak, SQLite ile, bir PostgreSQL sunucusunda ya da SchallOS Cloud’da SaaS olarak çalıştırılabilir. Bu durumda işlevsel kullanım aynı kalır. Ancak farklı çalışma biçimlerinin çoklu kullanıcı desteği, yedekleme, performans ve yönetim konusunda kendine özgü gereksinimleri vardır. Bu nedenle geçiş, veri aktarımı ve doğrulama yoluyla kontrollü bir şekilde gerçekleştirilir. SSC/SSD mimarisi, her hedef için tamamen yeni bir projenin yürütülmesi gerekliliğini ortadan kaldırır. - Başarılı bir geçişin ardından FileMaker veya FileMaker Sunucusuna hâlâ ihtiyacım olacak mı?
Hayır. Tam bir geçişin ardından uygulama, SchallOS Runtime tarafından çalıştırılır. Tarayıcı üzerinden çalıştırma için de ne FileMaker sunucusu ne de WebDirect gereklidir. Eski FileMaker sistemi referans veya arşiv amaçlı olarak korunabilir, ancak üretim ortamında çalışmak için bir ön koşul değildir. Düzenler, formüller, işlevler, veri erişimi, güncellemeler ve dağıtım SchallOS tarafından devralınır. Böylelikle, taşınan uygulama için önceki FileMaker çalışma zamanı bağımlılıkları da ortadan kalkar. - Yapay zeka, SchallOS’a nasıl entegre edilmiştir?
AI, formül düzenleyicisinde, Özel İşlevlerde, işlev kapsayıcılarında ve dokümantasyon katmanında doğrudan kullanılabilir. Yalnızca güncel soruyu değil, aynı zamanda ilgili alanları, tabloları, açıklamaları ve bağımlılıkları da bilir. Taşınan çözümlerde, orijinal FileMaker komut dosyası da ek bilgi kaynağı olarak kullanılabilir. Yapay zeka, formülleri açıklayabilir, kod oluşturabilir, hataları inceleyebilir ve dokümantasyon hazırlayabilir. Kalite, maliyet ve veri koruma hususlarının dikkate alınabilmesi için modellerin temel olarak değiştirilebilir olması amaçlanmaktadır. - AI, fonksiyon konteynerlerinin kodunu gerçekten programlıyor mu?
Evet. Geliştirici, görevi, parametreleri, beklenen sonucu ve izin verilen yetenekleri tanımlar. Yapay zeka, bu temele dayanarak çalıştırılabilir kodu oluşturur. Bu kod, görünür, denetlenebilir ve sürümlenebilir durumda kalır. Geliştirici, değişiklik talep edebilir, testler yapabilir ve önceki sürümleri karşılaştırabilir veya geri yükleyebilir. Böylece yapay zeka, programlama işinin büyük bir kısmını üstlenir, ancak teknik sorumluluğu üstlenmez. Özellikle iş açısından kritik süreçlerde, gereksinimler, yetkiler ve olası yan etkiler yine de dikkatle kontrol edilmelidir. - Formül düzenleyicisi hangi olanakları sunuyor?
Formül düzenleyici, tipik matematiksel, mantıksal, metinle ilgili hesaplamaların yanı sıra tarih ve saat hesaplamalarını da destekler. Formüller ve özel işlevler gerçek zamanlı olarak değerlendirilir ve anında test edilebilir. Başlangıçtaki komut yelpazesi, FileMaker’nin uzun yıllar boyunca gelişen işlev havuzundan daha küçüktür. Ancak formül ortamı genişletilebilir. Eksik fonksiyonlar eklenebilir veya kendi özel fonksiyonlarınızla yerine getirilebilir. Bu süreçte de entegre yapay zeka, mevcut FileMaker formüllerini aktarabilir veya yeni hesaplamalar geliştirebilir. - SchallOS hangi bilgileri otomatik olarak kaydeder?
Yapı düzeyinde, tablolarda, alanlarda, düzenlerde, formüllerde ve işlev kapsayıcılarında yapılan değişiklikler kaydedilir. Veri düzeyinde ise kayıt değişiklikleri, durum değişiklikleri, onaylar, içe aktarmalar ve diğer iş olayları günlüğe kaydedilebilir. Buna ek olarak, dağıtımlar, güncellemeler ve yedeklemeler gibi operasyonel olaylar da kaydedilir. Birbiriyle ilişkili geliştirme çalışmaları, Değişiklik Oturumları içinde bir araya getirilebilir ve daha sonra bir sürüme atanabilir. Böylelikle, sadece sonradan yazılmış notların bir derlemesi yerine, uygulamanın izlenebilir bir geçmişi oluşturulur. - SchallOS bu verilerden müşteri ve performans raporları oluşturabilir mi?
Evet. Entegre yapay zeka, kaydedilen olaylardan teknik belgeler, müşteri raporları, sürüm notları veya performans raporları oluşturabilir. Bu süreçte, birden fazla teknik değişiklik, iş açısından sağlanan faydayı anlaşılır bir şekilde açıklayan bir açıklamaya özetlenebilir. Temel oluşturan olaylar görüntülenebilir durumda kalır, böylece geliştirici ifadeleri kontrol edebilir. Her değişiklik otomatik olarak faturalandırılabilir değildir. Bu nedenle, nihai hizmet raporunun seçimi, değerlendirilmesi ve onaylanması geliştiriciye aittir. - Güncelleme süreci nasıl işliyor?
Değişiklikler öncelikle Değişiklik Oturumlarında toplanır ve bir sürüm halinde birleştirilir. Bir sürüm, yeni bir SSC, gerekli SSD geçişleri, ön koşullar, imzalar, kontroller ve geri alma bilgilerini içerebilir. SchallOS Control, hedef örneği kontrol eder, bir yedekleme oluşturur ve ardından güncellemeyi gerçekleştirir. Kurulumun ardından yapı, veriler ve önemli işlevlerin beklenen duruma uygun olup olmadığı kontrol edilir. Aynı temel süreç, hem SchallOS için hem de bununla geliştirilen müşteri çözümleri için kullanılır. - Runtime, Control ve Cloud arasında ne gibi farklar vardır?
SchallOS Runtime, yayınlanmış uygulamaları çalıştırır ve mizanpajları, formülleri ve işlev kapsayıcılarını sağlar. SchallOS Control, örnekleri, veritabanı adaptörlerini, çalışma zamanı profillerini, güncellemeleri ve teknik denetimleri yönetir. SchallOS Cloud, çalışma zamanı ve veri depolamayı merkezi olarak işletilen bir SaaS hizmeti olarak sunar. SchallOS Studio, asıl geliştirme ortamı olmaya devam eder. Tüm alanlar aynı SSC ve SSD temel yapılarını kullanır, ancak bir uygulamanın yaşam döngüsü içinde birbirinden açıkça ayrılmış görevleri üstlenir. - Haklar, kurulumlar ve hassas veriler nasıl korunur?
Kullanıcı hakları, bir kişinin çözüm içinde hangi işlevsel işlemleri gerçekleştirebileceğini belirler. Çalışma zamanı ve yetenek profilleri ise bir kurulumun hangi teknik işlevlere sahip olduğunu da belirler. SSC ve SSD paketleri, kimlik bilgileri, sağlama toplamları ve imzalarla korunabilir. Ayrıca, yapay zeka bağlamı da sınırlandırılabilir; böylece tüm müşteri verileri otomatik olarak işlenmez. Özellikle hassas ortamlar için özel sunucular veya gelecekte yerel yapay zeka modelleri de kullanılabilir. Somut güvenlik yapılandırması, ilgili kullanım durumuna göre belirlenir. - SchallOS ne zaman kullanıma sunulacak?
Genel kullanıma açılması 2026 sonbaharında planlanmaktadır. İlk etapta odak noktası Studio ve Runtime, SSC ile SSD'nin ayrılması, mevcut FileMaker yapılarının taşınması, formüller, özel işlevler, yapay zeka ile programlanmış işlev konteynerleri, dokümantasyon, olay günlükleri, dağıtım ve güncellemeler olacaktır. SchallOS Control de kurulumların yönetimi konusunda merkezi bir rol üstlenecektir. Uzun vadede planlanan her işlevin, lansman sırasında tam olarak geliştirilmiş olması gerekmez. Öncelikle, ilk üretken uygulamalar için sağlam bir çekirdek oluşturmak önemlidir.
