[go: up one dir, main page]


Next.js untuk AMP 
Membangun halaman AMP melalui rendering sisi-server React memberikan momentum yang cukup bagi kami untuk menyadari bahwa kami perlu menambah kemampuan untuk mendukung kasus penggunaan ini. Itulah sebabnya kami berintegrasi dengan Next.js, salah satu framework paling populer untuk React. Fakta menarik: nextjs.org seluruhnya dibangun dengan AMP!

 amp-script
Pengubah permainan <amp-script> akhirnya meluncur tahun ini. Komponen yang sangat dinanti-nantikan ini memungkinkan Anda menambahkan JavaScript kustom ke halaman AMP Anda, berbagi kode antara halaman AMP dan non-AMP, dan membangun hal-hal yang sebelumnya tidak mungkin dilakukan.

 OpenJS foundation menyambut AMP 




Kami mengungkapkan hal yang berikutnya untuk model tata kelola terbuka dengan mengumumkan keputusan untuk bergabung dengan OpenJS Foundation. Misinya selaras dengan misi kami, dan akan memperbesar beragam suara dalam teknologi dan mendukung upaya kami untuk membuat web yang lebih baik. 

 AMP di kotak masuk Anda 




Gmail meluncurkan dukungan AMP untuk email, guna menghadirkan pengalaman terbaik pengguna ke kotak masuk Anda. Pengirim email sekarang bisa membuat pengalaman mulus dan konten interaktif untuk meningkatkan interaksi. AMP untuk email juga memiliki keterlibatan dari penyedia email utama yang lain seperti Outlook dan Yahoo Mail, dan kami berharap untuk membentuk kembali ekosistem email bersama. 

Komponen baru juga tersedia di Mail.ru, dan pengguna awal sudah merayakan hasil yang luar biasa. OYO, Perusahaan perhotelan terbesar di India, mengalami peningkatan 60% dalam konversi saat menguji AMP untuk email. 

 Terima kasih telah menyukseskan AMP Conf  
Tim kami bertemu dengan hampir 500 orang termasuk Anda di Tokyo pada #AMPConf tahunan kami yang ketiga. Selain pengumuman produk, kami juga meluncurkan amp.dev yang didesain ulang total, sebuah situs web untuk semua contoh kode, template, dan dokumentasi kami. AMPConf2020 saat ini sedang dikerjakan, jadi nantikan informasi selanjutnya di mana kami akan menghadirkan acara yang berikutnya.

 AMP Contributors Summit di Big Apple 
Pada awal Oktober kami bertemu dengan sekitar seratus kontributor di New York pada acara tahunan #AMPCS2019 untuk membahas fitur-fitur baru AMP. Tidak hanya ceramah, kami menyelenggarakan sesi breakout di mana kami bekerja bersama untuk meningkatkan project kami, ///dan menyempurnakan beberapa fitur AMP///. 

 Komunitas yang kuat
Hampir 1.000 orang telah berkontribusi kode untuk AMP dan membantu kami merancang web yang lebih cepat dan lebih baik untuk semua orang. Tahun ini saja, 341 kontributor telah membuat lebih dari 18.300 kontribusi di semua repositori AMP project. 





 Orang-Orang di Balik Kode
Komunitas memainkan peran besar dalam menyukseskan AMP; di situlah kami membagikan apa yang kami ketahui dan mempelajari apa yang tidak kami ketahui. Jadi kami meluncurkan seri ‘Orang-Orang di Balik Kode‘ untuk memahami bagaimana anggota komunitas menggunakan AMP dalam kehidupan nyata untuk membuat perbedaan. 

 19 Roadshow baru ///siap kami lakukan/// 
Tahun ini, AMP melakukan roadshow 19 kali, dan menghadirkan Roadshow kami ke seluruh dunia. Dari Johannesburg hingga Seoul, 1.600 orang datang termasuk Anda untuk melihat apa itu AMP. 
Roadshow dirancang untuk membantu developer membangun situs web AMP lengkap dengan percaya diri. Jadi kami mendalami empat pilar kunci: desain, interaktivitas, DevOps, dan monetisasi, untuk memastikan Anda memiliki semua yang dibutuhkan agar berhasil. 

Jika Anda ingin melihat ke mana kami akan datang pada tahun 2020, kunjungi halaman AMP Roadshow untuk mencari tahu. Tidak melihat kota Anda di daftar? Beri tahu kami, kami selalu mencari tempat baru untuk dikunjungi, atau jadi host event Anda sendiri. Kami akan menyediakan semua materinya – yang perlu Anda lakukan hanyalah datang!





 Visi 2020 
Ini merupakan tahun yang luar biasa. Terima kasih atas kreativitas dan komitmen Anda untuk membuat web yang lebih cepat dan mengutamakan pengguna bagi semua orang. Kami sangat menantikan hal yang berikutnya untuk AMP, dan berharap bisa melanjutkan kerja sama kita di tahun yang baru. Agar tidak ketinggalan informasi tentang semua project AMP dan melihat visi 2020 kami, silakan mendaftar newsletter ini. 

 Ditulis oleh Alex Durán, AMP Project Marketing di Google





2019 adalah tahun yang besar bagi AMP. Kami terus menumbuhkan komunitas kami dan menciptakan pengalaman luar biasa di berbagai situs web, email, cerita, dan iklan. Jadi, mari kita kilas balik ke awal tahun ini dan merekap semua tonggak pencapaian yang kita capai bersama.  Baca dan tonton videonya di bawah:





Next.js untuk AMP 
Membangun halaman AMP melalui rendering sisi-server React memberikan momentum yang cukup bagi kami untuk menyadari bahwa kami perlu menambah kemampuan untuk mendukung kasus penggunaan ini. Itulah sebabnya kami berintegrasi dengan Next.js, salah satu framework paling populer untuk React. Fakta menarik: nextjs.org seluruhnya dibangun dengan AMP!

 amp-script
Pengubah permainan <amp-script> akhirnya meluncur tahun ini. Komponen yang sangat dinanti-nantikan ini memungkinkan Anda menambahkan JavaScript kustom ke halaman AMP Anda, berbagi kode antara halaman AMP dan non-AMP, dan membangun hal-hal yang sebelumnya tidak mungkin dilakukan.

 OpenJS foundation menyambut AMP 




Kami mengungkapkan hal yang berikutnya untuk model tata kelola terbuka dengan mengumumkan keputusan untuk bergabung dengan OpenJS Foundation. Misinya selaras dengan misi kami, dan akan memperbesar beragam suara dalam teknologi dan mendukung upaya kami untuk membuat web yang lebih baik. 

 AMP di kotak masuk Anda 




Gmail meluncurkan dukungan AMP untuk email, guna menghadirkan pengalaman terbaik pengguna ke kotak masuk Anda. Pengirim email sekarang bisa membuat pengalaman mulus dan konten interaktif untuk meningkatkan interaksi. AMP untuk email juga memiliki keterlibatan dari penyedia email utama yang lain seperti Outlook dan Yahoo Mail, dan kami berharap untuk membentuk kembali ekosistem email bersama. 

Komponen baru juga tersedia di Mail.ru, dan pengguna awal sudah merayakan hasil yang luar biasa. OYO, Perusahaan perhotelan terbesar di India, mengalami peningkatan 60% dalam konversi saat menguji AMP untuk email. 

 Terima kasih telah menyukseskan AMP Conf  
Tim kami bertemu dengan hampir 500 orang termasuk Anda di Tokyo pada #AMPConf tahunan kami yang ketiga. Selain pengumuman produk, kami juga meluncurkan amp.dev yang didesain ulang total, sebuah situs web untuk semua contoh kode, template, dan dokumentasi kami. AMPConf2020 saat ini sedang dikerjakan, jadi nantikan informasi selanjutnya di mana kami akan menghadirkan acara yang berikutnya.

 AMP Contributors Summit di Big Apple 
Pada awal Oktober kami bertemu dengan sekitar seratus kontributor di New York pada acara tahunan #AMPCS2019 untuk membahas fitur-fitur baru AMP. Tidak hanya ceramah, kami menyelenggarakan sesi breakout di mana kami bekerja bersama untuk meningkatkan project kami, ///dan menyempurnakan beberapa fitur AMP///. 

 Komunitas yang kuat
Hampir 1.000 orang telah berkontribusi kode untuk AMP dan membantu kami merancang web yang lebih cepat dan lebih baik untuk semua orang. Tahun ini saja, 341 kontributor telah membuat lebih dari 18.300 kontribusi di semua repositori AMP project. 





 Orang-Orang di Balik Kode
Komunitas memainkan peran besar dalam menyukseskan AMP; di situlah kami membagikan apa yang kami ketahui dan mempelajari apa yang tidak kami ketahui. Jadi kami meluncurkan seri ‘Orang-Orang di Balik Kode‘ untuk memahami bagaimana anggota komunitas menggunakan AMP dalam kehidupan nyata untuk membuat perbedaan. 

 19 Roadshow baru ///siap kami lakukan/// 
