Uzmanlık Alanlarım — Ali Kılıçarslan

Görüntü İşleme ve Bilgisayarlı Görü

Sahadaki görüntü, laboratuvardaki görüntü değildir.

Karşılaşılan problem

Bir su sayacının endeksini insan gözü yarım saniyede okur; kamera okuyamaz. Camda buğu, kadranda kir, bodrumda ışık yok, açı her seferinde farklı. Aynı sorun tarımda da var: bir marul yaprağındaki lekenin hastalık mı yoksa gölge mi olduğunu ayırmak, modelden önce veriyi anlamayı gerektiriyor.

Yaklaşımım

Modeli en son yazıyorum. Önce veriyi topluyor, ön işleme adımlarını (gri tonlama, eşikleme, gürültü azaltma, perspektif düzeltme) tek tek görselleştiriyor ve hangi adımın neyi kazandırdığını ölçüyorum. Sınıflandırma ancak girdi kararlı hâle geldikten sonra anlamlı oluyor. Gerçek zamanlı analizde ise doğruluk kadar kare başına süre de bir kısıt olarak masada duruyor.

Kullanılan teknolojiler

Örnek proje

Su Sayacı Otomatik Okuma Prototipi

Ortaya çıkan sonuç

ASKİ stajı sırasında su sayacı okuma için yapay zekâ destekli bir prototip geliştirdim. Ardından MarulVision marul analiz platformu ve balık türü tanıma çalışmaları geldi.

Bu çalışmadan kalan

Görüntü işlemede başarıyı belirleyen şey model mimarisi değil, girdi kalitesi. Sahada çalışacak bir sistem tasarlıyorsanız veri toplama protokolünü modelden önce yazmanız gerekiyor.

Gömülü Sistemler

Kodun doğru olması yetmez; sensörün doğru olması gerekir.

Karşılaşılan problem

Pronova Hydroponics tarafında sistem, pH ve EC değerlerine bakarak pompa çalıştırıyor ve besin dozajlıyordu. Yani yazılımın verdiği karar doğrudan fiziksel bir sonuç üretiyordu. Kalibre edilmemiş bir sensörün ürettiği "makul görünen" veri, panelde hiçbir uyarı vermeden yanlış dozajlamaya dönüşebiliyordu.

Yaklaşımım

Ölçüm zincirini tek parça olarak ele aldım: sensör → kalibrasyon → ESP32 firmware → eşik kuralları → röle/pompa → log. Dozajlama kararlarını koda gömmek yerine kural hâline getirdim, böylece saha koşulu değiştiğinde firmware yeniden yazılmadan eşik ayarlanabildi. Her karar loglandı — bir pompanın neden çalıştığı sonradan sorulabilir olmalıydı.

Kullanılan teknolojiler

Örnek proje

Pronova Hydroponics — IoT İzleme ve Dozajlama Sistemi

Ortaya çıkan sonuç

ESP32 tabanlı gömülü yazılım, sensör entegrasyonu, pompa/röle kontrolü ve dozajlama kuralları uçtan uca geliştirildi; saha kalibrasyonu ve devreye alma süreçleri yürütüldü.

Bu çalışmadan kalan

Gömülü sistemde "çalıştı" ile "güvenilir" arasında kalibrasyon, loglama ve devreye alma prosedürü vardır. Bunlar olmadan sistem laboratuvarda doğru, sahada tahmindir.

Robotik ve IoT

Fiziksel dünyaya müdahale eden yazılımın hata bütçesi sıfırdır.

Karşılaşılan problem

Bir web uygulamasında hata mesajı gösterirsiniz; bir röleyi yanlış tetiklediğinizde pompa çalışır. IoT tarafında asıl problem veri toplamak değil, kesintiye ve yanlış ölçüme rağmen doğru davranmaktır: bağlantı kopunca cihaz ne yapacak, sensör saçmalarsa hangi değer güvenli kabul edilecek?

Yaklaşımım

Cihazı merkeze bağımlı bırakmıyorum. Karar kuralları cihaz üzerinde çalışır, merkez yalnızca izler ve eşik günceller. Bağlantı koptuğunda cihaz bilinen son güvenli duruma geçer, veriyi yerel olarak tutar ve bağlantı gelince gönderir. Bu, saha mobil uygulamalarındaki çevrimdışı kuyruk mantığıyla birebir aynı mühendislik problemidir.

