Uber için Excel’i yaptım, ama kısa süre sonra çöpe atıldı

 (basta.substack.com)
2 puan yazan GN⁺ 2023-09-16 | 1 yorum | WhatsApp'ta paylaş
  • 2016’da Uber’in Business Intelligence organizasyonu, Uber China rekabeti için gereken verileri hızla kullanabilmek amacıyla bir R model çalıştırma aracı ve Excel benzeri bir UI geliştirdi; ancak Uber China Didi’ye satılınca bu özellik kısa süre sonra kaldırıldı
  • R-Crusher, veri bilimcilerin Vertica verilerini dizüstü bilgisayarlara indirip R modellerini gece boyunca çalıştırdığı kırılgan akışı API tabanlı bir çalıştırma aracına dönüştürmeyi amaçlayan dahili bir sistemdi
  • Çin şehir ekipleri, sürücü teşviklerini hesaplamak için kullanılan Excel dosyalarına alışkındı; ekip de yüzlerce ila binlerce formülü doğrudan JavaScript’e taşımak yerine, tarayıcıda XLS dosyalarını ve formülleri çalıştıran bir elektronik tablo motoru uyguladı
  • Sonuçların Excel’den ufak farklarla sapmasının nedeni, veri bilimcilerin döngüsel referanslar ile doğrusal regresyon yapmasıydı; çözüm, Excel’de olduğu gibi yakınsayana kadar yinelemeli hesaplama yapmak oldu
  • İyi yazılmış kod bile çözmeyi hedeflediği iş problemi ortadan kalktığında kaldırılabilir; mühendisliğin değeri, kodun ömründen çok problem çözmeye yakındır

Uber China’yı ayakta tutan dahili veri aracı

  • 2016’da Uber’e katıldıktan sonra Crystal Ball ekibinde ilk frontend mühendisi olarak çalışmaya başladı
    • Ekip yaklaşık 4 kişiden oluşuyordu ve çoğu güçlü biçimde backend eğilimliydi
    • Rolü, dahili araçları şirket çalışanlarının gerçekten kullanabileceği UI’lara dönüştürmekti
  • O dönemde veri bilimciler Vertica’dan veri indirip R modellerini gece boyunca birden fazla dizüstü bilgisayarda çalıştırıyordu
    • Sabah, modeli çökmemiş dizüstü bilgisayarlardan ancak o gün kullanılabilecek veriler çıkıyordu
    • Başarısız olan dizüstü bilgisayarlar gerekli veriyi üretemiyor, bu da şirketin para kaybetmesine yol açıyordu
  • Ekibin geliştirdiği R-Crusher, API çağrısıyla kod indirip çalıştıran ve sonuç dosyaları üreten bir CI sistemine yakındı
  • R-Crusher’ın frontend’i olan Wesley, katılıştan sonraki birkaç hafta içinde ilk sürümüyle hazır hale geldi
    • Sonraki 6-7 ay boyunca kullanıcı özellikleri, hata ayıklama araçları ve frontend ekibinin genişletilmesi devam etti

Çin pazarı ve sürücü teşviki hesaplaması

  • 2016’da Uber içinde iki büyük eksen, uygulamanın yeniden yazılması/yeniden tasarlanması ve Uber China idi
  • Crystal Ball ekibinin çalışması nihayetinde Uber China’yı desteklemeye yönelikti
    • R-Crusher, Didi ile rekabet etmek için gereken verileri elde etmeye yarayan bir araçtı
    • Çin, Uber için önemli bir fırsattı ve gerekli verilerin bir kısmının R-Crusher’dan çıkması planlanıyordu
  • Yaz aylarında yeni bir gereksinim geldi
    • Çin’deki yolculuk talebi tahmin verilerini gece boyunca üreten bir model vardı
    • Bu veri tek başına faydalı değildi; belirli bir Excel elektronik tablo sekmesine konduğunda sürücü teşviklerini hesaplayan etkileşimli bir araca dönüşüyordu
  • Finans sorumlusu, söz konusu elektronik tablonun Wesley’in içine konmasını istedi
    • Şehir ekiplerinin yalnızca Excel kullanmayı bildiğini söyleyerek “Excel gibi yapın” talebinde bulundu
    • Mühendislik zamanının yetersiz olduğu açıklandı, ancak her gün araç olmadan milyonlarca dolar kaybedildiği yanıtı geldi

