Sudah umum untuk membuka dan menggunakan server web di dalam aplikasi guna menangani fitur-fitur yang mewajibkan nama domain, localStorage, dan sebagainya.
Menurut saya, cara komunikasi web/aplikasi yang umum di aplikasi hibrida adalah melalui API yang disediakan di sisi OS dan browser, yang juga disebut bridge. Menurut saya server web lokal bukan hal yang wajib.
Alasan penggunaan server web lokal di sana jadi masalah, misalnya, karena bisa memungkinkan kerentanan seperti mengakses port localhost dari Chrome mode penyamaran untuk merusak anonimitas pengguna. Kalau teknik seperti ini memang wajib di aplikasi hibrida.. ya aplikasi hibrida harus hilang.
Artikel ini benar-benar sangat bermanfaat. Bukan hanya perlu alat yang kuat, kita juga harus siap membuat alat yang dibutuhkan saat diperlukan. Karena itu, kalau semuanya berjalan dengan baik, manfaat yang didapat juga besar.
Sepertinya di Korea juga situasinya mirip. Dibanding hanya itu, kombinasi jurusan lain + kemampuan coding, seperti biologi + kemampuan coding, rasanya justru akan lebih menguntungkan untuk mencari kerja. Dengan berkembangnya berbagai framework dan cloud, serta munculnya alat LLM, akses ke coding menjadi semakin mudah (seperti dulu dari assembly -> C -> Python), jadi sepertinya untuk bisa masuk ke pasar kerja kita harus bisa melakukan hal lain selain kemampuan coding saja.
Saat membuat skrip sederhana untuk sekali pakai, ini memang jelas berguna. Sangat menghemat waktu
Juga berguna dalam kasus yang perlu diselesaikan tetapi tidak bisa diberi banyak waktu. Namun, untuk saat ini meski umumnya berguna, ini masih belum bisa sepenuhnya menggantikan manusia. Saya tidak tahu akan berkembang sejauh apa ke depannya, tetapi untuk sekarang sebagai asisten, tingkat kegunaannya lumayan bisa dipakai.
Saat kuliah S2, pembimbing saya pernah makan bersama seorang insinyur yang berasal dari Google dan tampaknya mendengar cerita tentang monorepo, lalu mengusulkan agar ke depannya kami juga mengelolanya dengan monorepo. Saya sampai susah payah membujuk beliau agar tidak jadi...
Memang ada banyak kelebihan dari monorepo, tetapi laboratorium kami, karena sifat pekerjaannya, cukup sering harus membagikan hasil kerja kepada orang luar. Kalau kami mengelola hasil kerja dengan monorepo, sepertinya kami akan sangat kesulitan terutama di bagian itu. Kalau multi-repo, kami tinggal mengatur cakupan publikasi untuk tiap hasil kerja.
Menurut saya, kebanyakan kasus orang menderita saat memakai monorepo biasanya karena proyeknya sejak awal sudah dipecah terlalu kecil. Proyek yang sebenarnya cukup satu atau dua malah dipecah jadi sekitar 10, lalu ketika itu disatukan dan dikelola dengan monorepo, akhirnya harus memakai tool pengelolaan monorepo dan kompleksitasnya pun meningkat. Lebih baik proyeknya sendiri langsung digabung menjadi satu atau dua; kalaupun ada lebih dari dua proyek, akan lebih nyaman kalau tidak memakai tool pengelolaan terpisah dan cukup memikirkannya sebagai menaruh semuanya dalam satu repositori dengan direktori yang dipisah.
Sudah umum untuk membuka dan menggunakan server web di dalam aplikasi guna menangani fitur-fitur yang mewajibkan nama domain,
localStorage, dan sebagainya.C: Saya juga bisa DBA+BackEnd+Middle Ware+Linux Engineer+Cloud Architecture, apakah saya boleh ikut?
Saya juga tidak bisa percaya aplikasi Meta, jadi saya tidak memakainya dan sebagai gantinya hanya menggunakannya lewat Chrome di Folder Aman.
Sekitar tahun 2025..
A: Spring, React, Android, iOS naik satu orang
B: Berarti masing-masing satu orang, total empat orang, ya?
A: Kan kubilang naik satu orang
B:
Memangnya manusia tahu apa!
Cari kerja memang brutal. Dari sudut pandang lain, ini juga kondisi yang paling pas untuk bikin layanan solo...
Sudah dibilang jangan lakukan begini, tetap saja ada 1 dari 10 orang yang melakukannya -_-
Terima kasih atas tulisan yang bagus.
Saya juga ingin hidup sebagai pengembang solo seperti ini.
Menurut saya, cara komunikasi web/aplikasi yang umum di aplikasi hibrida adalah melalui API yang disediakan di sisi OS dan browser, yang juga disebut bridge. Menurut saya server web lokal bukan hal yang wajib.
Alasan penggunaan server web lokal di sana jadi masalah, misalnya, karena bisa memungkinkan kerentanan seperti mengakses port localhost dari Chrome mode penyamaran untuk merusak anonimitas pengguna. Kalau teknik seperti ini memang wajib di aplikasi hibrida.. ya aplikasi hibrida harus hilang.
Terima kasih atas tanggapan cepatnya~
Artikel ini benar-benar sangat bermanfaat. Bukan hanya perlu alat yang kuat, kita juga harus siap membuat alat yang dibutuhkan saat diperlukan. Karena itu, kalau semuanya berjalan dengan baik, manfaat yang didapat juga besar.
Sepertinya di Korea juga situasinya mirip. Dibanding hanya itu, kombinasi jurusan lain + kemampuan coding, seperti biologi + kemampuan coding, rasanya justru akan lebih menguntungkan untuk mencari kerja. Dengan berkembangnya berbagai framework dan cloud, serta munculnya alat LLM, akses ke coding menjadi semakin mudah (seperti dulu dari assembly -> C -> Python), jadi sepertinya untuk bisa masuk ke pasar kerja kita harus bisa melakukan hal lain selain kemampuan coding saja.
Saya memberikan tepuk tangan!
Saat membuat skrip sederhana untuk sekali pakai, ini memang jelas berguna. Sangat menghemat waktu
Juga berguna dalam kasus yang perlu diselesaikan tetapi tidak bisa diberi banyak waktu. Namun, untuk saat ini meski umumnya berguna, ini masih belum bisa sepenuhnya menggantikan manusia. Saya tidak tahu akan berkembang sejauh apa ke depannya, tetapi untuk sekarang sebagai asisten, tingkat kegunaannya lumayan bisa dipakai.
Saat kuliah S2, pembimbing saya pernah makan bersama seorang insinyur yang berasal dari Google dan tampaknya mendengar cerita tentang monorepo, lalu mengusulkan agar ke depannya kami juga mengelolanya dengan monorepo. Saya sampai susah payah membujuk beliau agar tidak jadi...
Memang ada banyak kelebihan dari monorepo, tetapi laboratorium kami, karena sifat pekerjaannya, cukup sering harus membagikan hasil kerja kepada orang luar. Kalau kami mengelola hasil kerja dengan monorepo, sepertinya kami akan sangat kesulitan terutama di bagian itu. Kalau multi-repo, kami tinggal mengatur cakupan publikasi untuk tiap hasil kerja.
Tulisan yang bagus ~
Ah, saya sudah menemukan solusinya dengan cara lain. Terima kasih!
Menurut saya, kebanyakan kasus orang menderita saat memakai monorepo biasanya karena proyeknya sejak awal sudah dipecah terlalu kecil. Proyek yang sebenarnya cukup satu atau dua malah dipecah jadi sekitar 10, lalu ketika itu disatukan dan dikelola dengan monorepo, akhirnya harus memakai tool pengelolaan monorepo dan kompleksitasnya pun meningkat. Lebih baik proyeknya sendiri langsung digabung menjadi satu atau dua; kalaupun ada lebih dari dua proyek, akan lebih nyaman kalau tidak memakai tool pengelolaan terpisah dan cukup memikirkannya sebagai menaruh semuanya dalam satu repositori dengan direktori yang dipisah.
Memberi
.topic_contentsmin-width: 0memperbaiki masalahnya.min-widthmemang benar-benar bikin pusing...Mungkin karena ada tabel, tata letak di perangkat seluler jadi rusak.