Transkript
Yani şimdi 11'den büyük, 13'den küçük mü diyoruz?
Evet, 11'den büyük, 13'den küçük.
13'den küçük olduğunun garantisi yok.
13'e eşit de olabilir.
Yok, garanti yok. Eğer 11'den büyük, 13'den küçükse 12 de olur.
12 oluyor sadece, onu diyeceğim.
Doğan sayıları olunca 12 olabiliyor ama belki de rasyonel bir sayı.
Esprim tutmadı. Serim ekip programına hoş geldiniz.
Volut ekibinden Şeyma Çapan ve Merve Barın ile birlikteyiz.
Ama önce Barış ve Onur ile birlikteyiz.
Hoş geldiniz arkadaşlar. Selam Fırat.
Merhaba. Hoş bulduk.
Nasılsınız? Görüşemedik bir süredir.
İyiydik. Talihsizlik oldu.
Bir süredir görüşmüyoruz.
Bir hafta mı oldu? Bir haftadan fazla.
Sözü tekrar Şeyma Çapan ve Merve Barın ile veriyoruz.
Biraz kendinizi sanatabilir misiniz? Selamlar.
Ben Şeyma. 2018 yılında bilgisayar mühendisliğinden mezun oldum.
Bir yıldır Trendyol'da Wallet ekibinde backend developer olarak çalışıyorum.
Bunun öncesinde de bir buçuk yıl kadar bir fintech şirketinde çalıştım.
Ben de Merve. Ben de 2018 yılında bilgisayar mühendisliğinden mezun oldum.
Bir senedir Trendyol'da çalışıyorum Wallet ekibinde backend developer olarak.
Buradan önce bir buçuk sene Şeyma'yla aynı fintech şirketinde çalışıyordum ben de.
Hatta oradan tanışıyoruz ikimiz de.
O zaman hoş geldiniz arkadaşlar.
Birazcık aksattık. Programı aslında daha önce çekecektik.
Dinleyicilerimiz için bir şey fark etmeyecek gerçi.
11'den büyük, 13'den küçük program olarak kayıda geçecek.
Ama biz bir böyle kayıt almakta zorlandık.
Ama bizim de çok merak ettiğimiz, konuşmak istediğimiz bir ekipti.
Wallet dediniz. Domain nedir?
Wallet nedir? Az önce Şeyma güzel böyle bir şeyle girdi.
Slogan gibi Wallet'ın bir sloganı gibi girdi.
Wallet'ın içeriğinde neler vardır?
Hiç bilmeyenler için bir anlatabilir misiniz?
Domain neyi kapsıyor acaba?
Tabii ki bildiğiniz gibi Trento üzerinde artık sanal bir cüzdan var.
Bir bakiye... yükleyip o bakiyeyle alışveriş yapabiliyorsunuz.
Aslında bizim ekipte tüm bu bakiye işlemleri, bizim depozitlediğimiz bakiye yükleme, withdraw, paranızı geri, kartınızı alabilme.
Normal payment, refund işlemleri, cüzdanın alternatif bir payment yöntemi olarak check-out ekranlarında görünmesi, volutla alakalı tüm kampanyalar, trend yol para diye bir kavram var artık hayatımızda,
volutlu ödemelerde kazanabiliyoruz, bunun yönetilmesi.
Aslında kısaca volutla alakalı tüm işler bizim ekibimizde.
Aslında bir ödeme yöntemi değil mi?
Alternatif bir ödeme yöntemi trend yolda.
Aynen öyle. Şu an ödemelerin %30'u hatta cüzdan üzerinden geçiyor diyebiliriz.
Bayağı ciddi bir hacim.
Peki kullanıcılar bu %30'luk kitle neden kredi kartlarıyla satın alım yerine cüzdana yöneliyorlar?
Son kullanıcı olarak neden cüzdan kullanmam gerekiyor?
Cüzdanın aslında kullanıcı sağladığı birden fazla fayda var.
Bir tanesi posil ödemelere göre 7 ile 15 kat daha hızlı respons dönüyoruz.
Biliyorsunuz bankaların respons time'ları çok değişken.
İkincisi ve en güzellerinden biri bence trend yol volutla ödeme yaptığınızda trend yol para kazanıyorsunuz aslında.
Bu şu an normal kullanıcılar %1, elit kullanıcılar da %2 kazanıyor.
Üçüncü olarak da refund'u söyleyebilirim.
İade, posa iadeler yine bankaya bağlı değişik olarak bir hafta 10 gün içinde hesabınıza yatıyordu.
Şu an volutla iadeyi seçerseniz aslında anında bakiyenize yansıdığını görebiliyorsunuz.
Ben de çok şeyi seviyorum bana para kazandırmasını o yüzden.
Sık sık kullanmaya çalışıyorum.
Şey sorayım ben de Trendyol'da birçok ekip farklı ekiplerle beraber çalışması gerekebiliyor.
Siz Wallet ekibi olarak hangi ekiplere ve domenlere daha yakın çalışıyorsunuz?
Biz neredeyse Trendyol'daki tüm takımlarla iletişim halindeyiz.
Bütün frontend takımları, payment ekibi, sipariş ekipleri, checkout, data analizi yapan ekipler ve müşteri hizmetlere dahil olmak üzere herkesle çalışıyoruz aslında.
Dolaylı veya direkt yolda.
Trendyol dışındaki insanların genelde Trendyol hakkında merak ettikleri şeylerden bir tanesi de ekip yapısı oluyor.
Sizin ekip yapısı nasıl? Biraz anlatabilir misiniz?
Backend, frontend ya da QA olarak kaç kişi var gibi.
Aslında şu an biz epey kalabalığız çünkü volut altında iki ekip var gibi düşünebiliriz.
Bir tane ekip şu an Trendyol içindeki volutla alakalı feature'lara ve geliştirmelere devam ediyor aslında.
İkinci ekipte şu an bir e-para lisans süreci var.
O süreç için gerekli olan şeyleri geliştiriyorlar aslında.
Bu lisanstan sonra Volt'u migrate edeceğiz.
Onun için geliştirmelere devam ediyoruz.
Toplamda iki QA. 9 back-end ve 4 front-end var aslında.
Epey kalabalık bir ikimiz. Peki onboarding stratejiniz nasıl?
Yani trend yolda son dönemde çok fazla kişi başladı.
Hatta böyle pandeminin başından beri 3 katına çıktık.
Sizin ekibinizde de yeni başlayan kişiler olmuştur büyük ihtimal.
Nasıl onboard ediyorsunuz insanları?
Evet gerçekten remote'a geçtiğimizden beri çok fazla insan başladı.
Bu iki ekibe ayrılma durumundan dolayı bizim de.
Yani ayrılacağımız durumdan dolayı.
Biz de şu şekilde ilerliyor onboarding.
Öncelikle bir body atıyoruz bizim takımdan.
Bu body aslında 2 hafta boyunca.
bu yeni gelen arkadaşımızla yakından ilgileniyor.
Ve böyle iki haftalık bir Excel oluşturuyoruz.
Bu Excel'lerde her takım, yani takımdaki her insanın anlatacağı bir konu oluyor.
Domain'le ilgili, sahip olduğumuz projelerle ilgili.
Ve bu yaklaşık bir saatlik anlatımlarda hem o insanı yakından tanımış oluyor hem de bizim projelerimizi yakından tanımış oluyor.
Aynı zamanda pair programming uyguluyoruz biz kendi takımımız içerisinde ve bu şekilde hızlı bir şekilde onboard edebiliyoruz aslında gelen arkadaşımıza.
İlk Wallet ortaya atıldığında, proje olarak atıldığında böyle event sourcing falan gibi şeyler konuşulmuştu yanlış hatırlamıyorsam.
Şu an bunun için kullandığınız bir framework var mı ya da daha genel sorayım.
Kullandığınız teknolojiler neler Wallet'ta?
Dediğim gibi aslında event sourcing var.
Şu an Wallet'ın core domaini event sourcing ve CQRS üzerinde kurulu.
Framework olarak da Exon'u kullanıyoruz, Exon framework'ı.
Nedir event sourcing? Daha önce hiç duymamış arkadaşlar için açıklamak gerekirse aslında biz wallet üzerinde bir state tutmuyoruz.
Sadece eventleri kaydediyoruz.
O wallet'un güncel state'ini eventleri işleyerek elde ediyoruz diyebiliriz.
Örnek bir akış söylemek gerekirse wallet'la bir ödeme isteği geldiğinde biz gerekli validasyonları yapıp bir event oluşturuyoruz aslında.
Bu eventi de bir event tablosuna kaydediyoruz.
Aynı zamanda bu eventi dinleyen bir de projection kısmımız var.
Bu projection kısmı da event'i dinleyip ilgili read model tablolarını dolduruyor.
Bu yapıyla zaten aslında SQList'e sağlamış oluyoruz.
SQList kısaca yazma ve okuma yerinin birbirinden tamamen ayrı olması.
Bizim şu an event tablolarımızla query model tablolarımız tamamen birbirinden ayrı.
Okuduğumuz APR'ler de farklı.
Onun dışında genel olarak APR'larımız backend'de Java ve Go ile yazılmış durumda.
Frontend'de de React kullanıyoruz.
DB tarafında da Postgre'de var, Couchbase'de var.
Genel olarak böyle. Exxon framework'ından bahsettiniz.
Sanırım DDD'ye uygulamak için kullanılan bir framework ama ne avantajları var?
Şöyle, mesela biz event sourcing'i ben de buraya ilk başladığımda benim için de yeni bir teknolojiydi.
Burada öğrendim. Aklıma mesela gelen ilk soru şuydu.
Aggregate diyoruz. Aggregate'i şey olarak düşünebilirsiniz.
Servolup bir aggregate. Aggregate'de gruplanmış eventler bütünü gibi düşünebilirsiniz.
Her bir istek geldiğinde, bizde bir command api var.
Aggregate ayağa kalkıyor ve son state'e ulaşıyor.
Ben ilk şunu sormuştum mesela. Her seferinde eventler işlemek maliyetli olmuyor mu?
Hani niye böyle bir yapı kurduk?
Exxon mesela hem snapshot diye bir mekanizması var hem event replaying.
Bunlar da destek veriyor aslında.
Yani kendi tarafımızda da yazılabilirdi ama bir framework kullanmak daha kolaylaştırdı.
Mesela orada snapshot mekanizması da şu.
Bizde 5 event de bir, bir snapshot event oluşturuyor.
Yani bunu özet bir event gibi düşünebilirsiniz.
Her state'i bulmak için aslında snapshot eventleri üzerinde geziyoruz gibi yani.
Böyle bir sürü artısı var. Event replay'in bir ihtiyaç duyurur musunuz?
Öyle bir kaza yaşadığınızda? Ben stage dv'yi uçurdum.
Yani benim ihtiyacım oldu.
Geçmiş olsun. Heyecanı olacak.
Öyle değil aslında.
Ben bayağı üzülmüştüm. Çünkü bizim Ömer Varkiye arkadaşımız onun bütün bir sürü testi stage üzerinde.
Sonra clientların bir sürü testi stage üzerindeydi.
Şöyle bir hata yaptım. Belki kamu spotu olabilir.
İşte lokalimde data yok diye stage DB'ye baktırdım.
JPA'nın da biliyorsunuz DDL auto diye bir ayarı var.
O crate'de kalmış. Uygulamayı ayağa bir kaldırdım.
Bütün DB uçtu. Sonra başımdan kaynar su döküldü.
O gün de doğum günümdü hatta.
Bütün günüm böyle al yanaklarla geçti yani.
Ama orada event replay için biz daha önceden çalışmıştık.
Böyle bir şeye ihtiyacımız olursa böyle bir kodlama bile yapmıştık.
Bir branşta duruyordu. Hadi dedik hani bu fırsat olabilir deneyelim.
Gerçekten de event tablosunu uçurmamıştım.
Ben read modelleri uçurmuştum komple.
O eventleri tekrar replay edip Tabloların hepsini doldurduk.
Biraz uzun sürdü. Birkaç saat sürdü.
Akşam orada geçirdik.
Merve falan sağ olsun hepsi bende durdu hızlığında.
Ama tabloları geri elde ettik yani.
Hiçbir data kaybımız olmadı.
Geçmiş olsun. En azından bütün hatalarınızı ortamda yaşamış olmak güzel.
Önemli olan production'a sağlam çıkabilmek.
Evet artık tüm konflikt dosyalarında o ayara bakıyorum yani.
Öyle söyleyebilirim. Süper.
Peki şimdi deployment süreçleriniz nasıl acaba?
Biraz onları bahsedebilir miyim? Şimdi production'a nasıl çıkıyorsunuz?
Ne kadar tıklıkta çıkabiliyorsunuz?
Biz neredeyse her gün deployment yapıyoruz.
Tabii ki bu Spintek işin büyüklüğüne göre bu sıklık artıp azalabiliyor.
Ama herhangi bir engelimiz yoksa istediğimiz kadar development yapma kabiliyetine sahibiz.
Bu kadar rahat yapabiliyor olmamızın sebebi de genelde future toggling kullanıyoruz biz yaptığımız geliştirmelerde.
Çünkü bir ödeme sistemi olduğumuz için...
Yaptığımız herhangi bir bug fark edilmeyen dış tarafı hemen etkileyebiliyor son kullanıcıyı.
O yüzden genellikle bunları bir ayara bağlı olarak çıkıyoruz biz.
Production'a çıkma evresinden önce ise kodu hem pair ve mob yazmaya çalışıyoruz genellikle gözden bir şey kaçmaması açısından.
Ve daha sonra da Şeyma'nın bahsettiği gibi stage ortamlarında bunu sıkça test ediyoruz.
Bir bug olmazsa da GitLab üzerinden production küberne testlerine gönderiyoruz.
Mob programming dedin. Mob programming'i nasıl uyguluyorsunuz?
Ne kadar zamanda bir uyguluyorsunuz?
Çünkü tüm takım böyle aynı koda bakıyor ya.
Şöyle. Aslında büyük işleri genellikle mob yapmayı tercih ediyoruz.
Bunu nasıl yapıyoruz? Öncelikle işin analizini bir zoom'da konuşuyoruz.
Daha sonrasında biri ekran paylaşarak o işi nasıl yapmaya karar verdiyse tek bir kişinin bilgisayarından kodlamaya başlıyoruz.
Daha sonrasında belki birer saat arayla belki yarım saat arayla komit atıp başka bir kişinin bilgisayarından devam ediyoruz bunu yazmaya.
Böylelikle hem kodu yazarken işe hakimiyetimiz artıyor hem de dışarıdan bir gözle bakarak bir yer eksik kaldıysa bunu tamamlayabiliriz.
Biliyoruz gibi oluyor. O şekilde.
Çok faydasını görüyor musunuz?
Bence kesinlikle görüyoruz ama büyük işlerde, küçük işlerde buna giriştiğimiz zamanlarda bazen vakit kaybı da oluyor açıkçası o kadar kalabalık çalışınca.
Ama büyük böyle nasıl desem, iadeyi baştan yazıyorsak ya da ödeme almak için yeni bir flow geldiyse bize o zamanlarda mob yapmayı tercih ediyoruz.
Süpermiş. Mob uygulayan daha önce duymamıştık galiba.
Yine bilindik konulardan geçeceğim biraz.
Code Review yapıyor musunuz?
Test süreciniz nasıl? Code review yapıyoruz.
Aslında Merve'nin de dediği gibi bizde genel olarak peer kesim var.
Yani ikili çalışan insanlar.
Büyük işlerde mob yapıyoruz.
Onun dışında da zaten mesela büyük işlerin bir PR'ı varsa code review session'lar yapıyoruz.
Sabahlar oluyor genelde.
Hep beraber toplanıyoruz. Birbirimize yaptığımız işleri anlatıyoruz sprint bitmeden.
Çünkü bazen gözden kaçabiliyor insanlar.
Çok iyi bir code review yapmıyor ya da işten haberdar olmuyor.
Birbirimize o şekilde sync tutuyoruz aslında.
Test konusunda da her işte unit test kesinlikle yazıyoruz.
Integration test yazıyoruz.
Son zamanlarda acceptance test de yazmaya başladık biz.
Sadece QA'miz yazmıyor yani.
Onun dışında zaten otomasyon test projelerimiz var.
Onlar pipelinede.
Her master code mercenarında onlar da tetikleniyor.
Onlar geçmeden production'a çıkamıyoruz zaten.
Peki test sürecinde bir eksik var desen ne olabilir?
Ne olabilir? Yine eksik test yazma olabilir yani.
Her case cover edilmemiş olabilir.
Bir şey sormak istiyorum ben de. Bir ödeme sistemi olduğunuz için aslında biraz kritik bir uygulama üzerinde çalışıyorsunuz.
Sonuçta üzerinden para geçen bir sistem diyeyim.
Dolayısıyla çok iyi de monitör etmeniz gerektiğini düşünüyorum.
Taraftaki deneyimlerinizi biraz paylaşabilir misiniz?
Monitörün kısmında neler yapıyorsunuz ya da bir instant oluşmadan önce bundan nasıl haberdar olabiliyorsunuz?
Şöyle orada, biz Nivreli Kibana gibi aslında monitoring tool'larını kullanıyoruz.
Nivreli'yi genellikle response time'ları ve error rate'leri gözlemlemek için, Kibana'yı ise error log'larını takip etmek için kullanıyoruz.
Buralarda normal deployment yapmadığımız bir gündeki değerlere baz alarak aslında normalin dışında bir değişiklik varsa bunun sebebini inceliyoruz.
Aynı zamanda database üzerimizde de her işlem tipleri için bizim kontrollerimiz var.
Mesela 3 dakika içerisinde iade işlemi gelmediyse veya iki dakika içerisinde bir ödeme alınmadıysa bu bizim tarafımıza Slack üzerinden ya da mail üzerinden alertler atıyor.
Biz bu alertler sonucunda hemen zoom üzerinden toplanıp aksiyon almaya başlıyoruz.
Daha sonrasında bu incident'ın tekrardan yaşanmaması için yeni nasıl alertler ekleyebiliriz bunları konuşuyoruz.
Bir de dediğiniz gibi bir ödeme yöntemi olduğumuz için aslında Biz daha çok iftek alan tarafız ve bizim dışarıdan aldığımız trafiği de kontrol etmemiz gerekiyor.
Sadece kendi sistemlerimiz değil de dışarıdan aldığımız API isteklerini de monitör ediyoruz.
Ve aynı şekilde buralarda da bir düşüş varsa bize alertler geliyor.
Bu arada ben daha demin eklemeyi unuttum aslında.
TDD'de yapıyoruz. Özellikle bu bakiye ile alakalı yaptığımız işlerde zaten kurduğumuz yapı da TDD'ye çok müsait.
Sonuçta biz bir event atıyoruz ve event sonucunda Balsher'in olmasını bekliyoruz.
O yüzden bakiye ile alakalı yaptığımız herhangi bir işte ilk önce testini yazıyoruz.
Sonra da aslında kodunu yazıyoruz.
Hatta böyle bug'lar çıktıkça bile aslında TDD yapılabilir değil mi?
Yani bir case'e atlamışsındır.
Onu bug fix'i geçerken testini yazıp ondan sonra fix desen çok daha iyi olabiliyor gerçekten.
Evet evet özellikle bu bakiye ve M6'lar üzerine bir işlem yaptığınızda.
Gerçekten ilk önce testini yazmak çok yararlı oluyor.
Geçenlerde yaşadığımız bir bug da bu şekilde çözmüştük aslında.
Çok çok küçük yüzdelerdeki iadeleri alırken bu iadeyi yapamama gibi bir problemimiz olmuştu.
Ve burada TDD yaparak aslında bu problemi daha rahat bir şekilde çözmüştük.
Birazdan daha şeye de geleceğiz zaten.
Yani yaşadığınız başka böyle candaki problemlere gelince onu da duymak isteriz.
Şimdi baktığımız zaman...
Bir yerde bakiyeden bahsediyoruz.
Teknik bir challenge var.
Yüksek bir throughput var.
İşte remote verdiği şey var.
Yorgunluk var. Evlerde olmamızın, pandeminin gibi.
Bakınca overall da düşününce Volt ekibinin en büyük challenge'ın ne olduğunu düşünüyorsunuz?
Sizin için en büyük zorluk nedir?
Yani aslında bizimkisi de scaling.
Yani Trendyol'daki çoğu ekipte olduğu gibi.
Şu an Volt'un daha bir yılı da olmadı aslında sistemde olalı.
Bir yılı olmayan bir projede şu an milyonlarca kullanıcısı var ve ödemelerin %30'u Volt üzerinden geçiyor.
O yüzden hem biz mevcut yapı için sürekli hem de yeni bir feature ekleyeceksek hep kafamızda hani bu daha nasıl performansa çalışır.
İşte bunu iki katı yük aldığımızda burası bunun part time'ı hep bu mindset ile ilerliyoruz.
Yani eminim bir yıllık bir takım olmanızın ve çok fazla yük almanızın bir getirisi de retrolardaki kanlı maddeler oluyordur.
Son Retro'da neler konuştunuz? Böyle çıkan ve iyileştirdiğiniz bir şey vermek verebilir misiniz?
Aslında bizim Retro'larımız pek kanlı geçmiyor.
Hatta son Retro'da da böyle kayda değer bir şey olmamıştı ama böyle en çok konuştuğumuz konulardan bir tanesi genellikle zaman algımız oluyor.
Remote özellikle mob yaparken zaman farkındalığımız azalıyor ve bu bizi verimsiz ve uzun süreler çalışmaya götürebiliyor.
Bu en çok Retro'da konuştum.
şeylerden bir tanesiydi.
Hala düzeltmeye de çalışıyoruz.
Bu şekilde diyebilirim.
Otomobil ekipler olduğumuz için böyle Trendyol'da gelen de kendi projelerimizdeki işte bazı metrikleri takip ederek sürekli böyle iyileşmeye çalışıyoruz.
Sadece işte bu request response time'lar değil, işte biraz daha böyle business metriklerini de takip ediyor aslında Trendyol'daki ekip.
Sizin böyle takip ettiğiniz metrikler var mı?
Nelerini takip ediyorsunuz kendinizi daha iyi götürebilmek için?
Burada business metrikleri olarak günlük açılan wallet sayısını, cüzdan üzerinden verilen sipariş sayılarını, normal siparişler ile cüzdan siparişlerinin oranlarına bakıyoruz.
Eğer buralarda bir olumsuz değişiklik varsa yakın zamanda yaptığımız developmentların bunları etkileyip etkilemediğini analiz ediyoruz.
Aynı zamanda 4K metrik olarak lead time'a da yakından takip ediyoruz.
Bazı feature'ların son kullanıcıya çok geç çıktığını fark ettik hatta burada da.
Ve bunu analiz ettiğimizde mikrofrontend yaparak bu sıkıntıyı azaltabileceğimizi fark ettik.
Hala bu konuda aksiyonlarımız devam ediyor.
Peki az önce Şeyma stage'i uçurdu.
Merve işte sen Refund'da o küsürratlarla ilgili bir case'den bahsettin.
Bunlar dışında böyle aklınıza gelen özellikle son zamanlarda olursa daha da güzel olabilir.
Canlı sistemde patladığınız bir case var mı?
Ve sonrasında ne gibi bir aksiyon aldınız?
Nasıl düzelttiniz bunu? Aslında en son olan olay bir iki hafta önce işte oldu.
Merve'nin dediği bu küsürratlardan dolayı yani mesela biz orada Böyle bir kez test etmemişiz.
Çok küçük tutarların çok fazla partial iadeye uğraması.
Orada tutayı yuvarlamışız, daha fazla iade etmişiz ama bir süreden sonra orada farklı bir lojiyi kırıp hata dönmüşüz.
Sonucunda çok bir şey etkilenmedi aslında.
Sonradan iadeyi tetikledik, fixleyip.
Nasıl fixledik? Orada TDD yaptık direkt zaten.
Böyle bir amountla böyle bir event geldiğinde.
Bir sürü test yazdık.
Emin olduktan sonra fiksi çıktık.
Onun dışında benim çok hatırladığım yok.
Yani direkt olarak bizden kaynaklı çok canlı sorun yaşamadık.
Bir SSL sorunu falan olmuştu.
Onunla gece bir bulut ödemelerinde kesinti olmuştu.
Ama benim aklıma ekstra gelmiyor.
Merve belki başka bir şey hatırlar.
Aslında dediğin gibi direkt olarak bizden kaynaklı bir sıkıntı olmuyordu.
Ama tabii ki çok fazla ekiple birlikte çalıştığımız için dolaylı yoldan biz de etkileniyorduk.
Gayet güzel. Black Friday atlattık ve Wallet'tan da çok bir şey duymadık demek ki.
Evet. Stabilizasyon kanalında Wallet diye aradık.
Aslında güzel data var. Stabilizasyon kanalında.
Çok iyi fikir. Hatta şey sonra suçlama yapacaksın.
Geçenlerde böyleydi ama. Böyle diyorsun ama bak burada bir sürü data var.
Ama altındaki thread'e bakmak lazım.
Wallet niye gitmiş? Arkadaşlar.
Yavaştan kapatabiliriz. Merve, Şeyma çok teşekkürler programa katıldığınız için.
Son olarak eklemek istediğiniz, paylaşmak istediğiniz bir şey var mı?
Ben de kendi adıma çok teşekkür ederim.
Hem böyle ekibin bilinirliğini attıracak bir program oldu.
Biz de dinleyip bilmediğimiz çok şey öğreniyoruz.
O yüzden böyle bir şeye kurguladığınız için teşekkürler.
Ben de çok teşekkür ederim. Çok güzel bir deneyim oldu.
Biraz da heyecanlıydım ama inşallah güzel olmuştur herkes için.
Gayet güzel. Teşekkürler katıldığınız için.
Sadece Merve programın başında benim bir numaram bozdu.
Sihir numaram bozdu. Artık bir daha onu yapamayacağım.
O yüzden biraz mutsuzum. Ama bu kurgunun en önemli parçası da şarkı.
Evet. Bu gerçek miydi ya?
Yani 11'den büyük, 13'den küçük program yaptık.
Her gelen de bir şarkı söyledi.
Merve o zaman ortak bir şey söyleyelim.
Yani düet olsun.
Söylemeyelim mi? Var mı istek parçanız?
Oo o kadar. İptal edelim.
Şeyma solist olarak söyleyecek çünkü.
Arada şey de yapabilir miyiz?
Değiştir deyip. İptaldığı kelimeden başka şarkılar mı?
İlk şarkıdan sonra muhtemelen ikinciyi istemeyeceksin.
Ne düşünüyorsun? O zaman ilk şarkıyı alalım o zaman.
Bunu dinleyicilerimiz karar versin.
Güzelmiş. Evet.
Şu an kestik mi?
Burada şarkı söylemişti.
Sen sanki söylemişsin de kesmişsiniz gibi yapacağız burayı.
Süper. Kulaklarınızın kalamasını istemedik o yüzden burayı sizle paylaşmıyoruz.
Tehdit edildiğin sesi haklı bu şarkıyla.
Anlatmaydı bu? Anlam yüklü bir şarkıydı gerçekten.
Gözleri çok güzeldi özellikle. Bir şey söyleyeceğim ben.
Ben galiba podcastlerin hiç sonunu dinlememişim.
Bunu anlıyorum ben. Her sene dilersin gerçekten.
Teşekkürler. Kimse dinlemiyor diye sonlarında böyle...
Ben şeyi hatırlıyorum.
Burçin de böyle ben söylemek istemiyorum falan gibi şeyler tepkiler vermişti.
Burçin söylemişti. Çok istekli arkadaşlar da vardı ama.
Çok güzel şarkı söyleyenler de vardı.
Sadece podcast'in sonlarından ayrı bir podcast yapabiliriz belki.
Evet. Şarkıları peş peşe dizip.
Yani en son lisede müzik derse Gesi Bağları'nı söylemiştim.
Ben lisede olduğunu düşündüm.
Gesi Bağları'nı mı istiyorsun? Liseden beri şarkı söylememiştim.
Peki. Yine ikinci şarkı da güzeldi.
Teşekkürler. O zaman.
İşte bu yüzden dinlenmiyor belki de programı.
Belki de şey dediler. O kadar güzel söylediler ki telif yedik.
Bir şey söyleyeceğim. Bu arada gerçekten her kaydın sonunda şarkı var mı?
Herkes söyledi mi bugüne kadar? Ona göre söyleyeceğim yani.
Herkes söyledi. Dinleyenler bilir.
Dinlemeyenler de sonradan yolladı.
Onları da bir şekilde ekledik yani.
Dans edenler var ya.
O zaman herkes sesini kapatsın.
Ben Gesi Bağları'nı söyleyeyim.
Sözlerini açayım. Ama kıkırdamayın.
Tamam. Bu
kadar yeter diye düşünüyorum.
Kendi sesim hiç iyi gelmiyor bu arada.
Umarım beni pop olamıyorsunuz.
Güzel. Gerçekten çok iyiydi.
Gerçekten güzel söyledin.
Bu kadar beklemedim. Bolu teki bir mızıkçılık yapsın istemedim.
Gayet güzel oldu. O zaman Merve şarkı söylemeyeceğini düşünüyorum.
Ve tekrar teşekkür ediyorum.
Tekrar teşekkür ediyorum. Programa katıldığınız için.
Biz de çok teşekkür ederiz gerçekten. Sağ olun.
Teşekkürler. O zaman Barış, Fırat sizler de hoşçakalın.
Hep beraber hoşçakalın.
Hep beraber hoşçakalın.
Hoşçakalın. Hoşçakalın.
Hoşçakalın. Neyse çok uzayacak.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.