Kullanılan teknolojiler

Örnek proje

Kablosuz Sayaç Okuma ve Gateway Mimarisi Değerlendirmesi

Ortaya çıkan sonuç

Pronova Hydroponics tarafında sensör-aktüatör kontrol döngüsü sahada devreye alındı. ASKİ tarafında RF Gateway, W-MBus ve Modbus tabanlı kablosuz sayaç okuma mimarisi teknik olarak değerlendirilerek pilot uygulama önerisi ve tedarikçi şartname soruları hazırlandı.

Bu çalışmadan kalan

Kablosuz her zaman daha iyi değildir. Kapsama, pil ömrü, gateway bağımlılığı ve açık protokol garantisi hesaba katılmazsa kurulum kolaylığı, yıllar süren bir tedarikçi bağımlılığına dönüşür.

Mobil Uygulama Geliştirme

Uygulamayı bodrumda, eldivenle ve tek elle kullanan biri için tasarlıyorum.

Karşılaşılan problem

Saha personeli ofis kullanıcısı değil. Telefonu güneşin altında, eldivenle, çoğu zaman şebekesiz bir bodrumda kullanıyor. Ekranda dört fotoğraf çekmesi, endeks girmesi, stoktan doğru sayacı seçmesi ve işi kapatması gerekiyor — hepsi bağlantı olmadan.

Yaklaşımım

Büyük dokunma alanları, net durum rozetleri ve Türkçe-anlaşılır hata mesajları. Katmanları ayırıyorum: app (tema, yönlendirme), core (ağ, konum, fotoğraf, senkron, depolama), features (görev, form, stok, senkron) ve shared bileşenler. Kritik akışta zorunlu alan doğrulaması kullanıcıyı ilk eksik alana kaydırıyor; form tamamlama tek bir veritabanı işlemi içinde kapanıyor, aksi hâlde görev tamamlanıp kaydın kuyruğa girmemesi mümkün.

Kullanılan teknolojiler

Örnek proje

Mekanik Sayaç Saha Takip Sistemi

Ortaya çıkan sonuç

ASKİ bünyesinde beş ayrı saha operasyon uygulamasında mobil taraf geliştirildi; üçü tamamlanıp kullanımda, ikisi canlı entegrasyon aşamasında.

Bu çalışmadan kalan

Mobil saha uygulamasında en tehlikeli hata çökme değil, sessiz başarıdır. Gönderilmemiş bir kaydın "gönderildi" görünmesi, kullanıcının sisteme olan güvenini tek seferde bitirir — ve bu güven geri gelmez.

Web ve Backend Sistemleri

API, mobil ile veritabanı arasındaki sözleşmedir; sözleşme belirsizse sistem belirsizdir.

Karşılaşılan problem

Saha uygulamasının arkasında görev çekme, stok çekme, form gönderme, fotoğraf yükleme ve token yenileme akışlarının hepsinin tutarlı davranması gerekiyor. Bir uçtaki hata diğerinde veri kaybı olarak görünüyor.

Yaklaşımım

Katmanlı ve okunabilir bir yapı: API katmanında sürümleme, kimlik doğrulama ve yapılandırılmış log; Data katmanında hafif bir ORM ile açıkça yazılmış SQL. Sorguları repository katmanında topluyorum ki veritabanı tarafındaki bir değişiklik uygulamanın her yerine dağılmasın. Her uç için Postman koleksiyonu tutuluyor — dokümantasyon çalıştırılabilir olmalı.

Kullanılan teknolojiler

Örnek proje

ASKİ Saha API Katmanı

Ortaya çıkan sonuç

Saha uygulamalarını besleyen ASP.NET Core API katmanında JWT tabanlı kimlik doğrulama, sürümlenmiş uçlar ve yapılandırılmış loglama ile çalışan uçlar geliştirildi. Kişisel tarafta ise framework ve CDN kullanmayan, tamamen yerel çalışan bir PHP/MySQL stok uygulaması yazıldı.

Bu çalışmadan kalan

