2 poin oleh GN⁺ 2023-09-16 | 1 komentar | Bagikan ke WhatsApp
  • Pada 2016, organisasi Business Intelligence Uber membuat alat eksekusi model R dan UI mirip Excel agar data yang dibutuhkan untuk bersaing di Uber China bisa digunakan dengan cepat, tetapi fitur itu segera dihapus setelah Uber China dijual ke Didi
  • R-Crusher adalah sistem internal yang bertujuan mengubah alur kerja rapuh, di mana data scientist mengunduh data Vertica ke laptop lalu menjalankan model R semalaman, menjadi alat eksekusi berbasis API
  • Tim kota di Tiongkok sudah terbiasa dengan file Excel untuk menghitung insentif pengemudi, sehingga tim membangun mesin spreadsheet yang menjalankan file XLS dan rumus di browser, alih-alih memindahkan ratusan hingga ribuan rumus langsung ke JavaScript
  • Penyebab hasil yang sedikit berbeda dari Excel ternyata karena data scientist menjalankan regresi linear dengan referensi sirkular, lalu sistem disesuaikan agar menghitung berulang seperti Excel sampai nilainya konvergen
  • Bahkan kode yang dibuat dengan baik pun bisa dihapus jika masalah bisnis yang hendak diselesaikan sudah hilang; nilai rekayasa lebih dekat pada pemecahan masalah daripada usia pakai kode

Alat data internal yang menopang Uber China

  • Setelah bergabung dengan Uber pada 2016, penulis bekerja sebagai engineer frontend pertama di tim Crystal Ball
    • Timnya berisi sekitar 4 orang dan sebagian besar sangat berorientasi backend
    • Perannya adalah membuat UI untuk alat internal agar benar-benar bisa dipakai orang-orang di perusahaan
  • Saat itu, data scientist mengunduh data dari Vertica lalu menjalankan model R semalaman di beberapa laptop
    • Pada pagi hari, hanya laptop yang modelnya tidak gagal yang menghasilkan data yang mungkin bisa dipakai hari itu
    • Laptop yang gagal tidak menghasilkan data yang dibutuhkan, dan itu bisa berujung pada kerugian uang bagi perusahaan
  • R-Crusher yang sedang dibuat tim lebih mirip sistem CI yang mengunduh dan menjalankan kode lewat pemanggilan API lalu menghasilkan file hasil
  • Wesley, frontend untuk R-Crusher, memiliki versi pertama yang siap hanya beberapa minggu setelah penulis bergabung
    • Selama 6–7 bulan berikutnya, mereka menambahkan fitur pengguna, alat debugging, dan memperluas tim frontend

Pasar Tiongkok dan perhitungan insentif pengemudi

  • Pada 2016, dua fokus besar internal Uber adalah penulisan ulang/desain ulang aplikasi dan Uber China
  • Pekerjaan tim Crystal Ball pada akhirnya ditujukan untuk mendukung Uber China
    • R-Crusher adalah alat untuk memperoleh data yang dibutuhkan guna bersaing dengan Didi
    • Tiongkok adalah peluang penting bagi Uber, dan sebagian data yang dibutuhkan direncanakan berasal dari R-Crusher
  • Pada musim panas, muncul permintaan baru
    • Ada model yang menghasilkan data prediksi permintaan perjalanan di Tiongkok semalaman
    • Data ini tidak terlalu berguna sendirian, tetapi jika dimasukkan ke tab tertentu dalam spreadsheet Excel, itu menjadi alat interaktif untuk menghitung insentif pengemudi
  • Penanggung jawab keuangan meminta agar spreadsheet itu dimasukkan ke dalam Wesley
    • Tim kota mengatakan mereka hanya bisa menggunakan Excel dan meminta agar dibuat “seperti Excel”
    • Saat dijelaskan bahwa waktu engineering tidak cukup, jawabannya adalah tanpa alat itu mereka kehilangan jutaan dolar setiap hari

