Kitaplığımı nasıl bir web sitesine dönüştürdüm — ve asıl işin neden yazılım olmadığını nasıl fark ettim

Kitaplık büyürken insanın kitaplarla ilişkisi sessizce değişiyor. İlk yüz kitapta hangi kitabın nerede olduğunu bilirsin. İkinci yüzde tahmin edersin. Üçüncü yüzde artık aramaya çıkarsın — ve çoğu zaman kitabı bulduğunda onu aramaya başlama sebebini unutmuş olursun.
Benim durumumda mesele raf düzeyinde de kalmıyordu. Kitapların bir kısmı evde, bir kısmı fakültedeki odamda, çocuk kitapları ayrı bir yerde duruyordu; buna yıllar içinde biriktirdiğim 33 GB’lık e-kitap arşivi ekleniyordu. Dört ayrı yerde, dört ayrı mantıkla duran bir koleksiyon. Sonucu şu oluyordu: bir kitabı evde bulamıyorum, odamda mı emin olamıyorum, e-book’u var mıydı hatırlamıyorum. Kitapçıda “bu bende var mıydı” sorusuna dürüstçe cevap veremiyorum.
Bu yazı, o soruna verdiğim cevabın hikâyesi. Ama önce en can alıcı kısmından başlayayım, çünkü projenin asıl mümkün kılıcısı orası.
Asıl mesele yazılım değildi: veriyi nasıl girersiniz?
Böyle bir projeyi düşünen herkesin karşısına çıkan ilk duvar şu: kitapları listeye kim girecek?
Üç yüz kitabı elle yazmak bir hafta sonunu yer. Barkod okutmak eski kitapların çoğunda işe yaramaz; benim rafımda ISBN’i olmayan, barkodu silinmiş, 1990’lardan kalma baskılar var. Kitabı tek tek eline alıp fotoğraflamak ise elle yazmaktan daha zahmetli.
Ben bambaşka bir yol denedim ve işe yaradı: rafın toplu fotoğrafını çektim. Sadece fotoğrafı. Sonra bu fotoğrafı Gemini’ye verip “bu görseldeki her kitabın yazarını, adını ve yayınevini tablo hâlinde çıkar” dedim.
Çıkardı.
Çok kipli yapay zekânın akademisyen için en somut faydalarından biri, hiç dijitalleştirilmemiş kişisel arşivi tek seferde dijitalleştirebilmesi.
Şunu somutlaştırayım. Yukarıdaki raf fotoğrafında Cem Yayınevi’nin beş ciltlik Türkiye Tarihi takımı, İlber Ortaylı’nın üç kitabı, Yavuz Selim Karakışla’nın Eski İnsanlar Eski Cemiyetler‘i, Zafer Toprak’ın Türkiye’de Yeni Hayat‘ı, Ötüken’den Yahya Kemal Taştan, İsmail Küçükkılınç ve Mehmet Kaan Çalen’in çalışmaları, en sağda da Donald Quataert’in Osmanlı İmparatorluğu 1700–1922‘si duruyor. Model bunların hepsini doğru okudu — üstelik sırtlar dikey, yazılar yan yatmış, bazılarında yazar adı üstte bazılarında altta, bazılarında hiç yok.

Bu işin ne kadar zor olduğunu takdir etmek için bir kitap sırtına dikkatle bakmak yeterli. Sırtta ne “yazar” etiketi vardır ne “yayınevi”. Sadece farklı puntolarda birkaç satır metin ve altta bir logo. Hangisinin başlık hangisinin alt başlık olduğunu, hangi ismin yazara hangisinin derleyene ait olduğunu tipografiden ve konumdan çıkarmak gerekir. Yayınevi çoğu zaman hiç yazmaz; sadece amblem vardır — Cem’in kuşu, Ötüken’in çiçeği, Doğan Kitap’ın harfleri. Model bu logoları tanıyıp yayınevi sütununu doldurdu.
Bunu bir yöntem olarak söylüyorum. Kitaplık burada sadece bir örnek; aynı işlem fişlenmemiş bir dosya dolabı, taranmamış bir belge yığını, elle tutulmuş bir defter için de geçerli.
Sonuçta elimde şu sütunlarla bir Excel tablosu oluştu: Raf No, Yazar / Derleyen, Kitap İsmi, Yayınevi. Projenin geri kalanı bu tablonun etrafında kuruldu.
Birinci aşama
Tablodan arayüze
Excel bir envanter deposudur, envanter arayüzü değildir. Telefonda açmak, filtrelemek, yatay kaydırmak — her biri küçük ama caydırıcı bir sürtünme. Sürtünmesi olan hiçbir kayıt sistemi kullanılmaz; sistem doğru kurulmuş olsa bile.
İstediğim şey tek cümleyle ifade edilebiliyordu: bir arama kutusu. Yazarın soyadını yaz, eşleşen kitaplar kalsın, gerisi kaybolsun. Kutuyu boşalt, bütün liste geri gelsin.
İlk sürüm tam olarak buydu: tek bir HTML dosyası, üstte arama çubuğu, altta liste. Kırk dakikalık bir iş.