Tahun ini, AMP melakukan roadshow 19 kali, dan menghadirkan Roadshow kami ke seluruh dunia. Dari Johannesburg hingga Seoul, 1.600 orang datang termasuk Anda untuk melihat apa itu AMP. 
Roadshow dirancang untuk membantu developer membangun situs web AMP lengkap dengan percaya diri. Jadi kami mendalami empat pilar kunci: desain, interaktivitas, DevOps, dan monetisasi, untuk memastikan Anda memiliki semua yang dibutuhkan agar berhasil. 

Jika Anda ingin melihat ke mana kami akan datang pada tahun 2020, kunjungi halaman AMP Roadshow untuk mencari tahu. Tidak melihat kota Anda di daftar? Beri tahu kami, kami selalu mencari tempat baru untuk dikunjungi, atau jadi host event Anda sendiri. Kami akan menyediakan semua materinya – yang perlu Anda lakukan hanyalah datang!





 Visi 2020 
Ini merupakan tahun yang luar biasa. Terima kasih atas kreativitas dan komitmen Anda untuk membuat web yang lebih cepat dan mengutamakan pengguna bagi semua orang. Kami sangat menantikan hal yang berikutnya untuk AMP, dan berharap bisa melanjutkan kerja sama kita di tahun yang baru. Agar tidak ketinggalan informasi tentang semua project AMP dan melihat visi 2020 kami, silakan mendaftar newsletter ini. 

 Ditulis oleh Alex Durán, AMP Project Marketing di Google


Artikel ini adalah tentang praktik terbaik yang kami temukan saat menggunakan Flow dalam aplikasi Android Dev Summit (ADS) 2019; yang baru saja dibuat open source. Baca terus untuk mengetahui bagaimana setiap layer aplikasi kami menangani streaming data.



Arsitektur aplikasi ADS mengikuti panduan arsitektur aplikasi yang direkomendasikan, dengan penambahan layer domain (UseCases) yang membantu memisahkan persoalan, menjaga class agar tetap kecil, terfokus, dapat digunakan kembali, dan dapat diuji:








Arsitektur aplikasi ADS 2019

Seperti banyak aplikasi Android, aplikasi ADS memuat data dari jaringan atau cache; kami menganggapnya sebagai kasus penggunaan yang sempurna untuk Flow. Untuk operasi tunggal, fungsi suspend lebih cocok dipakai. Ada dua komitmen utama yang menyebabkan refactor aplikasi menggunakan Coroutine. Komitmen pertama melakukan migrasi operasi tunggal, dan yang kedua adalah melakukan migrasi ke streaming data.


Pada artikel ini, Anda bisa menemukan prinsip-prinsip yang kami ikuti untuk melakukan refactor aplikasi dari penggunaan LiveData di semua layer arsitektur menjadi hanya penggunaan LiveData untuk komunikasi antara View dan ViewModel, serta Coroutine untuk UseCase dan layer bawah arsitektur kami.





1. Memilih mengekspos streaming sebagai Flow (bukan Channel)
Ada dua cara untuk menangani streaming data di coroutine: Flow API dan Channel API. Channel adalah sinkronisasi sederhana sedangkan Flow dibangun untuk memodelkan streaming data: ini adalah pabrik berlangganan untuk streaming data. Namun, Channel bisa digunakan untuk mendukung Flow, seperti yang akan kita lihat nanti.
Utamakan Flow karena ia menyediakan lebih banyak fleksibilitas, serta operator dan kontrak yang lebih eksplisit daripada Channel
Flow secara otomatis menutup streaming data karena sifat dari operator terminal yang memicu eksekusi streaming data dan menyelesaikannya dengan sukses atau luar biasa bergantung pada semua operasi flow di sisi produser. Karena itu, Anda tidak bisa (tidak dengan mudah) membocorkan sumber daya di sisi produser. Ini lebih mudah dilakukan dengan Channel: produser mungkin tidak perlu membersihkan sumber daya berat jika Channel tidak ditutup dengan benar.

Layer data aplikasi bertanggung jawab menyediakan data dengan membaca dari database atau mengambil dari Internet. Sebagai contoh ini adalah antarmuka DataSource yang mengekspos streaming data event pengguna:

interface UserEventDataSource {
  fun getObservableUserEvent(userId: String): Flow< UserEventResult > 
}


2. Cara menggunakan Flow di arsitektur aplikasi Android Anda
UseCase dan Repositori
Layer di antara View/ViewModel dan DataSource (dalam kasus kami adalah UseCase dan Repositori) sering kali perlu menggabungkan data dari beberapa kueri atau mentransformasi data sebelum ia bisa digunakan oleh layer ViewModel. Sama seperti sekuens Kotlin, Flow mendukung banyak operator untuk mentransformasi data Anda. Ada banyak operator yang sudah tersedia, atau Anda bisa membuat transformasi sendiri (mis. menggunakan operator transform). Namun, Flow mengekspos lambda suspend pada banyak operator, sering kali kita tidak perlu melakukan transformasi khusus untuk menyelesaikan tugas-tugas kompleks, cukup panggil fungsi suspend dari dalam Flow.

Dalam contoh ADS, kami ingin menggabungkan UserEventResult dengan data sesi dalam layer Repositori. Kami menggunakan operator map untuk menerapkan lambda suspend ke setiap nilai Flow yang diambil dari DataSource:

/* Copyright 2019 Google LLC. 
   SPDX-License-Identifier: Apache-2.0 */
class DefaultSessionAndUserEventRepository(
    private val userEventDataSource: UserEventDataSource,
    private val sessionRepository: SessionRepository
) : SessionAndUserEventRepository {

    override fun getObservableUserEvent(
        userId: String?,
        eventId: SessionId
    ): Flow> {
        // Handles null userId

        // Observes the user events and merges them with session data
        return userEventDataSource.getObservableUserEvent(userId, eventId).map { userEventResult ->
            // lambda of the map operator that can call suspend functions
            val event = sessionRepository.getSession(eventId)

            // Merges session with user data and emits the result
            val userSession = UserSession(
                event,
                userEventResult.userEvent ?: createDefaultUserEvent(event)
            )
            Result.Success(LoadUserSessionUseCaseResult(userSession))
        }
    }
}


ViewModel

Saat melakukan komunikasi UI ↔ ViewModel dengan LiveData, layer ViewModel harus menggunakan streaming data yang berasal dari layer data menggunakan operator terminal (mis. collect, first atau toList). Lihat kode selengkapnya di sini.

/* Copyright 2019 Google LLC. 
   SPDX-License-Identifier: Apache-2.0 */
// Simplified version of the real code
class SessionDetailViewModel(
    private val loadUserSessionUseCase: LoadUserSessionUseCase,
    ...
): ViewModel() {

    private fun listenForUserSessionChanges(sessionId: SessionId) {
        viewModelScope.launch {
            loadUserSessionUseCase(sessionId).collect { loadResult ->
                // Update multiple LiveDatas to notify the View
            }
        }
    }
}

Jika Anda mengonversi Flow ke LiveData, Anda bisa menggunakan extension function Flow.asLiveData() dari library lifecycle LiveData ktx androidX. Sangat mudah karena ia akan membagikan satu langganan pokok untuk Flow dan akan mengelola langganan berdasarkan siklus hidup pengamat. Selain itu, LiveData juga mempertahankan nilai terbaru untuk pengamat yang datang terlambat dan langganan aktif saat terjadi perubahan konfigurasi. Lihat kode yang lebih sederhana berikut yang menunjukkan bagaimana Anda bisa menggunakan extension function:

class SimplifiedSessionDetailViewModel(
  private val loadUserSessionUseCase: LoadUserSessionUseCase,
  ...
): ViewModel() {
  val sessions = loadUserSessionUseCase(sessionId).asLiveData()
}
Disclaimer: Cuplikan kode di atas bukan bagian dari aplikasi; itu adalah kode versi sederhana yang menunjukkan bagaimana Anda bisa menggunakan Flow.asLiveData().



3. Kapan waktu yang tepat menggunakan BroadcastChannel atau Flow sebagai detail implementasi
Kembali ke implementasi DataSource, bagaimana kita bisa mengimplementasikan fungsi getObservableUserEvent yang dijelaskan di atas? Tim mempertimbangkan dua implementasi alternatif: builder flow atauBroadcastChannel API. Masing-masing ditujukan untuk kasus penggunaan yang berbeda.

Kapan menggunakan Flow

Flow adalah cold stream. Cold stream adalah sumber data yang produsernya akan dijalankan untuk setiap listener yang mulai mengonsumsi event, menghasilkan streaming data baru yang dibuat pada setiap langganan. Setelah pemakai berhenti mendengarkan atau blok produser selesai, streaming data akan ditutup secara otomatis.
Flow sangat sesuai ketika produksi data harus dimulai/dihentikan untuk mencocokkan dengan pengamat
Anda bisa mengeluarkan elemen dalam jumlah terbatas atau tidak terbatas menggunakan builder flow.

