afetharita.com binlerce depremzedeye nasıl yardım etti?

Eray Gündoğmuş
19 min readFeb 21, 2023

click for english

afetharita.com

Özet

6 Şubat 2023'te Kahramanmaraş bölgesinde gerçekleşen ve 10 ile etki eden 7.7 ve 7.6 büyüklüğündeki depremler 19 Şubat verilerine göre 22 bin 327 kişinin hayatını kaybetmesi, 80 bin 278 kişinin yaralı olarak kurtulmasına neden oldu.

Depremden saatler sonra Eser ve Furkan öncülüğünde kurulan ve bilgi işlem profesyonellerinin gönüllülüğe davet edildiği AYA: Açık Yazılım Ağı Discord sunucusunda kurtarma ekiplerine, depremzedelere ve yardım etmek isteyenlere kaynak olabilecek bir proje geliştirmeye başladık: afetharita.com.

Kısa bir özetle böylesine büyük bir depremin ilk günlerine hazırlıksız yakalanıldığı için zor durumdaki afetzedeler acil yardım taleplerini sosyal medya üzerinden yapmaya başladılar. Binlerce gönüllü ile birlikte yapay zeka ve makine öğrenimi gibi teknolojileri kullanarak sosyal medyadaki bu yardım taleplerini okunaklı verilere dönüştürdük ve afetharita.com üzerinde görselleştirdik. Daha sonrasında ise afet ile ilgili ihtiyaç duyulabilecek önemli verileri gerekli kurumlardan toplayıp haritaya ekledik.

35 milyon toplam istek ve 627 bin özel ziyaretçi rakamlarına ulaşan ve afetin en acil ve kritik dönemlerinde yazılım desteği sağlayan ve STK’ların, gönüllülerin ve afetzedelerin afet ile ilgili önemli verilere ulaşmasında büyük etki gösteren bu uygulamada sürecin nasıl geçtiğini neler yaşadığımı ve teknik detayları açıklıkla yazıya dökmek istedim.

afetharita.com 10 günlük istatistik

Oldukça uzun bir yazı olacağı konusunda uyarmalıyım.

Yazının tamamını okuduğunuzda böyle bir projenin uçtan uca nasıl geliştirildiği, birçok disiplinin bir arada nasıl çalıştığı, teknik kararların hangi kriterlere göre alındığı, nasıl yönetildiği ve benzeri konuları teknik geniş bir perspektiften görebileceksiniz.

Başlarken

Depremden birkaç saat sonra projenin frontend tarafına katıldığımda tam bir kaosla karşılaştım. İnsanlar yardım etmek istiyorlardı, ancak nasıl katkıda bulunabileceklerini bilmiyorlardı. Bu nedenle, eyleme geçmek ve bir plan oluşturmak için acilen harekete geçmemiz gerekiyordu. Sorduğum gibi herkes ne yapabileceğini düşünüyordu. Bu sırada arkadaşım Zafer, harita entegrasyonunu benim üstlenebileceğimi söyledi. Bu sayede, projeye katkıda bulunmaya başladık.

Bu noktada, dünya çapında bir örneğe dönüşecek bir projeye başladığımın farkında bile değildim.

İlk 3 saat: Belirsizlik

  • Ne kadar süremiz var?
    Kısıtlıdan daha az. Çok az diyebiliriz.
  • Tasarım nerede?
    Henüz net bir tasarım yok. Bununla birlikte, proje geliştirme sürecinin hızlı bir şekilde ilerletilmesi için detaylı bir tasarım çalışması yapmak için zaman olmayabilir.
  • Uygulamayı yoğunlukla kim ve hangi cihazdan kullanacak?
    Depremzedeler, saha ekipleri ve STK’lar bu verileri kullanabilirler. Bu nedenle, arayüzün anlaşılır ve teknik detaylardan uzak olmasının önemli olduğu söylenebilir. Ayrıca hem depremzedelere hem de hareket halindeki ekiplere en yakın cihazın telefon olacağı öngörüldüğünden mobil öncelikli arayüzler geliştirilmeliyiz.
  • İnternet hızı?
    Deprem sonrası afet durumunda internet hızı genellikle düşük olabilir. 2G internet hızı ortalama 0.1 mbs/saniye, 3G hızı ise 3 mbs/saniye olabilir. Bu nedenle, proje geliştiricileri backend takımıyla koordinasyon halinde en hafif veri akışı ve modelini belirlemeli, böylece kullanıcıların en kötü senaryolarda bile hizmet alabilmeleri sağlanmalı.

Nerede kalmıştık? Zafer, abi napıyoruz? Evet, harita.

Toparlarsak bu haritanın temel amacı hızlı ve basit olmasıydı. Deprem bölgesinde internet erişiminin az olması ve dolayısıyla uygulamayı kullanacak kişilerin büyük sorun yaşayabileceğini düşünerek bir kaç temel amaç edindik. Yapacağımız uygulama hızlı çalışmalı, basit bir kullanıcı deneyimi olmalı ve sürekli ayakta kalmalıydı. Böylelikle depremzedelere ulaşacak STK gönüllüleri hızlıca bu bildirilen konumları görebilecek ve yardım edebilecekti.

Harita kilit noktayı oluşturduğu için burada kullanacağımız teknolojiyi doğru seçmeliydik. Bunun için ekiptekilerle tartıştığımızda sonuç olarak Leaflet kullanmakta kara kıldık.