İlk kullanımda ilk kusur da çıktı. “ilber” yazınca İlber Ortaylı gelmiyordu. Türkçede büyük-küçük harf dönüşümü İngilizcedeki gibi davranmaz; i/İ ve ı/I çiftleri karşılaştırmayı sessizce bozar. Aramaya Türkçe karakterleri eşitleyen bir katman ekledik — ç/c, ş/s, ğ/g, ü/u, ö/o, ı/i. Bu küçük düzeltme, sitenin en çok işe yarayan özelliği oldu. Çünkü kimse telefonda doğru harfle yazmıyor.
İkinci aşama
Raf şeridi: veriyi mekâna geri bağlamak
Arama çalışıyordu ama bir şey eksikti. Site bana kitabın var olduğunu söylüyordu, nerede olduğunu değil. Oysa benim sorum en başından beri ikincisiydi.
Listenin üstüne bir raf şeridi koyduk: her rafı kendi renginde bir blok olarak gösteren, rafın kaç kitap taşıdığını genişliğiyle anlatan yatay bir bant. Bir bloğa dokununca liste o rafa iniyor. Raflara etiket ve not eklenebiliyor.

Şeritten önce elimde bir arama motoru vardı; şeritten sonra bir envanter oldu.
Bu eklemeden sonra ekrandaki nesne bir tablo olmaktan çıkıp kitaplığın şematik bir haritasına dönüştü. Buradan çıkardığım ders şu: veriyi görselleştirmek süs değil, çoğu zaman sorunun kendisini yeniden tanımlamaktır.
Üçüncü aşama
Veri nereden gelecek?
Kitapları koda gömmek ilk gün için pratik, ikinci hafta için felakettir. Her yeni kitapta dosyayı açıp elle satır eklemek anlamsızdı. Üç yol denedik.
Koda gömülü liste hızlıydı ama her güncelleme bir kod müdahalesi demekti. Tarayıcıdan Excel yüklemek çalışıyordu ama liste sadece o tarayıcıda saklanıyordu — telefonda güncel, bilgisayarda eski. Üçüncü yol kazandı: Google E-Tablolar bağlantısı. Tabloya kitabı ekliyorum, site bir sonraki açılışta oradan okuyor. Tek kaynak, her cihazda aynı liste.
Bu tercih birkaç teknik problemi beraberinde getirdi ve her biri öğreticiydi. Sheets’in “web’de yayımla” adresi güncellemeleri dakikalar sonra yansıtıyordu; normal paylaşım bağlantısını farklı bir uç noktaya çevirmek ise saniyeler içinde. Site artık yapıştırılan adresi kendisi doğru biçime dönüştürüyor. Dosyayı bilgisayarda çift tıklayarak açtığımda tarayıcı dış adrese erişimi engelliyordu; buna karşı ikinci bir çekme yolu eklendi.
Bir de şu vardı: internet yoksa ne olacak? Her başarılı çekişte veri yerel olarak saklanıyor, bağlantı kurulamazsa site son kopyayla açılıyor. Ama sessizce değil — üstte “bağlanamadı · 2 sa önceki kopya” uyarısı çıkıyor. Bunda ısrar ettim.

Bir sistem eski veri gösteriyorsa bunu söylemek zorundadır. Sessizce eski veri gösteren araç, hiç çalışmayan araçtan tehlikelidir.
Dördüncü aşama
Bir kitaplıktan dörde
Ofisteki kitapları da eklemek istediğimde asıl mimari soru çıktı: bunlar aynı listenin bir sütunu mu, yoksa ayrı listeler mi?
Ayrı listeler oldu — çünkü fiziksel olarak ayrılar ve her biri kendi tablosundan besleniyor. Ama arama hepsini birden tarıyor. Kategori sekmeleri bir süzgeç; arama ise evrensel. Bir kitabı ararken önce nerede olduğunu bilmem gerekmiyor, zaten sorum bu.
Kategori sayısı zamanla dörde çıktı: Ev, Ofis, Aybike (çocuk kitapları) ve E-Kitap — sonuncusu OneDrive’daki e-kitap arşivinin listesi.