val oneElementFlow: Flow = flow {
  // producer block starts here, stream starts
  emit(1)
  // producer block finishes here, stream will be closed
}
val unlimitedElementFlow: Flow = flow {
  // producer block starts here, stream starts
  while(true) {
    // Do calculations
    emit(result)
    delay(100)
  }
  // producer block finishes here, stream will be closed
}
Flow cenderung digunakan untuk tugas-tugas berharga karena menyediakan pembersihan otomatis melalui pembatalan coroutine. Perhatikan bahwa pembatalan ini bersifat kooperatif, flow yang tidak pernah ditangguhkan tidak pernah dapat dibatalkan: dalam contoh kami, karena delay adalah fungsi penangguhan yang memeriksa pembatalan, ketika pelanggan berhenti mendengarkan, Flow akan berhenti dan membersihkan sumber daya.


Kapan harus menggunakan BroadcastChannel

Channel adalah saluran primitif serentak untuk berkomunikasi antara coroutine. BroadcastChannel adalah implementasi dari Channel dengan kemampuan multicast.
Ada beberapa kasus di mana Anda mungkin ingin menggunakan implementasi BroadcastChannel di layer DataSource Anda:
Gunakan BroadcastChannel ketika produser dan konsumen memiliki masa pakai yang berbeda atau beroperasi sepenuhnya secara independen satu sama lain
BroadcastChannel API sangat cocok ketika Anda menginginkan produser mengikuti siklus hidup yang berbeda dan menyiarkan hasil terkini kepada siapa pun yang mendengarkan. Dengan cara ini, produser tidak perlu memulai setiap kali listener baru mulai mengonsumsi event.

Anda masih bisa mengekspos Flow ke pemanggil, mereka tidak perlu tahu tentang cara implementasinya. Anda bisa menggunakan fungsi ekstensi BroadcastChannel.asFlow() untuk mengekspos BroadcastChannel sebagai Flow.

Namun, menutup Flow tersebut tidak akan membatalkan langganan. Saat menggunakan BroadcastChannel, Anda harus menjaga siklus hidupnya. Mereka tidak tahu apakah ada listener atau tidak, dan akan menjaga sumber daya tetap aktif sampai BroadcastChannel dibatalkan atau ditutup. Pastikan untuk menutup BroadcastChannel ketika tidak lagi diperlukan. Selain itu, ingat bahwa saluran yang ditutup tidak dapat aktif lagi, Anda harus membuat instance baru.

Contoh cara penggunaan BroadcastChannel API bisa ditemukan di bagian berikutnya.


Disclaimer

Beberapa bagian dari Flow dan Channel API masih dalam tahap eksperimental, mereka kemungkinan akan berubah. Ada beberapa situasi di mana Anda saat ini menggunakan Channel, tetapi rekomendasi di masa mendatang mungkin berubah menggunakan Flow. Secara khusus, proposal StateFlow dan share operator Flow mungkin mengurangi penggunaan Channel di masa mendatang.



4. Mengonversi streaming data API berbasis callback ke Coroutine.

Beberapa library sudah mendukung coroutine untuk operasi streaming data, termasuk Room. Bagi yang tidak, Anda bisa mengonversi semua API berbasis callback ke Coroutine


Implementasi Flow

Jika Anda ingin mengonversi streaming API berbasis callback agar menggunakan Flow, Anda bisa menggunakan fungsi channelFlow (juga callbackFlow, yang memiliki implementasi yang sama). channelFlow membuat instance Flow yang elemennya dikirim ke Channel. Ini memungkinkan kami untuk menyediakan elemen yang berjalan dalam konteks yang berbeda atau secara serentak.

Dalam contoh berikut, kami ingin mengeluarkan elemen yang kami dapatkan dari callback ke dalam Flow:
  1. Buat aliran dengan builder channelFlow yang mendaftarkan callback ke library pihak ketiga.
  2. Keluarkan semua item yang diterima dari callback ke Flow.
  3. Ketika pelanggan berhenti mendengarkan, kami membatalkan pendaftaran langganan API menggunakan suspend fun awaitClose. 
    4. 
/* Copyright 2019 Google LLC. 
   SPDX-License-Identifier: Apache-2.0 */
override fun getObservableUserEvent(userId: String, eventId: SessionId): Flow {

    // 1) Create Flow with channelFlow
    return channelFlow {

        val eventDocument = firestore.collection(USERS_COLLECTION)
            .document(userId)
            .collection(EVENTS_COLLECTION)
            .document(eventId)
    
        // 1) Register callback to the API
        val subscription = eventDocument.addSnapshotListener { snapshot, _ ->
            val userEvent = if (snapshot.exists()) {
                parseUserEvent(snapshot)
            } else { null }

            // 2) Send items to the Flow
            channel.offer(UserEventResult(userEvent))
        }

        // 3) Don't close the stream of data, keep it open until the consumer
        // stops listening or the API calls onCompleted or onError. 
        // When that happens, cancel the subscription to the 3P library
        awaitClose { subscription.remove() }
    }
}
    Lihat kode selengkapnya di sini.


Implementasi BroadcastChannel

Untuk streaming data yang melacak autentikasi pengguna dengan Firestore, kami menggunakan BroadcastChannel API karena kami ingin mendaftarkan satu listener Authentication yang mengikuti siklus hidup yang berbeda dan menyiarkan hasil terkini kepada siapa pun yang mendengarkan.

Untuk mengonversi API callback ke BroadcastChannel, Anda membutuhkan lebih banyak kode daripada dengan Flow. Anda bisa membuat class di mana instance BroadcastChannel dapat disimpan dalam variabel. Selama inisialisasi, daftarkan callback yang mengirimkan elemen ke BroadcastChannel seperti sebelumnya:

/* Copyright 2019 Google LLC. 
   SPDX-License-Identifier: Apache-2.0 */
class FirebaseAuthStateUserDataSource(...) : AuthStateUserDataSource {

    private val channel = ConflatedBroadcastChannel>()

    private val listener: ((FirebaseAuth) -> Unit) = { auth ->
        // Data processing logic

        // Send the current user for observers
        if (!channel.isClosedForSend) {
            channel.offer(Success(FirebaseUserInfo(auth.currentUser)))
        } else {
            unregisterListener()
        }
    }
    
    @Synchronized
    override fun getBasicUserInfo(): Flow> {
        if (!isListening) {
            firebase.addAuthStateListener(listener)
            isListening = true
        }
        return channel.asFlow()
    }
}
Lihat kode selengkapnya di sini.




5. Tips pengujian

Untuk menguji transformasi Flow (seperti yang kami lakukan di UseCase dan layer Repositori), Anda bisa menggunakan builder flow untuk menampilkan data palsu. Misalnya:

/* Copyright 2019 Google LLC.
   SPDX-License-Identifier: Apache-2.0 */
object FakeUserEventDataSource : UserEventDataSource {
  override fun getObservableUserEvents(userId: String) = flow {
    emit(UserEventsResult(userEvents))
  }
}
class DefaultSessionAndUserEventRepositoryTest {
  @Test
  fun observableUserEvents_areMappedCorrectly() = runBlockingTest {
    // Prepare repo
    val userEvents = repository
          .getObservableUserEvents("user", true).first()
    // Assert user events
  }
}
Agar sukses menguji implementasi Flow, kami sarankan menggunakan operator take untuk mendapatkan beberapa item dari Flow dan operator toList sebagai operator terminal untuk menerima hasilnya dalam daftar. Lihat contohnya dalam pengujian berikut:

class AnotherStreamDataSourceImplTest {
  @Test
  fun `Test happy path`() = runBlockingTest {
    // Prepare subject
    val result = subject.flow.take(1).toList()
    // Assert expected result
  }
}
Operator take sangat cocok untuk menutup Flow setelah Anda mendapatkan item. Tidak menutup Flow yang dimulai (atau BroadcastChannel) setelah setiap pengujian akan membocorkan memori dan membuat rangkaian pengujian yang kacau dan tidak konsisten.


 Catatan: Jika implementasi DataSource dilakukan dengan BroadcastChannel, kode di atas tidaklah cukup. Anda harus mengelola siklus hidupnya dengan memastikan bahwa Anda memulai BroadcastChannel sebelum pengujian dan menutupnya setelah pengujian selesai. Jika tidak, Anda akan membocorkan memori. Anda bisa melihat pengujian seperti ini dalam contoh Flow berikut.
Menguji praktik terbaik Coroutine juga berlaku di sini. Jika Anda membuat coroutine baru dalam kode yang sedang diuji, Anda mungkin ingin menjalankannya di thread pengujian untuk eksekusi deterministik pengujian. Ketahui selengkapnya tentang hal ini dalam pembicaraan Testing Coroutines ADS 2019.


Ringkasan

  • Utamakan mengekspos Flow kepada konsumen daripada Channel karena semua kontrak eksplisit dan operator yang disediakan Flow.
  • Dengan Flow, blok produser akan dieksekusi setiap kali ada listener baru dan siklus hidup streaming data akan ditangani secara otomatis.
  • Dengan BroadcastChannel, Anda bisa berbagi produser tetapi Anda harus mengelola siklus hidupnya sendiri.
  • Pertimbangkan untuk mengubah API berbasis callback ke coroutine untuk integrasi API yang lebih baik dan idiomatis dalam aplikasi Anda.
  • Uji implementasi Flow secara mudah dengan menggunakan operator take dan toList.



