Selamat datang di postingan ketiga dari seri WorkManager kami. WorkManager adalah library Android Jetpack yang memudahkan penjadwalan tugas-tugas tidak bersamaan dan bisa ditunda yang harus berjalan dengan andal. Ini adalah praktik terbaik terkini untuk sebagian besar pekerjaan latar belakang di Android.
Jika Anda sudah mengikuti sejauh ini, kami sudah membahas tentang:

• Apa itu WorkManager dan kapan menggunakan WorkManager
• Cara menggunakan WorkManager API untuk menjadwalkan Pekerjaan

Dalam entri blog ini, saya akan membahas:

• Menggunakan WorkManager di Kotlin
• Class CoroutineWorker
• Cara menguji class CoroutineWorker Anda menggunakan TestListenableWorkerBuilder.

WorkManager di Kotlin

Cuplikan kode dalam entri blog ini ada di Kotlin, menggunakan library KTX (KoTlin eXtensions). WorkManager versi KTX menyediakan fungsi ekstensi untuk Kotlin yang lebih ringkas dan idiomatis. Anda bisa menggunakan WorkManager versi KTX untuk menambahkan dependensi pada artefak androidx.work:work-runtime-ktx ke file build.gradle Anda, seperti yang dijelaskan pada catatan rilis WorkManager. Artefak ini mencakup CoroutineWorker dan metode ekstensi lainnya yang berguna untuk WorkManager.

Lebih ringkas dan idiomatis

KTX WorkManager menyediakan sintaks yang lebih bagus ketika Anda perlu membangun objek Data untuk diberikan atau dikeluarkan dari class Worker. Dalam hal ini sintaks Java akan terlihat seperti:

Data myData = new Data.Builder()
                      .putInt(KEY_ONE_INT, aInt)
                      .putIntArray(KEY_ONE_INT_ARRAY, aIntArray)
                      .putString(KEY_ONE_STRING, aString)
                      .build();

Di Kotlin, kita bisa melakukannya jauh lebih baik dengan menggunakan fungsi pembantu workDataOf:

inline fun workDataOf(vararg pairs: Pair<String, Any?>): Data

Ini memungkinkan untuk menulis ekspresi Java sebelumnya sebagai:

val data = workDataOf(
        KEY_MY_INT to myIntVar,
        KEY_MY_INT_ARRAY to myIntArray,
        KEY_MY_STRING to myString
    )

CoroutineWorker

Selain class worker yang tersedia dalam Java (Worker, ListenableWorker dan RxWorker), terdapat juga class khusus Kotlin yang menggunakan Coroutines Kotlin untuk Pekerjaan Anda.
Perbedaan utama antara class Worker dan CoroutineWorker adalah bahwa metode doWork() dalam CoroutineWorker merupakan fungsi menangguhkan dan bisa menjalankan tugas yang tidak bersamaan, sedangkan doWork() Worker hanya dapat menjalankan tugas bersamaan. Fitur CoroutineWorker lainnya adalah ia secara otomatis menangani penghentian dan pembatalan selagi class Worker perlu mengimplementasikan metode onStopped() untuk melingkupi kasus-kasus ini.
Untuk konteks lengkap tentang berbagai opsi ini, Anda bisa merujuk ke panduan Threading dalam WorkManager.
Di sini saya ingin berfokus pada CoroutineWorker, yang mencakup beberapa perbedaan kecil tetapi penting, dan kemudian menyelami cara pengujian class CoroutineWorker Anda menggunakan fitur pengujian terbaru yang diperkenalkan di WorkManager v2.1.
Seperti yang kami tulis sebelumnya, CoroutineWorker#doWork() hanyalah fungsi menangguhkan. Ini, secara default, diluncurkan pada Dispatchers.Default:

class MyWork(context: Context, params: WorkerParameters) :
        CoroutineWorker(context, params) {

override suspend fun doWork(): Result {

return try {
            // Do something
            Result.success()
        } catch (error: Throwable) {
            Result.failure()
        }
    }
}

Penting untuk dipahami bahwa ini adalah perbedaan mendasar ketika menggunakan CoroutineWorker sebagai pengganti Worker atau ListenableWorker:

Tidak seperti Worker, kode ini tidak berjalan pada Executor yang ditetapkan dalam Konfigurasi WorkManager Anda.

Seperti yang baru saja kami katakan, CoroutineWorker#doWork() default-nya adalah Dispatchers.Default. Anda bisa menyesuaikannya menggunakan withContext():

class MyWork(context: Context, params: WorkerParameters) :
        CoroutineWorker(context, params) {

override suspend fun doWork(): Result = withContext(Dispatchers.IO) {

return try {
            // Do something
            Result.success()
        } catch (error: Throwable) {
            Result.failure()
        }
    }
}

Kebutuhan untuk mengubah Dispatcher yang digunakan CoroutineWorker adalah hal yang jarang terjadi dan Dispatchers.Default merupakan opsi terbaik untuk sebagian besar kasus.

Untuk mempelajari lebih lanjut tentang cara menggunakan WorkManager dengan Kotlin, Anda bisa mencoba codelab ini.

Menguji class Worker

WorkManager memiliki beberapa artefak tambahan yang bisa mempermudah pengujian Pekerjaan Anda. Anda bisa membaca lebih lanjut tentang hal ini dalam halaman dokumentasi pengujian WorkManager dan panduan “Pengujian dengan WorkManager 2.1.0” yang baru. Implementasi asli untuk pembantu pengujian ini memungkinkan penyesuaian WorkManager sehingga berfungsi secara bersamaan dan Anda kemudian bisa menggunakan WorkManagerTestInitHelper#getTestDriver() untuk dapat menyimulasikan penundaan dan menguji pekerjaan berkala.
Poin utama di sini adalah Anda memodifikasi perilaku atau WorkManager untuk mengarahkan class Worker agar ia bisa diuji.
WorkManager v2.1 menambahkan fungsionalitas TestListenableWorkerBuilder baru yang memperkenalkan cara baru untuk menguji class Worker Anda.
Ini adalah update yang sangat penting untuk CoroutineWorker karena dengan TestListenableWorkerBuilder Anda benar-benar langsung menjalankan class worker untuk menguji logikanya.

@RunWith(JUnit4::class)
class MyWorkTest {
    private lateinit var context: Context

    @Before
    fun setup() {
        context = ApplicationProvider.getApplicationContext()
    }

    @Test
    fun testMyWork() {
        // Get the ListenableWorker
        val worker = 
            TestListenableWorkerBuilder<MyWork>(context).build()

        // Run the worker synchronously
        val result = worker.startWork().get()

        assertThat(result, `is`(Result.success()))
    }
}

Hal penting di sini adalah bahwa hasil menjalankan CoroutineWorker diperoleh secara bersamaan dan Anda bisa memeriksa secara langsung apakah logika class Worker Anda sudah berperilaku dengan benar
Dengan menggunakan TestListenableWorkerBuilder, Anda bisa memberikan input data ke Worker atau mengatur runAttemptCount, sesuatu yang dapat berguna untuk menguji logika retry dalam pekerjaan Anda.
Sebagai contoh, jika Anda mengupload beberapa data ke server, Anda mungkin perlu menambahkan beberapa logika retry untuk memperhitungkan masalah konektivitas.

class MyWork(context: Context, params: WorkerParameters) :
        CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val serverUrl = inputData.getString("SERVER_URL")

        return try {
            // Do something with the URL
            Result.success()
        } catch (error: TitleRefreshError) {
            if (runAttemptCount <3) {
                Result.retry()
            } else {
                Result.failure()
            }
        }
    }
}