Sebepleri kısaca şunlardı:

  • Açık kaynak.
  • Dış(external) bağımlılıkları yok.
  • Tarayıcı desteği var.
  • 42KB bundle boyutu ile oldukça hafif.
  • Özelleştirilebilir.
  • İyi dökümante edilmiş.
  • Mobil kullanıcı dostu.

Bağımlılık olarak haritayı ekledim ve ilk commitlerimde haritayı ekranda gösterdim. Haritada gösterilecek her bir nokta için detayların gösterileceği bir modal veya sayfaya ihtiyaç olduğunu düşündüm ve bu nedenle MUI React Drawer bileşenini de projeye dahil ettim.

Drawer bileşeninin son hali

Bu arada unutmadan Material UI kararının artıları hazır bir tasarım sistemi sunarak ihtiyaçlarımızı karşılaması ve bileşen düzeyinde test ihtiyacımız kalmaması olarak özetlenebilir. Öte yandan olumsuz tarafta oldukça ağır sayılabilecek (493kb) bir boyutu var.

Dokümantasyon?

Diğer geliştirici arkadaşların da katkı sağlayabilmesine destek olabilmek ve teşvik etmek için projeye birkaç taslağa bakarak README.md ve CONTRIBUTING.md ekleyip katkı yapmadan önce dikkat edilmesi gereken konular, projenin kurulumu, kod formatı, commit mesajları için semantik commit ile ilgili detayları düzenleyip ekledim.

İlk 12 saat: Doğru konumlanma

1. Mock API ile çalışma

Backend geliştiricilerini beklerken bloke eden durumun ortadan kaldırılması ve geliştirmeye devam edebilmek için önemli bir adım.

Anonim bir backend geliştiricinin de söylediği gibi “İyi frontend geliştirici backend tarafını beklerken de geliştirme yapandır.”

Frontend ekibinin API beklmesine gerek yoktu. Çünkü kullanacağımız paketin verileri nasıl istediğini biliyorduk. Bunun için bir mock API oluşturmak ve gerçek API hazır olduğunda ise gerçeğiyle yer değiştirmek işimizi çözecekti.

2. Hızlı teslim etme

Testing in production

Kaotik bir durumun içinde öngördüğüm en temel şeylerden biri şuydu: İhtiyaçlar değişebilir. Veri tipi değişebilir. Arayüz değişebilir. Ancak zamanla yarıştığımız gerçeği değişemez.

Zamanla yarıştığımız gerçeğinin olduğu bir geliştirme ortamında uzun teknik tartışmalara girmenin anlamsız olduğunu gördüm ve insiyatif kullanarak bu süreci yönetebilirim diyerek kendimi ortaya attım.

Hem güvenli hem de hızlı bir geliştirme ortamı oluşturmak için 3 ana branch üzerinden ilerlemek adına main, rc (release candidate) ve development branchlerini açıp diğer arkadaşların yardımıyla branch protection ekledim. Artık:

  • PR açılıp takım tarafından onaylanınca Vercel’in preview linkinden test edilerek en az 2 kişiden onay aldıktan sonra development branch’ine merge olacak,
  • Development branchindeki değişiklikler rc branchine deploy edilmesi için mergelenecek ve rc branchine özel bir domain ile (rc.afetharita.com) üzerinden canlıya çıkmaya aday geliştirmeler toplu halde test edilebilecek,
  • Production’a release almak için direkt olarak ana domain’e bağlı olan main branchine rc branch merge edilecek,
  • Hotfix için ise main branch bir önceki versiyondan bir kopya alınarak direkt merge edilecekti.
Gitflow Workflow

Frontend tarafına kattığım ikinci bir yaklaşım ise testing in production (TIP) pratiğini uygulamaktı.

Test ekipleri, ürün yöneticileri ve tasarımcılarla henüz iletişime geçememiş olsak da, yazılımımızın testlerini kendi kendimize yapmak zorunda kaldık. Bu durumda hatalar yapma olasılığımız yüksek olduğundan, bu soruna çözüm bulmak yerine, ürünümüzün kullanıcısı olan sahadan gelen geri bildirimlerle ihtiyaçları ve hataları önceliklendirmeye karar verdim. Takım olarak, önceliğimiz, kusursuz bir yazılım geliştirme süreci oluşturmak değil, ancak önce basit olanı yaparak ve canlı bir ürün ortaya çıkararak ilerlemek olmalıydı.

Bu sebeple takım olarak development ve rc branchlerinde kabul testleri yapmak yeterli oldu.

3. Başlangıç yükü (initial load)

Açılışta kullanılmayan veriler ile ilgili istek atılmaması ilk açılıştaki veri yükünü aza indirebilirdi. Açılışta yalnızca bildirimlerin lokasyonuna pin koyduğumuz ve diğer detaylı veriler sayfa yüklenene kadar kullanılmadığı için ihtiyaç halinde detaylar için ayrı bir istek atmak çalıştığımız mock API özelinde iyi bir çözüm oldu.

// get pin[]
pin {
id: number,
geo: {
x: number,
y: number
},
}
// get pin details
pinDetails: {
id: number,
geo: {...},
context: {...},
...
}

4. Kullanım kolaylığı, mobil yaklaşım, tarayıcı ve cihaz desteği

Takım olarak dikkat etmemiz gereken konulardan biri, kullanıcı geri bildirimleri idi. Bu konuda, ilk deploy alındığı andan itibaren rc.afetharita.com ortamını hazırladık ve çevremdeki teknik bilgisi olmayan dostlarıma gönderip telefonlarından test etmelerini ve karşılaştıkları sorunları bize bildirmelerini istedim.