Di Kubernetes Podcast, kami membawakan Anda kumpulan berita mingguan cloud, beserta wawancara mendalam dengan anggota komunitas. Saat kami mempublikasikan episode ke 50 dan yang terakhir untuk 2019, saatnya untuk melihat kembali beberapa momen favorit kami tahun ini.


Tahun ini, kami coba untuk keluar dari studio. Kami menjadi host rekaman langsung di Google Cloud Next di San Francisco, serta bertemu dengan pendengar kami di KubeCon EU di Barcelona dan KubeCon NA di San Diego. Tidak ada yang lebih memuaskan bagi kami daripada meminta seseorang mendatangi Anda di sebuah konferensi dan memberi tahu Anda bahwa mereka menikmati acaranya, atau bahkan bertanya tentang keluarga rubah yang Anda sebut di salah satu episode tinggal di halaman belakang rumah Anda.  Kami sungguh sangat berterima kasih kepada semua orang yang datang, atau menyapa kami di lorong.

Open source menjangkau seluruh penjuru dunia, dan kami kagum pada semua pendengar yang telah bergabung dengan komunitas podcast dari seluruh dunia. Sesekali kami mengirimkan stiker melalui postingan: mereka telah sampai ke puluhan negara di hampir setiap benua. (Kami masih menantikan pendengar dari Antartika yang perlu dijangkau!) Terima kasih kepada audience kami yang luar biasa, yang telah memberitahukan betapa kami membantu mereka terhubung dan belajar tentang komunitas Kubernetes. Kami benar-benar berterima kasih kepada Anda karena telah setia mendengarkan.



kubernetes podccast headphones.png
Dedikasi luar biasa yang di-tweet kepada kami dari seorang pendengar podcast
Kami ingin membagikan beberapa episode terpopuler di tahun 2019:
  • Cerita Kegagalan Kubernetes, bersama Henning Jacobs (episode 38): Untuk memiliki peluang sukses yang terbaik, ada baiknya belajar dari kegagalan. Setelah mengalaminya sendiri, Henning terinspirasi untuk mulai mengumpulkan cerita kegagalan orang lain.
  • Ingress, bersama Tim Hockin (episode 41): Sebagai orang tua yang bangga dengan project Kubernetes, Tim adalah Googler 15 tahun dan perancang sebagian besar jaringan Kubernetes dan tumpukan penyimpanan—ekstensi nyata dari bertahun-tahun pekerjaannya di kernel Linux.
  • Langsung di Google Cloud Next, bersama Eric Brewer (episode 49): Dalam event langsung pertama kami, Eric bergabung dengan kami untuk berbicara tentang sejarahnya dalam membangun infrastruktur untuk penelusuran, teorema CAP, dan mengumumkan Kubernetes kepada dunia.
  • KeyBank, bersama Gabe Jaynes (episode 51): Bank tidak selalu merupakan terminal dan mainframe. Bank yang smart, seperti KeyBank, adalah Kubernetes dan mainframe! Tim Gabe bekerja sama dengan Google Cloud sebagai mitra desain.
  • Istio 1.2, bersama Louis Ryan (episode 58): Louis telah bekerja di infrastruktur API dan layanan mesh di Google selama 10 tahun. Dia berbicara tentang sejarah Istio, keputusan desainnya, dan tujuan masa depannya.
  • Menyerang dan Melindungi Kubernetes, bersama Ian Coldwater (episode 65): Pelajari cara melindungi infrastruktur container Anda dari Ian: mereka dibayar untuk menyerangnya, dan pembicara konferensi yang populer tentang topik ini.
  • CRD, API Machinery, dan Ekstensibilitas, bersama Daniel Smith (episode 73): Kontributor Kubernetes senior lainnya, Daniel bergabung dengan project sebelum open-source, dan memimpin tim Google dan open-source yang membangun CRD dan fitur ekstensibilitas lainnya.
  • Kubernetes 1.17, bersama Guinevere Saenger (episode 83): Episode akhir sebelum episode terakhir kami untuk tahun ini adalah wawancara dengan pemimpin Tim Rilis untuk Kubernetes 1.17 yang baru. Pelajari bagaimana Guinevere berubah dari pianis konser menjadi software engineer dan memimpin tim beranggotakan lebih dari 30 orang untuk menghasilkan rilis Kubernetes final tahun 2019.
Jika Anda memiliki waktu senggang selama liburan, mengapa tidak berlangganan dan menikmati satu atau beberapa episode?  Bagi mereka yang tidak bisa mendengarkan, atau memilih tidak mendengarkan, kami juga menawarkan transkrip setiap episode pada halamannya di kubernetespodcast.com.

Kami akan beristirahat dua minggu selama periode liburan, tetapi kami akan kembali lagi di bulan Januari!




kubernetes podcast.png

Ditulis oleh Vint Cerf, Vice President and Chief Internet Evangelist; Grant Erickson, Principal Engineer; Kevin Po, Product Manager


Google mengumumkan Project Connected Home over IP, Working Group baru bersama mitra industri seperti Amazon, Apple dan Zigbee Alliance (terpisah dari protokol Zigbee 3.0/PRO yang sudah ada). Project ini bertujuan untuk membangun standar baru yang memungkinkan komunikasi berbasis IP di seluruh perangkat smart home, aplikasi seluler, dan layanan cloud. Pabrikan perangkat, penyedia silikon, dan developer lain diundang untuk bergabung dengan kelompok kerja dan menyumbangkan teknologi open-source saat ini ke dalam inisiatif untuk mempercepat pengembangannya sehingga pelanggan dan pembuat perangkat bisa memperoleh manfaat lebih cepat.




Kami memiliki postingan Kata Kunci yang menggambarkan project dan potensinya untuk membuat protokol “plug-and-play” seperti USB untuk rumah. Kami berharap standar baru ini akan mempermudah developer untuk membuat perangkat yang dapat diandalkan, aman, terjamin, bersifat pribadi, interoperable, dan terhubung ke Internet tetapi juga bersifat opsional.





Untuk mempercepat inisiatif ini, Google akan memberikan kontribusi teknologi inti dari project OpenWeave, dan juga menyediakan keahlian dalam protokol jaringan mesh berdaya rendah IP-carrying seperti Thread. Dalam postingan ini, kami akan mendalami lebih jauh pemikiran Google untuk protokol konektivitas smart home, dan bagaimana kami melihat potensi konvergensi dari teknologi ini dalam industri.





Menempatkan Internet di Internet of Things
IP ditambah UDP dan TCP, telah menghadirkan kepada kita kekayaan Internet, web, dan revolusi seluler. Ini sama halnya dengan semua hal yang menjadikan smart home dan menempatkan “Internet” di Internet of Things.


Karena kemampuan unik IP untuk menyatukan teknologi jaringan yang berbeda, ia menyediakan platform yang ideal untuk konvergensi di rumah pintar. Selain itu, alih-alih membutuhkan produk dan infrastruktur aplikasi khusus, solusi berbasis IP bisa meningkatkan infrastruktur jaringan off-the-shelf yang dapat dibagikan di banyak aplikasi dan produk. Ini membantu mengurangi kekacauan kabel dan colokan akibat gateway dan hub yang sudah menjadi hal biasa di banyak smart home hari ini.



Solusi berbasis IP seperti Project Connected Home over IP mendukung komunikasi end-to-end langsung, pribadi, dan aman antara perangkat, seluler, dan layanan cloud dengan model pemrograman dan pengembangan yang familier serta konsisten sehingga memudahkan developer untuk meningkatkan pengalaman dan solusinya di seluruh domain tersebut. Pendekatan ini mengurangi titik-titik serangan dan kelemahan di mana keamanan bisa saja dihentikan dan diinisiasi ulang.



Ketika kami memulai perjalanan rumah pintar lebih dari delapan tahun yang lalu, kami melihat opsi teknologi yang ada, mencatat banyak tumpukan yang terintegrasi secara vertikal, dan mempertimbangkan biayanya bagi pengguna dan mitra. Karena itu, kami berinvestasi dalam teknologi pelengkap berbasis IP dan IP-carrying, yaitu Weave dan Thread, untuk menghadirkan manfaat IP ke dua layer tumpukan jaringan—layer aplikasi dan layer jaringan nirkabel berdaya rendah.




Pertumbuhan industri smart home telah menambahkan teknologi dan pembelajaran baru, seperti model data dan desain penemuan layanan. Industri sekarang memiliki keinginan kuat untuk menyatukan pembelajaran ini menjadi satu protokol tunggal yang bisa diadopsi secara luas, dan pada akhirnya memberikan pengguna pilihan untuk mengatur dan mengontrol perangkat smart home dalam ekosistem pilihan mereka. Kami berharap Project itu akan mewujudkan visi ini.





Project Connected Home over IP
Project ini, yang diilustrasikan di bawah, akan menyatukan yang terbaik dari pasar dan teknologi teruji-produk untuk membangun solusi yang memberikan manfaat seperti:
  • Standar aplikasi yang mudah diadopsi untuk set teknologi jaringan, meliputi Wi-Fi, Thread, dan Bluetooth Hemat Energi (BLE).
  • Keamanan data end-to-end dan privasi antara perangkat seluler dan rumah, serta layanan cloud.
  • Set komponen pengaturan default dasar yang terintegrasi dan terstandardisasi.
  • Platform dan teknologi agnostik-ekosistem—perangkat apa pun, ekosistem apa pun.
  • Mengurangi penerjemah dan gateway tunggal dengan membangun di atas IP
  • Model pemrograman yang konsisten untuk perangkat, seluler, dan cloud.