Anda kemudian bisa menguji logika retry ini dalam pengujian menggunakan TestListenableWorkerBuilder:

@Test
fun testMyWorkRetry() {
    val data = workDataOf("SERVER_URL" to "http://fake.url")

    // Get the ListenableWorker with a RunAttemptCount of 2
    val worker = TestListenableWorkerBuilder<MyWork>(context)   
                     .setInputData(data)
                     .setRunAttemptCount(2)
                     .build()

    // Start the work synchronously
    val result = worker.startWork().get()

    assertThat(result, `is`(Result.retry()))
}

@Test
fun testMyWorkFailure() {
    val data = workDataOf("SERVER_URL" to "http://fake.url")

    // Get the ListenableWorker with a RunAttemptCount of 3
    val worker = TestListenableWorkerBuilder<MyWork>(context)
                     .setInputData(data)
                     .setRunAttemptCount(3)
                     .build()

    // Start the work synchronously
    val result = worker.startWork().get()

    assertThat(result, `is`(Result.failure()))
}

Kesimpulan

Dengan rilis WorkManager v2.1 dan fitur-fitur baru dalam workmanager-testing, CoroutineWorker benar-benar menonjol karena kesederhanaan dan fungsionalitasnya. Pengujian bisa dilakukan dengan sangat mudah dan pengalaman keseluruhan di Kotlin sangatlah bagus.
Jika Anda belum mencoba CoroutineWorker dan ekstensi lainnya yang termasuk dalam workmanager-runtime-ktx, saya sangat menyarankan untuk mencobanya di project Anda. Ketika saya bekerja dengan Kotlin (yang saat ini selalu saya lakukan), ini adalah cara pilihan saya untuk menggunakan WorkManager!
Saya harap Anda bisa mendapatkan manfaat dari artikel ini dan saya ingin mendengar tentang bagaimana Anda menggunakan WorkManager atau fitur WorkManager apa yang dapat dijelaskan atau didokumentasikan dengan lebih baik.
Anda bisa menghubungi saya di Twitter @pfmaggi.

Sumber Daya

• Panduan Programmer
• Panduan Referensi
• Codelab: Background Work with WorkManager
• IssueTracker publik WorkManager
• Catatan Rilis
• Tag [android-workmanager] Stack Overflow
• Kode Sumber WorkManager (bagian dari AOSP)




Ditulis oleh Robby Neale, Software Engineer
TensorFlow menyediakan berbagai macam operasi yang sangat membantu dalam membangun model dari gambar dan video. Namun, ada banyak model yang dimulai dengan teks, dan model bahasa yang dibangun dari teks memerlukan beberapa prapemrosesan sebelum teks bisa dimasukkan ke dalam model. Misalnya, tutorial Klasifikasi Teks yang menggunakan set IMDB dimulai dengan data teks yang telah dikonversi menjadi ID integer. Prapemrosesan yang dilakukan di luar grafik ini dapat menyebabkan ketidaksimetrisan jika terjadi perbedaan pada waktu inferensi dan pelatihan, dan membutuhkan kerja ekstra untuk mengoordinasikan langkah prapemrosesan ini.

TF.Text adalah library TensorFlow 2.0 yang bisa dengan mudah diinstal menggunakan PIP dan dirancang untuk mengatasi masalah ini dengan menyediakan operasi untuk menangani prapemrosesan yang sering ditemukan dalam model berbasis teks, dan fitur lain yang berguna untuk pemodelan bahasa yang tidak disediakan oleh TensorFlow inti. Contoh yang paling umum dari operasi ini adalah tokenisasi teks. Tokenisasi adalah proses memecah string menjadi token. Biasanya, token ini adalah kata, angka, dan/atau tanda baca.
Setiap tokenizer yang disertakan menampilkan RaggedTensor dengan dimensi terdalam pemetaan token ke string individu asli. Akibatnya, peringkat bentuk yang dihasilkan meningkat satu. Ini diilustrasikan di bawah, tetapi mohon periksa juga panduan ragged tensor jika Anda belum familier dengan RaggedTensors.

Tokenizer

Kami awalnya menyediakan tiga tokenizer baru (seperti yang diusulkan dalam RFC baru-baru ini). Tokenizer baru yang paling dasar adalah tokenizer whitespace yang memisahkan string UTF-8 pada karakter whitespace ICU yang ditentukan (mis. spasi, tab, baris baru).

Rilis awal ini juga menyertakan tokenizer skrip unicode, yang membagi string UTF-8 berdasarkan batas skrip Unicode. Skrip Unicode adalah kumpulan karakter dan simbol yang secara historis terkait dengan derivasi bahasa. Lihat nilai-nilai UScriptCode International Components for Unicode (ICU) untuk daftar set lengkapnya. Perlu dicatat bahwa ini mirip dengan tokenizer whitespace dengan perbedaan yang paling kentara adalah bahwa ia memisahkan tanda baca USCRIPT_COMMON dari teks bahasa (mis. USCRIPT_LATIN, USCRIPT_CYRILLIC, dll).

Tokenizer akhir yang disediakan dalam peluncuran TF.Text adalah tokenizer wordpiece. Ini adalah tokenizer teks tanpa pengawasan yang membutuhkan kosakata yang telah ditentukan sebelumnya untuk membagi token menjadi subkata (prefiks & sufiks). Wordpiece biasanya digunakan dalam model BERT.

Masing-masing menghasilkan token pada string yang dikodekan dengan UTF-8 dan menyertakan opsi untuk memasukkan offset byte ke string asli. Ini memungkinkan pemanggil untuk mengetahui deretan byte dalam string asli untuk setiap token yang telah dibuat.

Kesimpulan

Ini hanyalah sedikit pembahasan mengenai TF.Text. Bersama dengan tokenizer, kami juga menyertakan operasi untuk normalisasi, n-gram, batasan rangkaian untuk pelabelan, dan banyak lagi! Kami mendorong Anda untuk mengunjungi repositori Github kami, dan mencoba menggunakan operasi ini dalam pengembangan model Anda sendiri. Penginstalan yang mudah dengan PIP:
pip install tensorflow-text
Dan untuk melihat contoh-contoh yang lebih mendalam, silakan lihat notebook Colab kami. Di sana terdapat berbagai cuplikan kode untuk banyak operasi yang baru tersedia yang tidak dibahas di sini. Kami berharap bisa melanjutkan upaya ini dan menyediakan lebih banyak fitur untuk membuat model bahasa Anda semakin mudah dibangun di TensorFlow.



Masuk ke dalam Machine Learning (ML) tanpa mengetahui apa yang ingin Anda capai adalah resep untuk sebuah bencana. Mari kita mulai secara baik dengan panduan pencegahan bencana langkah demi langkah ini.

Dalam empat tahun terakhir (di Google, dan sebelumnya di Comet Labs), saya memiliki kesempatan bekerja dengan ratusan startup dan perusahaan di seluruh dunia untuk membantu mereka menentukan strategi ML, mulai dari framing masalah sampai implementasi end-to-end model ML yang beroperasi dalam produksi. Kami bekerja sama dalam menerapkan model untuk meningkatkan efisiensi operasional (mis. peralatan internal, DevOps, dll.), menyingkirkan bottleneck (mis. memberikan “kekuatan magis” kepada tim layanan pelanggan), mengembangkan fitur produk yang didukung ML, dan membangun produk baru bersama-sama.
Dalam prosesnya, kami melakukan pendekatan penerapan ML dari berbagai sudut: implementasi teknologi, pengembangan produk, budaya dan struktur organisasi, manajemen sumber daya manusia, go-to-market, penetapan harga/monetisasi, UI/UX dll. Dalam setiap kasusnya, kami selalu mulai dengan berfokus pada framing masalah yang ingin kami selesaikan dengan model yang dipelajari mesin. Postingan ini berfokus secara khusus pada praktik terbaik untuk menentukan model ML Anda dengan mempertimbangkan kesuksesan, skala, dan kelayakan.
Setelah membaca postingan ini dan meninjau desain, Anda seharusnya sudah mengetahui jalur yang jelas ke depannya untuk memandu implementasi ML awal Anda.