Bir API'nin kalitesi mutlu yolda değil, hata yolunda belli olur. Doğru cevabı vermek kolaydır; hatayı doğru sınıflandırmak ve istemcinin ne yapacağını söylemek zordur.

Kurumsal Yazılım ve Entegrasyon

Kurumda hiçbir sistem yalnız yaşamaz.

Karşılaşılan problem

Bir saha uygulaması tek başına hiçbir işe yaramıyor. Personel kimliği kurumsal sicilden, abone bilgisi abone sisteminden, adres UAVT'den, fotoğraf ayrı bir dosya servisinden, yetki E-Portal üzerinden geliyor. Dış tarafta ise Başkent 153 üzerinden vatandaş başvuruları düşüyor ve doğru birime yönlendirilmesi gerekiyor.

Yaklaşımım

Dış sistemi doğrudan istemciye açmıyorum. Araya bir katman koyuyorum: dış API anahtarı yalnızca sunucuda kalıyor, kurum içi istemciler sadeleştirilmiş uçları kendi iç anahtarlarıyla kullanıyor. Sınıflandırma gibi belirsiz işlerde ise iki katmanlı bir yaklaşım: yapay zekâ önerir, kural motoru yedeklidir ve karar her zaman insana bırakılabilir.

Kullanılan teknolojiler

Örnek proje

Başkent 153 Arıza Yönlendirme Otomasyonu

Ortaya çıkan sonuç

Dış başvuru sisteminden gelen arıza kayıtlarını kurum içinde güvenli biçimde alan, sınıflandıran ve ilgili birime yönlendiren bir ara katman ile operasyon paneli geliştirildi.

Bu çalışmadan kalan

Entegrasyonda asıl risk teknik değil, sahiplik sınırıdır. Hangi hatanın kimin tarafında olduğu baştan tanımlanmazsa her arıza bir sorumluluk tartışmasına dönüşür.

Oracle ve PL/SQL

İşlem sınırını kim çiziyorsa sistemi o kontrol eder.

Karşılaşılan problem

Mekanik Sayaç projesinde sahadan gelen tamamlanmış işler sürekli hata veriyordu. Mobil taraf "gönderilemedi" diyor, oysa Oracle tarafında iş çoktan kalıcı olarak kaydedilmişti. Tekrar denemeler ise "kayıt artık bekleyen listede yok" hatasına düşüyordu.

Yaklaşımım

Suçu istemcide aramak yerine işlem sınırlarını izledim. Kök neden şuydu: veritabanı prosedürü kendi içinde commit ediyor, API ise atamayı ayrı bir transaction ile yönetiyordu. Prosedür commit ettikten sonra API'nin telafi adımı asıl işlemi geri alamıyordu. Bulguyu canlı kayıt kanıtıyla (mobil kayıt, başvuru durumu, takılan sayaç ve tarih) belgeleyip sorumlu katmanı net şekilde raporladım — üzerinde tek bir INSERT/UPDATE çalıştırmadan, yalnızca SELECT ile.

Kullanılan teknolojiler

Örnek proje

Mekanik Sayaç Saha Takip Sistemi

Ortaya çıkan sonuç

Pilotu bloke eden hatanın kök nedeni prosedür içi commit ile API telafi tasarımının çakışması olarak tespit edildi ve API ekibine somut değişiklik talebi olarak iletildi.

Bu çalışmadan kalan

Dağıtık bir sistemde en pahalı hata, iki katmanın da kendi içinde doğru olup birlikte yanlış olmasıdır. Prosedür içindeki tek bir commit, üstündeki bütün telafi mantığını sessizce geçersiz kılar.

CBS, Harita ve Saha Operasyonları

Konum bir veri alanı değil, bir kanıttır.

Karşılaşılan problem

Bir işin yapıldığını nasıl kanıtlarsınız? Asfalt yamada serilen alan, kazı kaydında koordinat, sayaç değişiminde adres — hepsi sonradan itiraz edilebilir. Üstelik GPS sahada her zaman çalışmıyor: bodrumda fix gelmiyor, açık alanda hassasiyet metrelerce değişiyor.

Yaklaşımım