Diagram piramida yang menunjukkan layer Aplikasi Project Connected Home over IP
Berikut adalah bagaimana kami melihat teknologi layer jaringan ini memenuhi kebutuhan smart home saat ini dengan protokol aplikasi yang diajukan Project berjalan di atasnya.






Dukungan Layer Jaringan: Efisien, Cepat, dan Mudah
Di Google, kami menemukan bahwa Thread, Wi-Fi, dan Bluetooth Hemat Energi adalah tiga teknologi konektivitas nirkabel saling melengkapi yang membuka kunci kasus penggunaan utama di rumah:
  • Efisien: Thread
    Thread adalah protokol jaringan mesh bertenaga rendah IP-carrying, yang dirancang khusus untuk infrastruktur jaringan dan aplikasi jaringan dengan bandwidth rendah. Ia juga melengkapi Seluler, Ethernet, atau Wi-Fi untuk interaksi seluler dan cloud. Thread sangat cocok untuk aplikasi yang membutuhkan keandalan tinggi di mana pemadaman mungkin tidak dapat diterima karena ia memiliki fitur mesh pengobatan otomatis.
    Kami sekarang menggunakan Thread di produk kami seperti Nest Detect dan Nest x Yale Lock.
  • Cepat: Wi-Fi
    Wi-Fi adalah jaringan nirkabel dengan bandwidth tinggi dan latensi rendah yang dirancang untuk infrastruktur jaringan dan aplikasi jaringan bertenaga listrik atau baterai yang dapat diisi ulang. Wi-Fi biasanya digunakan untuk melakukan streaming konten terbaru dari Google Play Store ke perangkat ruang keluarga atau seluler Anda seperti Pixel atau Nest Hub Max; ia juga bisa menjadi solusi yang bagus untuk produk seperti Nest Camera atau Nest Learning Thermostat. Yang terakhir, ketika disambungkan dengan teknologi IP-carrying seperti Thread, Wi-Fi adalah jalur ke seluler, Internet, dan layanan cloud untuk perangkat terhubung yang berdaya rendah.
  • Mudah: Bluetooth Hemat Energi
    Ponsel saat ini menyediakan cara yang sangat mudah untuk memeriksa perangkat smart home Anda dari mana saja. Ponsel hampir secara universal mendukung Bluetooth Hemat Energi (BLE), sehingga menyediakan cara mudah untuk menghubungkan dan mempersiapkan perangkat. Selain perannya yang penting dalam pengaturan default, BLE juga bisa berfungsi sebagai link kedekatan langsung-ke-seluler, yang tidak hanya mudah tetapi juga dapat membantu memenuhi persyaratan peraturan “terdekat” untuk aplikasi keamanan dan keselamatan. Sebagai contoh, kami menggunakan BLE sebagai metode komunikasi untuk App Silence, fungsionalitas hening alarm seluler di Nest Protect.







Akselerasi melalui Teknologi Teruji dan Open Source
Mengembangkan standar baru apa pun adalah proses yang intensif dan tidak mudah, yang secara langsung memengaruhi time-to-market ke komunitas.




Project ini bertujuan mengatasi tantangan time-to-market dengan menyatukan dan membangun aspek-aspek terbaik dari teknologi yang telah teruji market seperti OpenWeave Google serta protokol dan model data lain dari organisasi mitra. Tujuannya adalah menggunakan upaya integrasi sistem untuk menggabungkan teknologi-teknologi ini menjadi sebuah protokol open-source kohesif yang bisa dengan cepat diiterasi dan diuji karena sebagian besar kode sudah ada. Kami berharap pendekatan ini akan membawa manfaat baru bagi pengguna dan pembuat perangkat dengan lebih cepat.




Mari Bergabung dengan Upaya Ini!
Kami sangat senang bisa bekerja sama dengan Amazon, Apple, Zigbee Alliance, komunitas open source, dan Anda menuju tujuan ini. Kami percaya Project ini akan membuat segalanya menjadi lebih mudah bagi pelanggan dan developer—menyediakan kemampuan untuk memilih beragam produk smart home yang menguntungkan, memberikan jaminan bahwa produk akan bekerja bersama, dan menghadirkan keamanan dan privasi, terlepas dari ekosistemnya. Sangat mirip dengan kemampuan untuk menggunakan printer USB, tanpa harus khawatir tentang apakah printer tersebut bekerja dengan Chromebook, Mac, atau komputer Windows.


Bergabunglah bersama kami di Connected Home over IP Working Group hari ini dan wujudkan visi Project! Anda juga bisa mempelajari lebih lanjut tentang teknologi smart home terbaru kami di sini dan bagaimana mereka mengaktifkan integrasi yang mudah dengan Asisten.


Catatan Editor: postingan berikut ditulis oleh Frédéric Wang, Mitra di Igalia
Selama tiga tahun berturut-turut, AMP Project bekerja sama dengan Igalia untuk menangani laporan bug dan permintaan perbaikan dari komunitas Web. Tugas khusus meliputi triase bug, proses debug dan analisis, menulis pengujian, menyediakan patch, dan diskusi dengan berbagai aktor platform Web. Ini tidak hanya berperan penting untuk mempercepat tujuan AMP project secara signifikan, tetapi juga secara umum bermanfaat bagi semua developer dan pengguna platform Web.
Entri blog ini menjelaskan aktivitas kami tahun ini, dengan fokus pada bug dan fitur WebKit/iOS. Namun, upaya Web platform interoperability kami sesekali meluas ke komunitas browser lain dan juga grup standardisasi.


Resize Observer
Intersection Observer diluncurkan dalam iOS 12.2 berkat Engineer Google Ali Juma. Ini adalah JavaScript API baru untuk memantau perubahan di titik temu elemen target dengan elemen ancestor atau dengan viewport dokumen tingkat atas secara tidak bersamaan.

Resize Observer adalah API serupa  yang kami implementasikan awal tahun ini di bawah tanda preferensi. JavaScript API ini memungkinkan developer Web untuk secara tidak bersamaan mengamati kapan suatu elemen diubah ukurannya, apa pun sebabnya. Ini tersedia di iOS 13 beta dan tanda preferensi yang sesuai telah diaktifkan secara default di trunk, jadi kami berharap fitur ini tersedia di rilis iOS 13.


Scroll
Apple mengambil alih tugas yang kami mulai tahun lalu untuk membuat <iframe> elemen dapat di-scroll dan perilaku ini sekarang diaktifkan secara default di versi iOS 13 terbaru. Perbaikan bug lain yang melibatkan elemen-elemen yang dapat di-scroll tersedia untuk scroll-snap-align, scrollability setelah resize indikator find-in-page setelah scroll serta untuk berbagai regresi iOS 13 yang terkait dengan scroll flickering dan jittering.

Peningkatan telah diimplementasikan untuk parameter ScrollIntoViewOptions API scroll. Dukungan untuk penyelarasan scroll logis diluncurkan di iOS 13. Kami juga melanjutkan upaya kami untuk mendukung parameter IDL scroll-behavior serta properti CSS dan kami berharap untuk menyelesaikannya di semester berikutnya. Saat mengerjakan ini, kami juga mendeteksi dan memperbaiki bug Chrome yang terkait dengan metode scrollIntoView(), termasuk kasus-kasus ketika terdapat scrollbar atau ketika scroller menggunakan mode penulisan non-default.

Masalah browser interoperability yang lama untuk pengguna terkait dengan nilai scrollLeft, scrollTop, dan API sejenis yang tidak konsisten dan salah satu pencapaian penting kami adalah memastikan perilaku standar yang lebih reliabel ketika mengatur atau mendapatkan koordinat scroll. Kami memperkenalkan opsi untuk membuat Chrome menggunakan nilai standar dalam mode penulisan non-default dan berencana meluncurkannya, setelah memastikan bahwa itu tidak akan menyebabkan kerusakan serius. Demikian pula, Apple memutuskan untuk mengaktifkan perubahan 2018 kami ke scroller viewport pada semua port WebKit.

Selain perbaikan bug rutin, kami mulai menerapkan fitur scroll menarik lainnya, termasuk kustomisasi overscroll dan overscroll-behavior yang merupakan API yang kuat bagi developer web untuk mengontrol apa yang terjadi ketika scroller mencapai batas-batasnya. Kami mengharapkan lebih banyak kemajuan tahun depan.


Resource Loading
Tujuan menarik yang lain adalah untuk memberikan lebih banyak kekuatan kepada pembuat Web untuk mengontrol loading behaviour. Secara khusus, ini memungkinkan kemampuan untuk mengontrol privasi dan mengoptimalkan tata letak halaman.