Langkah 0: Lakukan Uji Respons Awal

Terlepas dari tahap perusahaan Anda, Anda harus terlebih dahulu melakukan tinjauan kritis terhadap praktik operasional saat ini, bottleneck, peluang pertumbuhan, dan potensi pengembangan fitur dan produk baru. Ada banyak cara untuk memanfaatkan ML sebagai bagian dari solusi. Ingatlah bahwa banyak kemungkinan blok pembangun bisnis Anda akan “berbicara satu sama lain” dan memengaruhi satu sama lain setelah Anda menerapkan infrastruktur data.

Jadikan bisnis Anda lebih efisien (dan lebih murah dioperasikan)

Tanyakan pada diri Anda pertanyaan-pertanyaan berikut: Proses apa saja yang menjadi kunci bisnis Anda? Bisakah salah satu di antaranya dioptimalkan (lebih lanjut)? Pindai melalui operasi, BD, pemasaran, pengembangan produk, dll. Berapa banyak waktu/uang yang Anda hemat dari mengoptimalkan satu alur kerja dibandingkan alur kerja lainnya? Menurut Anda, berapa lama waktu yang dibutuhkan untuk memasukkan alur kerja otomatis? Bagaimana Anda berencana melatih orang untuk menjaganya? Di bagian mana dalam proses tersebut, Anda membutuhkan peran manusia?
Perlu diingat bahwa proses ini mungkin tidak menyenangkan, tetapi juga akan memungkinkan Anda untuk semakin banyak membuat keputusan yang berbasis data dan mengerahkan orang di belakang data dan bukan keputusan proses yang acak. Memilih satu alur kerja untuk dioptimalkan dengan ML, bersama dengan membangun infrastruktur data yang kuat, akan memungkinkan Anda untuk secara bertahap mengoptimalkan lebih banyak proses dan bahkan mungkin mengarah pada pengembangan fitur produk.
Salah satu startup yang baru-baru ini bekerja sama dengan kami menyadari bahwa salah satu program pelatihan karyawan mereka menelan biaya $15 juta/tahun. Mereka berusaha mencari cara mengotomatiskan bagian penilaian proses pelatihan untuk meluangkan lebih banyak waktu penilai manusia agar bisa menggandakan pelatihan untuk karyawan yang berprospek. Implementasi proses berbasis ML ini memungkinkan mereka untuk menurunkan biaya ~30% setelah implementasi pertama, serta memulai pelatihan model NLP yang telah mereka integrasikan ke dalam produk mereka untuk memberikan layanan yang lebih baik kepada pelanggan.

Berikan tim dan pengguna Anda kekuatan super

Tanyakan pada diri Anda pertanyaan-pertanyaan berikut: Adakah fitur internal yang bisa Anda kembangkan untuk membuat karyawan, pengguna, dan/atau individu lain dalam rantai nilai Anda lebih efisien? Bisakah Anda menstandarkan waktu luang karyawan mis. dengan membangun fitur kolaborasi, atau template dan proses terstandardisasi untuk menstandarkan pengiriman layanan? Bisakah Anda memanfaatkan keahlian karyawan atau pemangku kepentingan lain dalam “pemberian label” set data, yang pada akhirnya akan menghasilkan penawaran produk yang lebih baik.
Misalnya, startup lain yang bekerja sama dengan kami mengembangkan fitur “panduan” untuk produk mereka yang menghasilkan peta panas di sekitar anomali dalam gambar medis yang harus diperhatikan dokter. Hal ini memungkinkan dokter untuk mempercepat 50% waktu pemindaian gambar untuk anomali tingkat tinggi dan berfokus pada bagian gambar yang relevan secara statistik. Para dokter kemudian akan menambahkan label dan catatan pada gambar-gambar ini, yang kemudian dimasukkan sebagai fitur ke dalam model. Model yang dihasilkan semakin lama semakin akurat.
Perhatikan bahwa mereka tidak memulai dengan mengatakan “model ML harus memiliki akurasi 99%,” Anda memulainya dengan mengatakan “produk secara keseluruhan harus memiliki akurasi 98%, dan untuk mencapainya, kita bisa menggunakan model ML yang memiliki akurasi 99% pada 90% input, tetapi tidak membuat keputusan pada 10% sisanya, dan meneruskannya ke panel yang terdiri dari 3 ahli radiologi.”

Hadirkan fitur atau produk yang didukung ML ke pasar

Tanyakan pada diri Anda pertanyaan-pertanyaan berikut: Set data apa yang Anda kumpulkan melalui produk/layanan saat ini? Data tentang perilaku pengguna, layanan pelanggan, dll.? Bagaimana Anda bisa memanfaatkan data ini untuk mengembangkan penawaran yang lebih baik atau lebih disesuaikan? Bisakah Anda benar-benar membangun produk yang sepenuhnya baru berdasarkan data ini? Bagaimana jika Anda mempertimbangkan kasus penggunaan/industri dari prinsip pertama, bisakah Anda mengembangkan produk yang sepenuhnya baru berdasarkan campuran dari sumber data baru dan yang sudah ada?
Sebagai contoh, satu tim yang bekerja sama dengan kami memikirkan kembali dengan serius cara memfasilitasi neuroplastisitas (yaitu kemampuan otak untuk mengatur kembali dirinya sendiri dengan membentuk koneksi saraf baru) dengan mengumpulkan seluruh set data baru melalui perangkat penangkap EEG, dan membandingkan hasil EEG yang berbeda untuk menghasilkan “pengobatan” EEG berbasis data. Orang mulai menggerakkan anggota tubuhnya lagi — gila! Satu catatan di sini adalah agar Anda sangat berhati-hati mengenai cara menghasilkan set data baru dan mengukur nilai relatif dari set data yang ada yang Anda tarik ke dalam model — kami nanti akan secara singkat membahas bias dan kelayakan dalam postingan ini.
Dalam semua kasus, kita perlu membedakan antara masalah dan solusi, serta antara tujuan tingkat-produk dan tujuan tingkat-model. “Machine Learning” selalu menjadi bagian dari solusi. Langkah pertama adalah “Kami ingin mengidentifikasi X secara reliabel.” Langkah kedua adalah “Kami memutuskan untuk memiliki model machine learning sebagai bagian dari prosesnya.” Kemudian muncul hasil, metrik kesuksesan, dan tujuan produk secara keseluruhan, dan itu harus selalu dimasukkan ke model ML.

Langkah 1: Jelaskan masalah Anda dalam Bahasa Inggris yang jelas

Tulis apa yang Anda inginkan untuk dikerjakan model machine learning. Tulis sejelas-jelasnya: “Kami ingin model machine learning untuk ____”. Contohnya, “Kami ingin model machine learning untuk memprediksi seberapa populer video tertentu yang baru saja diupload di masa mendatang.” Pada titik ini, pernyataan tersebut bisa bersifat kualitatif, tetapi pastikan ini menangkap tujuan Anda yang sebenarnya, bukan tujuan yang tidak langsung.