Test ekiplerimiz projeye dahil olana kadar, en önemli metrik olarak kullanıcı geri bildirimlerini toplamaya çalıştık.

Her geri bildirimi ufak bir not kağıdına ekleyerek, kendi çalışmalarımda uyguladım ve takım arkadaşlarıma bu geri bildirimleri ilettim. Bu sayede fikir alışverişi ve iş birliği sağladık.

5. Kullanılacak harita özelliklerini ekleme: Isıl harita, kümeleme ve lejant

Önce, haritaya bir lejant ekleyerek başladık. Bu, kullanıcıların hangi renklerin hangi verileri temsil ettiğini anlamalarına yardımcı olacaktı.

afetharita.com lejant kapalı durum
afetharita.com lejant açık durum

Daha sonrasında kümelenme için Leaflet.markercluster isimli eklentiyi kullanmak istedik. Bu eklenti, büyük veri kümelerinde performans artışına neden olacak ve harita üzerindeki işlemlerin daha hızlı ve akıcı bir şekilde gerçekleştirilmesini sağlayacaktı. Bunun yanı sıra, eklentinin 3.6K gibi yüksek bir sayıda star alması ve Leaflet.js kütüphanesi ile uyumlu olması, tercih etmemizin sebepleri arasındaydı.

afetharita.com kümeleme

Isıl harita için ise react-leaflet için bir harita bileşeni olan react-leaflet-heatmap-layer’i tercih ettik.

afetharita.com ısı haritası

İlk 36 Saat: Toparlanış

Konular: Kaos, insan kaynakları süreçlerinin eksikliği, yardım etmek isteyen geliştiricilere aktarım yapılamaması, mesaj fazlalığından dolayı Discord kullanımının zorlaşması, backend entegrasyonu, canlıya çıkma.

Kaos

Discord sunucusu duyuldukça daha çok kişinin katılmaya başlamasıyla sık sık sesli kanalların kalabalıklaşması ve pair programming yapmanın zorlaşması gibi sorunlarla karşılaşıyorduk.

Bu durumda, sesli kanallardaki kullanıcıları gruplara ayırarak farklı issuelar ile ilgilenmeye teşvik ettim.

Ancak daha sonra fark ettiğim bir sorun ise geliştiricilerin yanı sıra yardım etmek isteyen ama gerçekten yapıcı bir katkı sunamayan kullanıcıların da kanallara katılmasıydı.

Herkesin katkı yapmaya çalışması ne kadar değerli olsa da kaotik ortam geliştirme yapmayı neredeyse imkansız hale getirmişti. İzolasyon gerekliydi ancak onca kalabalığın içinde de gerçekten değerli fikirleri kaçırmamak için de bir önlem alınmalıydı.

Bu sebeple moderatörlerden sesli ve yazılı kanallara sadece “afetharita” rolü olan kullanıcıların erişim sağlayabilmesi için gerekli değişiklikleri rica ettim. Bu sayede geliştirme önerisi olan veya hata raporu yapacak kişileri direkt GitHub Issues kısmına yönlendirebilecektik.

Sıradaki başlık ile birlikte ise wombo-combo yapılarak bu sorun büyük oranda engelllenmiş olacaktı.

Pull Request ve Issue Taslakları

İfade özgürlüğü önemli ancak kurallara uygun olduğu müddetçe. PR ve issueları okurken doğru anladığımızdan emin olmak için yeteri kadar detaylı açıklanmış olması çok önemliydi. Aşağıdaki örnekteki gibi detaylı açıklamaya teşvik edici taslakları ekledim.

afetharita frontend bug report taslağı

Taslakları eklerken bazen çok kurallı ve otoriter hissettim, ama sonuçta bu çözümlerin işe yaradığını ve kaotik ortamın önüne geçeceğine inanıyordum.

Ancak burada bir sorun vardı: Açılan issue ve PR’ların bu taslaklara uygunluğunu kim denetleyecekti?

afetharita-checkforce

Hemen aylar önce frontend alanındaki geliştiricileri birleştirmek ve açık kaynak bir oluşum olması adına kuruculuğunu üstlendiğim Frontendship kanalından tanıdığım güvenilir, fedakar ve bu işi ciddiye alacak harika arkadaşlarımı bir araya toplayarak bir ekip kurarak onlara GitHub’da triage yetkisi verdim.

Bu harika ekip repository’de açılan issue ve PR’ları denetleyecek ve uygun olmayanlara invalid olarak etiketleyerek yazara kurallara uygun şekilde tekrar denemesini söyleyecekti. Böylelikle geliştiricilerin üstünden büyük bir yük alacaklardı.

ID Kontrolleri

İlerlemelerin ve yapılan işlerin parçalanmış olması ve birlikte anlaşılabilir bir bütün oluşturması için GitHub issue ID’leri önem taşıdı. Yine checkforce ekibi eğer açılan PR bir issue ID’ye işaret etmiyorsa o PR’lar kapatılıp tekrar açılması konusunda ricada bulunuyordu.

Etiketler

afetharita-checkforce takımının geliştirme süreçlerine katılmasıyla birlikte etiketleri uygun şekilde düzenlemek ve açıklamalarını yazmamak olmazdı.

Etiketler de çalışma düzenini kabul edilebilir hale getirmek için önemli bir rol oynadı.

Hazırladığım GitHub etiketlerinin son hali

Discord yapısı