Atribut referrerpolicy telah diterapkan untuk menentukan berapa banyak informasi perujuk yang harus dimasukkan dalam permintaan yang terkait dengan loading resources elemen HTML. Ini hanya diterapkan untuk elemen <iframe> dan <script> serta tersedia di iOS 13 di bawah experimental feature flag. Kami akan terus berbicara dengan Apple untuk melihat kapan ini bisa diaktifkan secara default atau diterapkan untuk elemen lain.

Atribut imagesrcset dan imagesizes pada <link rel=preload> juga telah diterapkan dan tersedia di iOS 13 di bawah experimental feature flag. Atribut ini memberikan kemungkinan untuk melakukan preload gambar responsif yang diwakili oleh elemen <img> dengan atribut srcset serta ukuran yang relevan dan mengoptimalkan pemilihan ukuran yang sesuai untuk perangkat pengguna.

Kami juga mulai mengirimkan patch untuk mendukung atribut lazyload pada elemen <img> dan <iframe>. Atribut ini memungkinkan pembuat Web untuk mengindikasikan bila memuat konten elemen dengan lazyload adalah ide yang bagus (mis. jika mereka tidak terlihat di viewport sampai pengguna melakukan scroll ke situ) atau bila konten mereka harus segera dimuat. Petunjuk ini sangat membantu browser untuk mengoptimalkan pemuatan sumber daya.

Yang terakhir, kami membuat dukungan eksperimental untuk atribut intrinsic size di WebKit. Proposal ini dimaksudkan guna membantu browser untuk menentukan rasio aspek atau ukuran gambar sebelum isinya benar-benar dimuat, untuk menghindari perubahan posisi post-load tambahan. Proposal ini telah digantikan oleh pendekatan berbasis CSS murni yang menangani kasus penggunaan yang sama. Eksperimen kami bermanfaat untuk diskusi antara vendor browser serta CSS WG, dan kami berencana untuk menulis ulang patch untuk mengimplementasikan pendekatan berbasis CSS di WebKit.


Kesimpulan
Kolaborasi antara AMP project dan Igalia untuk memajukan Platform Web telah sangat berhasil. Ada beberapa tugas yang tertunda dan ide-ide baru yang harus dikerjakan sehingga kami menantikan untuk melanjutkan kerja keras ini tahun depan!
Labels: ,


Awal tahun ini, kami mengumumkan Cloud Run, platform komputasi terbaru untuk container tanpa server, yang bisa berjalan pada infrastruktur Google yang dikelola penuh–atau pada kluster Google Kubernetes Engine (GKE) Anda dengan Cloud Run for Anthos. Portabilitas ini dicapai dengan API open-source Knative.
Dengan Cloud Run for Anthos, kami menyediakan dan mengelola semua yang Anda butuhkan untuk mendukung container tanpa server dalam kluster GKE, misalnya Knative dan service mesh, dan ini sekarang sudah tersedia secara umum. Mari kita lihat beberapa peningkatan dan fitur terbaru, termasuk kemampuan autoscaling dan jaringan yang lebih baik, sehingga mempermudah penerapan dan pengoperasian layanan mikro tanpa server di kluster Anthos GKE Anda. (Pastikan juga untuk memeriksa semua hal terbaru di Cloud Run yang dikelola penuh.)

Manajemen traffic

Cloud Run for Anthos sekarang bisa mengarahkan setiap permintaan atau RPC secara acak antara beberapa revisi layanan dengan persentase traffic yang Anda konfigurasi. Anda bisa menggunakan fitur ini untuk melakukan penerapan canary dari versi aplikasi yang lebih baru, mengirimkan sedikit persentase traffic dan memvalidasi jika kinerjanya benar, sebelum secara bertahap meningkatkan traffic-nya.
Selain itu, kemampuan manajemen traffic baru ini memungkinkan Anda kembali ke versi aplikasi lama dengan cepat. Anda bisa mengatur traffic ke layanan Anda di Cloud Console, serta fitur command-line gcloud.
traffic manage.png

Menghadirkan Cloud Run ke kluster lokal Anda

Cloud Run for Anthos versi Beta hanya mendukung kluster GKE yang berjalan di Google Cloud Platform (GCP). Dengan ketersediaan Cloud Run for Anthos secara umum, kini Anda bisa menerapkan Cloud Run untuk kluster lokal yang Anda terapkan di VMware.
Dengan ini, Anda bisa memiliki pengalaman operator dan developer tanpa server yang sama di kedua lingkungan. Anda bisa menggunakan gcloud atau Cloud Console untuk menerapkannya ke kluster Anthos dan memantaunya, terlepas dari apakah mereka berjalan secara lokal, atau di GCP.
developer and operator.png

Dukungan untuk Kubernetes Secret dan ConfigMap

Anda sekarang bisa memasang sumber daya Kubernetes Secret dan ConfigMap yang ada dalam kluster Anda ke layanan Cloud Run menggunakan antarmuka Cloud Console atau gcloud. Ini memungkinkan Anda menerapkan layanan tanpa harus membuat file manifes Kubernetes yang panjang.
cloud run gcp.png

Menyempurnakan jaringan dan parameter autoscaling

Dengan peningkatan terbaru di Cloud Console dan gcloud, Anda sekarang bisa menyetel lebih lanjut parameter autoscaling dan jaringan aplikasi dalam tingkat per revisi.
  • --min-instances / --max-instances memungkinkan Anda menetapkan batas penskalaan aplikasi. Misalnya, menyetel --min-instances lebih besar dari 0 akan mencegah layanan Anda turun ke nol jika tidak ada aktivitas untuk mencegah cold start.
  • --timeout memungkinkan Anda menetapkan waktu tunggu permintaan khusus untuk layanan.
  • --port memungkinkan Anda untuk menyesuaikan dan menetapkan nomor port yang didengarkan aplikasi ter-container Anda. Hal ini memungkinkan Anda untuk menghadirkan aplikasi ke Cloud Run tanpa harus mengubah nomor port server aplikasi.
Beberapa opsi ini sekarang masih dalam versi Beta, tetapi tidak lama lagi, opsi ini dan banyak opsi konfigurasi lainnya akan tersedia untuk Anda dalam baris perintah dan Cloud Console.

Membuat layanan Anda lebih mudah diamati

Secara default, Cloud Run for Anthos terintegrasi dengan Stackdriver Monitoring untuk mengekspos metrik dari layanan yang telah Anda terapkan. Dengan ketersediaan umum, Anda bisa menemukan metrik ini dalam Stackdriver Metrics, atau langsung di tab "Metrics" pada halaman Cloud Run layanan.

Metrik ini mencakup beberapa sinyal penting: latensi permintaan, tingkat error, penggunaan CPU dan memori, serta jumlah instance container. Anda bisa menggunakan metrik ini lebih jauh lagi untuk menelusuri aplikasi menurut revisi, dan membuat pemberitahuan serta SLO menggunakan Stackdriver Monitoring.

create alerts.png
Perhatikan bahwa Anda mendapatkan set metrik yang sama bahkan jika kluster Anthos Anda berjalan secara lokal, misalnya di VMware.

Jejak kluster yang lebih kecil

Add-on Istio sekarang bersifat opsional untuk Cloud Run for Anthos, karena Cloud Run sekarang memasukkan komponen-komponen tertentu dari Istio. Istio versi penuh tetap merupakan pelengkap yang sempurna untuk Cloud Run jika Anda ingin memiliki kebijakan traffic level kluster dan menggunakan dasbor Anthos Service Mesh untuk memiliki satu panel kaca visibilitas guna melihat layanan dalam kluster Anda. Komunitas Istio baru-baru ini membuat beberapa penyempurnaan pada Istio, termasuk pengurangan jejak sumber dayanya.

Mitra ekosistem

Kami bekerja sama dengan berbagai ISV di bidang CI/CD, keamanan, dan kemampuan pengamatan sehingga Anda bisa terus menggunakan fitur favorit Anda dengan aplikasi yang berjalan di Cloud Run for Anthos. Klik di sini untuk melihat daftar mitra dan integrasi Cloud Run terbaru.

Cobalah sekarang!

Kedua Cloud Run sepenuhnya dikelola dan Cloud Run for Anthos sekarang sudah tersedia dan siap dicoba untuk aplikasi Anda. Anda bisa mencoba Cloud Run pada kluster Anthos GKE dengan mengikuti panduan quickstart gratis hingga Mei 2020. Anda juga bisa menggunakan kesempatan uji coba gratis GCP selama 12 bulan untuk mendapatkan kredit $300 dan membuat sebuah kluster dengan Cloud Run for Anthos. Dan jika Anda sudah menjalankan Anthos secara lokal, cobalah panduan quickstart ini untuk menerapkan Cloud Run ke lingkungan VMware Anda.