Langkah 2: Identifikasi hasil ideal menurut Anda

Model ML Anda ditujukan untuk menghasilkan beberapa hasil yang diinginkan. Apa hasilnya, tidak bergantung pada model itu sendiri? Perhatikan bahwa hasilnya mungkin sangat berbeda dari cara Anda menilai model dan kualitasnya (kami akan membahas metrik di bagian berikutnya). Tuliskan: “Hasil ideal kami adalah:____”. Mengikuti contoh yang dimulai di atas, hasil ideal Anda mungkin hanya melakukan transcode video populer untuk meminimalkan penggunaan sumber daya penayangan, dan untuk merekomendasikan video yang menurut orang bermanfaat, menghibur, dan mereka sukai.
Pada tahap ini, Anda tidak perlu membatasi diri pada metrik yang sudah dioptimalkan produk Anda (itu akan dibahas pada langkah berikutnya). Sebaliknya, cobalah untuk fokus pada tujuan yang lebih besar dari produk atau layanan Anda.

Langkah 3: Tentukan metrik kesuksesan Anda

Tulis metrik kesuksesan dan kegagalan dengan sistem ML. Metrik kegagalan itu penting (mis., Bagaimana Anda tahu kalau sistem ML gagal?). Ingatlah bahwa metrik kesuksesan dan kegagalan harus diungkapkan secara terpisah dari metrik evaluasi untuk model (mis., Jangan berbicara tentang ketepatan, mengingat, atau AUC; sebaliknya, bicarakan tentang hasil yang diharapkan). Sering kali metrik ini akan dikaitkan dengan hasil ideal yang Anda tetapkan di atas. Tulis tanggapan untuk pernyataan ini: “Metrik kesuksesan kami adalah: ____”, “Hasil kunci (KR) kami untuk metrik kesuksesan adalah: ____”, dan “Model ML kami dianggap gagal jika: ____”.
Misalnya, metrik kesuksesan Anda bisa berupa penggunaan sumber daya CPU. Dalam kasus tersebut, KR Anda untuk metrik kesuksesan adalah meraih 35% penghematan biaya CPU untuk transcoding, dan model ML Anda akan dianggap gagal jika pengurangan biaya sumber daya CPU kurang dari biaya CPU untuk pelatihan dan penayangan model. Metrik kesuksesan lain mungkin adalah jumlah video populer yang diprediksi dengan tepat. Di sini, KR Anda untuk metrik kesuksesan adalah memprediksi dengan tepat 95% teratas 28 hari setelah diupload. Model ML Anda akan dianggap gagal jika jumlah video populer yang diprediksi dengan tepat tidak lebih baik daripada heuristik saat ini.
Berhenti di sini! Tanyakan pada diri Anda: “Apakah metrik ini bisa diukur?” “Bagaimana saya mengukurnya?” Tidak apa-apa jika ini dilakukan melalui eksperimen langsung. Banyak metrik kesuksesan tidak bisa ditangkap secara offline. Saat memutuskan metrik Anda, pikirkan hasil ideal yang Anda tentukan di langkah sebelumnya. Kapan Anda bisa mengukurnya? Berapa lama bagi Anda untuk mengetahui apakah sistem ML baru Anda sukses atau gagal?
Jangan membatasi diri Anda pada kesuksesan atau kegagalan biner. Ada jangkauan yang lebih luas: bencana / lebih buruk dari sebelumnya / hampir sama dengan sebelumnya / peningkatan, tetapi tidak sebagus yang diharapkan / semuanya luar biasa. Perlu diingat juga bahwa jika ada beberapa metrik, sebuah sistem bisa berada di tingkat yang sama pada suatu metrik dan tingkat yang berbeda pada metrik yang lain.
Pastikan juga untuk mempertimbangkan biaya pemeliharaan dan engineering dalam jangka panjang. Kegagalan bisa terjadi meskipun metrik berhasil. Sebagai contoh; sebuah model mungkin bisa memprediksi kalau mereka mengklik video yang direkomendasikan dengan sangat baik, tetapi ia mungkin selalu merekomendasikan video “click bait”.
Catatan tentang Tinjauan Desain: Anda perhatikan bahwa panduan ini diselingi dengan “tinjauan desain” untuk memvalidasi pendekatan sebelum Anda melanjutkan ke bagian berikutnya. Kami sangat merekomendasikan kerja sama dengan tim produk atau engineering lain (di perusahaan Anda atau eksternal) yang juga tengah menerapkan ML. Penerapan ML dengan sendirinya tidak akan pernah menjadi resep kesuksesan Anda (ini semua tentang data!), dan Anda pasti akan mendapat banyak manfaat dari berbagi praktik terbaik dengan praktisi lain yang juga berada “di ladang yang sama”. Jika Anda memiliki akses ke tim engineering pelanggan Cloud melalui penyedia Cloud, atau dukungan engineering melalui program lain, kami mendesak Anda untuk mendapatkan masukan tentang jawaban Anda melalui panduan langkah demi langkah ini.

** Tinjauan Desain: Tujuan Sistem ML **

Seperti yang dijelaskan di atas, saya sekarang mengundang Anda untuk berpasangan dengan kolega atau tim, dan meninjau respons satu sama lain terhadap langkah-langkah di atas (1–3) sambil menanyakan diri Anda pertanyaan berikut:
Kejelasan Deskripsi Masalah: Apakah Anda memahami tujuan model?
Kegagalan dan Kesuksesan: Sebagai orang luar, apakah Anda bisa menilai kesuksesan atau kegagalan sistem ML berdasarkan metrik dan tujuan yang ditetapkan? Sertakan contoh di mana Anda menilai kegagalan sistem.

Langkah 4: Tentukan output ideal Anda

Tulis output yang Anda ingin dihasilkan model ML. Sekali lagi, tulis (dalam bahasa Inggris): “Output dari model ML kami adalah: ____”, dan “Ini ditetapkan sebagai: ____”. Misalnya, output dari model ML Anda menjadi salah satu dari 3 kelas video {sangat populer, agak populer, tidak populer}. Ini akan ditetapkan sebagai {3, 7, 90}-persentil teratas dari waktu tonton 28 hari setelah diupload.
Ingatlah bahwa output harus bisa diukur dengan definisi yang dapat dihasilkan mesin. Misalnya, “pengguna menikmati membaca artikel” akan menghasilkan hasil yang jauh lebih buruk daripada “pengguna akan berbagi artikel”. Tanyakan pada diri Anda apakah Anda bisa mendapatkan contoh output untuk digunakan bagi data pelatihan. Bagaimana dan dari sumber apa Anda akan mendapatkannya? Contoh output Anda mungkin perlu direkayasa, seperti dalam contoh di atas, yang akan mengubah waktu menonton video menjadi persentil.
Pada tahap ini, jika sulit untuk mendapatkan contoh output yang akan digunakan untuk pelatihan, Anda mungkin perlu meninjau kembali respons terhadap langkah-langkah sebelumnya untuk merumuskan kembali masalah dan tujuan menjadi sesuatu yang akan memungkinkan Anda untuk melatih model pada data.

Langkah 5: Gunakan output