Tarayıcının içinde Excel’i taklit etmek

  • Elektronik tabloyu backend’de Python veya R koduna dönüştürecek zaman yoktu; frontend’de çok miktarda JavaScript yazılması gereken bir durum oluştu
  • Daha önce Box’ta geliştirilen Box Sums prototipi temel alındı
    • React tabanlı basit bir elektronik tablo UI’ı ve temel bir formül motoru vardı
    • XLS/XLSX dosyası sayfaya bırakıldığında içeriği bir Node kütüphanesiyle ayrıştırıyordu
  • Uber için uygulamada hedef Excel’in kendisi değil, Excel’e yakın davranıştı
    • XLS dosyasını girdi olarak okudu
    • Excel formüllerini verinin üzerinde çalıştırdı
    • Backend, yolculuk talebi verilerini iki boyutlu dizi olarak sağladı; frontend de bunu gizli bir sekme gibi formül motoruna koydu
    • Kullanıcının değiştirmesi gereken hücreler dışındakileri salt okunur yaptı
  • Kritik nokta, yüzlerce ila binlerce yoğun formülü doğrudan JavaScript’e çevirmemekti
  • Uygulama sürecinde XLS dosyasındaki formüller çıkarıldı; gerekli fonksiyonlar ve sözdizimi formül motoruna eklendi

    • Excel sözdizimi genişletmeleri

      • Mutlak hücre referansı
      • Başka sayfadaki hücre referansı
      • Mevcut Box demosunda olmayan elektronik tablo sözdizimleri

Neredeyse doğru ama yanlış sayılar ve döngüsel referanslar

  • İlk karşılaştırmada Excel ile kendi motorunun sonuçları çok küçük farklarla ayrışıyordu
    • Excel çıktısı 3.03 olduğunda kendi çıktısı 3.01 oluyordu
    • Excel çıktısı 1.002 olduğunda kendi çıktısı 1.000 oluyordu
  • Tamamen yanlış değerlerden ziyade neredeyse doğru değerler daha zorlayıcıydı
    • Basit bir mantık hatasından çok, ince bir hesaplama farkı olma ihtimali yüksekti
  • Birim testleri geçiyordu; JavaScript double ile Excel’in kayan nokta gösterimi arasındaki fark da neden değildi
  • Veri bilimciye sorulunca neden ortaya çıktı
    • Elektronik tablo, doğrusal regresyon yapmak için döngüsel referanslar kullanıyordu
    • Excel döngüsel referansları her zaman hata olarak ele almıyor
    • Hesaplanan değer belirli bir epsilon’dan küçük farkla yakınsadığında yinelemeli hesaplamayı durdurup başarılı olmuş gibi işliyor
  • Uygulama, döngüsel bağımlılık grafiğini algılayıp önceki hesaplanan değer ile yeni hesaplanan değer arasındaki farkı karşılaştıracak şekilde değiştirildi
    • Fark yeterince küçükse yeni değer kullanıldı
    • Değilse yineleme sayısı artırılıp hesaplamaya devam edildi
    • Eşik yineleme sayısı 1000 olarak belirlendi
  • Değişiklik yaklaşık bir buçuk gün sürdü ve çıktı Excel ile örtüştü
    • Testler yazıldı ve Wesley’e entegre edildi
    • Proje Temmuz’un ikinci haftasında teslim edildi

Yayından sonra gelen güvenlik talebi ve ani rafa kaldırma

  • Araç gerçekten yayına alındı ve Uber China şehir ekibi üyeleri giriş yapıp kullandı
    • Üretilen sayıların sürücü teşviklerinde kullanıldığını biliyorum
    • Zamanlama Temmuz’un üçüncü haftasıydı
  • Temmuz’un son haftasında finans sorumlusu, hücreye tıklanınca formülün görünmesini sorun etti
    • Didi çalışanlarının Uber China’ya stajyer olarak başvurup veri sızdırabileceği endişesi iletildi
    • Bu tehdit modeli önceden mühendislik ekibiyle paylaşılmamıştı
  • Formülleri tamamen korumak için hesaplamayı sunucuya taşımak gerekiyordu, ancak bu talep kapsamının dışındaydı
    • O anki düzeltme, UI’da hücreye tıklandığında formülün görünmemesi şeklinde yapıldı
  • 2016 Ağustos’unun ilk haftasında Uber China Didi’ye satıldı
    • Birçok çalışan bunu önce haber bildirimleriyle öğrendi
    • Birkaç saat sonra işlem dahili e-postayla duyuruldu
  • Uber China ortadan kalkınca bu UI Wesley’den kaldırıldı
    • Bir daha çalıştırılmayacak bir veri işi için özel yapılmış bir UI’dı
    • Tarayıcıda Excel’i yeniden yapma talebi bir daha gelmedi