Sunucudaki herkesin aynı projede çalışmadığını ve afetharita’nın amiral gemi olma potansiyelini göz önünde bulundurarak yine moderatörlerden sunucunun yapısı dışında bir şey yapmalarını rica ettim.
afetharita.com kategorilerini disiplinlere göre ayırmak ve izolasyonu arttırmak.

İlk başta yalnızca tek bir kategori altında ayrılsa gelecek 24 saatte aşağıdaki hale gelecekti.

afetharita discord yapısı

Kod standartları

İlk önceliğimiz kod kalitesi değildi ancak kod tabanımız giderek büyüdükçe endişelerimiz arttı ve kaos ortamı oluşma riskiyle karşı karşıya kaldık. Bu nedenle, kod standartlarını korumak için bazı araçları kullanmaya karar verdik.

ESlint ve Prettier araçlarını projeye dahil ettik ve yapılandırmalarını tamamladık. Ayrıca, Husky adlı sevdiğim bir araçla, ara bir stage oluşturarak pre-commit hook ekledik. Böylece, projede çalışan herkes commit göndermeden önce kod formatlama ve hata kontrolü yapmak zorunda kaldı.

Ayrıca, commit mesajlarımız için belirli standartları korumak için semantik commit kurallarını uygulayan commitlint özelliğini de ekledik. Bazı pull requestlerde --no-verify seçeneğinin kullanıldığını fark ettik ve bunu önlemek için GitHub Actions ile ikinci bir kontrol sağladık.

API bağlantısı
Projenin backend tarafında hazırlanan veri modelini projenin canlıya alma aşamasına gelmeden öğrenmiştik ve bu nedenle tek yapmamız gereken, bir API_URL eklemek oldu. Test ortamında CORS hatası almak dışında herhangi bir sorun yaşamadık. Ancak herkesin hızlı bir şekilde yanıt vermesi sayesinde bu hatayı neredeyse senkron bir şekilde çözdük.

Sanırım en zoru hala duygularla savaşmaktı.

Sosyal medyada gördüğümüz yıkım, uykusuzluk, gerginlik. Ve sadece benim için değil. Kiminle sohbet etsem yorgun bir ses tonuyla hala uyumadığını veya bayılmak üzere olduğunu söylüyordu. Bu çabayı gördükçe insanlığa olan inancım ve umudum artıyordu.

Canlıya çıkma

Verileri ekrana basabilmek için gerekli geliştirmeleri tamamladıktan sonra son kontrolleri yaparak rc ortamına alıp test ettik. Ancak, uygulama için daha fazla geliştirmeye ihtiyaç duyduğumuzun farkındaydık. Yine de, test aşamasında herhangi bir önemli sorunla karşılaşmadık. Sonuç olarak, afetharita.com’u kullanıma açmak için hazır olduğumuzu düşünerek canlıya aldık.

afetharita.com’u canlıya aldığımda duyduğum heyecanı paylaştığım tweet

Şimdiye dek anlattıklarımda özellikle frontend kısmı üzerinde yoğunlaştım çünkü geri kalan çalışmalarından ne olduğundan tam olarak haberdar değildim.

Ancak, Türkiye’de açık kaynak bir topluluğun gerçekleştirebildiği en büyük takım çalışmalarından birinin yapıldığından emindim. Discord sunucusunda, her disiplinden profesyonel bir araya gelerek, ortak hedefler uğruna çalışmıştık. Birçok kişi, çalışma saatleri ve zaman farklarına bakılmaksızın, gece gündüz demeden yoğun bir şekilde çalışmıştı. Sizce bu süre zarfında diğer ekipler neler yapmıştı?

  • Yapay zeka tarafında ilk gün verilen ekran görüntüsünden metine çevirip bu metinde adres, telefon ve isim bilgilerini çekip database’e kaydeden bir uygulama geliştirildi. Metine çevirmek için easyocr kullanıldı ve adresi çekmek için OpenAI DaVinci modeli eğitildi. Üçüncü gün bu model ile verilen bir tweet’te ihtiyaçları çeken bir model eğitimine başlandı. Bu model ihtiyaçları ayırt edebilecekti.
  • Legal ekibi bu süreçte yapılan işin mahiyeti itibariyle işlenecek kişisel veriler bakımından gerekli yasal metinlerin hazırlanması, karşılaşılması muhtemel riskler bakımından ekip arkadaşlarının bilgilendirilerek gönüllü olarak hukuki danışmanlık verilmesi gerekliliğiyle legal ekip olarak AYA’ ya destek sağlamaya çalıştı.
  • Test ekipleri ihtiyaç ve gereksinimlere göre insan havuzumuzu belirli proje ve işlere kanalize etti ve liderlik etmeye gönüllü olan kişileri de planlamasında görevli hale getirdiler. Sonrasında testler yapmaya başlayıp dokümante ederek yüksek seviye gereksinimleri oluşturdular. Bir Excel dokümanında hataları detaylandırarak önceliklendirerek bu konuları GitHub’a yani geliştirme ekiplerine taşıdılar
  • Moderasyon ekipleri hızlıca katkı sunmak için sunucuya gelen insanları ilgili ekip ve kanallara yönlendirdiler, rol düzenini daha iyi hale getirip her ekibin daha hızlı ve stabil çalışabilmelerini sağladılar. Bunun yanında sunucudaki mesajları sürekli olarak kontrol edip spam ve zararlı mesajları temizlediler. Bunun sonrasında ekiplerle aktif şekilde iletişimde kalıp bilgilendirme, duyuru gibi iletişim konularını çözdüler.
  • Cloud & Infra & DevOps ekibi olarak sürecin aciliyeti ile birlikte cloud çözümleri tercih ettiler. Hem yatayda hem dikeyde ölçekleyebilmek, teknoloji bağımsız bir şekilde 1000 kişilik geliştirme ekiplerine en iyi desteği vermek için projeleri dockerize edip multi cloud provider olacak şekilde cloud ortamlarına production deployment yapacak CI&CD pipeline’larını oluşturdular. Böylece teknoloji ve insan bağımsız şekilde takımlarlar tarafından hazırlanan ve ilgili branch’lere mergelenen kodlar canlıya çıkmış oluyordu. Paralelde depended database, monitoring, cache ve streaming çözümleri için yine cloud ortamlarındaki serverless çözümleri seçerek hem maintenance hem de zero downtime eforlarını da çözümlemiş oldular. Çalışan tüm sistemler serverless ve HA (high available) kurgulanmış oldu.
  • Sosyal medya ekipleri uygulama fikirlerinin hayata geçmesi ile birlikte uygulamaların daha fazla insana erişmesi için pazarlama ve iletişim çalışmalarına başlandı. Açık Yazılım Ağı kurumsal kimliğinin tasarımından, sosyal medya hesaplarına içerik hazırlanmasına, STK’lar ile işbirliğinden fenomen iletişimine farklı alt çalışma grupları oluşturuldu ve hızla organize olundu. Uygulamalar ve topluluk ile ilgili iletişim bu ekipler tarafından yapıldı.