Pikirkan kapan output harus diperoleh dari model ML, dan bagaimana ia digunakan dalam produk Anda. Tuliskan: “Output dari model ML akan dibuat: ____”, dan “Hasilnya akan digunakan untuk: ____”.
Misalnya, prediksi popularitas video akan dibuat segera setelah video baru diupload. Hasilnya akan digunakan untuk menentukan algoritme transcoding untuk video.
Pertimbangkan bagaimana Anda akan menggunakan hasil yang diprediksi dalam produk Anda. Apakah akan langsung ditampilkan kepada pengguna di UI? Apakah akan dipakai oleh logika bisnis yang selanjutnya? Persyaratan latensi apa yang Anda miliki?
Persyaratan tersebut (yang juga merupakan persyaratan model ML) bisa memengaruhi informasi yang bisa digunakan untuk membuat prediksi. Misalnya, latensi penggunaan data dari layanan jarak jauh mungkin membuatnya tidak layak digunakan. Jika sumber data ketinggalan dalam menyediakan informasi baru, maka log yang diproses dapat dihasilkan hanya sekali sehari, dan/atau informasi tertentu tidak diketahui sampai ia benar-benar terjadi (seperti event konversi).

Langkah 6: Identifikasi heuristik Anda

Sebelum kita melangkah lebih jauh, mari kita berhenti sejenak dan berpikir tentang bagaimana Anda akan menyelesaikan masalah jika Anda tidak menggunakan ML (mis., heuristik apa yang mungkin Anda gunakan). Tuliskan: “Jika tidak menggunakan ML, kami akan: ____”. Misalnya Jika Anda tidak menggunakan ML, Anda akan menganggap video baru yang diupload oleh kreator yang pernah mengupload video populer di masa lalu akan menjadi populer kembali. Di sini, pikirkan tentang skenario ketika Anda harus mengirimkan produk besok, dan Anda hanya bisa membuat hardcode logika bisnis. Apa yang akan Anda lakukan? Tuliskan.

** Tinjauan Desain: Output **

Bergabunglah dengan tim, dan tinjau respons masing-masing anggota terhadap langkah-langkah di atas (4–6) sesuai dengan kriteria berikut:
Output Model: Akankah model ML menghasilkan output yang bermanfaat dan berguna?
Heuristik: Adakah set heuristik yang masuk akal yang bisa digunakan untuk menguji konsep awal tanpa menggunakan ML? Bagaimana ia bisa ditingkatkan? Heuristik tambahan apa yang bisa Anda usulkan?

Langkah 7: Rumuskan masalah Anda sebagai masalah ML

Sebelum kita mulai mencari tahu apa tipe ML yang harus Anda terapkan untuk menyelesaikan masalah, berikut adalah rekap cepat dari empat cara utama yang bisa diterapkan oleh ML secara efektif hari ini: 1) Klasifikasi (manakah label n?), 2) regresi (prediksi nilai numerik), 3) klustering (yang paling mirip contoh lainnya), 4) generasi (output kompleks). Rujuk ke materi MLCC jika Anda tidak jelas tentang kelas model yang berbeda.
Sekarang tulis apa yang menurut Anda merupakan solusi teknis terbaik untuk masalah Anda. Misalnya, masalah Anda dapat dibingkai sebagai klasifikasi label-tunggal 3 kelas, yang memprediksi apakah video akan berada di salah satu dari tiga kelas, {sangat populer, agak populer, tidak populer}, 28 hari setelah diupload.

Langkah 8: Tetapkan masalah Anda sebagai masalah “sederhana”

Ketika pertama kali memulai, rumusan masalah yang lebih sederhana, lebih mudah untuk dipertimbangkan dan diimplementasikan. Saya sarankan untuk mengambil masalah Anda dan menyatakannya sebagai klasifikasi biner atau masalah regresi unidimensional (atau keduanya). Sebagai contoh: “Kami akan memprediksi apakah video yang diupload kemungkinan besar akan menjadi sangat populer (klasifikasi biner)”, atau “Kami akan memprediksi seberapa populer video yang diupload berdasarkan jumlah penayangan yang akan diterimanya dalam jendela 28 hari (regresi).”

** Tinjauan Desain: Pemodelan **

Bergabunglah dengan tim, dan tinjau respons masing-masing anggota terhadap langkah-langkah di atas (7–8) sesuai dengan kriteria berikut:
Pendekatan Keseluruhan: Apakah model yang diajukan terlihat akan menyelesaikan masalah yang disebutkan? Mengapa atau mengapa tidak?
Desain Pertama: Apakah model yang disederhanakan sudah cukup disederhanakan dan dikurangi? Jelaskan bagaimana desain dapat lebih disederhanakan.

Langkah 9: Desain data Anda untuk model

Tulis data yang Anda inginkan agar dibuat prediksi oleh model ML, dalam tabel berikut:

Satu baris merupakan satu bagian data yang membuat satu prediksi. Anda hanya boleh memasukkan informasi yang tersedia saat prediksi dibuat.
Sebagai contoh:

Langkah 10: Cari tahu dari mana data Anda berasal

Mari kita tulis dari mana masing-masing input berasal, dan mari kita nilai seberapa banyak upaya guna mengembangkan pipeline data untuk membangun setiap kolom untuk satu baris. Periksa sumber daya untuk membantu Anda mempertimbangkan data apa yang akan dimasukkan ke dalam model Anda, dan bagaimana menyiapkan tim anotasi data setelah Anda mengumpulkan data.
Pikirkan kapan contoh output tersedia untuk tujuan pelatihan. Jika contoh output sulit diperoleh, Anda mungkin ingin mengunjungi kembali Langkah 5 (Output Anda), dan memeriksa apakah Anda bisa menggunakan output yang berbeda untuk model.
Pastikan semua input tersedia pada waktu penayangan (ketika prediksi dibuat), tepat dalam format yang Anda tulis. Jika sulit mendapatkan semua input pada waktu penayangan dalam format yang persis sama, Anda mungkin perlu mengunjungi kembali Langkah 9 (Desain data Anda untuk model) untuk mempertimbangkan kembali input, atau Langkah 5 (Menayangkan output) untuk mempertimbangkan kembali ketika penayangan dapat dilakukan.

Contoh

Langkah 11: Fokus pada input yang mudah didapat

Di antara input yang Anda daftarkan pada Langkah 9, pilih 1–3 input yang mudah didapat, dan yang Anda yakini akan menghasilkan hasil awal yang masuk akal.

Pada Langkah 6, Anda mendaftar satu set heuristik yang bisa Anda gunakan. Input mana saja yang akan berguna untuk mengimplementasikan heuristik ini? Pertimbangkan biaya engineering untuk mengembangkan pipeline data untuk menyiapkan input, dan manfaat yang diharapkan dari setiap input dalam model. Fokus pada input yang bisa diperoleh dari satu sistem dengan pipeline sederhana. Disarankan untuk memulai dengan infrastruktur minimum saat pertama kali memulai.

** Tinjauan Desain: Data **

Bergabunglah dengan tim, dan tinjau respons masing-masing anggota terhadap langkah-langkah di atas (9–11) sesuai dengan kriteria berikut.
Input yang Mudah: Apakah set “fitur input mudah” cukup disederhanakan dan mudah diperoleh? Bisakah input ini disederhanakan lebih jauh lagi?
Label: Apakah Anda dapat memperoleh contoh output (label) untuk tujuan pelatihan?
Bias: Set data apa pun akan bias dalam beberapa cara. Bias ini dapat memengaruhi pelatihan dan prediksi yang dibuat. Misalnya, penyematan kata yang dilatih dari sumber data tertentu mungkin memiliki bias yang tidak cocok digunakan dalam konteks lainnya. Atau set pelatihan mungkin tidak mewakili pengguna akhir model. Sebutkan beberapa sumber bias potensial dalam set data yang akan digunakan (dan cari sumber daya luar biasa yang seharusnya dieksternalisasi oleh tim Google ML Fairness untuk I/O pada Mei 2019).
Kompleksitas dan Risiko Implementasi: Sebutkan aspek-aspek desain yang mungkin sulit diterapkan, berisiko, atau terlalu rumit atau tidak diperlukan.
Kemampuan untuk Belajar: Apakah model ML dapat belajar? Buat daftar skenario di mana sistem mungkin mengalami kesulitan belajar. Misalnya, tidak mencukupinya contoh positif, data pelatihan mungkin terlalu kecil, label terlalu gaduh, sistem mungkin mengalami kesulitan generalisasi kasus baru, dll.