Kodun ömründen çok problem çözme

  • O dönemde büyük bir kayıp ya da hayal kırıklığı hissi yoktu
    • Önce kodu GitHub’da yayımlamak istediğini düşündü, sonra bir sonraki işe geçti
    • Emek verilen kodun kısa süre kullanılıp ortadan kalkmasına dair küçük bir burukluk vardı
  • Bir mühendisin yazdığı kod bir gün legacy code olur
    • Birileri bir gün o kodu kaldırmaktan memnuniyet duyabilir
    • İyi yazılmış kodun uzun süre korunması başlı başına amaç değildir
  • Mühendis olarak gelişmek, teknolojiyi kullanarak iş değerini daha iyi üretme yönüyle bağlantılıdır
    • İş değeri; teknik çıktılar, işbirliği, mentorluk, ekibe destek gibi birçok yolla üretilebilir
  • Uber China ortadan kalktıktan sonra bu projeyle üretilecek başka iş değeri kalmamıştı
    • Zorlamaya devam etmek ne bireye ne şirkete fayda sağlardı
  • “Cattle, not pets” DevOps ifadesi kod için de geçerlidir
    • Kod, işi yerine getiren bir araçtır; o iş artık faydalı değilse emekli olmaya hazır demektir
    • Duygular nedeniyle koda evcil hayvan gibi davranmak, iş anlayışının tersine hareket ettirir

Rafa kaldırılan projenin bıraktığı sorular

  • Bir projenin kaldırılması onu hemen başarısız saymayı gerektirmez
  • Rafa kaldırılan çalışma şu soruları bırakır
    • Proje kısıtlarını karşılamayan bir şey mi yapıldı
    • İstenen şey mi yapıldı, ama baştaki istek mi yanlıştı
    • Temel problem yanlış mı anlaşıldı
    • İstenen çözüm gerçek son kullanıcıların ihtiyacını çözdü mü
    • Paydaşlara sorulmamış sorular var mıydı
    • Beklentiler yanlış ya da belirsiz miydi
    • Teslim edilen sağlamlık düzeyine gerçekten ihtiyaç var mıydı
    • Daha basit ya da daha az zeki bir çözüm yeterli olur muydu
    • Başarı kriteri yanlış mı belirlendi
    • “İstenen şeyi yapmak” dışında bir başarı kriteri var mıydı
  • Proje kapanışını yalnızca başarısızlık olarak görmek, teknik olmayan sorunların nerede saptığını öğrenme fırsatını kaçırmak demektir
  • Özenle yapılmış parçalar bile daha büyük sistem içinde sorunsuz çalışmıyorsa kaldırılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-16