Meniru Excel di dalam browser

  • Tidak ada waktu untuk memindahkan spreadsheet ke kode Python atau R di backend, sehingga situasinya mengarah pada penulisan banyak JavaScript di frontend
  • Prototipe Box Sums yang sebelumnya dibuat di Box menjadi dasar
    • Prototipe itu punya UI spreadsheet sederhana berbasis React dan mesin rumus dasar
    • Jika file XLS/XLSX dijatuhkan ke halaman, isinya diparse dengan library Node
  • Implementasi untuk Uber tidak menargetkan Excel itu sendiri, melainkan perilaku yang mendekati Excel
    • Membaca file XLS sebagai input
    • Menjalankan rumus Excel di atas data
    • Backend menyediakan data permintaan perjalanan sebagai array 2 dimensi, dan frontend memasukkannya ke mesin rumus seperti tab tersembunyi
    • Selain sel yang memang perlu dimanipulasi pengguna, semuanya dibuat hanya-baca
  • Inti pendekatannya adalah menghindari penerjemahan langsung ratusan hingga ribuan rumus padat ke JavaScript
  • Dalam proses implementasi, mereka mengekstrak rumus dari file XLS lalu menambahkan fungsi dan sintaks yang diperlukan ke mesin rumus
    • Perluasan sintaks Excel

      • Referensi sel absolut
      • Referensi sel dari sheet lain
      • Sintaks spreadsheet yang tidak ada di demo Box sebelumnya

Angka yang hampir benar, tetapi salah, dan referensi sirkular

  • Pada perbandingan pertama, hasil Excel dan hasil mesin buatan sendiri sedikit berbeda
    • Saat keluaran Excel 3.03, keluaran mereka 3.01
    • Saat keluaran Excel 1.002, keluaran mereka 1.000
  • Nilai yang hampir benar justru lebih sulit ditangani daripada nilai yang jelas salah
    • Kemungkinan besar penyebabnya bukan kesalahan logika sederhana, melainkan perbedaan perhitungan yang halus
  • Unit test lolos, dan perbedaan representasi floating point antara JavaScript double dan Excel juga bukan penyebabnya
  • Setelah bertanya kepada data scientist, penyebabnya terungkap
    • Spreadsheet itu menggunakan referensi sirkular untuk menjalankan regresi linear
    • Excel tidak selalu memperlakukan referensi sirkular sebagai error
    • Jika nilai perhitungan konvergen hingga selisihnya di bawah epsilon tertentu, Excel menghentikan iterasi dan menganggapnya berhasil
  • Implementasinya kemudian diubah untuk mendeteksi graf dependensi sirkular dan membandingkan nilai perhitungan sebelumnya dengan nilai baru
    • Jika selisihnya cukup kecil, nilai baru digunakan
    • Jika tidak, jumlah iterasi ditambah dan perhitungan dilanjutkan
    • Batas jumlah iterasi ditetapkan ke 1000
  • Perubahan itu memakan waktu sekitar satu setengah hari, dan hasil keluarannya pun cocok dengan Excel
    • Mereka menulis test dan mengintegrasikannya ke Wesley
    • Proyek itu diserahkan pada minggu kedua Juli

Setelah rilis: tuntutan keamanan dan penghentian mendadak

  • Alat itu benar-benar dirilis, dan anggota tim kota Uber China masuk untuk menggunakannya
    • Sejauh yang diketahui, angka yang dihasilkan dipakai untuk insentif pengemudi
    • Waktunya adalah minggu ketiga Juli
  • Pada minggu terakhir Juli, penanggung jawab keuangan mempersoalkan bahwa rumus terlihat saat sel diklik
    • Muncul kekhawatiran bahwa pegawai Didi bisa melamar sebagai intern Uber China lalu mengambil data tersebut
    • Model ancaman seperti ini tidak dibagikan sebelumnya kepada tim engineering
  • Untuk benar-benar melindungi rumus, perhitungannya harus dipindahkan ke server, tetapi itu berada di luar cakupan permintaan
    • Perbaikan langsung yang dilakukan adalah menyembunyikan rumus di UI saat sel diklik
  • Pada minggu pertama Agustus 2016, Uber China dijual ke Didi
    • Banyak karyawan pertama kali mengetahuinya dari notifikasi berita
    • Beberapa jam kemudian, transaksi itu diumumkan lewat email internal
  • Setelah Uber China hilang, UI tersebut dihapus dari Wesley
    • Itu adalah UI kustom untuk pekerjaan data yang tidak akan pernah dijalankan lagi
    • Tidak pernah ada lagi permintaan untuk membuat ulang Excel di browser