Langkah 12: Tetapkan sistem ML end-to-end Anda sendiri

Tinjau tips di https://www.tensorflow.org/programmers_guide/

Langkah 13: Langkah Berikutnya

Setelah mengisi worksheet ini dan mendapatkan masukan desain, implementasi pertama Anda harus didasarkan pada model yang disederhanakan (baik klasifikasi biner maupun regresi) menggunakan beberapa (1–3) input yang mudah didapatkan. Setelah pengaturan dasar ini berfungsi, Anda bisa mengulangi desain ini untuk semakin mendekatkannya ke tujuan final. Saat Anda siap untuk “melakukannya sendiri,” periksa sumber ini. Semoga berhasil! Beri tahu kami bagaimana kelanjutannya.
Malika Cantor adalah Global Lead di Google Developers Launchpad dan editor blog The Launchpad. Dia sebelumnya adalah mitra pendiri di Comet Labs, sebuah lab riset eksperimental dan firma VC yang berfokus untuk mendukung startup Machine Learning terapan tahap awal. Silakan beri pertanyaan/komentar di bagian komentar dan/atau tweet!
Semua bekerja sama: Kudo untuk Ola Ben Har, Przemek Victor Pardel, Oleksandr Zakharchuk, Paweł Nowak, dll. yang menyelenggarakan event Machine Learning Kickstarter di Warsawa dan membuat worksheet Framing Masalah ML (yang banyak dibahas dalam postingan ini). Terima kasih kepada tim Google EngEdu karena secara resmi mengeksternalisasi masalah framing konten akhir tahun lalu. TERIMA KASIH kepada Thomas J. White IV dan Brett Kamita untuk editing dan proofreading yang berkelas, Jeremy Neuner untuk gambar dan leluconnya, Joshua Yellin, Nishu Lahoti dan Richard Hyndman untuk penyempurnaannya, Maya Grossman dan Jennifer Harvey untuk pemasaran, Peter Norvig dan Cassie Kozyrkov karena sudah menjadi mitra saya dalam kejahatan. Roy Geva Glasberg karena sudah membiarkan kami meluncurkan hal ini :)


Ditulis oleh Sam Lin, Product Manager, Android


Dengan Project Marble, tim Android Studio berfokus pada upaya untuk membuat fitur-fitur dasar dan alur Integrated Development Environment (IDE) yang solid. Kinerja adalah tenant yang mendasari dalam memberikan IDE berkualitas tinggi. Untuk tujuan ini, kami mempertajam fokus produk dan hanya akan mendukung sistem operasi 64-bit ke depan. Menggunakan Android Studio dengan sistem operasi 64-bit memungkinkan akses yang efisien ke memori, baik untuk IDE maupun Android Emulator, dan secara keseluruhan mengarah pada pengalaman pengembangan yang lebih baik. Meskipun tidak akan memengaruhi sebagian besar pengguna Android Studio, perubahan ini memang berdampak jika Anda menggunakan versi 32-bit Microsoft^® Windows^®. Untuk membantu transisi bagi developer yang menggunakan Microsoft Windows versi 32-bit, kami ingin memberi Anda detail tentang timeline depresiasi mendatang ditambah langkah-langkah yang harus dilakukan untuk bersiap-siap menghadapi perubahan ini.

Timeline

Untuk meminimalkan dampak perubahan ini terhadap sistem operasi 64-bit yang didukung secara eksklusif, kami pertama-tama akan menghentikan dukungan untuk versi 32-bit. Selama fase depresiasi, baik Android Studio maupun Android Emulator akan terus bekerja, tetapi produk-produknya tidak akan menerima update fitur baru. Selama masa transisi ini, Anda masih bisa mendownload produk dari situs web Android Studio. Setelah satu tahun, kami akan secara resmi mengakhiri dukungan produk dan akan menghapus link download versi 32-bit. Catatan, jika Anda sebelumnya sudah menginstal Android Studio versi 32-bit selama periode ini maka produk tersebut akan terus berfungsi, tetapi kami tidak akan menyediakan link untuk mendownload ulang produk tersebut. Tanggal untuk periode akhir dukungan dan depresiasi bisa dilihat dalam tabel di bawah ini:

Versi Produk 32-bit yang Didukung	Depresiasi dari	Akhir Dukungan pada
Android Studio IDE 3.6	31 Desember 2019	31 Desember 2020
Android Emulator 28.0.25	30 Juni 2019	31 Desember 2020

Keuntungan lingkungan pengembangan 64-bit

Ada beberapa keuntungan ketika kita menggunakan Android Studio versi 64-bit, yang meliputi:

• Kinerja - IDE bisa bekerja lebih baik karena dapat mengakses memori lebih dari 4GB. Peningkatan memori khususnya memberikan pengalaman yang lebih baik ketika Anda mengerjakan project besar.
• Dukungan Aplikasi 64-bit - Anda bisa membangun versi aplikasi 32-bit dan 64-bit bila aplikasi Anda menggunakan kode native C/C++. Pengujian pada kedua arsitektur bisa membantu Anda bersiap-siap untuk persyaratan 64-bit di Google Play yang dimulai pada 1 Agustus 2019.
• Pengujian pada Emulator - Citra sistem Android Emulator 32-bit maupun 64-bit didukung oleh Android Emulator versi 64-bit. Fleksibilitas ini mempermudah pengujian aplikasi Anda di berbagai lingkungan Android dengan satu mesin pengembangan.

Langkah berikutnya

Ringkasan, sebelum mengakhiri dukungan untuk Android Studio versi 32-bit, kami ingin memberi tahu Anda terlebih dahulu, menyediakan panduan, dan memberikan waktu tunggu satu tahun untuk membantu Anda bermigrasi ke sistem operasi 64-bit. Anda masih bisa menggunakan Android Studio versi 32-bit, tetapi perlu diingat bahwa versi ini tidak akan menerima update di masa mendatang. Oleh karena itu, jika Anda ingin bermigrasi, kami sarankan Anda memulai perencanaan lebih awal sehingga Anda bisa terus mendapatkan update produk terbaru dan memanfaatkan secara maksimal peningkatan kinerja lingkungan pengembangan 64-bit.



Pekan ini, kami kembali ke Google I/O tahun ke-4 berturut-turut untuk berbagi informasi bagaimana kami membuat Firebase lebih baik untuk semua developer aplikasi, dari startup terkecil satu orang hingga bisnis perusahaan terbesar. Tidak peduli berapa kali kami naik stage, misi kami tetap sama: untuk membantu developer seluler dan web agar sukses dengan mempermudah proses membangun, menyempurnakan, dan mengembangkan aplikasi Anda. Sejak meluncurkan Firebase sebagai platform pengembangan seluler Google di I/O 2016, kami selalu kagum dengan apa yang Anda bangun dengan fitur kami. Suatu kebanggaan bagi kami karena bisa membantu perjalanan Anda mengubah dunia!
Misalnya, di Uganda, sebuah start-up baru yang bernama Teheca menggunakan Firebase untuk mengurangi tingkat kematian bayi dan ibu dengan menghubungkan orang tua dengan perawat untuk perawatan pasca-kelahiran. Di India, tempat di mana smartphone dengan cepat menggantikan TV sebagai sumber hiburan utama, Hotstar, aplikasi streaming video terbesar di India, menggunakan Firebase dengan BigQuery untuk mengubah pengalaman menonton dengan membuatnya lebih sosial dan interaktif. Begini cara mereka melakukannya, dengan kata-kata mereka:

