İnsanların kullandığı tarayıcıların sayısı zaten çok fazla değilken framework neden bu kadar çok? Tarayıcıları yöneten şirketlerin en iyi framework’ü yapıp onu da birlikte yönetmesi en iyi çözüm olmaz mı? Bu kısır döngüyü daha ne kadar sürdüreceğiz.
Ortaya konan tespitlere katılıyorum ama sonuca katılmıyorum.
Bu durumun yüzeydeki nedeni, yazıda da belirtildiği gibi, "uygulama gibi web"e olan talebin artmış olması.
Hem şimdi hem de o zaman web, "uygulama gibi bir şey" yapmak için çok uygun değildi; ama epey zorlayınca "benzerini yapmak mümkün" olan bir yapıdaydı diye düşünüyorum.
Aslında web’in doğuş amacı, tezler gibi bir tür "belge"yi paylaşmak için oluşturulmuş bir platform olmasıdır.
Bunu HTML’in temel bileşenlerine bakınca da anlayabilirsiniz.
Sonra CGI gibi dinamik içerik üretebilen teknolojiler ortaya çıktı, tarayıcı tarafına da script dilleri gömülünce ortaya çıkan sonuca dinamizm katmak mümkün oldu ve "belge olarak web" anlayışından uzaklaşma başladı.
Sorun şu ki, bu ilk kopuş anından bugüne kadar web’in temeli hâlâ "belge" tabanlı bir sistem.
Elbette WebSocket, WebRTC, WASM gibi "belge" yöneliminden uzak yeni teknolojiler çokça çıktı; ama bugün hâlâ web sitelerinin büyük çoğunluğu mevcut "belge" tabanlı platforma dayanarak geliştiriliyor.
Hâlâ ekran çizmek için div etiketlerini üst üste koymak zorundayız.
Buraya kadar durum tespiti; peki çözüm ne diye düşününce,
gerçekçilik gibi şeyleri hiç hesaba katmadan ideal bir sonraki platformun işlevlerini hayal edersem şöyle olurdu.
(Bunun tüm siteler için geçerli olması gerektiğini söylemiyorum; yalnızca uygulama niteliği taşıyan siteler için.)
Öncelikle tarayıcı bir tür uygulama başlatıcısı olurdu.
Bir kez indirildikten sonra çevrimdışı da çalışabilmesi gerekirdi.
Ve uygulama, mevcut html/css/js üçlüsünden çıkarak başka dillerle geliştirilirdi.
Bu süreçte Android’de olduğu gibi tarayıcı da bir tür framework sağlayabilirdi.
Sunucuyla iletişim biçimi de mevcut web isteklerinin dışına çıkıp başka bir paradigma kullanabilirdi.
Gerçek zamanlılık gerektiren iletişimde mevcut TCP iletişimi olduğu gibi kullanılabilir,
HTTP protokolünü kullanmayan daha basit bir RPC iletişimi de yeni baştan tasarlanıp kullanılabilirdi.
Bir ay önce, hem CURSOR kullanarak AI coding’in ne olduğunu öğrenmek hem de geliştirme framework’ü geliştirmeye başlamak için işe koyuldum.
Yaklaşık 3 hafta boyunca, başarıyla ilerlerken AI Agent tarafından doğrulanmış kaynak kodun tekrar tekrar bozulduğunu gördüm; AI Agent’ı kontrol etmek için her türlü yöntemi denedim ama başarısız oldum.
Sonra, geliştirme framework’ünü geliştirmeden önce önceliğin AI Agent’ı kontrol eden kaynak kodu geliştirmek olduğunu fark ettim.
Sonuç olarak, ilk AI’nin ne olduğunu anlamak için başlamamın üzerinden tam 1 ay geçtikten sonra, AI Agent’ı tamamen kontrol edebilen (daha doğrusu harici LLM ya da AI Agent’a ihtiyaç duymayan), yapay zeka tarafından %100 geliştirilebilen ve %100 işletilebilen bir yazılımı tamamlamayı başardım.
Şu anda 14. gündeyim; ek iyileştirmeler için bu META AI’yi yeniden eğitip operasyon kuralları oluşturarak bunlara uymasını sağlama sürecini yürütüyorum. Aynı zamanda, daha önce insanlar tarafından eksik şekilde yapılmış 3 MES sistemini eşzamanlı olarak migrate edip iyileştiriyor ve standardize ediyorum; çalışma artık son aşamaya girmiş durumda.
MCP-B teknolojisinin temel vizyonunun şu olduğu söylenebilir.
"Güvenilir bir aracı olan Chrome uzantısı (Extension) üzerinden, tarayıcının zaten güvenli şekilde yönettiği kullanıcı bilgilerini (çerezler, oturum, kimlik doğrulama vb.) kullanarak,
web sayfasında geliştiricinin önceden tanımladığı 'araçları (Tools)' AI sohbet penceresinden doğal dil komutlarıyla çağırıp kontrol etmek."
Ancak ben bunun "ölçeklenme ihtimali pek yokmuş gibi göründüğünü" düşünüyorum ve nedenleri de şöyle.
Kullanıcı direnci: En büyük eşik bu. Kullanıcılar, kendi tarayıcı bilgilerine erişen bir uzantıyı kurma konusunda içgüdüsel bir direnç ve güvenlik kaygısı taşıyor. Bu teknolojinin sunduğu kolaylık, bu kaygıları aşacak kadar ezici değilse, kullanıcılar kurulumu erteleyecektir.
Web geliştiricisinin yükü: Web sitesi geliştiricileri, mevcut API'leri oluşturmanın yanı sıra MCP-B için 'araçları (Tools)' ayrıca tanımlayıp yönetmek gibi ek bir yük üstlenmek zorunda kalacak. Bu teknoloji yaygın biçimde benimsendiğinde elde edilecek fayda büyük değilse, geliştiriciler durduk yere bu çifte çabayı harcamak istemeyecektir.
Güvenlik sorunlarında sorumluluğun kime ait olduğu: Bu teknoloji üzerinden bir güvenlik olayı yaşanırsa sorumluluğun web sitesi geliştiricisinde mi, uzantı geliştiricisinde mi, yoksa AI model sağlayıcısında mı olduğu belirsizleşebilir. Bu tür bir karmaşıklık, şirketlerin teknolojiyi benimsemekten kaçınmasına yol açar.
Merkezi bir platformun yokluğu: Şu anda "hangi web sitesinin hangi araçları sunduğunu" gösteren standartlaştırılmış bir dizin ya da platform yok. Kullanıcıların, bir web sitesini ziyaret etmeden önce hangi AI işlevlerini kullanabileceklerini bilmesi zor.
Sonuç olarak,
MCP-B fikrinin kendisi teknik olarak son derece ilgi çekici ve yenilikçi olsa da, hem kullanıcılar hem de geliştiriciler için "neden özellikle bu yöntemi kullanmak gerekiyor?" sorusuna net bir yanıt veremeyecek gibi görünüyor. Mevcut API yaklaşımına kıyasla sağladığı avantajlar belirsizken, güvenlik kaygısı ve geliştirme karmaşıklığı gibi dezavantajları açıkça ortada.
Bu nedenle, şimdilik bu teknoloji bazı meraklılar ya da belirli amaçlara sahip geliştiriciler arasında deneysel olarak kullanılabilir; ancak web ekosisteminin geneline yayılması için aşılması gereken çok sayıda zorluk var gibi görünüyor.
Bu yazının temel meselesine katılıyorum, ancak bazı kısımlarda insanın biraz durup düşündüğü noktalar da var.
Örneğin, şirketimiz tarafından işletilen belirli bir hizmeti tanıtan web sitesi, tam da bu yazıda övülen türden bir sadeliği koruyor. Neyse ki bu web sitesinin unsurlarının çoğu yeterince statik. Frontend tarafındaki HTML ve CSS gibi kodlar herhangi bir framework olmadan doğrudan insanlar tarafından elle yazılmış, JS olarak da yalnızca jQuery ve Google Analytics bulunuyor. Duyurular veya ilan panosu gibi bölümler jQuery kullanan AJAX ile gerçekleştirilmiş olsa da, bunun mantıksız ya da aşırı karmaşık bir düzeyde olduğunu düşünmüyorum. Ben web geliştirmeye uzun zaman önce giriş yaptığımda bunun jQuery tabanlı olarak gerçekleştirilebilecek bir seviyede olduğunu düşünürdüm. Bildiğim kadarıyla bu site Internet Explorer döneminden beri işletiliyordu, yani ben doğrudan yapmadım, ama bence hiç de fena değil.
Ama burada Git sürüm yönetimi ve CI/CD pipeline'ı da var; staging sunucusu ile gerçek production sunucusu birbirinden ayrılmış durumda. main branch'ine bir Pull Request merge edildiğinde pipeline, bundler'ın ürettiği çıktıları staging sunucusuna otomatik olarak deploy ediyor; sorumlu kişi staging sunucusunu kontrol edip dağıtımı nihai olarak onayladıktan sonra bu kez production sunucusuna deploy ediliyor. Geçmişte ise sadece FTP üzerinden kaynak dosyaları doğrudan production sunucusunda ezerek güncelleme yapılıyordu; ilgili iş bizim ekibe geçtikten sonra bunu bu şekilde değiştirdik.
Bu gerçekten mantıksız bir karmaşıklık mı? Geçmişte bu web sitesinin başlık etiketini düzeltmek, FTP bağlantısını destekleyen AcroEdit (evet, o sitenin HTML'ini doğrudan yazan kişiler hâlâ bunu kullanıyordu) ile production sunucusundaki HTML dosyasına girip tek satır değiştirerek kaydetmekle biten bir işti; o kişiler muhtemelen bunu böyle hissedebilir.
Ama bana göre bu düzeyde bir karmaşıklık eklemesi gayet katlanılabilir bir şeydi. Sonuçta yapılan her iş yalnızca bir başlık etiketini düzenlemek kadar basit değil. Ayrıca eski kodların yorum satırına alınarak üst üste birikmesi yerine, istendiğinde geri döndürülebileceği için hiç çekinmeden tamamen silinebilmesi; değişikliklerin şeffaf şekilde izlenebilmesi ve rollback yapılabilmesi; bundler sayesinde gerekirse biraz daha temel optimizasyonların eklenebilmesi bence yeterince büyük avantajlar. Gerçek ortama deploy edilmeden önce önizleme yapılabilen bir staging sunucusu eklemek de bir bakıma karmaşıklık sayılabilir, ama ben bunun gerekli olduğunu düşünüyorum.
Ben de çeşitli web sitelerinin iç kod yapısının aşırı karmaşık ve ağır hâle gelmesinden epey rahatsızım. Bugünlerde Windows'taki Outlook uygulaması web app tabanlı, ama son zamanlarda özellikle daha da ağırlaştı. Ekranda sadece e-posta gövdesi yazmak ya da gövdenin tamamını seçmek bile takılmaya neden oluyor, hatta bazen "sayfa yanıt vermiyor" noktasına geliyor. Neden böyle diye merak edip web Outlook'ta geliştirici araçlarını açtığımda gerçekten şaşırdım. Bir kez cache'i temizleyip sayfayı yeniledim, 1 dakika sonra bile hâlâ bir sürü istek akmaya devam ediyordu. Tarayıcıdan baktığımda yalnızca MS Office sitesiyle ilgili birkaç gigabayt veri depolanmış olduğunu gördüm.
Ama bu yazı birçok şeyi birbirine karıştırıyor; bazı kısımlarına katılıyorum ama bazı kısımlarına pek katılamıyorum. Semantik HTML ya da erişilebilirlik konusunda geçmişin aslında daha da korkunç olduğunu biliyorum. Üstelik geliştirici deneyiminin iyileşmesinin kullanıcı deneyimini kötüleştirdiği iddiasına, web frontend geliştiricisi olmadığım için mi bilmiyorum ama hiç katılamıyorum. Hatta bütün güç ve kontrolün geliştiricilerde toplandığını söylemek bana saçma geliyor. Şirketlerde güç yönetimde değil mi? Yoksa Batı'da şirket yapısı Kore'dekinden biraz farklı mı?
Her zaman olduğu gibi denge ve itidal, sadelik ve pratiklik önemli değerlerdir ve karar verirken bunlara öncelik verilmesi gerektiğine tamamen katılıyorum. Ama bu yazı, "tüm web sitelerine birer yazılım ürünü gibi davranılması"nı sanki bütünüyle geliştiricilerin sorumluluğuymuş gibi öne sürüyor; bence bu da asıl meseleye dair farkındalığı bulanıklaştırıyor. Ayrıca sistemli olmayan o 'eski güzel günler'i yüceltiyor gibi görünen kısımlar da bence eleştirilmeli.
Benimsedikleri geliştirme felsefeleri birbirinden çok farklı, o yüzden.........
Görünen o ki yapay zeka da tarafsız değil.
Çok korkutucu.
Kötü niyetle kaydedilmiş kayıtların,
hafızayı ve deneyimi bastırıp kanıta dönüşerek
bizi tehdit edebilecek olması.
İnsanların kullandığı tarayıcıların sayısı zaten çok fazla değilken framework neden bu kadar çok? Tarayıcıları yöneten şirketlerin en iyi framework’ü yapıp onu da birlikte yönetmesi en iyi çözüm olmaz mı? Bu kısır döngüyü daha ne kadar sürdüreceğiz.
Neden iptal olduğunu merak ediyorum.
Kullanıcıya yağcılık yapan yapay zekanın nihai biçimi, meğer patrona yağcılık yapan yapay zekaymış...
Ortaya konan tespitlere katılıyorum ama sonuca katılmıyorum.
Bu durumun yüzeydeki nedeni, yazıda da belirtildiği gibi, "uygulama gibi web"e olan talebin artmış olması.
Hem şimdi hem de o zaman web, "uygulama gibi bir şey" yapmak için çok uygun değildi; ama epey zorlayınca "benzerini yapmak mümkün" olan bir yapıdaydı diye düşünüyorum.
Aslında web’in doğuş amacı, tezler gibi bir tür "belge"yi paylaşmak için oluşturulmuş bir platform olmasıdır.
Bunu HTML’in temel bileşenlerine bakınca da anlayabilirsiniz.
Sonra CGI gibi dinamik içerik üretebilen teknolojiler ortaya çıktı, tarayıcı tarafına da script dilleri gömülünce ortaya çıkan sonuca dinamizm katmak mümkün oldu ve "belge olarak web" anlayışından uzaklaşma başladı.
Sorun şu ki, bu ilk kopuş anından bugüne kadar web’in temeli hâlâ "belge" tabanlı bir sistem.
Elbette WebSocket, WebRTC, WASM gibi "belge" yöneliminden uzak yeni teknolojiler çokça çıktı; ama bugün hâlâ web sitelerinin büyük çoğunluğu mevcut "belge" tabanlı platforma dayanarak geliştiriliyor.
Hâlâ ekran çizmek için
divetiketlerini üst üste koymak zorundayız.Buraya kadar durum tespiti; peki çözüm ne diye düşününce,
gerçekçilik gibi şeyleri hiç hesaba katmadan ideal bir sonraki platformun işlevlerini hayal edersem şöyle olurdu.
(Bunun tüm siteler için geçerli olması gerektiğini söylemiyorum; yalnızca uygulama niteliği taşıyan siteler için.)
Öncelikle tarayıcı bir tür uygulama başlatıcısı olurdu.
Bir kez indirildikten sonra çevrimdışı da çalışabilmesi gerekirdi.
Ve uygulama, mevcut html/css/js üçlüsünden çıkarak başka dillerle geliştirilirdi.
Bu süreçte Android’de olduğu gibi tarayıcı da bir tür framework sağlayabilirdi.
Sunucuyla iletişim biçimi de mevcut web isteklerinin dışına çıkıp başka bir paradigma kullanabilirdi.
Gerçek zamanlılık gerektiren iletişimde mevcut TCP iletişimi olduğu gibi kullanılabilir,
HTTP protokolünü kullanmayan daha basit bir RPC iletişimi de yeni baştan tasarlanıp kullanılabilirdi.
Vay canına, anlaşılan WindSurf'ün geleceği de pek parlak görünmüyor.
Bir ay önce, hem CURSOR kullanarak AI coding’in ne olduğunu öğrenmek hem de geliştirme framework’ü geliştirmeye başlamak için işe koyuldum.
Yaklaşık 3 hafta boyunca, başarıyla ilerlerken AI Agent tarafından doğrulanmış kaynak kodun tekrar tekrar bozulduğunu gördüm; AI Agent’ı kontrol etmek için her türlü yöntemi denedim ama başarısız oldum.
Sonra, geliştirme framework’ünü geliştirmeden önce önceliğin AI Agent’ı kontrol eden kaynak kodu geliştirmek olduğunu fark ettim.
Sonuç olarak, ilk AI’nin ne olduğunu anlamak için başlamamın üzerinden tam 1 ay geçtikten sonra, AI Agent’ı tamamen kontrol edebilen (daha doğrusu harici LLM ya da AI Agent’a ihtiyaç duymayan), yapay zeka tarafından %100 geliştirilebilen ve %100 işletilebilen bir yazılımı tamamlamayı başardım.
Şu anda 14. gündeyim; ek iyileştirmeler için bu META AI’yi yeniden eğitip operasyon kuralları oluşturarak bunlara uymasını sağlama sürecini yürütüyorum. Aynı zamanda, daha önce insanlar tarafından eksik şekilde yapılmış 3 MES sistemini eşzamanlı olarak migrate edip iyileştiriyor ve standardize ediyorum; çalışma artık son aşamaya girmiş durumda.
Ve şimdi bir başka evrime daha hazırlanıyorum.
MCP-B teknolojisinin temel vizyonunun şu olduğu söylenebilir.
"Güvenilir bir aracı olan Chrome uzantısı (Extension) üzerinden, tarayıcının zaten güvenli şekilde yönettiği kullanıcı bilgilerini (çerezler, oturum, kimlik doğrulama vb.) kullanarak,
web sayfasında geliştiricinin önceden tanımladığı 'araçları (Tools)' AI sohbet penceresinden doğal dil komutlarıyla çağırıp kontrol etmek."
Ancak ben bunun "ölçeklenme ihtimali pek yokmuş gibi göründüğünü" düşünüyorum ve nedenleri de şöyle.
Sonuç olarak,
MCP-B fikrinin kendisi teknik olarak son derece ilgi çekici ve yenilikçi olsa da, hem kullanıcılar hem de geliştiriciler için "neden özellikle bu yöntemi kullanmak gerekiyor?" sorusuna net bir yanıt veremeyecek gibi görünüyor. Mevcut API yaklaşımına kıyasla sağladığı avantajlar belirsizken, güvenlik kaygısı ve geliştirme karmaşıklığı gibi dezavantajları açıkça ortada.
Bu nedenle, şimdilik bu teknoloji bazı meraklılar ya da belirli amaçlara sahip geliştiriciler arasında deneysel olarak kullanılabilir; ancak web ekosisteminin geneline yayılması için aşılması gereken çok sayıda zorluk var gibi görünüyor.
Bu yazının temel meselesine katılıyorum, ancak bazı kısımlarda insanın biraz durup düşündüğü noktalar da var.
Örneğin, şirketimiz tarafından işletilen belirli bir hizmeti tanıtan web sitesi, tam da bu yazıda övülen türden bir sadeliği koruyor. Neyse ki bu web sitesinin unsurlarının çoğu yeterince statik. Frontend tarafındaki HTML ve CSS gibi kodlar herhangi bir framework olmadan doğrudan insanlar tarafından elle yazılmış, JS olarak da yalnızca jQuery ve Google Analytics bulunuyor. Duyurular veya ilan panosu gibi bölümler jQuery kullanan AJAX ile gerçekleştirilmiş olsa da, bunun mantıksız ya da aşırı karmaşık bir düzeyde olduğunu düşünmüyorum. Ben web geliştirmeye uzun zaman önce giriş yaptığımda bunun jQuery tabanlı olarak gerçekleştirilebilecek bir seviyede olduğunu düşünürdüm. Bildiğim kadarıyla bu site Internet Explorer döneminden beri işletiliyordu, yani ben doğrudan yapmadım, ama bence hiç de fena değil.
Ama burada Git sürüm yönetimi ve CI/CD pipeline'ı da var; staging sunucusu ile gerçek production sunucusu birbirinden ayrılmış durumda.
mainbranch'ine bir Pull Request merge edildiğinde pipeline, bundler'ın ürettiği çıktıları staging sunucusuna otomatik olarak deploy ediyor; sorumlu kişi staging sunucusunu kontrol edip dağıtımı nihai olarak onayladıktan sonra bu kez production sunucusuna deploy ediliyor. Geçmişte ise sadece FTP üzerinden kaynak dosyaları doğrudan production sunucusunda ezerek güncelleme yapılıyordu; ilgili iş bizim ekibe geçtikten sonra bunu bu şekilde değiştirdik.Bu gerçekten mantıksız bir karmaşıklık mı? Geçmişte bu web sitesinin başlık etiketini düzeltmek, FTP bağlantısını destekleyen AcroEdit (evet, o sitenin HTML'ini doğrudan yazan kişiler hâlâ bunu kullanıyordu) ile production sunucusundaki HTML dosyasına girip tek satır değiştirerek kaydetmekle biten bir işti; o kişiler muhtemelen bunu böyle hissedebilir.
Ama bana göre bu düzeyde bir karmaşıklık eklemesi gayet katlanılabilir bir şeydi. Sonuçta yapılan her iş yalnızca bir başlık etiketini düzenlemek kadar basit değil. Ayrıca eski kodların yorum satırına alınarak üst üste birikmesi yerine, istendiğinde geri döndürülebileceği için hiç çekinmeden tamamen silinebilmesi; değişikliklerin şeffaf şekilde izlenebilmesi ve rollback yapılabilmesi; bundler sayesinde gerekirse biraz daha temel optimizasyonların eklenebilmesi bence yeterince büyük avantajlar. Gerçek ortama deploy edilmeden önce önizleme yapılabilen bir staging sunucusu eklemek de bir bakıma karmaşıklık sayılabilir, ama ben bunun gerekli olduğunu düşünüyorum.
Ben de çeşitli web sitelerinin iç kod yapısının aşırı karmaşık ve ağır hâle gelmesinden epey rahatsızım. Bugünlerde Windows'taki Outlook uygulaması web app tabanlı, ama son zamanlarda özellikle daha da ağırlaştı. Ekranda sadece e-posta gövdesi yazmak ya da gövdenin tamamını seçmek bile takılmaya neden oluyor, hatta bazen "sayfa yanıt vermiyor" noktasına geliyor. Neden böyle diye merak edip web Outlook'ta geliştirici araçlarını açtığımda gerçekten şaşırdım. Bir kez cache'i temizleyip sayfayı yeniledim, 1 dakika sonra bile hâlâ bir sürü istek akmaya devam ediyordu. Tarayıcıdan baktığımda yalnızca MS Office sitesiyle ilgili birkaç gigabayt veri depolanmış olduğunu gördüm.
Ama bu yazı birçok şeyi birbirine karıştırıyor; bazı kısımlarına katılıyorum ama bazı kısımlarına pek katılamıyorum. Semantik HTML ya da erişilebilirlik konusunda geçmişin aslında daha da korkunç olduğunu biliyorum. Üstelik geliştirici deneyiminin iyileşmesinin kullanıcı deneyimini kötüleştirdiği iddiasına, web frontend geliştiricisi olmadığım için mi bilmiyorum ama hiç katılamıyorum. Hatta bütün güç ve kontrolün geliştiricilerde toplandığını söylemek bana saçma geliyor. Şirketlerde güç yönetimde değil mi? Yoksa Batı'da şirket yapısı Kore'dekinden biraz farklı mı?
Her zaman olduğu gibi denge ve itidal, sadelik ve pratiklik önemli değerlerdir ve karar verirken bunlara öncelik verilmesi gerektiğine tamamen katılıyorum. Ama bu yazı, "tüm web sitelerine birer yazılım ürünü gibi davranılması"nı sanki bütünüyle geliştiricilerin sorumluluğuymuş gibi öne sürüyor; bence bu da asıl meseleye dair farkındalığı bulanıklaştırıyor. Ayrıca sistemli olmayan o 'eski güzel günler'i yüceltiyor gibi görünen kısımlar da bence eleştirilmeli.
Sıkıcıymış gibi…
Kore, başı sonu Java memleketi olduğu için ona yabancı geliyor haha
Diğer ülkelerin teknolojisi != diğer ülkelerin verisi
diye düşünüyorum
Önce ücretsiz sunulana kadar inanmıyorum. Grok zaten 30 dolar bile, abone olmaya çekiniyorum...
hahaha aniden darbe yemiş yüksek lisans öğrencisi afallamış ..
Rails kullanın, mutlu olun
Girişimi destekliyorum ama...
Yeni bir organizasyon kurup 1.0'ı çöpe atmak gibi bir şey yapmasalar iyi olur.
(Kore) Şirket hayatı mı? haha
Keşke YCD olarak da çıksa~