Ditulis oleh Mariam Hasnany, Product Manager, Flutter
Kami senang bisa mengumumkan bahwa dukungan web untuk Flutter sudah masuk versi Beta!
Mengapa kami menghadirkan Flutter ke web?
Developer membangun aplikasi yang harus berjalan di seluler dan web. Penting bagi kami agar Anda bisa merancang dan membangun apa yang Anda inginkan, dan tahu bahwa dengan Flutter itu akan bekerja dengan indah kapan pun Anda membutuhkannya. Sebagai developer, mempelajari satu set keahlian yang bisa dengan mudah ditransfer ke berbagai platform sangatlah dibutuhkan. Dukungan web untuk Flutter memungkinkan developer menggunakan kode yang sama, menghadirkan fitur dengan lebih cepat, dan memastikan konsistensi untuk pengalaman mereka di seluruh perangkat. Selain itu, kompiler Dart yang kuat untuk web dan arsitektur Flutter yang dirancang portabel mempermudah pembuatan pengalaman web interaktif yang menakjubkan menggunakan Flutter.
Lebih dari sekadar pratinjau
Sejak merilis dukungan web sebagai pratinjau teknis di Google I/O tahun ini, dan dimulainya program pengguna awal pada bulan Juli, kami terus bekerja keras untuk mendukung animo yang semakin besar dalam memperluas dukungan web Flutter baik di Google maupun publik yang lebih luas.
Jadi, apa yang dimaksud Beta untuk web?
Dengan dirilisnya Flutter 1.12, web Flutter mendukung keluaran dari pratinjau teknis ke versi Beta. Saat Anda berada di saluran Beta dan telah mengaktifkan dukungan web, membuat project Flutter baru tidak hanya akan memasukkan aplikasi host Android dan iOS, tetapi sekarang juga memasukkan web/direktori yang berisi semua yang diperlukan untuk melakukan compile dan menjalankan kode project yang sama dalam sebuah browser.
Kami percaya dukungan web Flutter mulai stabil dan siap untuk mulai dipergunakan developer pemberani dalam sejumlah skenario. Seiring dengan langkah kami ke tahap pengembangan berikutnya, kami akan terus melakukan perubahan dan meningkatkan aksesibilitas, cakupan pengujian, dan banyak lagi.
Skenario yang bisa dicoba
Karena kami mengembangkan dukungan Flutter untuk berjalan di web, kami secara khusus berfokus pada sejumlah skenario yang kami pikir sangat cocok untuk karakteristik Flutter. Kami percaya bahwa set fitur kami cukup lengkap sehingga developer bisa membangun pengalaman web interaktif yang kaya. Saat bekerja dengan mitra pengguna awal, kami telah memvalidasi dan menyempurnakan dukungan untuk skenario berikut.
Aplikasi mandiri yang terhubung
Flutter memungkinkan developer untuk membangun satu aplikasi dari kode yang sama untuk pengalaman seluler dan browser. Journey, salah satu pengguna awal kami, menggunakan Flutter untuk membangun aplikasi di berbagai platform.


Journey, sebuah aplikasi sosial, baru-baru ini meluncurkan aplikasi lintas platform menggunakan Flutter

Luke O'Brien, Pendiri Journey, mengatakan “Empat bulan lalu, saya akan membangun Journey hanya untuk Android untuk MVP. Saya menemukan Flutter dan berpikir, ‘Ini terlalu bagus untuk menjadi kenyataan’, tetapi memutuskan untuk menjalankannya. Itu adalah keputusan terbaik yang pernah saya buat sampai saat ini. Flutter memangkas waktu pengembangan hingga separuhnya (bahkan mungkin lebih dari itu) dan sekarang kami telah meluncur di Android, iOS, dan web — menggandakan potensi pertumbuhan pengguna. Sulit untuk melebih-lebihkan dampak Flutter dalam mengubah visi saya menjadi kenyataan.’

 Konten interaktif sematan
Salah satu skenario adalah menyematkan aplikasi mini yang kaya dan data-sentris di dalam situs induk; Anda tidak memerlukan layanan navigasi atau fungsionalitas seperti-aplikasi lainnya. Menyematkan konfigurator mobil baru, teka-teki silang, atau visualisasi data interaktif ke situs web yang sudah ada hanyalah beberapa contoh kunci yang sesuai dengan skenario ini. Pengguna awal showcase chatbots AEI Studio menyematkan Flutter dalam dialog chat web mereka yang menampilkan animasi, input teks dengan keyboard, dan lainnya.


Weatherbot adalah salah satu chatbots AEI Studio yang menyematkan Flutter dalam dialog chat web mereka


 Aplikasi yang ringan
Meskipun runtime seluler khusus Flutter masih bisa memberikan pengalaman yang lancar saat ini, terkadang friksi penginstalan aplikasi menghambat pengguna untuk memulai. Aplikasi Flutter saat ini yang memiliki pengalaman web ringan memberikan perusahaan yang terbaik dari keduanya. Meskipun konsumsi utama aplikasi tetap ada di seluler, aplikasi web yang ringan bisa memberikan pengalaman yang kaya dan lebih sedikit fitur dengan fungsionalitas yang bertalian menggunakan fitur, framework, komponen UI, dan logika bisnis yang sama.

 Aplikasi pendamping
Aplikasi pendamping adalah pengalaman web yang dibuat menggunakan Flutter untuk mendukung aplikasi seluler konsumsi utama Anda. Misalnya, menggunakan Flutter untuk membangun aplikasi web yang memungkinkan admin atau pengguna internal untuk membuat konten atau mengelola backend bagi aplikasi seluler Flutter Anda. Meskipun aplikasi web ini dianggap sebagai pengalaman yang terpisah, aplikasi ini bisa memanfaatkan banyak kode yang sama dari aplikasi seluler.
Plugin ada di sini!
Flutter memiliki konsep plugin, yang memungkinkan Anda berbicara dengan library native untuk platform yang Anda jalankan. Saat Anda menjalankan aplikasi Flutter di web, Anda bisa mendapatkan akses penuh ke semua library JS. Kami mengerjakan semua kode JS-interop di belakang layar sehingga semua plugin bisa berfungsi seperti yang Anda harapkan baik di seluler maupun web. Kami telah mengimplementasikan beberapa plugin yang paling banyak diminta sehingga mereka dapat bekerja secara konsisten di seluruh aplikasi web dan native. Sekarang, Anda juga bisa menulis plugin sendiri seperti yang dilakukan Ben Hagan untuk video_player, dan Hadrien Lejard untuk paket sentry. Paket-paket berikut ini telah diupdate:
Kami juga menambahkan pemberian tag platform dan pemfilteran pada repositori paket pub.dev.
Pertama, pada halaman detail paket, kami mendaftar platform yang didukung paket. Proses ini mempermudah identifikasi bila suatu paket memiliki dukungan web.


Halaman detail paket pub.dev menampilkan SDK dan tag kompatibilitas platform

UI penelusuran juga memiliki filter baru, sehingga Anda bisa menemukan paket yang memiliki dukungan web. Ini didasarkan pada tag manifes platform baru yang sekarang tersedia di Flutter 1.12.


UI penelusuran pub.dev menunjukkan SDK dan dukungan filter platform

Jalan menuju versi stabil
Kami membuat banyak kemajuan dengan versi beta, tetapi masih banyak pekerjaan yang harus dilakukan. Pekerjaan kinerja kami belum lengkap dan kami sedang berupaya memperluas cakupan kami untuk aksesibilitas, kompatibilitas browser, dan yang lain.

 Aksesibilitas
Kami memiliki dukungan aksesibilitas di browser seluler melalui TalkBack di Android dan VoiceOver di iOS. Beberapa fitur yang sudah diimplementasikan untuk teknologi bantu lintas platform termasuk hal-hal seperti UI traversal dan traversal order, tanda interaksi UI seperti bisa di-tap, label, dapat diedit, inkremental, gambar, live-region, dan dapat diperiksa. Dan, kami sedang berupaya menambahkan dukungan pembaca layar untuk browser web desktop.

 Dukungan browser
Seiring dengan Flutter yang terus berevolusi dari framework khusus seluler kemudian juga mencakup idiom ux desktop, dukungan Flutter untuk browser web desktop akan meningkat dan terasa lebih mulus. Kami berencana untuk mendukung dan mengujinya untuk Chrome, Edge, Firefox, dan Safari di browser desktop dan seluler.

 Cakupan pengujian
Sejak pratinjau, kami meningkatkan cakupan pengujian kami baik pada framework maupun mesin web Flutter. Sampai hari ini, kami menjalankan pengujian otomatis di Chrome, dan mengujinya secara manual di Safari. Masih banyak pekerjaan pengujian yang harus dilakukan, dan regresi dapat muncul dalam skenario yang belum diuji.
Cobalah dukungan web Flutter, berkontribusi, dan bagikan!
Sekarang adalah waktu yang tepat untuk mencoba dukungan web Flutter! Buka flutter.dev/web untuk memulai, dan temukan contoh, dokumentasi, dan lainnya. Jika Anda sudah bereksperimen dengan dukungan web Flutter, Anda bisa beralih ke saluran beta.
Ada lebih dari 1800 plugin Flutter saat ini; tetapi, sebagian besar untuk iOS atau Android. Anda bisa membantu menjembatani kesenjangan antara seluler dan web dengan menambahkan dukungan web ke plugin yang sudah ada atau dengan membuat plugin sendiri. Untuk membantu memandu Anda, kami menerbitkan artikel tentang cara menulis plugin web.
Penutup
Kami berharap Anda senang dengan dukungan web Flutter yang masuk ke saluran beta, dan merasakan komitmen kami seiring dengan proses yang semakin dekat dengan rilis dukungan web berkualitas-produksi.
Kami menyambut baik semua masukan, dan berharap Anda membagikan apa yang sedang Anda kerjakan menggunakan #Flutter. Kami benar-benar senang bisa melihat Anda menggunakan Flutter untuk membangun pengalaman web interaktif yang indah!
Labels: ,


