Yazılım geliştirme, mobil uygulama, CRM/ERP, yedekleme ve altyapı üzerine deneyimle yazılmış yazılar.
Done Dynamics, müşteri verilerinin güvenliği ve dışa bağımlı yapay zekayı azaltmak için zsoftrade ile birlikte 1.000.000 TL'lik Mac Studio sunucu yatırımı yaptı: M3 Ultra 512 GB ve M4 Max 36 GB.
Devamını oku →Bir konu aratıldığında ilk on sonucun çoğu birbirinin cümle sırası değişmiş hâlidir. Aynı tanım, aynı beş madde, aynı kapanış. Hiçbirinde bir şey denenmemiştir. Bu yazılım blogu tam o boşluk için var: burada yazılan her şey ya kendi altyapımızda ya bir müşterinin sahasında karşılığı olan bir karardan çıkıyor. Fark okurken hemen belli olmuyor. Uygularken oluyor.
Done Dynamics bir kurumsal yazılım şirketi; günün büyük bölümü sunucu, ağ, uygulama ve arama görünürlüğü tarafında geçiyor. Yazıların çıkış noktası da orası. Bir donanım alındığında, bir mimari değiştirildiğinde ya da yapılan bir tahmin tutmadığında not tutuluyor; notların bir kısmı burada yayımlanıyor. Şirket tanıtımı değil, karar dökümü.
Bu sayfanın altında beş şey anlatılıyor: pazarlama yazısıyla saha notunun farkı, derleme içeriğin neyi gizlediği, burada hangi sorulara cevap arandığı, teknik karar alırken tekrar eden hatalar ve ele alınan konu başlıkları. Sonda da yayında olan yazıya dair kısa bir not var.
Bir uyarı da baştan: burada yazılanların hepsi belirli bir zamana ve belirli bir donanıma ait. Altı ay sonra bazı sayılar değişmiş olacak. Değiştiğinde yazı silinmeyecek, üstüne not düşülecek. Teknik metnin en dürüst hâli, eskidiğini kabul edenidir.
Pazarlama amaçlı yazı bir sonuca doğru ilerler. Sonuç baştan bellidir: aranan ürün ya da hizmet. Metin o sonuca giden yolu döşer, karşı argümanları hafifçe geçer, riskleri dipnota indirir. Kötü niyetli olması gerekmez; yalnızca yönü sabittir. Okuyucu da genelde bunu sezer, çünkü hiçbir cümlede tereddüt yoktur.
Saha notunda yön sabit değildir. Bir karar alınmış, uygulanmış ve sonucu görülmüştür. Sonuç bazen beklendiği gibi çıkar, bazen çıkmaz. Yazının değeri de tam olarak burada birikir: neyin işe yaramadığını yazmak, neyin yaradığını yazmaktan daha az satar ama daha çok işe yarar. Bir teknoloji kararının maliyeti çoğu zaman kararın kendisinde değil, geri dönüşünde saklıdır.
İkinci fark ölçekte. Pazarlama metni genellemeyi sever: "işletmeler için ideal çözüm". Saha notu koşulu söylemek zorundadır — kaç kullanıcı, hangi veri hacmi, hangi bağlantı hızı, hangi bütçe. Aynı mimari on kişilik bir ofiste mükemmel çalışırken üç yüz kişilik bir yapıda çöker. Koşulu yazmayan metin, okuyucuya kendi durumunu değerlendirme imkânı bırakmaz.
Üçüncü fark zaman. Pazarlama yazısı yayımlandığı gün en doğrudur, sonra eskir. Saha notu tersine çalışır: altı ay sonra "o karar tuttu mu" sorusu sorulabilir hâle gelir ve metnin gerçek sınavı orada başlar. Bir yazılım blogu ancak eski yazılarının arkasında durabildiği ölçüde okunmaya değer. Bu yüzden burada tarih ve donanım modeli gibi bağlayıcı ayrıntılar açık yazılıyor.
Bir de okuyucu tarafı var. Pazarlama metnini okuyan kişi karar vermeye hazırdır; saha notunu okuyan kişi genelde bir şeyi çözmeye çalışıyordur. İkisinin sorusu aynı değil. Birincisi "kiminle çalışayım" diye sorar, ikincisi "bu yapı benim yükümü kaldırır mı" diye. İstanbul yazılım taleplerinde ikinci grup ağır basıyor; karşımızdaki kişi çoğu zaman kendi teknik ekibi olan, kıyaslama yapmak isteyen biri. Ona satış metni göndermek vakit kaybı. Ölçüm göndermek işe yarıyor.
Derleme içerik kolay üretilir. Beş kaynaktan okunur, sıra değiştirilir, bir giriş ve bir kapanış eklenir. Ortaya çıkan metin teknik olarak yanlış olmayabilir. Sorun başka: hangi cümlenin ölçülmüş bir gerçek, hangisinin bir başkasının varsayımı olduğu kaybolur. Kaynak zinciri koptuğunda hata da düzeltilemez hâle gelir, çünkü hatanın nereden girdiği bilinmez.
Yaygın bir örnek var: yıllar önce doğru olan bir eşik değeri, bugünkü metinlerde hâlâ dolaşır. Donanım değişmiştir, kütüphane sürümü değişmiştir, sınır artık orada değildir. Ama cümle her derlemede bir sonrakine geçtiği için ölmez. Birinci elden yazılmış metinde bu olmaz; yazan kişi kendi ölçümünü verdiği için tarih de, koşul da metnin içindedir.
İkinci gizlenen şey maliyet. Derleme içerik bir teknolojinin kurulumunu anlatır, bakımını anlatmaz. Oysa bir sistemin gerçek bedeli kurulum gününde değil, on sekizinci ayında görünür: sürüm yükseltmesi, yedek doğrulaması, personel değişimi, mevzuat güncellemesi. Alanya yazılım ekibimizin sahada en sık düzelttiği durum da bu — internetten okunmuş bir tarife göre kurulmuş, bakımı hiç konuşulmamış bir yapı.
Üçüncü gizlenen şey bağlam. Bir çözümün hangi ölçekte doğrulandığı yazılmadığında okuyucu onu kendi ölçeğine taşıdığını sanır. Oysa taşımaz. On kullanıcıyla denenmiş bir kurulum üç yüz kullanıcıda bambaşka davranır ve bunu ancak canlıya alındıktan sonra öğrenirsiniz — en pahalı öğrenme biçimi. Bu yazılım blogu içinde bir yaklaşım anlatılırken hangi ölçekte denendiği de yazılıyor. Kısıtı yazmak metni zayıflatmaz; sınanabilir kılar.
Arama sonuçları hızla dolduruluyor. Bir konu hakkında yüzlerce metin üretmek artık dakikalar sürüyor ve bu metinlerin çoğu birbirinin ortalaması. Ortalamanın sorunu yanlış olması değil, karar verdirmemesi. Okuyucu üç sayfa gezer, hepsinde aynı beş maddeyi görür ve kendi sorusunun cevabını hiçbirinde bulamaz. Kaybedilen şey zaman.
İkinci kayıp aykırı bilginin silinmesi. Bir modelden çıkan metin, veri kümesindeki en yaygın görüşü tekrarlamaya eğilimlidir. Sahada işe yarayan çözümlerin bir kısmı ise yaygın değil, koşula özgüdür. Küçük bir işletmede doğru olan bir mimari, çoğunluk öyle yapmadığı için ortalama metinlerde hiç geçmez. Bu yazılım blogu için ilkeler arasında ilk sırada duran şey de bu: azınlıkta kalan ama ölçülmüş kararı yazmak.
Üçüncü kayıp sorumluluk. Bir metnin arkasında adı geçen bir insan yoksa, yanlış çıktığında kimse hesap vermez. Burada yayımlanan yazıların yazarı belli ve o yazar aynı kararı kendi altyapısında uygulamış kişi. Yapay zekâyı kullanmıyor muyuz? Kullanıyoruz — hem de kendi donanımımızda çalıştırdığımız modellerle. Fark şurada: metni model yazmıyor, karar veren insan yazıyor.
Dördüncü kayıp doğrulanabilirlik. Ölçüm yapılmadan yazılan cümleler birbirine benzer; ölçüm yapılarak yazılanlar benzemez, çünkü her ortamın sayısı farklıdır. Bir metinde donanım modeli, sürüm numarası, süre ya da tutar geçiyorsa o metin sınanabilir. Geçmiyorsa yalnızca hoş bir anlatı vardır ortada.
Beşinci kayıp daha sinsi: aramanın kendisi bozuluyor. Ortalama metin çoğaldıkça iyi metni bulmak zorlaşıyor ve okuyucu bir yerden sonra aramayı bırakıp ilk gördüğüne göre karar veriyor. Karar da genelde yanlış çıkıyor. Alanya yazılım ekibimize gelen taleplerin bir bölümü tam buradan doğuyor — altı ay önce kurulmuş, bugün sökülmesi gereken bir yapı. Sökmek kurmaktan pahalı.
Bir ölçüt önerelim. Bir metni okurken kendinize şunu sorun: burada, yazarın kendi başına gelmiş olması gereken tek bir ayrıntı var mı? Bir hata mesajı, bir sürüm numarası, gece yaşanmış bir aksaklık, bir tedarikçiyle yapılmış tartışma. Yoksa metin muhtemelen başka metinlerden derlenmiştir. Kusursuz bir ölçüt değil. Pratikte iyi çalışıyor ve hiçbir araç gerektirmiyor.
İlk soru teknoloji seçimi. Hangi çerçeve, hangi veritabanı, hangi barındırma modeli? Bu sorunun tek doğru cevabı yok, ama yanlış cevaplama biçimi var: popülerlik sırasına bakarak seçmek. Seçim ekibin bildiği şeye, işin ömrüne ve bakımı kimin üstleneceğine bağlı. Yazılarda karşılaştırma yapılırken kazanan ilan edilmiyor; hangi koşulda hangisinin oturduğu yazılıyor. Kazanan yok. Koşul var.
İkinci soru altyapı kararı. Bulutta mı, kendi donanımında mı, ikisi karışık mı? Bu karar aylık faturayla değil, üç yıllık toplam maliyetle ve veri hassasiyetiyle veriliyor. Kiralanan kaynak esnektir, satın alınan kaynak öngörülebilir. İkisinin doğru olduğu senaryolar birbirinden çok farklı ve genelde işin trafik profiline bakılarak ayrışıyor. Yük dalgalıysa kirala. Sabitse hesapla.
Üçüncü soru maliyet karşılaştırması. Bir sistemin gerçek maliyeti lisans bedeli değil; lisans, barındırma, bakım, eğitim ve duruş riskinin toplamı. Sayılar yan yana konmadan yapılan tartışma fikir alışverişinden ibaret kalıyor. Burada tutarlar yazıldığında kaleminin de yazılmasına dikkat ediliyor, çünkü toplam rakam tek başına yanıltıcı. Tek satır az şey anlatır.
Dördüncü soru mevzuat uyumu. KVKK yükümlülükleri, verinin nerede tutulduğu, kayıt saklama süreleri, erişim yetkisinin nasıl belgelendiği. Bunlar hukuki metinlerde soyut, sahada çok somut. Antalya yazılım ve turizm tarafında en sık gelen soru misafir verisinin nerede durduğu; sağlık tarafında ise kimin hangi kaydı görebildiği. İki soru da mimariyi doğrudan değiştiriyor. Sonradan eklenmiyor.
Beşinci soru sahadan çıkarılan dersler. Bir kurulumun ikinci ayında ortaya çıkan aksaklık, ilk gün yazılan plandan daha öğreticidir. Yedeğin geri dönmediği bir gece, bir ağ kesintisinin nasıl yayıldığı, bir güncellemenin neyi bozduğu — bunlar kimsenin övünmediği ama herkesin ihtiyaç duyduğu notlar. İstanbul yazılım tarafındaki projelerde çok lokasyonlu yapılar, bu dersleri en hızlı üreten ortam oluyor.
Altıncı bir soru daha var: ne zaman hiçbir şey yapmamak doğru? Her teknik şikâyetin karşılığında bir proje olması gerekmiyor. Bazı sistemler eski ama ayakta ve dokunmanın maliyeti dokunmamanın maliyetinden yüksek. Bunu söylemek bir yazılım şirketi için ticari olarak kârlı değil, okuyucu için doğru. Yenilemenin gerçekten gerektiği eşiği yazmak, yenilemeyi övmekten zor bir iş.
Beş sorunun ortak yanı şu: hiçbirinin cevabı tek kelimelik değil. "Hangisi daha iyi" sorusuna verilen tek kelimelik cevaplar koşulu atladıkları için yanlış. Bu yazılım blogu içinde bir kıyaslama yapılırken önce koşul yazılıyor, sonra sonuç. Sıra tersine döndüğünde metin reklama dönüşüyor. Okuyucu da kendi durumunu ancak koşul yazılıysa tanıyabiliyor.
Birincisi popülerliğe göre teknoloji seçmek. Bir aracın çok konuşuluyor olması, sizin işinize uyduğunu göstermez. Topluluk büyüklüğü faydalıdır; işin ömrü, ekibin bildiği dil ve bakımı kimin yapacağı ondan daha belirleyici. Beş yıl yaşayacak bir sistemi, iki yıl sonra kimsenin bakmayacağı bir moda üzerine kurmak pahalı bir tercih. Sıkıcı teknoloji çoğu zaman doğru teknolojidir.
İkincisi kıyaslama yapmadan taahhüt vermek. "Bu mimari bizim yükümüzü kaldırır" cümlesi ölçülmeden söylendiğinde bir temenni. Küçük bir yük testi, gerçek veriyle yapılmış bir deneme ya da bir günlük pilot kurulum, aylarca sürecek bir yanlıştan çok daha ucuz. Ölçüm yapmanın maliyeti neredeyse her zaman ölçüm yapmamanın maliyetinden düşük çıkıyor. Önce ölçün. Sonra söz verin.
Üçüncüsü bakım maliyetini hesaba katmamak. Kurulum tek seferlik, bakım süreklidir. Sürüm yükseltmeleri, güvenlik yamaları, sertifika yenilemeleri, yedek doğrulama ve izleme — hiçbiri ilk teklifte görünmez, hepsi ikinci yıldan itibaren gündelik iş hâline gelir. Bir sistemi seçerken sorulacak asıl soru şu: bunu on sekiz ay sonra kim güncelleyecek?
Dördüncüsü tek kişiye bağımlı sistem kurmak. Bir yapıyı yalnız bir kişi anlıyorsa, o yapı çalışsa bile kırılgandır. Şifreler bir yerde, kurulum mantığı bir başka yerde, kararların gerekçesi hiçbir yerde. Kişi ayrıldığında geriye dokunulmaya korkulan bir sistem kalır. Yazılı mimari, ortak erişim ve devredilebilir dokümantasyon; üçü de kurulum aşamasında ucuz, sonradan pahalıdır. Yazın. Bugün yazın.
Beşinci bir madde daha eklenebilir: bir sistemi çıkış planı olmadan seçmek. Veriyi dışarı almanın yolu yoksa, o tedarikçiyle olan ilişki teknik değil hukuki bir bağa dönüşür. Dışa aktarma biçimi ve veri sahipliği ilk gün konuşulmalı. Bir kurumsal yazılım şirketi ile çalışırken bunu sormak, sözleşmedeki her maddeden daha çok şey anlatır.
Altıncısı kararı tek masada almak. Sunucu tarafını bilen kişi ile uygulamayı yazan kişi aynı toplantıda değilse ortaya iki ayrı doğru çıkar ve ikisi birbirini bozar. Veritabanı seçimi bunun en net örneği — geliştirici için rahat olan yapı, sistem tarafı için bakımı zor olabiliyor. İstanbul yazılım projelerinde bu iki masayı erken birleştirmek, sonradan yapılacak göç işlerinin çoğunu baştan siliyor. Toplantı ucuz. Göç değil.
Bu hataların ortak kaynağı acele. Karar toplantısında en yüksek sesle savunulan seçenek kazanıyor, ölçüme vakit ayrılmıyor ve bakım tarafı "sonra bakarız" listesine düşüyor. İki hafta gecikmek pahalı görünür. İki yıl yanlış mimariyle yaşamak daha pahalı. Bir kararın geri alınabilir olup olmadığını sormak, çoğu zaman kararın kendisinden değerli. Geri alınabiliyorsa hızlı ilerleyin. Alınamıyorsa yavaşlayın.
Sunucu ve altyapı yatırımı ilk başlık. Ne zaman kiralamak, ne zaman satın almak mantıklı? Amortisman süresi, elektrik ve soğutma, yedek donanım, arıza anında geçiş planı. Kâğıt üzerinde ucuz görünen kiralamanın hangi yük profilinde pahalıya döndüğü ve tersi. Bu hesabın en can alıcı tarafı, kullanımın sabit mi dalgalı mı olduğu. Cevap değişince mimari de değişiyor.
İkinci başlık yapay zekâ modellerinin kendi donanımda çalıştırılması. Hangi model boyutu hangi bellekle çalışır, bir sorgunun gerçek gecikmesi nedir, dışarıya veri göndermeden ne kadarını halledebilirsiniz? Bu alanda pazarlama gürültüsü yüksek olduğu için ölçümlü yazı ihtiyacı da yüksek. Alanya yazılım ve altyapı ekibimizin son iki yıldaki en büyük yatırımı da tam bu başlıkta yapıldı.
Üçüncü başlık veri egemenliği ve KVKK. Verinin fiziksel olarak nerede durduğu, hangi ülkenin hukukuna tabi olduğu, alt yüklenicilerin kim olduğu ve bir denetimde nelerin belgelenmesi gerektiği. Yurt dışındaki bir servise gönderilen her istek, aynı zamanda bir hukuki soru. Bu yazılım blogu içindeki en teknik olmayan ama en çok sonuç doğuran konu başlığı bu.
Dördüncü başlık yedekleme mimarisi. Kaç kopya, kaç konum, kaç sürüm; geri dönüş hedefi ne kadar; tatbikat ne sıklıkla yapılıyor? Yedek almak kolay, geri yüklemek zordur ve aradaki fark ancak felaket anında öğrenilir. Beşinci başlık arama motoru görünürlüğü: teknik düzeltmelerin ne zaman okunmaya başladığı, iç bağlantı yapısı, sayfa hızının payı. Altıncısı ölçüm ve analitik — hangi verinin gerçekten karar değiştirdiği, hangisinin yalnız panoyu doldurduğu. Antalya yazılım ve otelcilik projelerinde bu iki başlık genelde birlikte gündeme geliyor.
Yedinci başlık ağ ve erişim tarafı: misafir ağının ayrılması, kayıt yükümlülükleri, uzaktan çalışan personelin bağlantısı. Sekizincisi sıkıcı görünen ama en çok soru gelen konu — dosya paylaşımı ve ortak çalışma alanı. Kimin hangi klasöre eriştiği, sürüm çakışmalarının nasıl çözüldüğü, verinin şirket dışına çıkmadan paylaşılabilmesi. Alanya yazılım ekibimizin kendi günlük işini de aynı yapı üzerinde yürütmesi yazılara doğrudan yansıyor: kullanmadığımız bir kurulumu tavsiye etmiyoruz. Bir yazılım blogu için en sağlam ölçüt bu olsa gerek.
Şu an yayında olan yazı Yapay Zeka Sunucu Yatırımı: 1.000.000 TL'lik Mac Studio Filosu başlığını taşıyor. İçeriği bir duyuru gibi başlıyor, gerekçe bölümünde başka bir şeye dönüşüyor: müşteri verisinin dışarıya çıkmaması ve dışa bağımlı yapay zekâ kullanımının sıfıra indirilmesi için kendi donanımımıza yatırım yapıldı. İki Mac Studio, iki ayrı iş yükü için yapılandırıldı.
Yazının değerli kısmı rakam değil, gerekçe zinciri. Neden kiralamak yerine satın alma? Hangi model hangi bellekle çalıştırılıyor, hangi iş yükü hangi makineye düşüyor, bu kararın geri dönüşü nasıl hesaplandı? Bir müşterinin sözleşmesinde "veriler yurt dışına çıkmayacak" maddesi varsa, o madde bir cümle değil bir donanım faturasıdır. Yazı tam olarak bunu anlatıyor.
Bu tür bir yatırımın herkese uyduğunu söylemiyoruz. Kendi donanımında model çalıştırmak elektrikten soğutmaya, yedek parçadan nöbet planına uzayan bir sorumluluk zinciri getiriyor; küçük ölçekte kiralamak hâlâ daha akıllıca. Karar, işlenen verinin hassasiyetine ve kullanım yoğunluğuna bakılarak veriliyor. Antalya yazılım tarafındaki bir otel için doğru olan çözüm ile bir hukuk bürosu için doğru olan çözüm aynı değil. Bir kurumsal yazılım şirketi olarak kendi kararımızı yazmamızın sebebi tavsiye vermek değil, gerekçeyi görünür kılmak.
Yazının içinde bir tablo var. İki makine, iki çip, iki bellek yapılandırması ve her birine düşen iş yükü. Okunması iki dakika süren, arkasında haftalarca hesap olan türden bir tablo. Hangi model hangi bellekte sığıyor, hangi iş gece hangisi gündüz çalışıyor, elektrik ve soğutma tarafı nereye oturuyor. Özü şu: yatırım duyurusu değil, kapasite planı. Rakamı görmek isteyen rakamı bulur. Asıl mesele rakamın altındaki hesap.
Aynı yazı İngilizce olarak da yayımlandı; yurt dışındaki iş ortaklarımızın aynı gerekçe zincirini okuyabilmesi için. Yeni yazılar takvimle değil, anlatmaya değer bir karar çıktığında yayımlanıyor. Bir yazılım blogu için haftalık yayın sözü vermek kolay; o sözü tutmak için içerik uydurmak da kolay. İkisini de yapmıyoruz.