İlk 72 saat: İyileşme

Hiçbirimiz tam olarak afetharita.com’un kullanılıp kullanmadığından emin değilken Furkan’ın yaptığı duyuruda 4.2M görüntüleme aldığını ve değerli AKUT gibi STK’ların bu dataları da arama kurtartma faaliyetlerinde kullandıklarını öğrendik.

AKUT, kendisine gelen mail, telefon, chatbox ve sosyal medya üzerinden gelen ihbarları takip ediyor ve analiz ediyor. Bizim kendilerine sağladığımız kanalı da değerlendirmeye aldılar ve ihbar yönetimine entegre ettiler

bir başka güzel haber

Backend kısmına API bağlantısı sağlamış olsak da mock olarak hazırladığımız gibi iki ayrı istekten verilerin gelmesi yerine pinlerin listesi ve ayrıntıları tek bir istekte verilerek performans kaybına yol açabilecek bir veri geldiği gözlemlendi. Response süresi 10 saniyeye kadar çıkabiliyordu.

Frontend tarafında, tecrübeli ve yetenekli arkadaşlarımın varlığı sayesinde sistem oturmuş ve kendiliğinden işlemeye başlamıştı. Bu süreçte, birbirimize güven duygusu oluştu ve işbirliği güçlendi.

Ancak backend tarafıyla senkronize olmak için kiminle iletişim kurmam gerektiği konusunda bilgi sahibi değildim. Bir süre boyunca sorularıma cevap bulmakta zorlandıktan sonra, backend tarafında bazı aksaklıklar yaşandığını ve API tarafının Trendyol’da Uzman Yazılım Mühendisi olarak görev yapan Emre liderliğinde yeniden yazıldığını öğrendim.

Çözüme odaklanarak, bilmediğim konular hakkında soru sormak yerine nasıl yardımcı olabileceğimi direk sordum. Emre’nin benzer problemler yaşadığını öğrendikten sonra vakti için teşekkür edip elimden geleni yapacağımı belirttim. Böylece, Emre ve backend takımı ile kesintisiz iletişim halinde olmaya başladık.

Frontend tarafında PR ve issueları kontrol etmek için uygulamayı sürdürdüğümüz yapıyı çok ufak düzenlemeler ile backend reposuna ekledim. checkforce takımı artık hep frontend hem de backend reposunu kontrol ediyor ve geçersiz issue ve PR’ları kapatıyorlardı.

Backend ve ilgili takımların uyumlu çalışabilmesi için sunucuda onlara özel kategori açıldı. Bu sayede backend takımı da odaklı bir şekilde çalışmalarını sürdürebilecekti.

Hizalanma

Takımlar arasında yaşanan gerginlikler ve ayrılıklar olsa da, birbirimizden ayrılmamamız gereken konular vardı. Önceliğimiz, yaptığımız uygulamaların depremzedelerin hayatını kurtarmak için nasıl yardımcı olabileceği konusunda odaklanmaktı.

Kişisel olarak söylemem gerekirse hayatımda hiç yazılım geliştirme konusunda bu kadar tutkulu olmamıştım. Artık afetharita.com için tüm takımları birbiriyle iletişim halinde ve hizalı hale getirmek yeni misyonumdu. Hali hazırda Emre ile el sıkışmış ve kenetlenmiş şekilde ilerlememiz dolayısıyla rahatlıkla takımlar işbirliği yapabilmeye başladı.

Kısa toplantılarla, her iki tarafın karşılaştığı engellere birlikte çözümler üretiyor ve sabırsızlıkla yeni API endpoint’ini bekliyorduk. Bekleme süresinde, frontend takımının ses kanallarına sık sık girerek PR ve issue’lar konusunda yardımcı oldum.

Legal konular