Menyelesaikan masalah lebih penting daripada umur kode

  • Saat itu tidak ada rasa kehilangan atau kekecewaan yang besar
    • Pikiran pertama justru ingin membuka kode itu di GitHub, lalu setelahnya lanjut ke pekerjaan berikutnya
    • Tetap ada sedikit rasa sayang karena kode yang dikerjakan dengan susah payah hanya dipakai sebentar lalu hilang
  • Kode yang ditulis engineer pada akhirnya akan menjadi legacy code
    • Suatu hari mungkin ada orang lain yang justru senang saat menghapus kode tersebut
    • Bahkan untuk kode yang dibuat dengan baik, bertahan lama bukanlah tujuan itu sendiri
  • Bertumbuh sebagai engineer berkaitan dengan makin mampu menggunakan teknologi untuk menciptakan nilai bisnis
    • Nilai bisnis bisa diciptakan lewat banyak cara: hasil teknis, kolaborasi, mentoring, dukungan tim, dan lainnya
  • Setelah Uber China hilang, tidak ada lagi nilai bisnis yang bisa ditambahkan dari proyek ini
    • Memaksakannya terus tidak akan membantu siapa pun, baik individu maupun perusahaan
  • Ungkapan DevOps “Cattle, not pets” juga berlaku untuk kode
    • Kode adalah sarana untuk menyelesaikan pekerjaan, dan jika pekerjaan itu tak lagi berguna, maka kode tersebut siap dipensiunkan
    • Jika karena emosi kita memperlakukan kode seperti hewan peliharaan, kita justru bergerak berlawanan dengan pemahaman bisnis

Pertanyaan yang ditinggalkan proyek yang dibuang

  • Proyek yang dihapus tidak perlu langsung dianggap gagal
  • Pekerjaan yang dibuang meninggalkan pertanyaan-pertanyaan berikut
    • Apakah yang dibuat gagal memenuhi batasan proyek
    • Apakah yang diminta memang berhasil dibuat, tetapi permintaan awalnya salah
    • Apakah masalah intinya dipahami dengan keliru
    • Apakah solusi yang diminta benar-benar memenuhi kebutuhan pengguna akhir
    • Apakah ada pertanyaan yang tidak diajukan kepada para pemangku kepentingan
    • Apakah ekspektasinya tidak akurat atau ambigu
    • Apakah tingkat ketahanan yang dibangun memang benar-benar diperlukan
    • Apakah solusi yang lebih sederhana atau kurang “cerdas” sebenarnya sudah cukup
    • Apakah kriteria keberhasilannya ditetapkan secara keliru
    • Apakah ada kriteria sukses selain “membuat apa yang diminta”
  • Jika penghentian proyek hanya dipandang sebagai kegagalan, kita kehilangan kesempatan belajar tentang di mana masalah nonteknis mulai melenceng
  • Bahkan komponen yang dibuat dengan sangat rapi pun bisa dihapus jika tidak bekerja mulus di dalam sistem yang lebih besar