Hacker News yorumları

  • En iyi alıntı şuydu: “Didi’de çalışanlar Uber China stajyeri olarak başvurup verilerimizi sızdırıyor. Formülleri görmelerine izin veremeyiz. Yoksa yaptığımız şeyi aynen kopyalarlar!”
    Bu gerçekten doğru. Amerikalılar, Çin’de her gün yaşanan ekonomik ve endüstriyel casusluk faaliyetlerinin seviyesini pek bilmiyor. 2000’lerin ortalarında, adını veremeyeceğim bir teknoloji şirketindeki ayrı bir ihlal olayına müdahale ederken, “Xinjiang’da bir teknoloji merkezi açtık, son zamanlarda giriş kartı kayıpları olağan dışı derecede arttı” dendiğini duydum; “Bunun kayıp değil de para karşılığı satılmış olabileceğini düşündünüz mü?” diye sorunca sessizlik oldu.
    Yöneticiler bunu bilip umursamıyor mu, yoksa sadece yetersizler mi bilmiyorum; ama Çin, endüstriyel casusluğu büyük ölçekte ürünleştirmiş durumda. Yakın zamanda GE Aviation da mağdur oldu: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...

    • Bunun gerçekten yaşandığını gördüm. Kilit mühendislerin ve teknik liderlerin ABD ve Avrupa şirketlerinde yeni nesil ürünler geliştirip, sonra dönüp Çin pazarı için fiilen aynı şeyi tasarlayıp geliştirdiklerini gördüm.
      Ardından Çin’de şirket kurup, Çinli yatırımcı alıp, Çin pazarı için neredeyse aynı ürünü üretiyorlar. Örneğin Thoratec/Abbot Heartmate III ile CH Biomedical, Auris/Verb/J&J Robotic & Digital Solutions ile Renovo Surgical gibi vakalar var.
      İronik biçimde, bu şirketlerden bazıları Çin’de başarılı olduktan sonra ABD ve Avrupa’ya satış yapıp rekabet etmeye çalışıyor. Artık bu bir sır da değil, kapalı kapılar ardında yürüyen bir iş de değil; sektörümüzde açıkça yaşanıyor ve çoğunlukla “böyle şeyler olur” diye kabul ediliyor.
      Bir diğer nokta da yabancı şirketlerin Çin’de iş yaparken varlıklarını korumasının çok zor olması. Bu yüzden akıllı şirketler doğrudan yapmaya hiç kalkışmıyor; çoğu zaman Çin pazarı için Çinli bir şirkete lisanslıyor. Böylece en azından her şeyin çalınmama ihtimali doğuyor.
    • Buna rağmen yazarın bir şirketin kodunu başka bir şirkette kullanmasını ya da şirket kodunu GitHub’da açıkça yayımlamasını kimse sorun etmiyor gibi görünüyor.
    • Çin hükümeti fikri mülkiyet hakkı ihlallerini pek umursamıyor. Tabii söz konusu fikri mülkiyet Çin’e aitse ve ihlali yapan Çinli olmayan bir şirketse durum başka.
      Eskiden çalıştığım ajansta, iBeacon donanımı için güzel bir kasa yapmak üzere bir endüstriyel tasarımcı getirmiştik. Sonuç harikaydı.
      Enjeksiyon kalıplamayı Çinli bir şirkete yaptırdık; numuneler de gayet iyiydi, kullanmaya karar verdik. Birkaç hafta sonra Alibaba/AliExpress’te bizim kasamızın satıldığını gördük.
      Batı’nın ya da başka ülkelerin kusursuz olduğunu söylemiyorum; ama burada konu bu değil. Çin imalatı ve ticaretiyle çalışmış tanıdığım herkes “kopyalandı”, “emeğimizi başkasına sattılar”, “anlaştığımızdan daha düşük kalitede x sağladılar” gibi şeyler yaşadı.
      Karşı argüman her zaman “Ama Batı da X yapıyor” ya da “Bu ırkçılık” noktasına varıyor.
      Çinli şirketler, özellikle Ali-X’te satış yapanlar, bu düzeni gerçekten seviyor. Çünkü fikri mülkiyeti bedavaya alıp özgün ekipman üreticisini fiyatla saf dışı bırakabiliyorlar. Tindie vb. platformlara koyulan maker tasarımlarının da kopyalanıp Ali’de ortaya çıktığı çok oluyor.
    • Sorun yalnızca kurumsal casusluk değil. Devlet düzeyinde casusluk faaliyetlerinin de ABD’deki tüm büyük şirketlere sızmış olma ihtimali yüksek. Makalenin bağlamında düşünürsek, bir kurumun hedeflerin Uber yolculuk bilgilerini gerçek zamanlı alabilmesi halinde ne kadar heyecanlanacağını hayal etmek yeterli.
    • Uber’ın Greyballing, sahte Lyft çağrıları rezerve etme, Anthony Levandowski’yi işe alma gibi şeyler yaptığını düşününce, Didi ile bir casusluk savaşına girmesi, bir mühendisin önceki işinden getirdiği kodu kullanması ve sonra bunu bizzat açıkça yayımlaması oldukça Uber’a özgü bir durum.
      https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
      https://www.theverge.com/2014/8/12/5994077/uber-cancellation...

  • Bu yazıyı okurken karmaşık özel kodların sökülüp atıldığı ve silindiği bir hikâye bekliyordum; ama yazar beklediğimin aksine bir mühendis olarak büyümüş
    “Cattle, not pets” DevOps deyişi buraya tam uyuyor. Kod ve o kodla yapılmış ürünler evcil hayvan değil, çiftlik hayvanıdır. İş görürler; o iş artık faydalı değilse de emekliye ayrılmaya hazırdırlar. Duygusal nedenlerle koda evcil hayvan gibi davranırsanız, işin çıkarlarına doğrudan ters düşen bir şey yapmış olursunuz
    Çok kod yazmak keyiflidir, çok problemi çözmek de keyiflidir. Ama iş dünyası, özellikle de startup’lar, aşırı odaklanmak zorundadır. Kariyerim fiilen toplantı odalarında oturup genç ve hevesli mühendislere yapmayın demekten ibaret gibi. Biraz moral bozucu ama aynı zamanda gerekli bir iş
    İyi bir mühendis, zekice kodla her sorunu çözebilir. Harika bir mühendis ise bazı sorunların aslında sorun olmadığını ve her gün güncellenen bir XLS indirme bağlantısının yeterli olabileceğini anlar

    • Kariyerimin başlarında öğrendiğim ve beni en çok etkileyen şey tam da “genç ve hevesli mühendislere yapmayın demek”ti
      Şirket içinde barındırdığımız bir servis için izleme sistemi yapıyorduk; yöneticim ortamımızın küçük bir parçasını izleyen ufak bir yardımcı aracı satın almak istiyordu. Bunu kendim yapabilecekken para verip almaya kalkması biraz gücüme gitmişti
      Yöneticim “Bunu yazıp test etmen ne kadar sürer?” diye sordu; ben de “Muhtemelen bir hafta, zor bir şey çıkarsa biraz daha uzun sürebilir” dedim. Bunun üzerine “O araç 500 dolar. Senin 40 saatlik ücretin ne kadar?” diye sordu
      O anda kafama dank etti ve o günden beri şirkette daha ucuza satın alınabilecek bir şeyi kendim yapmadım
    • Makalede “tarayıcı içindeki Excel” faydalı bir çözümdü; ama sorun elektronik tabloyu tarayıcıda göstermek değil, belirli bir kullanıcı arayüzünü doğru kullanıcılara hızlıca ulaştırmaktı. Yukarıdaki yorumda geçen “harika bir mühendis XLS indirme bağlantısının yeterli olabileceğini bilir” sözü de aynı bağlamda
      Substack sayfasının altındaki kontrol listesi de bu düzeyde gereksinim tespiti için yeterli değil. O sorular yalnızca durumu tarif eder; onları sormuş olmak bu basit çözüme ulaşmayı sağlamazdı. Kontrol listesiyle düşünmek bir koltuk değneği gibidir ve sorunu gereğinden fazla karmaşıklaştırır
      Buradaki önemli sinyallerin tamamı örgütsel ve sosyaldir; süreç iyileştirilerek çözülecek bir mesele değildi. Uygulama ayrıntılarına dahil olmayan biri, uygulama ayrıntılarıyla ilgili sorulara yanıt veremez
      “Sadece Excel gibi yapın” sözü, bambaşka hedefleri olan birinin verdiği düşük kaliteli bir yanıttır. Gerçek kullanıcıya daha yakın biriyle konuşup itirazı oradan geliştirmek gerekirdi. Eksik olan şey, zayıf varsayımları fark etmek ve tüm tarafların uzlaşacağı kadar ayrıntılar netleşene dek bilerek kod yazmama cesaretiydi. “Sorumlu kişiye” öylece evet denmemeli
    • 2016’da bile tam olarak aynı işi yapan birden fazla hazır seçenek vardı. Genç bir mühendisin tekerleği yeniden icat ederken büyük bir başarı hissi yaşaması ve daha sonra o zekice çözümün harcanan emeğe değmediğini fark etmesi için mükemmel bir örnek
      2006’da da birini o yola girmemeye ikna etmeye çalışarak uzun bir konuşma yapmıştım; 2026’da da birileri yine bunu yapmaya kalkacak
      “Acaba başkaları bu tam sorunu nasıl çözmüş?” diye durup düşünebilmek, geliştirici olarak olgunlaşmanın çok büyük bir parçası; keşke okullarda buna daha fazla odaklanılsa
    • Ne demek istediğini, bunun bir eleştiri olup olmadığını da pek anlamadım. Alıntılanan kısmın hemen öncesinde asıl yazının yazarı GitHub’daki koda bağlantı veriyor: https://github.com/WebSheets
      Kısa süre içinde zamanında ve başarılı biçimde tamamlandığı anlatılıyor diye uygulama tercihinin kötü olduğu sonucuna varılamaz. Aksine, fazla başarılı olup Excel özelliklerinin fazlasını uygulamış; sonra da bunları kaldırarak düzeltmiş. Bir XLS indirme bağlantısında bunu nasıl kaldıracaktı?
      Esas mesele koda fazla bağlanmamak; bazı durumlarda bu “kendin yapma, XLS indirme bağlantısı kullan” olabilir, ama bundan ibaret değil
    • İlginç ve yeni bir problemle karşılaştığım her seferinde şüpheleniyorum. Genel olarak programlama sıradan olmalı ve zaten binlerce kez çözülmüş problemleri çözüyor olmalısınız. Bir şey yeni görünüyorsa, çoğu zaman çözdüğüm problemi doğru tanımlamamış olma ihtimalim yüksektir

  • “Hiçbir şey olmadı ama o kodu bir gün kullanırım diye sakladım. Fikrim, bu kodu Uber’in kullanımına göre uyarlamaktı”, “İlk tepkim kodu GitHub’da yayımlamak oldu” kısımları çok şaşırtıcı
    O kod Box’ın ya da Uber’in mülkü değil mi? Yazar, MIT lisansıyla yayımlamadan önce izin aldığından söz etmiyor

    • Asıl yazının yazarıyım. O kodu başlangıçta mesai saatleri dışında yazmıştım. Box’a kodu vermeyi teklif ettim ama istemediler
      Uber, kendilerinden çıkmamış, üzerinden yarım yıldan fazla geçmiş, binlerce satırlık JavaScript olan ve bir aydan kısa süre kullanılmış bir kodu istiyorsa mektup gönderebilir
    • Bu tür hikâyelerin çoğu hukuk ekibine kâbus yaşatacak türden bence
    • Uber ve işe aldığı insanlar bana “hukuk” ya da “mülkiyet” gibi şeyleri pek umursayan tipler gibi hiç görünmedi
    • Bir kişinin kendi serbest zamanında yaptığı iş için şirketlerin dava açabilmesine olanak tanıyacak şekilde şirketlere haklar verilmiş olması gerçekten midemi bulandırıyor
    • Evet. Bu çok riskli. Büyük bir şirketin açtığı davaya karşı kişisel kaynaklarla savunma yapmak zorunda kalmak gerçekten berbat bir şey

  • “Tarayıcıda çalışan eksiksiz bir elektronik tablo motorunu benim yazdığıma bir türlü inanamamıştı” kısmına ben de inanmakta zorlanıyorum; iyi anlamda da değil
    Apache POI kullanırsanız headless Excel çalıştırabilirsiniz. Java’da sayfaları alıp programatik olarak etkileşime girebilirsiniz; önceki işimde tam olarak aynı nedenle kullanmıştım. Fonksiyonlar, hücre referansları vb. her şey gayet iyi çalışıyordu
    Sadece şans eseri circ sorununu bulmuş. Peki ileride karşılaşacağı Excel’in gizli küçük tuhaflıkları ne olacak? Gerçekten JS ile Excel’in eksiksiz bir kopyasını yapıp bakımını mı üstlenecek? Bu gerçekten frontend ekibinin hedefi mi?
    Biraz arama yapsaydı burada işin %90’ından fazlasından kaçınabilirdi gibi geliyor. Üstelik bunu backend ekibi de üstlenebilirdi

    • Bir teslim tarihi vardı, ekipte çalışan bir ürün çıkarabilecek tek fikir bendeydi ve ben de zamanında çalışan ürünü yayınladım
      Uber kendi veri merkezlerini işletiyordu. Gerçek Excel çalıştıracak bir Windows makinesi ya da VM tedarik etmek mucize gerektirirdi. Yeni bir frontend servisini yaklaşık 30 dakikada ayağa kaldırabiliyordum; ayrıca halihazırda bir ölçüde çalışan kod da vardı, yani tamamen sıfırdan başlamadım. Bu sistemin farklı veri setlerine sahip birden fazla kişi tarafından aynı anda kullanılmak zorunda olduğunu da hesaba katmak gerekir
      Sürekli daha fazla özellik ve Excel’le eşdeğerlik isteselerdi bunu değerlendirirdim, ama istemediler
      Yaptığım tercihi birçok kişinin yapmasını beklemiyorum. Ama çalıştı ve şaşırtıcı derecede iyi çalıştı. Yazıdan sadece “büyük ve karmaşık bir projeydi” sonucunu çıkardıysanız, yazı vermek istediğim mesajı doğru aktaramamış demektir
    • Adil olmak gerekirse, onun yazdığı şey belirli bir elektronik tabloyu çalıştırabilen bir elektronik tablo motoruydu. Karmaşıktı ama gereken şey, insanların Excel’den beklediği sonsuz özellik kuyruğu değil, uygulanması gereken sabit bir fonksiyon kümesiydi
      Ben olsam UI gereksinimlerini daha fazla sorgular, arkada Excel çalıştırma tarafını savunurdum sanırım. Ama çok sayıda sayısal girişin her yere dağıldığı durumlarda bu tanıdık bir UI
      100 satır F# ile elektronik tablo yapmayı anlatan şu yazıyı hep eğlenceli bulmuşumdur: https://tomasp.net/blog/2018/write-your-own-excel/ Buradan gerekli özellik kümesine genişletmek yönetilebilir düzeyde
    • Junior bir mühendisin mid-level ve senior seviyeye büyümesindeki en büyük alanlardan biri, tekerleği yeniden icat ettiği anı fark edebilmektir. Örneğin Excel ya da Microsoft Office paketiyle ilgili bir programlama işi aldıysanız, önce arama yapmaya değer. Çünkü bir yerlerdeki bir mühendisin 10 yıl önce aynı işi üstlenip blog yazısı yazmış ya da GitHub deposu oluşturmuş olma olasılığı yüksektir
    • Genel amaçlı bir sistem yöneticisi olarak bazen geleceğimin ne olduğunu bilmiyorum; ama en azından veri ekiplerimizi sürekli patlayan dizüstü bilgisayar kümeleri ve ucuz Excel yerine doğru düzgün hesaplama düğümleri kullanmaya ikna ettiğimi söyleyebilirim. Bunun gerçekten no-ops hayali olduğundan emin misiniz?
    • Apache POI ile headless Excel çalıştırıp Java’dan sayfalarla programatik olarak etkileşime girmek, tarayıcıda nasıl yardımcı oluyor?

  • Sonunda modelin UI’ı olarak kendi yaptıkları bir “Excel” kopyası oluşturmuşlar; gerekçe de “şehir ekipleri Excel’den başka bir şey kullanmayı bilmiyor”muş
    Ben tam tersini yapardım. Modelin dışa aktardığı veriye Excel’i bağlayıp şehir ekiplerinin gerçek Excel’i kullanmaya devam etmesini sağlardım. Çoğu finans ekibi bunu böyle yapıyor gibi görünüyor

    • Şehir ekipleri Çin’de olduğu için böyle bir lüksümüz yoktu. Her şey Uber’in BeyondCorp benzeri düzeninin arkasında olmak zorundaydı ve Çin ana karasındaki insanları doğrulamanın pratik bir yolu yoktu. Kullanabileceğimiz tek yüzey tarayıcıydı
    • Sorun şu kısımdı: “Elektronik tablo hücresine tıklayınca formül görünüyor. Öyle görünmemeli”, “Excel gibi yapmanızı söylemiştik”, “Didi’de çalışan kişiler Uber China stajyeri olarak başvurup verilerimizi sızdırıyor. Formülleri görmelerine izin veremeyiz. Görürlerse yaptığımız şeyi aynen kopyalarlar!”
    • Bu tarz bir çözüm geliştiriyoruz. Elektronik tablo modelini doğrudan şirket veritabanına bağlıyor, pivotları ve formülleri de SQL’e çeviriyoruz. Bunun değerli olduğunu düşünen kişilerle konuşmak isterim: https://arcwise.app

  • Merak edenler için Excel döngüsel başvuru belgesi: https://support.microsoft.com/en-us/office/remove-or-allow-a...
    Yinelemeli hesaplamaya aşina değilseniz, döngüsel başvuruyu olduğu gibi bırakmak istememe olasılığınız yüksektir. Yinelemeli hesaplamayı açabilirsiniz; ancak formülün kaç kez yeniden hesaplanacağını belirlemeniz gerekir. Maksimum yineleme sayısını veya maksimum değişim değerini değiştirmeden yinelemeli hesaplamayı açarsanız Excel, 100 yinelemeden sonra ya da döngüsel başvurudaki tüm değer değişimleri yinelemeler arasında 0,001’in altına düştüğünde — hangisi önce olursa — hesaplamayı durdurur. Bununla birlikte maksimum yineleme sayısını ve kabul edilebilir değişim miktarını kontrol edebilirsiniz

  • Uber ya da Box bu kodun kendilerine ait olduğunu iddia etseydi yazarın bu duruma farklı bakıp bakmayacağını merak ediyorum. Kod gerçek potansiyelini ortaya koyamamış olsa bile, en azından tüm dünyanın onu görüp kabul edebilmesi bir ölçüde katarsis sağlayabilir gibi geliyor.
    Ben stajyer olarak çalışırken baştan sona bir programlama dili yapmıştım. Gecikmeli değerlendirme vardı, garbage collection vardı; tırnaksız MAC adreslerinin geçerli sözdizimi olması gibi uygulamaya özgü tuhaflıklar da vardı.
    Bytecode ya da JIT gibi şeyler yoktu; yorumlayıcı sözdizimi ağacında dolaşıp stack’e değerleri push/pop ederek çalışıyordu, ama yaptığımız iş için yeterince hızlıydı. Yorumlayıcı saf ANSI C ile yazılmıştı ve Valgrind de gayet memnundu.
    Tamamen unutulmuş da olabilir, o şirketin teknik altyapısının çekirdeği hâline gelmiş de olabilir. O kod, yazdığım air-gapped laboratuvarın dışına hiç çıkmadığı için bilmemin yolu yok. 3 yıl önce üniversiteden yeni mezunken, bu açık ara yazdığım “gerçekten işe yarar yazılımlar” içinde en havalısıydı; hâlâ da üst sıralarda. Bazen ona ne olduğunu merak ediyorum.

    • Yazarın kaçırdığı nokta, Box ve Uber’in o kodu zaten kendilerine ait saymış olması. İş sözleşmesinde böyle yazıyordur.
      Yazar, orta kademe bir yöneticiye, hatta üst düzey bir yöneticiye “Bunu istiyor musunuz?” diye sorduğunda ve o yönetici “Hayır” dediğinde bunun şirket için hukuken bağlayıcı olduğunu sanıyor gibi görünüyor.

  • “Özellikle akıllıca ya da zarif kodu bir başyapıt gibi görmek kolaydır. Gerçekten de güzel bir süs eşyası olabilir. Ama biz mühendisler güzel süs eşyaları üretme işinde değil, sonuç üretme işindeyiz” cümlesi bana dokundu.
    Yine de kodumu gören herkesin bileceği gibi, ben kodun ve yaptığı işin de çok güzel olmasını isterim. Genelde bakımını yine benim yapacağım kodu yazdığım için, 1 yıl sonra baktığımda da anlayabilmem gerekir.
    Şu anda burada duyurmayacağım ve pek de kredi toplamayı düşünmediğim bir projenin son aşamasındayım; gerçekten müthiş bir şey. Böyle olmasının nedeni kimsenin bunun için para ödememesi ve kimsenin bundan para kazanmaması.
    Para her şeyi mahvedebildiği gibi, aynı zamanda her şeyi mümkün de kılar.

  • Eski Uber BI ekibinin bakış açısından gerçekten harika bir yazı. Ben o dönemde Vertica ekibindeydim ve incentive’lara harcanan çabanın miktarı akıl almazdı. Downtime, ürün özellikleri ve mühendislik kapasitesi açısından günde milyonlarca doların uçup gitmesi sık konuşulan bir konuydu.
    Özellikle Uber China döneminde bir direktörün UI olarak doğrudan spreadsheet istemesi de son derece doğal bir şey olurdu. Ben de kişisel olarak her ay ekibe e-postayla gelen bir spreadsheet’ten FX fiyatlarını Vertica’ya yüklüyordum. Otomatik toplamayla kontrol akışını tersine çevirecek kapasite olmadığından bu süreç 1 yıldan uzun süre kaldı.

  • “Bugüne kadar Uber’in şirket içi uygulama sistemi kadar iyi tasarlanmış bir şey görmedim. Başlangıçtan, *.uberinternal.com alt alan adında Hello World’ü tam CI/CD ile çalıştırmaya kadar 30 dakikadan az sürüyordu” sözü içimi biraz ısıttı.
    O dönemde Uber’de tüm bunların içinde yer almıştım.