E-Kitap kategorisi ayrı bir çıkmaz üretti: OneDrive paylaşım bağlantıları site için okunabilir veri döndürmüyor. Çözüm teknik değil örgütsel oldu; e-kitapların envanterini de Google E-Tablolar’a taşıdım. Sistemin diline uymayan bir kaynağı zorlamak yerine kaynağı sistemin diline çevirmek çok daha ucuz çıktı. Bu, yazılımdan çok yöntem meselesi.
Beşinci aşama
Dört bin satırda ne kırılıyor?
E-Kitap listesi eklenince satır sayısı 4.000’i geçti ve site takılmaya başladı. İki ayrı darboğaz vardı.
Raf sayımı karesel çalışıyordu: her raf için bütün liste baştan taranıyordu. 280 kitapta görünmeyen bu maliyet, 4.000 kitapta felç edici hâle geldi. Tek geçişte sayan bir yapıyla değiştirdik. İkincisi, bütün kartların bir kerede çizilmesiydi; sayfalı çizime geçtik — her seferinde 300 kart, sayfa sonuna gelindiğinde gerisi sessizce yükleniyor.
Küçük veriyle yazılmış kod yanlış değildir, sadece ölçek varsayımı gizlidir. Varsayım değiştiğinde kırılan şey kod değil, o gizli varsayımdır.
Bunun akademik çalışmadaki karşılığını düşünmemek elde değil.
Altıncı aşama
Bir açık kapı hikâyesi
Kaynak adreslerini ve raf notlarını değiştiren bir yönetim paneli ekledik; kullanıcı adı ve parolayla, parola düzgün biçimde özetlenip saklanacak şekilde. Ancak bir düzenleme sırasında panel açma fonksiyonuna test için konulmuş if(false) satırı orada unutuldu ve kimlik kontrolünü tamamen devre dışı bıraktı. Panel bir süre boyunca herkese açıktı.
Bunu yazıyorum çünkü bu tür açıkların çoğu kötü tasarımdan değil, geçici çözümün kalıcılaşmasından doğuyor. Test için konulan satır silinmeyi bekliyor, kimse beklemediği için orada kalıyor. Aynı mekanizmayı makale taslaklarında da görürüz: “burayı sonra düzeltirim” notu, yayımlanmış metinde durur.
Yedinci aşama
Yayına çıkmak
Site GitHub Pages’e taşındı. Kendi logomdan bir favicon ve uygulama simgesi üretildi, bağlantı paylaşımında düzgün önizleme çıkması için etiketler eklendi, çevrimdışı açılabilmesi sağlandı. Telefona ana ekrandan eklenince uygulama gibi çalışıyor.

Bu noktada gerçek bir Android uygulaması yazmayı da düşündüm. Tek ayırt edici özelliği barkod/ISBN taraması olacaktı. Ama tabloya kitabı elle eklemek zaten zahmetli bir iş değil — hele raf fotoğrafından toplu çıkarma yöntemi varken. Yerli uygulamanın tek gerekçesi ortadan kalkınca proje orada durdu. Yapılmayan iş de bir karardır ve kaydedilmeyi hak eder.
Geriye dönüp bakınca
Kısıt verimliydi. Bütün proje tek bir HTML dosyası olarak kaldı: ayrı stil dosyası yok, derleme adımı yok, bağımlılık yönetimi yok. Bu kısıt bazı şeyleri imkânsız kıldı ama projeyi taşınabilir yaptı. Dosyayı bir yere koyuyorsun, çalışıyor. Kişisel araçlarda bakım maliyeti, özellik zenginliğinden daha belirleyicidir.
Veriyi arayüzden ayırmak asıl kazançtı. Kitap listesi kodun içinde kalsaydı proje ilk ayında ölürdü. Kaynağı Google E-Tablolar yapmak, envanteri güncellemeyi “yazılım işi” olmaktan çıkarıp gündelik bir işe indirdi. Bir aracın yaşayıp yaşamayacağını belirleyen şey, güncellemenin ne kadar sıkıcı olduğudur.
Ve en başa dönersek: bu proje aslında bir yazılım projesi değil, bir veri girişi projesiydi. Arayüzü kurmak birkaç oturum sürdü; asıl duvar üç yüz kitabın tabloya nasıl gireceğiydi. O duvarı bir fotoğraf makinesi ve bir dil modeli aştı. Yapay zekâ araçlarının akademik hayattaki değerini tartışırken çoğu zaman metin üretimine odaklanıyoruz. Oysa benim için en somut fayda burada oldu.
Daha önce hiç dijitalleştirilmemiş olanı dijitalleştirmek.