Kisah-kisah seperti ini menginspirasi kami untuk terus membuat Firebase lebih baik. Bahkan, kami telah merilis lebih dari 100 fitur dan peningkatan baru selama 6 bulan terakhir! Baca terus untuk mengetahui tentang pengumuman terbesar kami di Google I/O 2019.

Menyederhanakan machine learning untuk semua developer aplikasi

Terjemahan baru, deteksi objek dan pelacakan, dan kemampuan AutoML dalam ML Kit
Tahun lalu, kami meluncurkan ML Kit, yang menghadirkan kepiawaian machine learning Google kepada developer seluler dalam paket yang kuat, tetapi mudah digunakan. ML Kit hadir dengan seperangkat API berbasis perangkat dan cloud yang siap digunakan dengan dukungan untuk model khusus, sehingga Anda bisa menerapkan kekuatan machine learning pada aplikasi Anda, terlepas dari pengetahuan Anda mengenai ML. Selama beberapa bulan terakhir, kami telah mengembangkannya dengan menambahkan solusi untuk Natural Language Processing, seperti Language Identification dan Smart Reply API. Sekarang, kami meluncurkan tiga kemampuan lagi dalam versi beta: On-device Translation API, Object Detection & Tracking API, dan AutoML Vision Edge.
On-device Translation API memungkinkan Anda menggunakan model offline yang sama seperti yang mendukung Google Terjemahan untuk menyediakan terjemahan teks yang cepat dan dinamis di aplikasi Anda ke dalam 58 bahasa. Object Detection & Tracking API memungkinkan aplikasi Anda secara real-time menemukan dan melacak objek paling menonjol dalam rekaman kamera langsung. Dengan AutoML Vision Edge, Anda bisa dengan mudah membuat model klasifikasi gambar khusus yang disesuaikan dengan kebutuhan Anda. Misalnya, Anda mungkin menginginkan aplikasi Anda agar dapat mengidentifikasi berbagai jenis makanan, atau membedakan spesies hewan. Apa pun kebutuhan Anda, cukup upload data pelatihan ke Firebase console dan Anda bisa menggunakan teknologi AutoML Google untuk membangun model TensorFlow Lite khusus agar ia dapat berjalan secara lokal di perangkat pengguna. Dan jika Anda merasa bahwa mengumpulkan set data pelatihan bukanlah hal yang mudah, Anda bisa menggunakan aplikasi open source kami yang membuat prosesnya lebih sederhana dan kolaboratif.
Pelanggan seperti IKEA, Fishbrain, dan Lose It! sudah menggunakan kemampuan ML Kit untuk meningkatkan pengalaman aplikasi mereka. Inilah kata mereka:

"Kami bekerja dengan Google Cloud untuk menciptakan pengalaman seluler baru yang memungkinkan pelanggan, di mana pun mereka berada, mengambil foto perabotan serta barang-barang rumah tangga dan dengan cepat menemukan produk itu atau yang serupa dalam katalog online kami. Cloud Vision Product Search API memberikan IKEA cara yang cepat dan mudah untuk mengindeks katalog kami, sementara Object Detection and Tracking API ML Kit memungkinkan kami mengimplementasikan fitur dengan mulus pada jendela bidik langsung di aplikasi kami. Google Cloud membantu kami memanfaatkan Vision Product Search dan kami sangat senang mengeksplorasi bagaimana hal ini bisa membantu kami menciptakan pengalaman yang lebih baik dan lebih nyaman bagi pelanggan kami.” - Susan Standiford, Chief Technology Officer of Ingka Group, mitra strategis dalam sistem waralaba IKEA dan operator IKEA di 30 market.

“Pengguna kami sangat tertarik dengan memancing, jadi menangkap dan memiliki akses ke gambar tangkapan dan informasi spesies merupakan hal yang sangat penting bagi pengalaman mereka. Melalui AutoML Vision Edge, kami berhasil meningkatkan jumlah tangkapan yang tercatat dengan informasi spesies sebesar 30%, dan meningkatkan akurasi model pengenalan spesies dari 78% menjadi 88%.”
- Dimitris Lachanas, Android Engineering Manager di Fishbrain

“Melalui AutoML Vision Edge, kami dapat membuat model di perangkat yang sangat prediktif dari awal. Dengan peningkatan pada algoritme pengenalan makanan yang canggih, Snap It, kami berhasil meningkatkan jumlah kategori makanan yang bisa digolongkan oleh pelanggan kami dalam gambar sebesar 21% sekaligus mengurangi tingkat error sebesar 36%, jumlah yang sangat besar untuk pelanggan kami.” - Will Lowe Ph.D., Director of Data Science & AI, Lose It!

Memberikan analisis yang lebih mendalam tentang kecepatan & kinerja aplikasi web

Performance Monitoring sekarang mendukung aplikasi web
Developer seluler native senang menggunakan Firebase Performance Monitoring untuk mengetahui bagian aplikasi yang berjalan lebih lambat dari harapan mereka, dan untuk pengguna aplikasi apa. Hari ini, dengan gembira kami umumkan bahwa Performance Monitoring juga tersedia untuk aplikasi web, dalam versi beta, sehingga developer web bisa memahami bagaimana pengguna sesungguhnya memanfaatkan aplikasi di luar sana.
Dengan menyematkan beberapa baris kode ke situs mereka, dasbor Performance Monitoring akan melacak dan memvisualisasikan metrik web tingkat tinggi (seperti pemuatan halaman dan statistik jaringan) serta metrik yang lebih terperinci (seperti waktu pertama menggambar dan delay input pertama) di seluruh segmen pengguna. Dasbor Performance Monitoring juga akan memberi Anda kemampuan untuk menelusuri segmen pengguna yang berbeda menurut negara, browser, dan lainnya. Sekarang, Anda bisa mendapatkan analisis mendalam tentang kecepatan serta kinerja aplikasi web dan memperbaiki masalah dengan cepat untuk memastikan pengguna akhir Anda memiliki pengalaman hebat secara konsisten. Dengan menambahkan dukungan web ke salah satu fitur paling populer, kami menegaskan kembali komitmen untuk membuat pengembangan aplikasi lebih mudah bagi developer seluler dan web.

Meningkatkan kemampuan segmentasi pengguna untuk personalisasi & analisis yang lebih baik

Pembuat audience baru di Google Analytics for Firebase
Google Analytics for Firebase menyediakan analytics gratis, tidak terbatas, dan tangguh sehingga Anda bisa mengukur hal-hal yang penting dalam aplikasi dan memahami pengguna Anda. Beberapa pekan lalu, kami mengumumkan pemfilteran lanjutan di Google Analytics for Firebase, yang memungkinkan Anda memfilter laporan event Analytics dengan sejumlah properti pengguna atau audience yang berbeda secara bersamaan.
Hari ini, kami gembira bisa menginformasikan bahwa kami telah membangun kembali sistem audience kami sepenuhnya dari awal dengan antarmuka baru. Pembuat audience baru ini mencakup fitur-fitur baru seperti urutan, pelingkupan, jendela waktu, durasi keanggotaan, dan lainnya sehingga Anda bisa membuat audience yang dinamis, tepat, dan segar untuk personalisasi (melalui Remote Config) atau interaksi kembali (melalui Cloud Messaging dan/atau App campaign baru).
Misalnya, jika Anda ingin membuat audience "pengguna Kupon" berdasarkan orang yang menukarkan kode kupon dalam aplikasi, kemudian menyelesaikan pembelian dalam aplikasi dalam waktu 20 menit, ini sekarang dimungkinkan dengan pembuat audience yang baru.