1 komentar

 
GN⁺ 2023-09-16
Komentar Hacker News
  • Kutipan terbaiknya adalah ini: “Orang-orang yang bekerja di Didi melamar sebagai intern Uber China lalu mencuri data kami. Kita tidak boleh membiarkan mereka melihat rumusnya. Kalau begitu mereka akan menyalin persis apa yang kita lakukan!”
    Pernyataan itu benar sekali. Orang Amerika tidak begitu memahami tingkat spionase ekonomi dan industri yang terjadi setiap hari di China. Sekitar pertengahan 2000-an, saat menangani insiden pembobolan terpisah di sebuah perusahaan teknologi yang tidak bisa saya sebutkan namanya, saya mendengar, “Kami membuka pusat teknologi di Xinjiang, dan belakangan ini kehilangan kartu akses terjadi sangat sering.” Ketika saya bertanya, “Pernah terpikir bahwa itu mungkin bukan hilang, melainkan dijual demi uang?”, suasana menjadi hening
    Entah para eksekutif tahu tetapi tidak peduli, atau mereka memang tidak kompeten, tetapi China telah memproduksikan spionase industri dalam skala besar. Baru-baru ini GE Aviation juga menjadi korban: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...

    • Saya pernah melihat hal seperti ini benar-benar terjadi. Saya melihat para engineer inti dan pemimpin teknis mengembangkan produk generasi berikutnya di perusahaan Amerika dan Eropa, lalu berbalik dan merancang serta mengembangkan hal yang pada dasarnya sama untuk pasar China
      Setelah itu mereka mendirikan perusahaan di China, menerima investasi dari investor China, dan membuat produk yang hampir sama untuk pasar China. Contohnya antara lain Thoratec/Abbot Heartmate III dan CH Biomedical, serta Auris/Verb/J&J Robotic & Digital Solutions dan Renovo Surgical
      Ironisnya, sebagian dari perusahaan seperti ini, setelah sukses di China, berusaha menjual ke Amerika dan Eropa serta bersaing di sana. Sekarang ini bukan lagi rahasia atau transaksi gelap; di industri kami hal ini terjadi secara terang-terangan dan umumnya diterima sebagai “memang begitu adanya”
      Satu hal lain adalah sangat sulit bagi perusahaan asing untuk melindungi asetnya saat berbisnis di China. Karena itu perusahaan yang cerdas sering kali sama sekali tidak mencoba melakukannya sendiri, melainkan melisensikannya ke perusahaan China untuk pasar China. Dengan begitu setidaknya ada kemungkinan tidak semuanya dicuri
    • Meski begitu, tampaknya tidak ada yang mempermasalahkan penulis yang memakai kode dari satu perusahaan di perusahaan lain, atau membuka kode perusahaan ke GitHub
    • Pemerintah China tidak terlalu peduli pada pelanggaran hak kekayaan intelektual. Kecuali jika kekayaan intelektual itu milik China dan dilanggar oleh perusahaan non-China
      Dulu di agensi tempat saya bekerja, kami pernah membawa seorang industrial designer untuk membuat casing yang bagus untuk hardware iBeacon. Hasilnya luar biasa
      Kami menyerahkan injection molding ke perusahaan China, dan sampelnya juga cukup bagus sehingga kami memutuskan memakainya. Namun beberapa minggu kemudian, kami melihat casing kami dijual di Alibaba/AliExpress
      Ini bukan berarti Barat atau negara lain sempurna, tetapi bukan itu yang sedang dibahas. Semua orang yang saya kenal yang pernah bekerja dengan manufaktur dan bisnis China pernah mengalami hal seperti “ditiru”, “upaya kami dijual kepada pihak lain”, atau “mereka menyediakan x dengan grade lebih rendah dari yang disepakati”
      Bantahannya selalu berujung pada “toh Barat juga melakukan X” atau “itu rasis”
      Perusahaan-perusahaan China, terutama yang berjualan di Ali-X, sangat menyukai struktur ini. Sebab mereka bisa mengambil kekayaan intelektual secara gratis dan menyingkirkan produsen peralatan asli lewat harga. Desain para maker yang diunggah ke Tindie dan tempat lain juga sering ditiru lalu muncul di Ali
    • Ini bukan hanya soal spionase korporat. Spionase tingkat negara juga sangat mungkin sudah masuk ke semua perusahaan besar Amerika. Dalam konteks artikel ini, cukup bayangkan betapa bersemangatnya sebuah lembaga jika bisa menerima informasi perjalanan Uber target secara real time
    • Mengingat Uber pernah melakukan Greyballing, pemesanan panggilan Lyft palsu, perekrutan Anthony Levandowski, dan sebagainya, terlibat dalam perang spionase dengan Didi, memakai kode yang dibawa engineer dari tempat kerja sebelumnya, lalu belakangan bahkan membukanya ke publik, terasa sangat khas Uber
      https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
      https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
  • Saat membaca tulisan ini, saya mengira akan ada cerita tentang kode kustom yang rumit disingkirkan dan dihapus, tetapi berbeda dari dugaan, penulisnya justru tumbuh sebagai engineer
    Pepatah DevOps “Cattle, not pets” sangat pas di sini. Kode dan produk yang dibuat dengan kode itu bukan hewan peliharaan, melainkan ternak. Mereka melakukan pekerjaan, dan ketika pekerjaan itu tidak lagi berguna, mereka siap dipensiunkan. Jika kita memperlakukan kode seperti hewan peliharaan karena alasan sentimental, itu berarti kita melakukan sesuatu yang bertentangan langsung dengan kepentingan bisnis
    Banyak kode menyenangkan untuk ditulis, dan banyak masalah menyenangkan untuk dipecahkan. Namun bisnis, terutama startup, harus sangat fokus. Karier saya pada dasarnya lebih dekat dengan pekerjaan duduk di ruang rapat dan mengatakan kepada engineer muda yang bersemangat untuk tidak membuatnya. Agak menyedihkan, tetapi juga sangat perlu
    Engineer yang baik bisa memecahkan masalah apa pun dengan kode yang cerdas. Engineer yang hebat memahami bahwa sebagian masalah sebenarnya bukan masalah, dan mungkin tautan unduhan XLS yang diperbarui setiap hari saja sudah cukup

    • Salah satu pelajaran paling berpengaruh yang saya dapatkan di awal karier adalah persis “mengatakan kepada engineer muda yang bersemangat untuk tidak membuatnya”
      Saya sedang membuat sistem monitoring untuk layanan yang di-hosting secara internal, dan atasan saya ingin membeli sebuah utilitas kecil untuk memantau bagian sepele dari lingkungan kami. Saya agak tersinggung karena ia mau membayar untuk membeli sesuatu yang bisa saya buat sendiri
      Atasan saya bertanya, “Berapa lama waktu yang kamu butuhkan untuk menulis dan mengujinya?” dan saya menjawab, “Mungkin seminggu, bisa sedikit lebih lama kalau ada bagian yang sulit.” Lalu ia bertanya, “Tool itu harganya 500 dolar. Berapa upah per jam untuk 40 jam kerjamu?”
      Saat itu saya tersadar, dan sejak itu saya tidak pernah membuat sendiri sesuatu yang bisa dibeli perusahaan dengan lebih murah
    • Dalam artikel disebutkan bahwa “Excel di dalam browser” adalah solusi yang berguna, tetapi masalahnya bukan menampilkan spreadsheet di browser, melainkan menyampaikan UI tertentu dengan cepat kepada pengguna yang tepat. Pernyataan di komentar di atas bahwa “engineer yang hebat tahu bahwa tautan unduhan XLS mungkin sudah cukup” juga berada dalam konteks yang sama
      Checklist di bagian bawah halaman Substack juga tidak cukup untuk memahami requirement pada tingkat seperti ini. Pertanyaan-pertanyaan itu hanya menggambarkan situasi, dan sekadar menanyakannya tidak akan membuat orang sampai pada solusi sederhana ini. Cara berpikir berbasis checklist adalah tongkat penyangga dan membuat masalah menjadi terlalu rumit
      Sinyal penting di sini semuanya bersifat organisasional dan sosial, bukan masalah yang bisa diselesaikan dengan memperbaiki proses. Orang yang tidak terlibat dalam detail implementasi tidak bisa menjawab pertanyaan tentang detail implementasi
      Ucapan “buat saja seperti Excel” adalah jawaban berkualitas rendah dari orang yang punya tujuan yang sama sekali berbeda. Seharusnya berdiskusi dengan orang yang lebih dekat dengan pengguna sebenarnya dan membangun sanggahan dari sana. Yang hilang adalah keberanian untuk mengenali asumsi yang lemah dan sengaja tidak menulis kode sampai detailnya cukup terkunci untuk disetujui semua pihak. Jangan sekadar mengatakan ya kepada “penanggung jawab”
    • Pada 2016 pun sudah ada beberapa opsi siap pakai yang melakukan hal yang persis sama. Ini contoh sempurna tentang engineer muda yang merasa sangat berprestasi karena menciptakan kembali roda, lalu belakangan menyadari bahwa solusi cerdas itu tidak sepadan dengan usaha yang dikeluarkan
      Pada 2006 pun saya pernah berdiskusi panjang untuk meyakinkan seseorang agar tidak menempuh jalan itu, dan pada 2026 pun pasti akan ada lagi orang yang ingin melakukannya
      Kemampuan untuk berhenti sejenak dan berpikir, “Bagaimana orang lain memecahkan masalah persis ini?” adalah bagian yang sangat besar dari perkembangan sebagai developer, jadi saya berharap sekolah lebih menaruh fokus pada hal itu
    • Saya tidak begitu paham apa yang dimaksud, atau apakah ini kritik. Tepat sebelum bagian yang dikutip, penulis asli menautkan kode di GitHub: https://github.com/WebSheets
      Hanya dari penjelasan bahwa implementasinya berhasil diselesaikan tepat waktu dalam tenggat singkat, kita tidak bisa menyimpulkan bahwa pilihan implementasinya buruk. Justru ceritanya adalah bahwa implementasi itu terlalu berhasil sehingga terlalu banyak fitur Excel yang diimplementasikan, lalu kemudian diperbaiki dengan menghapusnya. Bagaimana mungkin itu dihapus dari tautan unduhan XLS?
      Intinya adalah jangan terlalu melekat pada kode, dan dalam beberapa situasi jawabannya bisa berupa “jangan buat sendiri, pakai tautan unduhan XLS”, tetapi itu bukan segalanya
    • Setiap kali menemukan masalah yang menarik dan baru, saya jadi curiga. Secara umum, pemrograman seharusnya biasa-biasa saja, dan kita seharusnya sedang memecahkan masalah yang sudah dipecahkan ribuan kali. Jika sesuatu tampak baru, biasanya kemungkinan besar saya belum mengidentifikasi dengan benar masalah yang sedang saya pecahkan
  • Bagian “Tidak terjadi apa-apa, tetapi saya menyimpan kode itu untuk suatu hari nanti ketika bisa dipakai. Ide saya adalah memoles kode ini agar sesuai dengan kebutuhan Uber”, dan “Reaksi pertama saya adalah membuka kode itu di GitHub” sangat mengejutkan
    Bukankah kode itu milik Box atau Uber? Penulis tidak menyebutkan bahwa ia mendapat izin sebelum merilisnya dengan lisensi MIT

    • Saya penulis aslinya. Kode itu awalnya ditulis di luar jam kerja. Saya menawarkan untuk memberikan kode itu kepada Box, tetapi mereka tidak menginginkannya
      Jika Uber menginginkan JavaScript ribuan baris yang bukan berasal dari mereka, sudah lewat lebih dari setengah tahun, dan dipakai kurang dari sebulan, mereka tinggal mengirim surat
    • Menurut saya cerita seperti ini adalah jenis yang akan membuat sebagian besar tim legal mimpi buruk
    • Uber dan orang-orang yang mereka pekerjakan tidak pernah terlihat seperti tipe yang terlalu peduli pada hal-hal seperti “hukum” atau “properti”
    • Saya merasa benar-benar jijik dengan kenyataan bahwa selama ini hak diberikan kepada perusahaan sehingga mereka bisa menuntut pekerjaan yang dilakukan seseorang di waktu luang pribadinya
    • Benar. Ini terlalu berisiko. Harus membela diri dengan sumber daya pribadi melawan gugatan dari perusahaan besar adalah hal yang benar-benar mengerikan
  • Bagian “dia sama sekali tidak percaya bahwa aku menulis seluruh mesin spreadsheet yang berjalan di browser” juga sulit kupercaya, dan bukan dalam arti baik
    Dengan Apache POI, kita bisa menjalankan Excel secara headless. Di Java, kita bisa mengambil sheet dan berinteraksi dengannya secara terprogram; di tempat kerja lamaku kami memakainya untuk alasan yang persis sama. Fungsi, referensi sel, dan sebagainya semuanya berjalan dengan baik
    Dia hanya beruntung menemukan masalah ‘circ’. Bagaimana dengan berbagai keanehan kecil tersembunyi Excel yang akan ditemui nanti? Benarkah akan membuat dan memelihara replika Excel lengkap dengan JS? Apakah itu memang tujuan tim frontend?
    Sepertinya dengan sedikit pencarian saja, lebih dari 90% pekerjaan di sini bisa dihindari. Bonusnya, tim backend juga bisa saja menanganinya

    • Ada tenggat, tim punya satu-satunya ide yang bisa menghasilkan produk yang berjalan, dan aku merilis produk yang berfungsi tepat waktu
      Uber mengoperasikan data centernya sendiri. Untuk menyediakan mesin Windows atau VM yang menjalankan Excel sungguhan mungkin butuh keajaiban. Aku bisa menyalakan layanan frontend baru dalam kira-kira 30 menit, dan sebagian kode sudah berjalan, jadi ini bukan benar-benar dimulai dari nol. Perlu juga diperhitungkan bahwa sistem ini harus dipakai secara bersamaan oleh banyak orang dengan set data berbeda
      Kalau mereka terus meminta lebih banyak fitur dan kesetaraan dengan Excel, aku akan meninjaunya, tetapi itu tidak terjadi
      Aku tidak berharap banyak orang akan membuat pilihan yang sama sepertiku. Namun pilihan itu berhasil, dan berhasil dengan sangat baik. Jika dari tulisan itu yang tertangkap hanya “ini proyek besar dan kompleks”, berarti tulisanku gagal menyampaikan pesan yang ingin kusampaikan
    • Agar adil, yang ia tulis adalah mesin spreadsheet yang bisa menjalankan satu spreadsheet tertentu. Memang kompleks, tetapi yang dibutuhkan adalah sekumpulan fungsi tetap yang harus diimplementasikan, bukan ekor fitur tak berujung yang diharapkan orang dari Excel
      Kalau aku, mungkin aku akan lebih mempertanyakan spesifikasi UI dan mendorong opsi menjalankan Excel di belakang layar. Namun jika ada banyak input angka di berbagai tempat, UI yang familier memang masuk akal
      Aku selalu menikmati tulisan tentang membuat spreadsheet dalam 100 baris F# ini: https://tomasp.net/blog/2018/write-your-own-excel/ Mengembangkannya ke kumpulan fitur yang dibutuhkan di sini masih terasa bisa ditangani
    • Salah satu area terbesar dalam pertumbuhan engineer junior menjadi mid-level dan senior adalah kemampuan mengenali momen saat kita sedang menciptakan ulang roda. Misalnya, jika mendapat tugas pemrograman yang berkaitan dengan Excel atau rangkaian produk Microsoft Office, ada baiknya mencari dulu. Kemungkinan besar ada engineer di suatu tempat yang mengerjakan hal yang sama 10 tahun lalu lalu menulis posting blog atau membuat repositori GitHub
    • Sebagai administrator sistem serbaguna, kadang aku tidak tahu masa depanku akan seperti apa, tetapi setidaknya aku bisa bilang bahwa aku membuat orang-orang data kami memakai node komputasi yang layak, bukan berkelahi dengan klaster laptop yang mudah jebol dan Excel murahan. Yakin ini benar-benar mimpi no-ops?
    • Bagaimana menjalankan Excel secara headless dengan Apache POI dan berinteraksi dengan sheet secara terprogram dari Java bisa membantu di browser?
  • Pada akhirnya mereka membuat replika “Excel” buatan sendiri sebagai UI untuk model, alasannya “tim kota hanya tahu cara memakai Excel”
    Kalau aku, aku akan melakukan kebalikannya. Aku akan menghubungkan Excel ke data keluaran model agar tim kota tetap bisa memakai Excel sungguhan. Sepertinya sebagian besar tim keuangan bekerja seperti ini

    • Karena tim kota berada di Tiongkok, kami tidak bisa menikmati kemewahan itu. Semuanya harus berada di balik sistem mirip BeyondCorp milik Uber, dan tidak ada cara realistis untuk mengautentikasi orang-orang di Tiongkok daratan. Satu-satunya permukaan yang bisa kami gunakan adalah browser
    • Masalahnya ada di bagian ini. “Kalau mengklik sel spreadsheet, rumusnya terlihat. Itu tidak boleh terlihat”, “Kan saya bilang buat seperti Excel”, “Orang-orang yang bekerja di Didi melamar sebagai intern Uber China lalu mencuri data kami. Mereka tidak boleh melihat rumusnya. Kalau begitu, mereka bisa menyalin persis apa yang kami lakukan!”
    • Kami sedang membuat solusi seperti ini. Menghubungkan model spreadsheet langsung ke database perusahaan, dan pivot maupun rumus juga diterjemahkan ke SQL. Ingin berbicara dengan orang yang merasa ini bernilai: https://arcwise.app
  • Dokumentasi referensi sirkular Excel bagi yang penasaran: https://support.microsoft.com/en-us/office/remove-or-allow-a...
    Jika tidak terbiasa dengan perhitungan iteratif, kemungkinan besar Anda tidak ingin membiarkan referensi sirkular begitu saja. Perhitungan iteratif memang bisa diaktifkan, tetapi Anda harus menentukan berapa kali rumus dihitung ulang. Jika perhitungan iteratif diaktifkan tanpa mengubah jumlah iterasi maksimum atau perubahan maksimum, Excel akan berhenti menghitung setelah 100 iterasi atau ketika semua perubahan nilai dalam referensi sirkular menjadi kurang dari 0,001 di antara iterasi, mana yang terjadi lebih dulu. Namun jumlah iterasi maksimum dan besaran perubahan yang dapat diterima bisa dikendalikan

  • Saya penasaran apakah penulis akan melihat situasi ini secara berbeda jika Uber atau Box mengklaim kode itu sebagai milik mereka. Meski kode itu tidak pernah benar-benar mencapai potensinya, setidaknya fakta bahwa seluruh dunia bisa melihat dan mengakuinya rasanya bisa memberi semacam katarsis
    Saat bekerja sebagai intern, saya pernah membuat seluruh bahasa pemrograman. Bahasanya dievaluasi secara lazy dan punya garbage collection, serta memiliki keanehan khusus aplikasi seperti alamat MAC tanpa tanda kutip yang dianggap sintaks valid
    Tidak ada bytecode atau JIT; interpreternya menelusuri pohon sintaks dan melakukan push/pop nilai ke stack, tetapi itu cukup cepat untuk pekerjaan kami. Interpreternya ditulis dalam ANSI C murni dan Valgrind pun sangat puas
    Bisa saja sudah sepenuhnya terlupakan, atau bisa juga menjadi inti infrastruktur teknis perusahaan itu. Kode tersebut tidak pernah keluar dari lab air-gapped tempat saya menulisnya, jadi tidak ada cara untuk tahu. Tiga tahun lalu, saat saya baru lulus kuliah, itu sejauh ini adalah “perangkat lunak yang benar-benar berguna” paling keren yang pernah saya tulis, dan sampai sekarang masih termasuk yang teratas. Kadang saya penasaran apa jadinya

    • Bagian yang terlewat oleh penulis adalah bahwa Box dan Uber sebenarnya sudah mengklaim kode itu sebagai milik mereka. Kemungkinan itu tertulis dalam kontrak kerja
      Penulis tampaknya keliru mengira bahwa ketika ia bertanya kepada manajer menengah, bahkan manajer senior, “Apakah Anda menginginkan ini?” dan manajer itu menjawab “Tidak”, maka jawaban itu mengikat perusahaan secara hukum
  • Kalimat ini terasa mengena: “Mudah untuk memperlakukan kode yang sangat cerdas atau elegan sebagai mahakarya. Memang bisa saja itu ornamen yang indah. Namun kita para engineer bukan berada dalam bisnis membuat ornamen indah, melainkan dalam bisnis menghasilkan hasil
    Namun siapa pun yang pernah melihat kode saya tahu bahwa saya juga ingin kode dan fungsinya terlihat sangat rapi. Biasanya saya menulis kode yang akan saya rawat sendiri, jadi setahun kemudian pun saya harus masih bisa memahaminya
    Saat ini saya berada di tahap akhir sebuah proyek yang tidak akan saya presentasikan di sini dan saya juga tidak berniat mengambil kredit besar darinya, tetapi benda ini benar-benar luar biasa. Alasannya bisa menjadi seperti itu adalah karena tidak ada yang membayar untuknya, dan tidak ada yang menghasilkan uang darinya
    Uang bisa merusak segalanya, sekaligus membuat segalanya menjadi mungkin

  • Ini tulisan yang benar-benar bagus dari sudut pandang mantan tim BI Uber. Saya berada di tim Vertica pada periode itu, dan jumlah upaya yang dicurahkan untuk insentif benar-benar membuat kepala pening. Hilangnya jutaan dolar per hari akibat downtime, fitur produk, dan bandwidth engineering adalah topik yang umum
    Khususnya pada masa Uber China, sangat masuk akal jika seorang direktur secara eksplisit meminta spreadsheet sebagai UI. Saya sendiri secara pribadi pernah memuat harga FX ke Vertica dari spreadsheet yang dikirim lewat email ke tim setiap bulan. Karena tidak ada bandwidth untuk membalik alur kontrol lewat pengambilan otomatis, proses itu bertahan lebih dari setahun

  • Pernyataan “Sampai sekarang pun saya belum pernah melihat sesuatu yang dirancang sebaik sistem aplikasi internal Uber. Dari awal hingga menjalankan Hello World dengan CI/CD penuh di subdomain *.uberinternal.com memakan waktu kurang dari 30 menit” membuat hati saya sedikit hangat
    Saat itu saya terlibat dalam semua ini di Uber