KVKK kapsamında ve yasalara uygun hareket ettiğimizden emin olmak için, sunucumuzda yer alan avukatlar tarafından hazırlanan Gizlilik Sözleşmesi, Veri Kaynakları ve Çerez Politikasını hızlı bir şekilde footer bölümüne ekledim.

Boğulma sorunu

Mevcut API tarafından dönen verinin büyük olması ve hazırlandığımız şekilde gelmemesi kullanıcı açısından büyük problemdi. Bir anda çok fazla veriyi kullanıcıya çektirip tarayıcısına yazdırmak gerçekten ciddi boğulmalara yol açacak gibi görünüyordu.

Buna 4 çözüm üretebildik.

  1. Haritayı varsayılan olarak tek bir şehire zoom yapmış şekilde açıp, sadece ekrandaki koordinatların verisini istemek. Bu sayede alana yönelik filtreleme yapmış olacaktık. Haritada zoom her değiştiğinde istek atmasını engellemek için de Google Haritalardan esinlendiğimiz “Alanı Tara” butonu ekledik.
  2. Yeni API tarafında /GET Pin Details isteği atılmadığı sürece yalnızca ID ve koordinatları dönmesi.
  3. Performans sorununa yol açan hatalar veya gereksiz render tetiklenmeleri varsa tespit edip düzeltmek.
  4. Filtreleme yapmak. Eğitilen yapay zeka modeli artık paylaşımların niyetini de ayırt edebilir hale geldiği için filtreleme özelliklerini eklemek ve varsayılan olarak son 1 saati göstermek de ilk açılış için inanılmaz bir fark yaratabilirdi.

Emeği geçen her kahraman sayesinde hepsini başardık. Belki de diğer taraftaki gönüllülerin yaptıklarını görmediğimden olsa gerek ancak bu proje nedeniyle tanıştığım ve beni her anlamda kendine hayran bırakan Umut’un saatler boyu çalışıp haritadaki kümelenmenin yol açtığı boğulma sorunu konusunda getirdiği akılcı çözüm gerçekten hayat kurtarıcı oldu. Umarım kendisi bunun hakkında bir yazı yazar. Umut, harika bir mühendissin!

Bir dakika dur dur! Büyüyebiliriz.

Artık backend ve frontend takımları koordineli bir şekilde çalışıyor olsalar da, uzmanlık alanımın ürün/proje yönetimi olmadığı ve bu konuda yardımcı olabilecek birçok kişinin beklediğinin farkındayım. Bu nedenle moderatörlere, hiring süreçlerine yardımcı olabilecek birine yönlendirmeleri için rica ettim.

Birlikte ürün yöneticisi ve frontend geliştirici ilanları paylaşmaya başladık çünkü daha fazla destek almamız gerekiyordu. Yeni katılan frontend geliştiricileri, diğer frontend takım liderleri tarafından karşılanıp aktarıldı, ben de ürün yöneticilerine güncel kalmalarını sağlamak için bilgi aktarımı yaptım. Ürün yönetim araçlarının entegre edilmesi ve backend/frontend takımları arasında koordinasyon sağlamak için arada bir köprü olmak görevimdi.

Aktarım yaptığım ürün yöneticisi arkadaşlara da geliştirme süreçlerinde gördüğüm eksiklikleri aktardım.

Ve çalışma düzenimize yeni kurallar ekledim.

Approved: Ürün yöneticileri GitHub’da issuelara onay vermedikçe artık işlerin başlamaması gerekiyordu. Ürün yöneticileri repolarda açılmış issue’ların önceliklendirecek ve geliştirme süreçlerini planlayacaktı.

Bu sayede geliştirme tarafında kimsenin gereksiz çalışmaması ve emeğinin boşa gitmemesi de sağlanmış olacaktı. Ayrıca ürünün gideceği yönü de kontrol altına almış olacaktık.

İlk başlarda ufak uyumsuzluklar olsa da kısa süre içinde geliştiriciler ve ürün yöneticileri de işbirliği yapmaya başlamıştı.

Ama bir dakika daha lütfen! Test?

Ürün yöneticilere yaptığım bir başka aktarım ise öncelikle frontend tarafında yeni özellik ve test ortamı genelinde test yapılması gerektiğiydi. Bu noktada da hali hazırda sunucuda bekleyen test uzmanlarını devreye sokmanın ve test takımı yöneticisiyle dirsek temasında olmanın vakti gelmişti.
GitHub’a test ile ilgili tested ve test-failed şeklinde iki etiket daha ekledim. Bu sayede PR’lar Vercel’in sunduğu önizleme ekranlarında test uzmanları tarafından test edilmeden merge edilmemeye özen gösterilmeye başlandı.

Bir saniye daha. Tasarım?

Hepsine selamlarımı iletmekle sunucudaki tasarımcı arkadaşların biz daha henüz canlıya çıkmamışken bir kullanıcı arayüzü tasarladıklarını unutmadan söylemem gerekiyor. Ancak hazır bir kütüphane kullandığımız için özelleştirmek çok vakit alır diye düşünüp onların yaptığı tasarımı bir eskiz gibi kullanmaktan öteye gidemedik. En baştan iletişim kuramamış oluşumuz bizi bir süre ayrı çalışma noktasına getirmişti. Ancak artık birleşmenin zamanı gelmişti ve daha kötü bir kullanıcı arayüzü oluşturmamak adına tasarımcıların değerli yardımlarını kabul etmek önemliydi.
Yine açılan issue’lar üzerinde ürün yöneticileri eğer açılmış issue’nun bir tasarıma ihtiyacı varsa ekleyebilsin ve tasarımcılar süreçleri takip edebilsin diye UI/UX isminde bir etiket daha ekledim. Bu sayede herkes bir issue tasarım beklediğinde durumdan haberdar olacaktı.