Stackdriver Logging, bagian dari set fitur manajemen operasi kami di Google Cloud, dirancang untuk mengelola dan menganalisis log untuk membantu Anda memecahkan masalah lingkungan hybrid cloud dan mendapatkan insight dari aplikasi Anda. Namun banyaknya volume data yang dihasilkan mesin bisa menimbulkan tantangan saat menelusuri semua log.
Setelah bekerja dengan pengguna Stackdriver Logging selama bertahun-tahun, kami telah mengidentifikasi cara termudah dan praktik terbaik untuk mendapatkan nilai yang dibutuhkan dari log Anda. Kami telah mengumpulkan tips favorit untuk menganalisis log dengan lebih efektif dan pemecahan masalah yang cepat, termasuk beberapa fitur baru untuk membantu Anda dengan cepat dan mudah mendapatkan nilai dari log: penelusuran tersimpan, library kueri, dukungan untuk tabel partisi saat mengekspor log ke BigQuery, dan lainnya.

1. Manfaatkan bahasa kueri lanjutan

Mode dasar default untuk menelusuri log Stackdriver adalah menggunakan menu drop-down untuk memilih sumber daya, log, atau tingkat keparahan. Meskipun ini sangat memudahkan Anda untuk memulai log, sebagian besar pengguna cenderung menggunakan filter lanjutan untuk menanyakan kueri yang lebih kompleks, seperti yang ditunjukkan di sini:
1 advanced query language.png
Beberapa fitur canggih dalam mode kueri lanjutan ini meliputi:
  • Operator perbandingan:
    =           # equal
    !=          # not equal
    > < >= <=   # numeric ordering
    :           # "has" matches any substring in the log entry field
  • Operator Boolean: Secara default, beberapa klausa digabungkan dengan AND, meskipun Anda juga bisa menggunakan OR dan NOT (pastikan untuk menggunakan huruf besar!)
  • Functions: ip_in_net() adalah favorit untuk menganalisis log jaringan, seperti ini:
        ip_in_net(jsonPayload.realClientIP, "10.1.2.0/24")
Tips pro: Sertakan nama log lengkap, rentang waktu, dan kolom lain yang diindeks untuk mempercepat hasil penelusuran Anda. Lihat ini dan tips lainnya untuk mempercepat kinerja.
Library kueri baru: Kami telah menanyai para ahli dari seluruh Google Cloud untuk mengumpulkan beberapa pertanyaan lanjutan yang paling umum menurut kasus penggunaan termasuk Kubernetes, keamanan, dan log jaringan, yang bisa Anda temukan di library kueri contoh dalam dokumentasi kami. Apakah ada hal lain yang ingin Anda lihat? Klik tombol “Send Feedback” di bagian atas halaman Sample Queries dan beri tahu kami.


2. Sesuaikan hasil penelusuran Anda

Sering kali ada kolom tertentu yang terkubur dalam entri log yang menarik perhatian ketika Anda menganalisis log. Anda bisa menyesuaikan hasil penelusuran untuk menyertakan kolom ini dengan mengklik kolom dan memilih “Add field to summary line.” Anda juga bisa secara manual menambahkan, menghapus, atau mengatur ulang kolom, atau mengaktifkan kontrol yang membatasi lebarnya dalam View Options. Konfigurasi ini bisa secara dramatis mempercepat pemecahan masalah, karena Anda mendapatkan konteks yang diperlukan dalam ringkasan. Lihat contohnya di sini:
2 Customize your search results.png


3. Simpan penelusuran favorit dan hasil penelusuran khusus dalam library penelusuran personal Anda

Kami sering mendengar bahwa Anda menggunakan penelusuran yang sama berulang kali, atau Anda berharap dapat menyimpan konfigurasi kolom khusus untuk melakukan penelusuran di masa mendatang. Jadi, kami baru saja meluncurkan fitur baru yang memungkinkan Anda menyimpan penelusuran, termasuk kolom khusus dalam library Anda sendiri.
3 Save your favorite searches.png
Anda bisa membagikan penelusuran tersimpan dengan pengguna yang memiliki izin pada project Anda dengan mengklik pemilih di sebelah Submit kemudian pilih Preview. Klik link Copy untuk memfilter dan membagikannya dengan tim Anda. Fitur ini sekarang masih dalam versi beta, dan kami akan terus mengerjakan fungsionalitas library kueri untuk membantu Anda menganalisis log dengan cepat.


4. Gunakan metrik berbasis log untuk dasbor dan pemberitahuan

Setelah menguasai kueri lanjutan, Anda bisa membawa analisis Anda ke tingkat selanjutnya dengan pemantauan real-time menggunakan metrik berbasis log. Misalnya, Anda ingin mendapatkan pemberitahuan ketika seseorang memberi akses ke alamat email dari luar organisasi. Anda bisa membuat metrik untuk mencocokkan log audit dari panggilan SetIamPolicy Cloud Resource Manager, di mana anggota yang tidak di bawah domain “my-org.com” diberikan akses, seperti yang ditunjukkan di sini:

  resource.type="project" logName="projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="cloudresourcemanager.googleapis.com"
protoPayload.methodName="SetIamPolicy"
protoPayload.serviceData.policyDelta.bindingDeltas.member:*
(NOT protoPayload.serviceData.policyDelta.bindingDeltas.member:"@my-org.com")
Dengan set filter, cukup klik Create Metric dan berikan nama.
4 Create Metric.png
Untuk menerima pemberitahuan jika log yang cocok datang, pilih Create Alert From Metric dari menu tiga titik di sebelah metrik baru dibuat yang ditetapkan pengguna. Ini akan membuka kebijakan pemberitahuan baru di Stackdriver Monitoring. Ubah agregator menjadi “sum” dan ambang ke 0 untuk “Most recent value” sehingga Anda akan menerima pemberitahuan ketika terdapat log yang cocok. Jangan khawatir jika belum ada data, karena metrik Anda hanya akan menghitung entri log sejak itu dibuat.
5 Create Alert From Metric.png
Selain itu, Anda juga bisa menambahkan alamat email, saluran Slack, SMS, atau nama serta akun PagerDuty, dan menyimpan kebijakan pemberitahuan Anda. Anda juga bisa menambahkan metrik ini ke dasbor bersama dengan metrik sistem dan khusus.


5. Melakukan kueri SQL lebih cepat pada log dalam BigQuery menggunakan tabel terpartisi

Stackdriver Logging mendukung pengiriman log ke BigQuery menggunakan log sink untuk melakukan analytics lanjutan menggunakan SQL atau bergabung dengan sumber data lainnya, seperti Cloud Billing. Kami sudah mendengar dari Anda bahwa menganalisis log selama beberapa hari dalam BigQuery akan lebih mudah jika kami mendukung tabel yang dipartisi. Jadi kami baru-baru ini menambahkan opsi tabel terpartisi yang menyederhanakan kueri SQL pada log dalam BigQuery.

Saat membuat sink untuk mengekspor log ke BigQuery, Anda bisa menggunakan tabel date-sharded atau tabel terpartisi. Pilihan default adalah tabel date-sharded, di mana sufiks _YYYYMMDD ditambahkan ke nama tabel untuk membuat tabel harian berdasarkan stempel waktu pada entri log. Tabel date-sharded memiliki beberapa kelemahan yang bisa menambah ke overhead kueri:
  • Melakukan kueri beberapa hari lebih sulit, karena Anda harus menggunakan operator UNION untuk menyimulasikan partisi.
  • BigQuery harus menyimpan salinan skema dan metadata untuk setiap tabel yang diberi nama tanggal.
  • BigQuery mungkin dibutuhkan untuk memverifikasi izin untuk setiap tabel yang diminta.
Saat membuat Log Sink, Anda sekarang bisa memilih opsi Use Partitioned Tables untuk memanfaatkan tabel terpartisi di BigQuery untuk mengatasi setiap masalah yang berkaitan dengan tabel date-sharded.
6 partitioned tables in BigQuery.png
Log yang di-streaming ke tabel terpartisi menggunakan kolom stempel waktu entri log untuk menulis ke partisi yang tepat. Kueri pada tabel terpartisi waktu-serap seperti itu bisa menentukan filter predikat pada kolom semu _PARTITIONTIME atau _PARTITIONDATE untuk membatasi jumlah log yang dipindai. Anda bisa menentukan rentang tanggal menggunakan filter WHERE, seperti ini:
WHERE _PARTITIONTIME BETWEEN TIMESTAMP("20191101") AND TIMESTAMP("20191105")
Pelajari lebih lanjut tentang kueri tabel terpartisi.
Cari tahu selengkapnya tentang Stackdriver Logging, dan bergabunglah dalam percakapan langsung dengan engineer dan tim manajemen produk kami.