Pengumuman menarik lainnya dari I/O

Selain tiga pengumuman besar di atas, kami juga membuat penyempurnaan berikut ke bagian Firebase yang lain.
Dukungan untuk kueri collection group di Cloud Firestore
Pada bulan Januari, kami meluluskan Cloud Firestore - database NoSQL kami yang dikelola sepenuhnya - keluar dari versi beta menjadi ketersediaan umum dengan tingkatan harga yang lebih rendah dan lokasi baru. Sekarang, kami telah menambahkan dukungan untuk kueri Collection Group. Ini memungkinkan Anda untuk menelusuri kolom di semua koleksi dengan nama yang sama, di mana pun mereka berada dalam database. Misalnya, bayangkan Anda memiliki aplikasi musik yang menyimpan datanya seperti ini:

Struktur data ini mempermudah pemrosesan ketika pengguna meminta lagu berdasarkan nama artis. Namun sampai hari ini, tidak mungkin melakukan kueri seluruh artis — seperti menemukan lagu terpanjang terlepas dari siapa yang menulisnya. Dengan kueri collection group, Cloud Firestore sekarang bisa melakukan penelusuran ini di semua dokumen lagu, meskipun mereka terletak di koleksi yang berbeda. Ini berarti pengaturan data secara hierarkis bisa dilakukan dengan lebih mudah, sembari tetap dapat menelusuri dokumen yang Anda inginkan.
Emulator Cloud Functions
Kami juga terus meningkatkan fitur dan paket emulator untuk meningkatkan produktivitas Anda guna pengembangan dan pengujian aplikasi lokal. Secara khusus, kami merilis emulator Cloud Functions baru yang juga bisa berkomunikasi dengan emulator Cloud Firestore. Jadi, jika Anda ingin membangun fungsi yang memicu pembaruan dokumen Firestore dan menulis data kembali ke database, Anda bisa menuliskan kode dan menguji keseluruhan alur secara lokal pada laptop Anda, untuk pengembangan yang jauh lebih cepat.
Kecepatan pemberitahuan yang dapat dikonfigurasi di Crashlytics
Firebase Crashlytics membantu Anda melacak, memprioritaskan, dan menyelesaikan masalah stabilitas yang mengikis kualitas aplikasi, secara real time. Salah satu pemberitahuan paling penting dalam Crashlytics adalah kecepatan pemberitahuan, yang memberi tahu Anda ketika masalah tiba-tiba bertambah parah dan berdampak pada banyak pengguna. Namun, kami menyadari bahwa setiap aplikasi bersifat unik dan ambang pemberitahuan satu-ukuran-untuk-semua mungkin bukanlah yang terbaik bagi Anda dan bisnis Anda. Itulah sebabnya, kini Anda bisa menyesuaikan kecepatan pemberitahuan dan menentukan seberapa sering dan kapan Anda ingin diberi tahu tentang perubahan stabilitas aplikasi Anda. Dengan gembira kami umumkan bahwa kami telah memperluas Crashlytics untuk menyertakan dukungan Unity dan NDK.



Penyempurnaan Test Lab
Firebase Test Lab mempermudah Anda dalam menguji aplikasi di perangkat fisik sesungguhnya, langsung dari CLI atau Firebase console. Dalam beberapa bulan terakhir, kami telah merilis sejumlah penyempurnaan untuk Test Lab. Kami telah memperluas tipe aplikasi tempat Anda bisa menjalankan pengujian dengan menambahkan dukungan untuk Wear OS by Google dan Android App Bundle. Kami juga menambahkan ML vision ke fitur monkey action Test Lab sehingga kami bisa menyimulasikan dengan lebih cerdas di mana pengguna akan menge-tap aplikasi atau game Anda. Terakhir, kami membuat pengujian lebih andal dengan partisi pengujian, deteksi pengujian kerapuhan, dan timeline robo action, yang memberi tahu Anda dengan tepat apa yang dilakukan crawler saat pengujian berjalan.


Kontrol yang lebih besar atas izin project Firebase
Keamanan dan privasi data selalu menjadi bagian dari prioritas utama kami. Kami ingin memastikan Anda memiliki kendali atas siapa yang bisa mengakses project Firebase Anda, itulah sebabnya kami memanfaatkan kontrol Identity & Access Management Google Cloud Platform untuk memberikan Anda kontrol izin yang lebih mendetail. Langsung dari Firebase console, Anda bisa mengontrol siapa yang memiliki akses dan bagian project Firebase mana yang bisa diaksesnya. Misalnya, Anda bisa memberikan akses ke subset fitur sehingga anggota tim yang menjalankan campaign notifikasi tidak dapat mengubah aturan keamanan database Firebase. Anda bisa bertindak lebih jauh lagi dan menggunakan konsol GCP untuk membuat peran khusus yang hanya mengizinkan akses ke tindakan yang perlu dilakukan oleh anggota tim.


Lebih banyak SDK open source
Agar Firebase semakin bermanfaat dan dapat diperluas, SDK kami akan terus open source dan kami menerima kontribusi dari komunitas. Kami berkomitmen untuk memberikan Anda transparansi dan fleksibilitas dengan kode yang Anda integrasikan ke dalam aplikasi seluler dan web. Baru-baru ini, kami menjadikan SDK C++ sebagai open source.

Merekap beberapa update dari Cloud Next 2019

Jika Anda ketinggalan berita Cloud Next 2019, berikut adalah rekap singkat dari update yang kami luncurkan pada bulan April:

• Integrasi Firebase Hosting dan Cloud Run: Integrasi ini menggabungkan CDN global Firebase Hosting dan fitur caching dengan container stateless yang dikelola Cloud Run sepenuhnya. Sekarang, lebih mudah menambahkan rendering sisi server berkinerja tinggi untuk situs Anda dalam bahasa apa pun yang diinginkan, tanpa harus menyediakan atau mengelola server sendiri.
• Dukungan tingkat-enterprise berbayar: Rencana dukungan Google Cloud Platform (GCP) mencakup dukungan untuk produk Firebase, yang merupakan opsi baru bagi pelanggan kami yang lebih besar yang tertarik dengan pengalaman dukungan berbayar yang lebih kuat. Sebagai pengingat, dukungan komunitas gratis akan selalu ada!

Update migrasi Fabric

Selain menjadikan Firebase lebih kuat, kami juga bekerja keras untuk menghadirkan Fabric terbaik ke Firebase. Kami tahu banyak dari Anda telah menunggu informasi lebih lanjut tentang hal ini, jadi kami telah membuat ringkasan perjalanan kami secara terperinci di sini.

Selanjutnya

Kami akan terus mengembangkan Firebase dan seperti biasa, kami menantikan masukan Anda! Dengan setiap penyempurnaan pada Firebase, kami bertujuan untuk menyederhanakan alur kerja pengembangan aplikasi dan kebutuhan infrastruktur, sehingga Anda bisa berfokus untuk membangun pengalaman pengguna yang luar biasa. Bila Anda ingin mengetahui apa yang berikutnya, bergabunglah dengan program Alfa dan bantu kami membentuk masa depan Firebase