Konumu tek başına değil; zaman damgası, personel sicili, cihaz kimliği ve fotoğrafla birlikte tek bir kanıt paketi olarak kaydediyorum. GPS beklemesini süresiz bırakmıyorum — zaman aşımı, hassasiyet değeri ve kullanıcıya görünür bir durum göstergesi olmalı. Rota hesabı çevrimdışıyken de bilinen bir referans noktasıyla çalışmaya devam ediyor.

Kullanılan teknolojiler

Örnek proje

ASKİ Asfalt Bölge ve Saha Takip Sistemi

Ortaya çıkan sonuç

Asfalt, sayaç ve su-kanal operasyonlarında kazı/iş kayıtları koordinat, ölçü ve öncesi-sonrası fotoğrafla ilişkilendirilerek uçtan uca izlenebilir hâle getirildi.

Bu çalışmadan kalan

Saha yazılımında konum alanını "opsiyonel" yapmak, sistemin kanıt değerini sıfırlar. Ama zorunlu yapıp GPS gelmediğinde kullanıcıyı kilitlemek de sahayı durdurur — aradaki dengeyi kurmak asıl tasarım problemidir.

DevOps, CI/CD ve Yazılım Altyapısı

Elle yapılan her yayın, bir gün yanlış yapılacak yayındır.

Karşılaşılan problem

Kurumsal ortamda mobil ve API tarafının aynı anda ilerlemesi, sürüm takibinin ve geliştirme-canlı geçişinin kontrollü olmasını gerektiriyor. Sahada çalışan bir uygulamada yanlış sürüm, veri uyumsuzluğu demek.

Yaklaşımım

Yayın öncesi doğrulamayı otomatik ve tekrarlanabilir tutuyorum: statik analiz, birim testleri ve release derlemesi her teslimden önce çalışıyor. Mekanik Saha Takip pilotunda teslim kriteri buydu — `flutter analyze` temiz, 44/44 test başarılı, release APK ve API derlemesi 0 hata 0 uyarı.

Kullanılan teknolojiler

Örnek proje

Mekanik Sayaç Saha Takip Sistemi

Ortaya çıkan sonuç

Teslim öncesi otomatik doğrulama zinciri işletildi; pilot raporunda statik analiz, test ve release derleme sonuçları kanıt olarak belgelendi.

Bu çalışmadan kalan

CI/CD'nin değeri hız değil, tekrarlanabilirlik. Aynı komutla aynı çıktıyı üretemiyorsanız, canlıya çıkan şeyin ne olduğunu gerçekten bilmiyorsunuz demektir.

Yapay Zekâ ve Otomasyon

Yapay zekâ karar vermez; öneri üretir ve kararı hızlandırır.

Karşılaşılan problem

Başkent 153 üzerinden ASKİ'ye düşen başvurular serbest metin. Bir kayıt kartlı sayaç mı, kaçak su mu, fatura itirazı mı yoksa kanal arızası mı — bunu insan okuyup ayırıyordu. Hacim büyüdükçe ayrıştırma tek başına bir iş yüküne dönüşüyordu.

Yaklaşımım

Sınıflandırmayı öneri katmanı olarak kurguladım, karar katmanı olarak değil. Model bir birim öneriyor, güven skoru veriyor ve gerekçesini yazıyor; düşük güvenli kayıtlar insana bırakılıyor. Model anahtarı yoksa kural motoru devreye giriyor — sistem yapay zekâ olmadan da çalışmaya devam ediyor. Toplu aktarma, derin tarama ve otomatik mod operatörün hızını artırıyor ama son sözü elinden almıyor.

Kullanılan teknolojiler

Örnek proje

Başkent 153 Arıza Yönlendirme Otomasyonu

Ortaya çıkan sonuç

Başvuru kayıtları on iki kurumsal birime otomatik sınıflandırılıyor; operasyon panelinde güven filtresi, toplu aktarma ve "insana bırakılanlar" görünümü ile insan denetimi süreçte tutuluyor.

Bu çalışmadan kalan

Otomasyonun kabul görmesi doğruluk oranından çok geri alınabilirlikle ilgili. Kullanıcı sistemin önerisini düzeltebildiğini gördüğü anda güvenmeye başlıyor.