Özerk afetharita.com

Backend, Cloud ve Data ekipleri arası iletişim zaten doğal yollardan sağlanıyordu. Discord tarafında aldığımız kategori düzeni sayesinde Tasarım, Test, Backend, Frontend, Cloud, Security ve Data ekipleri birbiriyle bağlantılı ve haberdar halde çalışıyordu.

Fakat Açık Yazılım Ağı başka nerelere hizmet veriyor ve ne tarz uygulamalar geliştiriyor pek de hakim değildim. Süreçler hakkında destek olabilmek ve bilgi alabilmek için daha önceden de tanışık olduğum ve rol model olarak gördüğüm Eser’e süreçte evinde beni misafir edip edemeyeceğini sordum.

Eser beni bir hafta boyunca evinde misafir etti ve şahit olduğum süreçlerde konulara ve kişilere yaklaşımıyla hayata olan bakışımı etkiledi. Ondan çok şey öğrendiğim bir süreç oldu.
Toplantılara girmekten ve herkesi dikkatle dinleyip cevap vermeye çalışmaktan 8 saat önce sipariş ettiği yemeği yiyemediğini ve su içmeyi unuttuğuna dahi şahit oldum.

Gelecek zamanlarda ise Eser ile senkronize olup fikir alışverişinde bulunarak ilerlemek bana genel resmi görmem, koordinasyonu arttırabilmem ve saha ile daha yakın iletişim halinde olabilmem için inanılmaz katkılar sağladı.

144 Saat: Henüz bitmedi

Arka tarafta Go ile yazılmış yeni API ile hız probleminin önüne geçilmişti ve fazlasıyla optimize edilmiş bir sistem kurulmuştu. İşler yolunda gidiyor gibi görünüyordu. Ancak depremzedeler için henüz bir şey bitmemişti. Aksine yeni başlıyordu. İhtiyaca göre ürünü şekillendirmeli ve veriler eklemeliydik.

Yeni veriler var

Sivil toplum kuruluşları, dernekler, yardım kuruluşları, basın ve medya kuruluşları ile kamu kurum ve kuruluşları tarafından paylaşılan/yapılan/yayınlanan yardım, destek ve arama kurtarma çağrılarını API ve haritaya ekleyip daha kapsamlı bir arayüz ve destek ve sunmaya devam ettik.

  • Ahbap Konumları
  • Hastaneler
  • Sıcak Yemek Noktaları

Yeni özellikler

Çoklu dil: Çok fazla dil özelliği kullandığımız bir uygulama olmamasına rağmen sahaya yurtdışında gelen ekiplerin de kullanma ihtimaline karşı ingilizce dil desteği ekledik.

Harita ayarları: Yolların durumu ve tanınamaz hale geldiği yerler olabileceğini düşünerek uydu ve arazi seçeneklerini de ekledik.

Filtreleme: Zaman filtresi ve ayrıca güvenilir kaynaklarca doğrulanmış verilerin de eklenmesi bildirimler de filtrelenebilir hale getirildi.

Sosyal medya bir silah mı?

Hepimizin içinde umut yeşermeye ve vicdanımızı biraz da olsa rahatlatacak şeyleri zaten öğrenmiştik. Direkt sahadan gönüllü koordinatörler arayıp teşekkür ediyor, uygulamayı kullandıklarını söylüyorlar ve geri bildirimde bulunuyorlardı. Bu durum bizi daha çok ateşliyordu.

Teknik tarafta önemli olan bir nokta uygulamayı kullanan herkesin bu ürün üzerinde sürekli uğraşıldığını ve hizmet sunmak için birçok kişinin çalıştığını bilmesi gerekliliğiydi.

Hali hazırda AYA’nın sosyal medya ekipleri afetharita.com için çalışmaya devam etse de geçen her dakikanın önemini bildiğimiz için tüm geliştiriciler sosyal medyada duyurular yapmaya başladık.

afetharita.com’un saha ekipleri ve depremzedeler tarafından duyulmasını sağlamak için herkes paylaşımlara destek oldu. Tam bu noktada değerli Memet Ali Alabora gibi tanınmış isimlerin de Discord sunucusunda destek için hata bildiriminde bulunduğu ve sosyal medyada paylaşım yaptığını gördük.

1.Hafta

Artık afetharita.com’un kullanıldığını biliyorduk. İnsanlara umut olduğunu biliyorduk. Milyonlarca istek aldığını ve fayda sağladığını biliyorduk.

Uygulamaya geliştirmeye devam etmemiz gerektiğini biliyorduk. Sanırım herkes biliyordu. Öyle ki yurtdışından ulaşan yardımsever bir dostum Berlin’de yardım toplama noktalarını ve detaylarını gösteren bir harita hazırlamış ve afetharita.com’a eklememiz için bana ulaştı. afetharita.com’daki haritaya direkt eklemek yerine afetharita.com/berlin domainini direkt o arkadaşımın haritaya yönlendirme kararı aldım.

Daha sonra aramıza afetharita.com/london ve afetharita.com/netherlands katıldı.

Kısacası artık afetharita.com üzerinden yurtdışına da veri ve bilgi aktarımı yapılmaya başlandı.

Üstelik haritaya yeni veriler ekledik:

İhtiyaca göre filtreleme: Kullanımı kolaylaştırmak için arkaplanda çalışan arkadaşlarımızın yapay zeka modelini yardım çağrılarını ihtiyaca göre ayırt edebilmeye başlatmasıyla birlikte niyete göre filtreleme eklendi. Biz de hemen bununla ilgili geliştirmeleri arayüze ekledik.

Haritanın tüm sosyal medyada duyulmasının yanı sıra, afetharita.com’un içeriğinin daha fazla kişiye ulaştırılması için geliştirmiş olduğumuz iframe modülünü -veri veya sistem paylaşımı olmaksızın- projelerine ekleyenler de oldu.

mynet.com/deprem-yardim-agi

Türk basınında bir çok yayın ve yabancı basında Yahoo, Euronews, Wired ve Time afetharita’dan söz etti.

uygulamayı kullanan saha gönüllülerinden geri dönüşler

Deprem felaketininden yaklaşık 30 saat sonra ücretsiz hizmete sunduğumuz afetharita.com henüz daha ilk haftasında bile çok etkili bir araç haline gelmişti. Hep beraber yaptığımız iş beni gururlandırsa da empati yaptıkça karmakarışık duygular yaşıyordum.

Bireysel olarak kazanımlarım paha biçilemez. Hayatımda bir örneğini daha muhtemelen göremeyeceğim bir projede yer alıp mükemmel insanlarla tanışma fırsatı buldum.

Ünvanların değil fikirlerin ve etkinin önemli olabileceğini, iletişim becerilerinin stres altındayken ne kadar önemli olduğunu, takım çalışmasının ne kadar etkili olabileceğini, bir başkası için bir şeyleri kolaylaştırmanın işleri ne kadar hızlandırabileceğini… Sevgiyi ve dayanışmayı.

Bu süreçlerde birlikte çalıştığım ve ilginç bir bağ kurduğum GHD şirketinde Ürün Yöneticisi olarak çalışan Caner Akın LinkedIn profilinde şu güzel cümlelerle duygularını ifade etti.

Şu 9 gün sanki 9 yıl gibiydi. Öyle bir zaman diliminden geçtik ki 40 yıllık arkadaşlar olduk. Kavga ettik, özür diledik, hep birlikte üzüldük. Gece gündüz birbirimizi bırakmadan çalıştık. Sabahlarken akrabasının, kardeşinin bedeninin bulunduğunu duyan kardeşimizle ağladık. 1 gün daha dedik devam ettik. En önemlisi şuydu: gurur duyduk. Sırtımızı dayayabileceğimiz insanlar olduğunu bilmek gurur duydurdu bize. Beklentisiz, saf temiz kalple bir can daha kurtulsun yeter ki diyen insanların Afet Harita’da hep birlikte olması yalnız olmadığımızı, çaresiz olmadığımızı hissettirdi.

afetharita.com Açık Yazılım Ağı altında geliştirilen ürünler arasında amiral gemi görevindeydi ama şu ana kadar burada yalnızca afetharita.com özelinde konuşmuş ve tecrübelerimi aktarmış olsam da arka planda milyonlarca trafik alan ve depremzedelere yazılım desteği veren birçok uygulama vardı.

Bu uygulamalar hakkında daha detaylı bilgi için afet.org’u ziyaret edebilirsiniz.

Tüm repositoryler ise public şekilde GitHub’da Açık Kaynak organizasyonu altında toplanmıştı.

2. Hafta

Cengiz Mataracı’nın AYA sunucusunun duyurular kısmında paylaştığı içerik

afetharita.com aslında hedeflediğimiz gibi depremin acil ve kritik günlerinde desteğini sağlamıştı ve kamuoyunda ses getirmişti.

Hatta öyle ki NBC’de bile afetharita.com’u anlatan bir haber yayınlandı...

10 günü aşan bir süre zarfından sonra artık gerekli farkındalığın ve yardımların ulaştırılması için ülke çapında hem gönüllü hem de kamu düzeyinde seferberlik yapılmaya başlandığı için yeni bir yol haritası belirleme ihtiyacı duyduk.

Günümüz: Yol haritamız

Açık Yazılım Ağı için ise KVKK kapsamında kişisel ve hassas verilerin yok edilmesinin vakti geldi.

afetharita.com için ilk aşamada sadece doğrulanmış ve kişisel bilgiler içermeyen veriler ile hizmet vermeye devam ediyor. Yakın zamanda ise tamamen kullanıma kapalı hale getirip gelen istekler afet.org’a yönlendirme yapılacak.

Bu kötü bir haber gibi gelebiliyor kulağa ama aslında değil çünkü artık 4. gün aklıma gelen hayali ve hedefi gerçekleşmeye artık daha yakınız. Ve şu an bile herhangi bir afet durumunda tekrar hizmet vermek için sistemimiz hazır.

Bu uygulama baştan sona indirilip kurulabilen bir programa dönüştürülmeli ve tüm dünyaya ücretsiz olarak hizmet sunarak herhangi bir afet durumunda özelleştirilip kullanılabilir olmalı.

Yönümüzü yine aynı takım çalışması ile bu hedefe doğru çevireceğimize de hep birlikte hemfikir olduk.

Projeleri desteklemek ve katkı sağlamak için Açık Yazılım Ağı hakkında daha fazla bilgi edinebileceğiniz linkler

afetharita.com
afet.org
https://github.com/acikyazilimagi

Son.

Bana ulaşmak ve sosyal medya hesaplarım için tıklayın.

--

--