Konuklar: Arif Yılmaz, Mehmet Alper Genç, Enes Yalınkaya, Onur Erdemiroğlu
79. bölümümüzde konuğumuz Listing ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Trendyol Talks'da Trendyol'daki kültürümüzü, kültürümüzden beslenen iş yapış biçimlerimizi ve ritüellerimizi konuşuyoruz. Trendyol Talks podcast kanalımızı takip etmeyi unutmayın!
Transkript
Selam ekip. Ben Odur Masadat ekibinden Fırat.
Ben Corrections Favorite ekibinden Kübra.
Teknoloji ekiplerine tanıdığımız süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast'imizin 79.
bölümündeyiz. Bu bölümde Product Listing ekibiyle birlikte olacağız.
Ekibi tanıyacağız, ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Arkadaşlar hoş geldiniz. Hoş bulduk.
Merhaba. Hoş bulduk. Merhaba.
Merhaba. Merhaba. Hoş geldiniz.
Bugün dört tane misafirimiz var.
Onur, Arif, Enes ve Alper olacak.
Ayrıca Kübra'yla beraberiz. Kübra'nın da ikinci bölümünü.
Kübra yakacağız, çıkacağız.
Teşekkürler. Evet, o zaman direkt ekibi tanıyarak başlamak istersiniz arkadaşlar.
Kısaca bir kendinizi tanıtabilir misiniz?
Kim ne deneyicidir? Kim başlamak ister?
Onur istersen senden başlayalım. Tabii ben başlayayım.
Merhabalar, ben Onur. Sektörde dördüncü yılındayım.
Son bir buçuk yıldır da Trendyol'da Listing ekibinde Developer Interest olarak çalışıyorum.
Ben de sözü Enes'e vermiş olayım.
Merhabalar, ben Enes.
Sektörde altıncı yılım.
Trendyol'da 3,5 yıl doldurdum.
İlk dolapta başladım.
2 yıl sonra da aslında rotasyonla bu ekibe geldim.
Yaklaşık 2 yıldır da bu ekiple çalışıyorum.
Ben de sözü peri bırakayım.
Merhabalar, Alper ben de.
2 senelik bir çalışma tecrübem var.
Bunun son 1,5 senesi Trendyol'da geçti.
Ben de backend engineer olarak çalışıyorum aslında.
Bu kadar yani. Ben de sözü Arif abime vereyim.
Merhabalar ben Arif. Benim de Trentoğlu'da 7 yılımda oldu.
Sektörde de 9. yılımdayım.
Bu 7 yılda farklı ekiplerde çalıştım.
Şu an listing ekibine liderlik yapıyorum.
Hoş geldiniz tekrardan. Evet 7.
yıl çok imiş. Benim de 6 olacak.
Böyle uzun süreli insana göre şey yapıyorum böyle.
Helal olsun falan ne kadar gelmişiz falan diye böyle.
Bir de şey oluyor bu kadar uzun süre olunca.
Yani aynı ekipte olmasam da her isim tanıdık geliyor.
O kadar uzun süredir bir yerlerde ile ortak yerlerde denk gelmiş oluyorsun.
Kesinlikle. 6. yılın güzelliği artık.
21 gün izin geliyor. 20 mi 21 mi o?
21. 21 mi?
Tamam. Benim Haziran 18 bir ayım kaldı.
Şu an onu bekliyorum. Yaşlandığınızı hissediyor musunuz peki?
Hiç de öyle bir şey yok. Daha çıtırım.
98 değil mi? Peki tekrar hoş geldiniz.
Listing takımının trendi odaki rolü nedir?
Yani neler üretiyorsunuz, neler yapıyorsunuz?
Tabii bu soruyu ben cevaplandırayım.
Öncelikle isterseniz listing nedir sorusuyla başlayalım.
Çünkü yaptığımız işin temelinde bu var.
Listing dediğimiz şey aslında bir ürünün satıcı ve beden bazında ayrıştırılmış halidir.
Bizim çok klasik bir örneğimiz var.
Adidas bir ayakkabı düşünelim.
Bu ayakkabının farklı bedenleri olabilir ve aynı ayakkabıyı satan...
Farklı satıcılar olabilir.
Biz bu her satıcının her beden için oluşturduğu ayrı ayrı yapılan her birine listing diyoruz.
Günün sonunda biz Trendyol'da aslında ürün değil bir listing satıyoruz.
Fiyatlar, stoklar gibi şeyler bunların hepsi listing üzerinden yönetiliyor.
Biz listing ekibi olarak da bu yapının kurulmasından sorumluyuz.
Hem Türkiye tarafında hem yurt dışındaki listinglerin oluşturulması.
Bunların üstüne gelen güncellemelerin yansıtılması ve listinglerin satılabilirliği ile uğraşıyoruz.
Burada listingin satılabilirliği önemli bir konu.
Onu biraz açayım. Listingler farklı sebeplerle kapatılabiliyor.
Örneğin orijinalliğinden şüphelendiğimiz listingler kapatılabilir.
faiz fiyattan satılan listingler kapatılabilir.
Bu süreç bunun gibi onlarca sebep daha var.
Bu sebepleri yöneten farklı farklı ekipler var.
Bunların biznesi bizde değil. Ama günün sonunda ilgili ekip bir listingi kapatmak istediğinde listing servislerine gelip kapatıyor.
Aynı şekilde bu sebep ortadan kalktıktan sonra da yine bizim servisleri kullanarak listingleri tekrar satışa açabiliyorlar.
Böyle özetleyebilirim. Biz sizin eventlerinizi dinliyoruz.
Bu kritik bilgiyi şu an paylaşmak istedim.
Listing oluşunca çünkü biz de şu an işte Fulfillment depo tarafındayız ve depo taraflarında özellikle ürünler var.
Okey ya da işte SPM ekibiyle vesaire işte biz Product Tribe'nin birçok ekibini burada ağırladık.
İşte birisi işte şey yapıyor biz ilk ürünleri işte yükleyen kısımlar izliyor.
İşte bir kısımlar işte Kübra'nın mesela eski ekibi var daha çok sellerler üzerinde ilerliyor vesaire gibi kısımlar oluyor.
Bir de Ürün tamam hazırlanma aşamaları var vs.
Satışa açılma var. Satışa açıldıktan sonra bunun işte operasyonel kısımlar artık olabileceği için iş artık bizi de ilgilendiriyor.
O yüzden de bizim için de ürün var okey ama bizim için ürün gerçekten ne zaman ürün oluyor?
Listingle beraber. O yüzden böyle bizim için de gerçekten sizin kısmınız çok kritik bir rol alıyor.
Yani bizim eventleri dinleyen aslında yaklaşık 44-45 tane şey var.
Konzumur var. O bakımdan tüm Trendyol'da evet yani tüm Trendyol'da yani bir sürü ekip dinliyordur bizim eventleri.
Evet evet. Gerçekten çok kor bir yerdesiniz ya bu kadar ekiple birlikte çalışmak.
Ya biz de bizim Tribe'de özellikle yani çok fazla ekip ve data provider kısımda olduğumuz için hem Tribe için hem Tribe dışı birçok ekiple beraber çalışıyoruz ve hepsiyle aynı olmanın belirli bir challenge'ı var.
Böyle onu da bir ara bir konuşacağım böyle farklı takımlarla çalışmanın ayrı bir challenge'ı oluyor böyle.
Gerçekten teorili pratik her zaman aynı olmuyor.
Ama ondan önce bir ekibi hazır tanıyoruz.
O kısımlardan bir devam edelim isterseniz.
Şu anda ekipte işte şu anda hem leader var burada aramızda hem QA var hem işte backend engineer var vesaire.
Şu an bu ekip tam olarak listening ekip kaç kişiden oluşuyor?
45 tane ekip dinliyor sizi.
Sizin ekip kaç kişiden oluşuyor?
QA developer vesaire.
Tabii ben yine kısa bir özetleyeyim.
Ekibimizde 5 developer var.
Buradaki arkadaşlarımızın dışında 2 kişi daha var.
Sadece Onur Devintes olarak.
rol alıyor. Bir de product manager arkadaşımız var.
Yani beş developer ve bir devintes arkadaşla geliştirmeleri yapıyoruz.
Bir QA mesela şu an sizde verimli oluyor mu?
Beş developer bir QA ya. Yoksa iki QA olmasa daha mı verimli geçerdi?
Bunun tam böyle şeyi de ekipten ekibe değişebiliyor ya.
Mesela sizin gibi birçok ekiple birlikte olan bir ekip için mesela.
Beşe bir mesela yeterli oluyor mu sizce?
Aslında şöyle biraz dönem dönem değişen bir nokta.
Yani akışta bence overhaul'da bir şekilde tek development test süreci ilerletiyor ama trendi o zaten sürekli challenger olan bir sistem.
Zaman zaman yorduğu kısımlar oluyor tabii ki.
Ama yani bence 5'e 1 gayet iyi ilerliyor diyeyim yani şu an.
Süper. Bu arada şu notu da düşeyim.
Araya girdim ama sprint sonuna doğru.
gerekirse developer arkadaşlarımız da elini taşın altına koyup testteki işleri ilerletip onlara destek oluyoruz.
Biz de benzerini yapıyoruz. Bizde de iki QA'dı.
Bir QA'miz rotasyon yaptı.
O yüzden hani benzeri mantıkla gitmemiz için eski yapıya yakın olması için biz de mesela QA işlerine giriyoruz vesaire otomasyonlar olur vesaire.
Peki bu ekibe Rotasyonla gelen iç oldu mu?
Yani biliyorsunuz ki tren yolu içerisinde çok böyle puştanan bir şey.
Rotate edelim işte hep aynı yerde durmayalım, konfor alanımızdan çıkalım gibi.
Var mıdır ekipte rotasyonla gelen eğer varsa onboarding süreçleri nasıl işledi?
Evet rotasyon sizin de dediğiniz üzere tren yolda çok yapılması tavsiye edilen bir şey.
Ve yakın zamanda rotasyonla ekibimize katılan bir arkadaşımız oldu.
Kendisinden önce de ben katıldım aslında ekibe rotasyonla.
Eylül 2024'te.
Ve kendi tecrübelerimden konuşmam gerekirse onboarding çok hızlı ve kapsayıcıydı.
Yine Arif abinin sprint sonu testler yoğunlaşırsa verdiği örnekteki gibi herkes elini taşın altına koydu gerçekten.
Hemen ilk günümden bizim takımın domenini kendi aralarında parça parça bölüp bana toplantı attılar.
Ve bu toplantılarda domeninden kendilerine düşen payı gayet kapsayıcı ama verimli bir şekilde aktardılar bana ve bunun sayesinde hızlıca adapte olabildim.
Aynı zamanda buddy'im kendisi de burada şu an Enes abi beni takımın bütün loop'larına bütün slack kanallarına bütün security izin gruplarına hızlıca aldı ve hani İngilizce'de derler ya hit the ground running diye
ben de gerçekten takımın eforları sayesinde hit the ground running eyleyebildim ve bu kültürde rotasyona yeni katılan arkadaşımızın onboarding prosedüründe.
International'daki satılabilirlik yönetimi domenini anlatmayı üstlenerek elimden geldiğince yaşatmaya çalıştım diyeyim.
Sen sanırım iki yıldır, bir buçuk yıldır Trendyol'daydın değil mi Alper?
Evet abi. Hangi ekipten geldin peki buraya?
Product Core ekibinden geldim.
Sanırım şeyleri yok onların.
Bir tane selam ekip bölümleri yok.
Olsa güzel olabilir. Evet.
Bir onlarla konuşalım en iyisi.
Sizi andık deyip onlara bir yazayım.
Burada rotasyon aslında Size iki kişi hatta rotasyonla gelmiş sanırım.
Çünkü bir Alper, bir sen bahsettin.
Bir de Enes sanırım bahsetti.
Gerçi o geleli iki yıl olmuş. Yine bayağı bir olmuş oldu.
Dolapta başlamıştı diye hatırlıyorum.
Evet yani ekibin artan sonraki Enes'ki ikincisi ben kaldım.
Ondan sonra üç tane daha arkadaş hatta dört tane arkadaş rotasyonla geldi bize.
Bu rotasyonlar tribe içinden olduğu zaman arkadaşlarını adapte etmesi daha kolay oluyor.
Çünkü böyle sanki tribe'da yoğur giyiş.
Aynı ama trikeler arası böyle değişiyor.
Hani çalışma şekilleri olsun, yoğurt yiyişleri değişiyor.
Mesela Alper bize aynı trike içerisinden rotasyonu geldiği için onun onboarding'i çok daha kolay oldu, rahat oldu.
Ama ben mesela buraya dolaptan rotasyonu geldiğinde ilk bir zaman bir afallamıştım.
Çünkü dolap trikelerindeki yoğurt yiyişle buradaki yoğurt yiyiş, yani iş yapı şekillerimiz.
Bayağı farklıydı. Ben daha sonra konuşacaktım biliyor musun?
Yani kesinlikle yani dolaptan buraya geçmek çünkü iki farklı ekip yani farklı evet hepimiz aynı şekildeyiz.
Tabii ki ortak kültürlerimiz var ama ikisi aynı geçiş değil.
Aynı rotasyon tam olmuyor aslında.
Evet. Tripe'ler arasındaki rotasyon böyle ufak böyle bir iş değişikliği gibi oluyor.
Çünkü teknoloji stekleri de bazı noktalarda değişiyor.
Problemler değişiyor. Ama Tripe içerisindeki rotasyonlarda şey oluyor genelde işte terminoloji aynı.
İşte Alper bize geldiğinde zaten listing ne olduğunu biliyordu.
İşte varyant ne, content ne.
Bu bilgiler Alper'de zaten vardı.
Ama başka projekten geldiğinde işte domen çok farklı geliyor insana.
O böyle yeni bir işe girmiş gibi bir heyecan oluyor.
Kesinlikle. Yani bizler mesela full film içerisinde işte rotasyonlar olunca ekipler arası şey diyoruz.
Evet yine depodayız.
Bu sefer ama deponun işte mal kabulündeyim.
Ama bu sefer artık iadesindeyim.
Artık şu kısmındayım gibi.
Ama hep bir... şeyi biliyoruz yani.
Overall architecture'ı biliyoruz tüm süreci.
O süreci şimdi farklı bir kısmını daha detaylarına iniyormuşsun gibi oluyor.
Çok benzeri bir kafam. O tarz rotasyon başka bir isim verilmeli bence ya.
Çünkü ben de geçen yıl ekibime rotasyon yaptım.
Ben de seller tribe'ından Discovery'e geçtim.
Tamamen dediğin şeyi yaşadım yani.
Ürün ne, content ne, listing ne hiç bilmiyorum bu tarafları.
Böyle tamamen yeni bir işe girmiş gibi hissettim yani.
Sudan çıkmış balığa dönüyorsun.
Tamamen biznesler değişiyor böyle.
Güzel ama buna hep böyle farklı yani kofralarından çıkıp böyle sana yeni şeyler katıyor kesinlikle.
Benim rotasyonda atlatamadığım bir şey vardı.
Ekipte de çok geyiğini yapmışız.
Ben hep yani kaç ay oldu?
2-3 ay boyunca falan listing'e geçtikten sonra hala Product Core'da yapılan bir şeyden ya da Product Core'un yaptığı bir şeyden bahsederken biz diyorum.
Alper. Senin bizin de işte artık biz listenizdi.
Artık kabullen bunu. Belki biraz da geyikle o biraz yani espriye vurduğum gibi oldu ama gerçekten o rotasyonla alışma sürecinin bir temsilcisi gibi bir
şey aslında. Evet o biraz da şey yapıyor.
Bilinçaltını veya o alışkanlıkları eski alışkanlıkları geri getiriyor yani.
Ama güzel rotasyon hepimize gerçekten de konfor alanına çıkarıp dediğim gibi farklı şeyler katıyor, güçler katıyor.
tren yolu farklı kollarını görmüş oluyorsun diyeyim.
Ve bu kolları geçerken de mesela az önce şeyden bahsetmiştik.
45 tane işte 45-46 ekip dinleşti.
Onlardan biri de bize sizin klanklarınızdan biri örneğin.
Yani bu kadar çok ekiple çalışmak diyelim ki bizim tarafta da bizimkisi kadar fazla değil.
Yani çalıştığımız ekip sayısı.
Ama onlara rağmen bizde bile yani ekiple aynı olmak işte gelen işlerde bunlar önceden konuşmak, toplantılarını yapmak vesaire gibi şeyler illaki bir challenge oluyor.
Yani belirli bir odak gerektiriyor diyeyim.
Sizin tarafta mesela bu işin bir challenge'ı veya ki eminim challenge'ı vardır.
Bunun için kurduğunuz bir düzen veya bir iş ayrımı, görev ayrımı vs.
var mı? Bizim tarafta aslında şöyle ilerleyişler.
Genelde farklı ekiplerle çalışacağımız zaman.
Bizim mesela Slack'ta şey kanalları yok.
Ekip bazlı, mesela Fulfillment ekibiyle denkmen bir kanalımız yoktur.
Ama sizin tribe'la bizim tribe'in ortak olduğu bir kanal vardır.
Çünkü şey oluyor yani biz sizin ekiple bir konuşsak bile belki farkında olmadan başka ekip de etkilenebilir.
Biz bundan çekindiğimiz için genelde konuşmaları DM üzerinden de yapmıyoruz.
Ekip bazlı da yapmıyoruz.
Genelde tribe bazlı collaboration kanallarımız oluyor.
Offering ve katalog tribe'ların mesela collaboration kanalları var.
Ya da diğer ekipler SPM ekibiyle, SPM tribe ile aslında bizim offering'in ortak kanalları var.
Bu ortak kanallardan, tribe kanallarından yönetmeye çalışıyoruz konuşmaları.
Ve genelde her şeyi şey yapmaya çalışıyoruz.
Bir dokumentasyonunu oluşturmaya çalışıyoruz.
Bir ilgili ekip bir işte RFC gibi bir döküman başlatıyor.
Sonra diğer ekibin de buna bir kontribüsyon yapmasını bekliyoruz.
Sonrasında bunu tribe kanallarından paylaşıp hani olası etkilenecek ekiplerin işte orayı bir tekliyoruz.
Onların da bir revüme etmesini istiyoruz.
Rehberimizin muhakkak devraş ekiplerini şey yapmaya çalışıyoruz.
eklemeye çalışıyoruz. Çünkü bir de bizim en büyük çıktığımız şey oldu işte.
Datalarımızın hepsi işte BigQuery'e besleniyor.
Oradan raporlamalar da etkileniyor.
Farkında olmadan DLH tarafındaki akışları da bozmak istemiyoruz.
Onları da süreçlerimize dahil ediyoruz.
Ama genelde şey oldu işte RFC'ler üzerinden, collaboration kanallarından yürütüyoruz bu süreçleri.
Mantıklı ya. Yani şey ortak kanallar vs.
Mesela ben şey kısmını hiç düşünmemiştim.
Her ekip acaba ikili konuşmalarınız, kanallarınız mı var sandım.
Konuşmanın başına öyle bir çıkarma yapmıştım.
Ama yok dediğin gibi bu sefer konuştuğun şey belki başka bir ekibi etkiliyor ve bunlar haberin olmuyor.
Evet. Ortak mantıklı sermiş.
RFC alışkanlığı da değilmiş aslında.
Ben RFC'ler deyince daha çok sadece tribe veya şirket genelinde olması gerekiyormuş gibi ya da alışkanlıklar hep bu yöndeymiş gibi düşünüyordum.
Ama sizde sanırım daha farklı olabiliyor.
Aynen öyle. Çünkü şey diyelim iki ekip beraber bir iş yapacak.
Buradaki motivasyon ne? Impact ne?
O ekip neler yapacak?
Biz neler yapacağız?
Eğer bir migration olacak mı?
Review eden arkadaş mesela bunu görüp sorabiliyor.
Buradaki dataların migration nasıl olacak?
Oldu da bir rollback senaryosu oldu.
Nasıl rollback yapılacak? Hangi ekip neyi yapacak?
Biz buradaki RFC dokümanlarını eklemelerini istiyoruz mesela.
Hangi future flag'ler var sizde?
Biz bu geliştirmeyi yaptık.
Siz de bu geliştirmeyi yaptınız. İlk hangi future flag açılacak?
Sonra hangi future flag açılacak?
İşte genelde şey oluyor.
End-to-end testlerde işte Onur'u yolluyoruz.
Onur dahil oluyor. Diğer ekibin Developer Inc.
arkadaşıyla senaryoları beraber çalışıyorlar.
Oralarda beraber çalışarak aslında süreci yönetmeye çalışıyoruz.
O zaman şey mi? Yani o RFC'yi Developer'in testler ve PO'lar mı beraber dolduruyor?
Yoksa Developer'lar da dahil olup sprintten bunun için ayrı bir iş mi alıyorsunuz?
Nasıl ilerliyor orası? Tekrar vereceksiniz diyelim ya da iki ekip.
Teknik bir şeyle karar vereceksiniz.
Bir dizayn olur. Event olur.
Basit bir şey de olabilir. Örneğin.
Yok ona herkes yoksa tüm ekipçe girip RFC toplantılarım oluyor ya da.
Yok. Sprinterist analiz taskını açıyoruz.
Bir arkadaşımızı o taskı yürütüyor.
Eğer işin boyutuna göre bir arkadaşımız da pair oluyor o taska.
Aslında developer arkadaşlarımız ilk başta şey yapıyorlar.
Developer ve PM arkadaşlarımız RFC dokümanını oluşturuyorlar.
Sonrasında bu daha teknik karar verme aşamasında analiz sonucunda arkadaşlar da bizim ekibe gelip bir anlatıyorlar.
Mesela bizim ekipten bir arkadaş bir analiz yaptı.
Sonra bir saatlik bir takvim atıp analizin üzerinden beraber geçiyoruz.
Hani edge case ile bir challenge ediyoruz.
Hani çözüm ne kadar iyi ya da buna bu kadar efor harcamalı mıyız yoksa daha kısa yolda yapabilir miyiz gibisinden tartışıyoruz.
Ondan sonra sürece QA arkadaşlarımız dahil oluyor.
İşte test senaryolarını ekliyorlar.
Spesleri yapacağız. O şekilde araçları oluşturuyoruz.
Güzel bir şey. Farklı bir alışkanlık.
Bunları görebiliyor muyuz böyle bir yerde?
Pandora'da vesaire doküman olarak.
Evet. Biz bunları kendi tarihimiz altında aslında dokümentasyon olarak yapıyoruz.
Topluyoruz. Çünkü şey oluyor.
Genelde lucid chartlarını filan da çizip ekliyoruz.
Çünkü 3-4 ekibin dahil olduğu bir akış var.
Diyelim işte geçen sene yapılmış.
Şimdi orada bir üzerine bir şey çalışmamız lazım.
Ya da oradan bir akıştan şüpheleniyoruz.
Nasıl bulacağız o arkadaşları, o geliştirme yapanları.
Sonuçta domeninde sürekli değiştiği için ekip etmesi de zor oluyor.
Genelde uyguladığımız pratik şey oluyor.
Komiti kim yapmış? Git bileğinden bakıp oradan Jira kartını bulup oradan da RFC'sine Lucidchart'ına bakıp bir akışı tekrardan analiz ediyoruz.
Biz genelde Jira'daki teknik analiz maddesinin içine doldurup her şeyi oraya koyuyoruz gibi bir şey oluyor ama Sinki'de farklı ve güzel bir mantıkmış.
Böyle bir Belki kayıttan sonra bakabilirim.
Merak ettim. Aynen abi.
Peki ben şeyi sormak istiyorum burada ya.
Sprint başlarında da mı hep böyle RFC ile başlıyorsunuz?
Yani bir sprint düzeniniz nasıl ilerliyor?
Özellikle mesela çok fazla kontraktınız olduğu için deployment süreçleri falan da hep böyle kanala haber veriliyor mu yani bu süreçlerde?
Belki ben şey yapabilirim.
Analiz tasklarını genelde...
sonda yapmaya çalışıyoruz.
Sprintin sonuna doğru yani şey yaparken taskları assign ederken ilk önce bir implementasyon yükü ya da testi uzun sürecek taskları erkenden
stage'e çıkarmayı prioritize edip analizi kim ya da kimler boşa düşerse sprintin sonuna doğru öyle alsın diye ilerliyoruz.
Deployment konusunda da bence bayağı hızlıyız.
Ortalama günde 3 deployment çıkartıyoruz.
Pandora'daki statistiklerimize göre.
Aslında şey bunun üzerine bayağı odaklandık.
Bayağı bir retroda bunları konuştuk.
Çok fazla internal tool bağladık birbirimizi daha hızlandırmak için.
Mesela Limon vardı daha önce hiç bahsedildi mi bilmiyorum ama biraz daha GitLab, Jira ve Slack entegrasyon botu gibi.
Mesela BMR için Gerekli miktarda review geldiği zaman automatic ready for QA'ya ya da benzer şekilde task proda deploy olduysa dana çekiyor.
Jira'da öyle hareket ettiriyoruz.
Onun dışında kod review'da açık bir task varsa sürekli bildirim atan bir Slack botumuz var.
Böyle pratiklerle aslında kendimizi hızlandırmaya çalışıyoruz.
Son bir madde olarak da mesela taskların açıklamalarının ve MR'ların formatı konusunda biraz şeyiz, biraz...
Katıyız ama iyi katıyız bence.
Belli detaylar olsun isteriz.
Definition of Done'ı çok iyi belirleriz.
Belirlemek isteriz daha doğrusu.
Ki bu detaylar zaten sormayı beklediğimiz detaylar önümüzde hazır olsun ki MR Template'ın ya da Task'ın içinde biz önemli olan detaylara odaklanabilelim.
Diploid sayınız gerçekten hayran bıraktı.
Günde üç. Peki ben şeyi merak ediyorum.
Bu kadar fazla mesela diploid çıkılıyor ama işte bunun yani ne kadar çok çıkarsa bir şey o kadar da bence hata oranında artabilir tabii.
Hani hıza bağlı artıyor bence.
O yüzden biraz onura sorum olacak burada.
Peki buradaki QA süreçlerini nasıl ilerletiyorsunuz?
Bütün işte kontraktörler falan nasıl ilerliyor bir taskın içerisinde?
Şöyle aslında zaten Yani deployment'ın yüksek çıkmasının sebebi de biraz şey, süreçleri de iyi ilerletmeye çalışıyoruz.
Olabildiğince otomatize testleri sürece dahil edip aslında bir taskı DOD'ye uygun olarak işte etki alanlarını ve beklenenlerini karşılayarak release etmeye özen gösteriyoruz.
Var olan akışları da iyice analiz ettiğimiz için.
Burada kontrak testler veya smoke testleri daha implement etmedik ama otomasyon akışlarımız iyi, iyileştirmeye başladık epeyce.
Süreçlerde de işte önceliğinde test case'leri ilerletip zaten teste geldiğinde de otomatize testleri koşup aslında süreci hızlı bir şekilde akıtıyoruz.
Biraz öyle gidiyor yani süreçlerimiz.
Burada peki testler vs.
Örneğin bizde yük testleri yapılıyor.
Ve yani şöyle yapılıyor.
Bir bizim kendi içerimizde yük testimiz var.
Ama bağlı olduğumuzda çok yerler oluyor.
Okey onları üzere yapabiliyoruz ama bir de tribe bazlı yapıyoruz.
Çünkü bizim süreçlerde bir sürecin çok iyi olması yani çok yüksek yükü kaldırabilmesi tek bir sürecin.
Genelde çok da yararlı olmayabiliyor.
Yani evet teknik olarak puan olarak çok yüksek çıkar vs.
ama örneğin diyelim ki işte depo mantığıyla söyleyeceğim.
Bir yerde mal kabul yapılabiliyor.
Çok iyi mal kabul yapılıyor ama işte kabul edilen arabaların gerçekten transferi sonrası yavaş çalışıyorsa bunun çok bir önemi yok.
Hızlı çalışsa da aslında müşteriye katkısı o kadar da olmuyor.
O yüzden bizim için end-to-end yani tribe bazlı, depo bazlı yük testleri genelde daha mantıklı veya daha yararlı oluyor diyeyim müşteri içinde.
Mesela sizlere buna benzer mantıklar oluyor mu?
Aslında öyle, bizde de öyle.
Aslında kalite odaklı bir yaklaşım veriyoruz bizde.
Hani çıktığımız bir işte zaten genellikle işte clientlarımıza kaliteli bir yani datayı gerçekten güzel servis edebileceğimiz şekilde performans testleri de gerçekleştiriyoruz.
Hani bu bağlamda hatta bir limitlerimizi belirleyip rate limiting de uyguluyoruz.
Yani böyle yoğun trafik dönemlerinde de hani sistemin istikrarını koruyalım ve işte aşırı yüklenmeleri engellemeye çalışalım gibi.
Yani oraları da dikkatlice handle etmeye çalışıyoruz diyeyim.
Aslında listing ekibiyiz ama mesela direktmen son kullanıcı bize gelmiyor.
Bizim aslında eventlerimiz sonucunda oluşan indexing ekipleri var.
Son kullanıcı aslında orayı hit ediyor.
Yani bizim direktmen müşterimiz son kullanıcı olmuyor.
O bakımdan aslında diğer ekiplerin yüklesleri daha şey, daha kritik oluyor.
Bizim de şöyle sorunlarımız oluyor.
İşte yaklaşık trend yolda 550 milyon listing var.
imkansız aldığımız elastik searchlerimiz var.
Diğer ekipler buralara çok fazla search trafiği veriyor.
Bizden önceki ekipler ve bizden sonraki ekipler var.
Yani satıcı ekranlarından bize satıcı kendi listingini görmek için bize bir istek atılıyor.
Diğer taraftan da bizim datalarımız sonucunda son nihai, son kullanıcının gördüğü datayı oluşturmak isteyen ekipler bize bir yerden istek atıyor.
Biz tam böyle ortada bir ekibiz aslında.
O zaman sizdeki atıyorum real throughput'u daha yüksek oluyordur diye tahmin ediyorum.
Evet. Bizdeki real throughput daha fazla.
Ama şöyle daha fazla.
Bizim de search throughput fazla oluyor aslında.
Bizden sonraki ekip aslında bizim datamızı indeksleyip son kullanıcıya hazır hale getiriyor.
Okey. O zaman sizin datanızı da alıp öyle arama kısmına aslında dahil ediyor gibi bir şey.
Evet. Süper.
Büyük maliyet testlerinde işte bizim Ares gibi internet turlarımız vs.
var. Open Source yapmış mıydık onu?
Yok, dışarıya değil. Aynen.
Internal Boot Tool'umuz Ares isminde.
İşte onu kullanıyoruz vs. Peki geliştirme anlamında Backend olur vs.
ya da DB olur. Burada hangi tercihleriniz var ya da neleri kullanıyorsunuz?
Uygulamalarımızın büyük çoğunluğu Kotlin ile yazıldı.
Kotlin ile async programlama çok kolay.
İşlerimizi çok hızlıca çözebiliyoruz ama artık yeni yazdığımız uygulamalarımızı Golang ile yazmaya çalışıyoruz.
Çünkü Golang ile minimum kaynakla performans uygulamalar yazabiliyoruz.
Böyle özetleyebilirim. Kotlin ve Golink uygulamalarımız var.
Veri tabanı olarak da NoSQL veri tabanlarıyla çalışıyoruz.
Ana datamız Couchbase'de tutuluyor.
İşte key volume mantığında çalıştığımız basit veri erişimi olan endpointlerde Couchbase'e kullanıyoruz ama demin Enes'in anlattığı gibi kompleks search kuralları için Elasticsearch'ı kullanıyoruz.
Couchbase'deki data aslında Elasticsearch'e de indeksleniyor ve kompleks kuralları burada çalıştırıyoruz.
Mikroservis mimariye sahibiz.
Burada da message broker olarak Kafka'yı çok yoğun bir şekilde kullanıyoruz.
Çok böyle hızlı böyle özetleyebilirim.
Kotlin'i backend olarak kullanan ekip sayısı sanırım daha az.
Genel olarak böyle bölümlerimizde şey oluyor.
Go, Java. Bizim tribe'de mesela .NET var.
Ama artık .NET gerçekten çok az ekipte var.
Ama Kotlin'de mesela sizde kullanıyor birkaç ekipte daha vardı.
Product tribe'ın aslında popüler.
Yakın çalıştığımız ekipin hemen hemen hepsinde.
Product tribe içinde Kotlin kullanılıyor.
Burada memnun musunuz peki Kotlin'den?
Genel bir fikirliğiniz neler?
Memnun musunuz ya da şey diyor musunuz mesela atıyorum business ağırlıklıysa Kotlin ama değilse o zaman Go kullanırız gibi bir mantığı var mı sizde?
Aslında öyle yok. Biz listing ekibine geldiğimizde Kotlin uygulamalarımız vardı.
İlk defa ben de Kotlin'le listing ekibinde kod yazmaya başladım.
Java'dan Kotlin'e geçişimiz hızlı oldu.
İkisi de JVM tabanlı olduğu için.
Ama dediğim gibi özellikle async programlama tarafı Kotlin'de güçlü.
Orada işlerimizi hızlıca halledebildik.
Golang tercihine geçmemizin sebebi demin dediğim gibi minimum kaynak maksimum performans.
JVM tabanlı olduğu için Kotlin uygulamaları biraz yavaş ayağa kalkıyor.
Biraz fazla kaynak tüketiyor.
Golang'da bunları minimize edebiliyoruz.
Öyle bir şeyimiz yok işte biz ne sağlıklı yeri Kotlin'le diğer uygulamaları Golang'da yazalım gibi bir ayrımımız yok.
Bizim ekibin dışından bir bilgi vereyim.
Hatta bu kaynak muhabbetinden ötürü.
Kotlin uygulamalarını ya da diğer dillerde yazılan uygulamaları ekipler müsait backlogları olduğu zaman Goleng'e de çeviriyorlar.
Bizim de uzun vadede öyle planlarımız var.
Benim eklemek istediğim bir şey vardı aslında Kotlin konusunda.
Ben Kotlin'in şeyini seviyorum.
Üniversitede Java 8 kullandım yoğunlukla.
İlk öğrendiğim dilo'ydu.
Sonradan ev gibi hissettirdi zaten.
Trendyol'dan önceki iş tecrübelerimde de yoğunlukla Java kullandım.
Benim Kotlin'le ilk tanışmam şeyde oldu.
Trendyol'da oldu ve Gerçekten Java'da olmasını istediğim ama olmayan her şey Kotlin'de varmış gibi hissettim.
Mesela parametrelere default değer verebilme, nullability'nin explicit olması ya da fonksiyonel paradigmalar böyle daha temiz yazılıyor bence.
Ben Kotlin hakkında onu diyebilirim yani.
Java ekosisteminin fırsatlarını çok daha rahat bir şekilde sunuyor benim gözümde.
O yüzden Kotlin'le backend yazmak apayrı bir heyecan.
Gayet seviyorum. Go'yu da seviyorum.
Go rengi haksızlık olmasın ama.
Bence sevmiyorsun. Sen Go'yu sevmiyorsun.
Ama Kotlin'i sevdiğim belli oldu evet.
Kotlin'i seven gerçekten bu arada kullanan, kullanıp da böyle memnun ya ben memnun değilim çok diyen az kişiyle karşılaştığım gibi.
Yani kullananlar genelde artık Java'dan Kotlin'i geçtikleri için mi ekstradan onları gözüne daha da güzel geliyor yoksa sıfırdan geçmelerine rağmen mi?
Ben kullanmadığım için bilgim yok.
Ama memnuniyet oranı yüksek yani gerçekten de.
Kotlin'i bu kadar övmüşken bir de şeyinden bahsedeyim.
Gördüğüm bir zararından bahsedeyim.
Ben IntelliJ dışı bir IDE'de şey yapmaya çalışırken bizim projelerimizi kaldırmaya çalışırken yani IDE'de demeyeyim özellikle editörlerde projelerimizi kaldırmaya çalışırken
orada JetBrains'de elde ettiğim kadar rahat bir çalışma ortamı elde etmeye çalışırken çok zorlandım.
Ve eninde sonunda...
pes edip JetBrains'e geri döndüm aslında.
O da biraz zihnimin arkasını kaşıyor gibi.
Bir tarz böyle IDE konusunda bir vendor lock-in oluyormuş gibi bir nevi.
İyisi de kötüsü de var ama bence iyileri kötülerinden alır.
İlla ki ya. Ve şey mesela benim kafamda şey işleşmiş.
Olmadığım bir dünya ama mesela yüce bacı bir insan işte intelijeyi dışında hiçbir şey kullanamaz ya da yani çok kullanman o kadar yüksek ki Hani Java eşittir, IntelliJ'dir.
Kafamda hep böyle bir eşleşme olmuş.
Mesela .NET biz çok fazla kullanıyoruz, çok aktif kullanıyoruz.
Önceden şey mesela bende, .NET ise Visual Studio'dur örneğin.
Ama işte Rider kullandıktan sonra şey oldum, hayır Rider da çok iyi, ben Rider kullanacağım.
Bu sefer işte, okey .NET demek ki Rider ve Visual Studio bu işin işte ileri gelenleridir.
Örnek veriyorum. En çok kullanılan ide gibi.
Böyle kafamda belirli diller için belirli ideler eşleşmiş mesela.
Sen bunları söyleyince fark ettim.
Değil mi? Ben de Java Kotlin ve JetBrains ID'leri hakkında öyle hissediyorum gerçekten.
Evet evet. Gerçekten öyle.
Burada aklıma gelmişken şeyi soracaktım.
Genelde böyle ekiplere şeyi soruruz.
İşte monitoring ve alert kısımlarda özellikle yaptığınız şeyler var mı?
İşte bazı önemli alertler genelde şeyden geliyor.
İyi bir incident yaşamışsındır ve onun alerti yoktur.
O yüzden onun alertini kurmuşsundur.
Yani bazı alertler böyle yaşanmışlıkların alerti oluyor.
Hani ilk aklına gelen alert değil de tecrübeyle gelen alertler oluyor vesaire.
İşte sizin de böyle kurduğunuz yani işte şunları özellikle monitör ederiz.
Şunlar için özellikle alertlerimiz vardır.
Ve hani şöyle bir incident yaşadık.
Anlatabileceğiniz güzel bir incident varsa onu da dinlemek isteriz.
Ki vardır diye düşünüyorum.
Bu soruya ben cevap vermiş olayım.
Ekip olarak aslında oldukça...
Kapsamlı monitörlük ve alorting yapımız var.
Diğer ekiplerin de kullandığı gibi yaygın araçlardan, Prometheus, Grafana, Kibana gibi yaygın araçları biz de kullanıyoruz.
Ama sadece bunlarla da sınırlı kalmıyoruz.
Kendi ihtiyaçlarımıza göre bazı araçlar da geliştirmeye başladık.
Bu araçlardan biri de Shiva.
Shiva bizim alort kanallarımızdaki iş akışını ciddi anlamda iyileştirmeye başladı.
Mesela bir alort düştüğünde kanallara, Shiva uygulaması otomatik olarak sistemlerden atıyorum.
Bir POD olur, bir Kafka, bir Couchbase olur veya herhangi bir bileşen.
O sistemle ilgili detayları çekip direkt ilgili silahın threadini iletiyor.
Bu da aslında olayın bağlamını daha iyi anlamamıza sağlıyor.
Yani bir şey bozuldu demiyoruz da ne oldu, neden olabilir, o an sistemde ne oluyor gibi bilgileri anlık olarak bizde paylaşmış oluyor.
Bu sayede de ekipler aslında çok daha hızlı harekete geçebiliyor.
Yani hata ayıklama sürecini de kısaltıyor.
Tabii sadece threshold-based alarmlarla da ilerlemiyoruz.
Sistemdeki olağan dışı davranışları yakalayabilmek için anomaly detection tavanı alarmlarımız da var.
Bu sayede işte beklenmedik bir durum varsa örneğin işte veri akışında bir gariplik var diyelim.
Bunları erkenden fark edip müdahale şansı yakalıyoruz.
Bir de olayları geriye dönük isteyebilmek için audit altyapımız var.
Özellikle Kafka topiklerindeki dönen eventleri veya işte kritik veri akışlarını elastik searchlerine saklıyoruz.
Bloglar sayesinde olaylar arasında neler olmuş, hangi sırayla olmuş, ne gibi, ne zaman olmuş gibi şeyleri detaylı bir şekilde görebiliyoruz.
Bunun üzerine de aslında yine Kronos adında UI geliştirdik bu audit altyapısı için.
İşte bu sayede de verileri timeline şekilde izleyebiliyoruz.
Bu da hem olayların kök nedenini bulmamıza yardımcı oluyor hem de sistemin genel davranışını daha yeni analiz etmemizi sağlıyor.
Bizim biraz altyapı bu şekilde diyebilirim açıkçası.
Ben Kronos'a geçen denk geldim.
Bir ya da iki hafta önce. Siz mi yazmışsınız bilmiyorum.
Yazdıysanız elinize sağ olun. Gerçekten.
Ben yazdım evet. Evet süper.
Sonra gidip reposuna falan da baktım.
Ne bu? Open source bir ürün. de bizimkiler alıp hani üstüne mi koymuş bizimkiler mi yazmış vesaire tam böyle anlamamıştım.
İşte ona bakıyordum vesaire.
Gerçekten güzel ürün yani eline sağlık.
Eyvallah. Yani bir timeline akışı gerçekten böyle yani bilmeyenler için arkadaşlar işte anlatayım.
Gerçekten bir yay var ve bir timeline var gerçekten adım adım.
İşte şu an bu olmuş. Bu ürün başında bu gelmiş.
Bir ürünün hayatını görüyorsun gibi böyle.
Benim baktığım örnek en azından öyle bir şeydi yani.
Evet aslında şöyle oluyor yani genellikle işte support isteklerinde geldiğinde direkt olarak hani gerçekten o ürünün başına ne gelmiş yani tabii listingin başına ne gelmiş gibi.
Tek tek akışları izleyerek daha aslında hızlıca sorunu çözmeye odaklanabiliyoruz diyeyim yani.
Ve çıktılar da supportlara çıktılar da çok kolaylaştı o şekilde.
Kronos da sanırım zaman tanrısıymış değil mi?
Ben aynen timeline'a uygun bir isim seçmek için öyle bir şey araştırdım evet.
Evet bu bilgiyi paylaşmak istedim teşekkürler.
Ben de biraz üzerine ekleyeyim.
Bizde baya bir Tanrı ismi var aslında.
Yani API'larımızın isimleri arasında Heimdall, Janus mesela var.
Zaten visible tool kullanmalarımız Kronos, Hekate, Shiva.
Ekip içerisinde böyle tool'larımızı ya da şeylerimizi genel olarak tool'larımızı mitolojik Tanrı figürleri isimlendirme geleneği var ya.
Bir de şey yani mesela sadece Yunan mitolojisi ya da Sadece İskandinav mitolojisi değil.
Her mitolojiden var ve bağlantılı bir tanrı da.
Rastgele bir tanrı ismi koyup da bazı projeler olur ya bir isim var.
Rastgele bir tanrı ismi de koymuş olabilir.
Hiç öyle değil. Hepsinin gerçekten bir background'ı var.
O yüzden çok iyi. Burada Onur Şiva'dan bahsetti.
Ben bil anlatamadığımızı düşünüyorum.
Benim işimi şöyle kolaylaştırıyor onu anlatayım.
Mesela bizim legalertlerimiz var.
İşte nöbetçi olduğumu düşünün.
Gece bir legalerti geldi.
İşte bilgisayarı açıp bir holderdan lag grafiğine bakmak yerine o threadin altına aslında shiva işte son 1 saatlik 2 saatlik lag grafiğini bize çiziyor hiç bilgisayarı açmadan sadece telefondan
slackten ne olmuş topikteki lag nasıl onu inceleyebiliyoruz t'leri filan da yapıyor bizim error retry topiklerimiz var oraya error topiğine mesaj düşünce bize şey geliyor alert geliyor yine bilgisayarı
açıp topiğe ne geldi kontrol etmek yerine işte o topiğe gelen son 10 mesajı En popüler o mesajı Shiba bize thread'de veriyor.
Oraya bakıp ne olmuş?
Ignore edilebilir bir alert mi?
Bildiğimiz bir durum mu? Ona bakıp zamandan kazanabiliyoruz.
O çok iyiymiş ya.
Mesela bizim fail alertlerimiz var.
Yani exception topiğine düşen mesajlar.
Böyle onun thread'ine mesela oraya düşecek bazı mesajları peak gibi görmek önden ya da dışarıdaysan telefondan bakmak on call.
Bizde çünkü on call 724 operasyon var vesaire.
Görmek çok mantıklıymış bunu.
Ben de bir düşüncem çok iyi.
Yani Shiva'yı entegre etmek çok basit.
Onun size destek olur muhtemelen.
Onu bir konuşalım ya o zaman.
Ben bunu bir merak ettim. Güzel bir şeymiş o.
Ben bilmiyordum. Yeni öğrendim.
Bir de buradan çıkıp overhaul'da baktığımız gibi anomali aletlerimiz var.
Onlara da değinelim. İşte bizim için anomali yaratabilecek durumları aslında biz bir şekilde alet tanımlamak istiyoruz.
Bunlar neler olabilir? İşte Türkiye'deki satılabilir listing sayısı.
Belli bir zaman aralığında atıyorum %10 düştüyse bu bir alert sebebiyeti verilebilir.
Arka planda yanlış bir operasyon yapılmış olabilir.
İlgili ekiplere böyle bir düşüş var.
Beklendik bir durum mudur diye uyarı çıkarabiliyoruz.
Bu tabi sadece Türkiye için değil satış yaptığımız tüm ülkelerdeki satılabilir listingler için böyle durumlar var.
Yine podcast'ın başında anlattığım listinglerin farklı kapanma sebepleri olabiliyor.
Orada da belli başlı...
Sebeplerle kapanmış listing sayılarına alertlerimiz var.
Atıyorum işte orijinallik sebebiyle kapanmış listing sayısı belli bir zaman aralığında belli bir threshold'un üstünde arttıysa burada bir operasyon mu var, yanlış bir işlem mi var diye ilgili ekipleri uyarıyoruz.
Böylelikle olası incident'ları bir tık da olsa önceden çözmeye, engellemeye çalışıyoruz.
Süper. Peki burada yani anomali alertleri bu arada biz de şey için kullanıyoruz.
Biz de Beholder diye ekibimiz var.
Daha önce onları da misafir etmiştik.
İşte onların anomali alertleri vs.
İşte biz de onların pilot ekiplerinden biriyiz.
Buna gibi denemeler yapıyorlar vs.
Ve orada çok güzel işler çıkarıyorlar.
İşte throughput da olsun, error rate da olsun vs.
İşte değişimler oluyor vs. gibi kısımlar var.
Biz orayı takip ediyoruz. Ve yararı da gerçekten oluyor.
Ama onun hassasını ayarlamak vs.
kolay olmayabiliyor. Ve çok fazla ürününüz var gerçekten.
Yani böyle gerçekten katkıda bulunuyorsunuz yani.
Hem kendiniz hem de dışarıya.
Burada bu bilgileri ne kadar paylaşılabiliyor musunuz dışarıya?
Öyle sorayım ya da hani. İşte open source olur ya da Medium'da yazı olur.
Bizde bazı ekipler çünkü işte Medium kanalımızı takip edenler varsa orada işte biz şöyle bir problemle karşılaşmıştık.
İşte şöyle bir şeyle çözdük gibi.
Ekip ona çok uygun bir ekip gibi duruyor.
Ondan dolayı soruyorum. Ya da böyle bir planınız var mı diyeyim yoksa da?
Bu zamana kadar paylaştığımız Medium yazıları oluyor.
Yakın zamanda aslında Arif'in şeyi vardı.
Mesela Elastik Search'ten çok...
10 milyon ya da 20 milyon bir data çekeceğiniz zaman bir search sonucunda scroll ile çekmemiz lazım.
Ama çok uzun sürüyor.
Diyoruz ki biz her datanın içerisine bir tane partition değeri ekliyoruz.
O partition değerlerine göre mesela paralel çekebiliyorsun.
Bu güzel bir yaklaşımdı. Bunun için mesela bir medium yazısı yazmıştı.
Hatta YouTube'da bir video da çektiler.
Trendo Learning kanalına.
Bizim private de çoğu ekip bunu kullanıyor.
Mesela şey de yapıyoruz. Bizim işte 550 milyon listingimiz var.
Ama bize işte search olarak 5-6 milyon RPM'de istekler geliyor.
İşte load test sonucunda baktık.
Mesela bir şey olmadı. Elastik serverimiz mesela bunu kaldırmadı.
Aktif aktif kullandık ama yine kaldırmadı.
Sonrasında iş şeye döndü.
Dedik ki biraz araştırdık.
İşte bir de istek atan ekiplere baktık.
Çoğu ekip mesela diyelim item number'la istek atıyor.
Dedik ki bunun elastik search tarafından nasıl optimiz edebiliriz?
Routing kullanmayı denedik.
Routing'e göre, item numaralara göre routing uyguladığımızda işte load test yaptık.
Baya performansımız arttı.
Response time'larımız baya bir düştü.
Buradaki bir learning'i bir medium yazısına çıkardık.
Bir medium yazısı olarak paylaştık.
İşte zaten Trendle içerisindeki Elasticsearch kuyrukları falan oluyor.
Orada da bu yaptığımız dediğimiz şeyleri, learning'leri paylaşıyoruz.
Onun haricinde Trendle'de zaten open source projeleri var.
İşte GoDCP Kafka var.
GoDCP Elasticsearch var.
Kafka Consumer var. Biz bunları kendi ekibimizdeki projelerde kullanıyoruz.
Futur'a ihtiyacımız olduğunda o projeye kontribüsyon sağlamak herkesin problemini çözmüş oluyor.
Yakın zamanda GoDSP Kafka projesine bir site, sinkini, sponsorlarını gibi bir yaklaşım ekledik.
Biz normalde şey yapıyoruz.
Kafka eventlerimizi başka bir Couchbase vakıtına yazıp vakıt üzerinden eventler atıyoruz.
Eventleri kaçırmamak için. İşte ne yapalım dedik.
Burada bir GoDSP Kafka kullanalım.
Şimdi ne yapacağız? Kafka'ya event başarılı şekilde atıldıktan sonra eğer success ise gitsin eventi bucket'tan silsin.
Mesela önceden böyle bir feature yoktu.
Bunu biz implement ettik.
Bizim ihtiyacımız doğrultusunda.
Sonrasında bunu GoDSP Elasticsearch'e filan da arkadaşlar implementasyonu yaptı.
Şu an bayağı ekipler kullanıyor.
O bakımdan hem Trendyol'un open source projelerini kullanarak oralardaki ihtiyaçların biz kontrolü yapıyoruz.
Herkes yararlanmış oluyor. Diğer taraftan başımızdan geçen learningleri de, deneyimleri de müdüm yazılarıyla paylaşmaya çalışıyoruz.
Gerçekten şirket taşı her yere bir katkı var çok iyi.
Elinize sağlık hepinizin. Evet bir de şey var işte Onur'un yaptığı bu Shiva'dır, Kronos'tur.
Bu projelerde de aslında Trendle içerisinde herkes, daha doğrusu bizim Tripi'yi aktif olarak kullanıyor ama daha Trendle serisini de yaymaya çalışıyoruz.
Elinize sağlık tekrardan.
Peki ben şeyi de merak ediyorum.
Çok fazla iş ve teknik konuştuk.
Sizin ekip içi iletişiminiz nasıl oluyor?
Bunu güçlendirmek için neler yapıyorsunuz?
Boş toplantılarınız, etkinlikleriniz falan oluyor mu?
Bunu belki ben cevaplandırabilirim.
Evet yapıyoruz aslında. Mesela takım içi iletişime değinmek gerekirse biz birebir kültürünü çok önemsiyoruz.
Yani sadece liderlerimizle ya da belki...
Bizim domenimize aynı bakış açısıyla bakmaya mesela developer PO gibi birebirler değil sadece biz hepimiz her birimizle düzenli olarak birebir yapmaya feedbacklerimizi samimi
bir şekilde iletmeye çok önem veriyoruz.
Fikir ayrılıkları olduğu durumda herkesin çekincelerini rahatça belirtebildiği herkesin eşit söz hakkına sahip olduğu bir ortam kurmaya da özen gösteriyoruz.
Bunun dışında biraz daha İş dışı iletişimi geliştirmek adına haftalık Fun Time ve Light Talks toplantılarımız var.
Bence kardeş ekibimiz diyebileceğim inventory ekibiyle beraber yapıyoruz.
Dinleyenler için onların da selam ekip bölümleri var bir uğrayın derim.
Fun Time'da genel olarak oyun oynarız.
Sohbetle karışık, çerezlik çok da odak gerektirmeyen bir oyun oynar.
Light Talks'da da... Ya sohbet eder ya da mesela birisinin anlatmak istediği yazılımla alakalı olsun olmasın bir şey olur.
Başkalarıyla paylaşmak istediği ilginç bir bilgi.
Onu da dinlediğimiz oluyor.
Tatil anıları mesela.
Bunlar gibi şeyler de.
Bizde genelde şey oluyor. Bazen oyun oynuyoruz dediğin gibi.
Şu an ismi unuttum bir arabayla birbirini patlatma oyunu vardı.
Arabayla. Evet.
Oyun oynuyoruz. Baya eğlenceli.
Çok gaza gelebiliyorsun. Ya da kinlenebiliyorsun.
Vesaire. Oyunda başka bir karakter olabiliyorum.
Ben de bazen ya da başkaları. Güzel olabiliyor.
Ya da dediğim gibi daha light house oluyor.
Çünkü bazen böyle oyun modunda olmuyorsun.
Daha böyle ya da birilerinin konuşacak bir şey oluyor ya da sohbet sarıyor vesaire.
Oyuna girmeyip sadece takılıyoruz yani boş boş.
İleriki muhabbet bir şeyleri açıyor ve birilerinin her zaman anlatacak bir şeyleri oluyor.
Belirli bir konu olmuyor yani her zaman.
Ve bir şekilde kendiliğinden akıyor.
Bizim bir de farklı yaptığımız bir şey toplantısı var.
Domini Refreshing toplantısı var aslında.
Böyle iki haftada bir yapıyoruz.
Burada işte arkadaşlar aslında Ekip içerisinde birbirimize işte domain ile business akışlarıyla alakalı böyle işte sorular soruyoruz birbirimize.
Birimizi öyle bir challenge ediyoruz.
O hal şey oluyor. Domain know-how'ın herkese davranmasına sebep oluyor.
Güzel bir motivasyon oluyor.
Hem de yine Lightbox havasında muhabbet ettiğimiz bir sesyon.
Ama şey oluyor yani domain know-how'ını bazen şey olabiliyor işte.
Üç ay önce bir arkadaşın implement ettiği akış.
ekibin diğer tarafına belki çok geçmemiş olabiliyor.
O akışla alakalı mesela sorular soruluyor.
Size bildin bilemedin işte bunun yarışmasını yapıyoruz kendi içerimizde.
O da güzel oluyor. O da iyiymiş.
Bunu ilk defa duydum. Ama güzelmiş.
Özellikle böyle bizzatlar vesaire çok fazla ise bir kişide kalma ihtimali varsa o kişinin ya da belirli kişilerde kalma ihtimali onun böyle nohavanın dağılması için doğal bir yol gibi böyle.
Aynen. Güzel mantıkmış.
Beğendim. Bizim taraftalarca şu an böyle bir şey olabilir mi diye bir düşüncem bende.
Güzel mantıkmış. Evet.
Yavaştan o zaman kapanışa geçiyorum.
Arkadaşlar çok teşekkürler hepinize geldiğiniz için.
Bu bölümde 79. bölümdeydik.
79. bölümümüzün bu bölümünde Product Listing ekibiyle beraberdik.
Tanıdık. Gerçekten de farklı farklı challenge'lar olan, bir sürü ürünü olan, hem şirket için hem şirket dışında böyle katkıları olan bir ekip.
Tekrardan geldiğiniz için çok teşekkür ederiz arkadaşlar.
Bir sonraki bölümde görüşmek üzere.
Bye bye. Biz teşekkür ederiz.
Görüşmek üzere. Teşekkürler.
Görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.