Tambahan dikit buat Horizontal Scaling. Sebenernya selain budget ada constraint lain, yaitu database yang digunakan. Apabila database yang digunakan tidak support horizontal scaling (atau cuma bisa vertical scaling), maka walau discaling sebanyak apapun dari BEnya, tidak akan membantu. Terus berkarya mas eko. Sepuh seperti apapun tetep harus nonton ini, sekedar reminder back to basics.
Terima kasih videonya pak. Dari ulasannya, imho cuma teknik rejection yang termasuk dalam back pressure, yang lain adalah cara menghandle spike, bukan back pressure itu sendiri. Pemahaman saya back pressure adalah teknik memberi sinyal ke client bahwa sistem dalam keadaan sibuk. Contoh lain implementasi back pressure adalah 1) menambah delay virtual untuk mengerem rate request client, 2) memberikan informasi di response ke client supaya client menahan request berikutnya supaya jangan terlalu cepat, 3) memberikan informasi di response client untuk mengulang request ke alamat server lain yang tidak sibuk.
saya cuma bisa ucapin terimakasih banyak pak Eko atas ilmunya,, semoga pak Eko diberi keberkahan umur untuk dapat terus berbagi kepada kami yang fakir ilmu..
Nanya mas. tolong dikoreksi klo salah, sepemahaman saya, thread ini berbanding lurus dengan jumlah core yang kita punya. misalkan, saya punya server dengan 2 cores. klo saya buat 100 thread maka ini justru akan memperlambat performance (karena pembuatan thread itu ada overhead costnya) jadi idealnya, jumlah thread itu relative sama atau sedikit lebih besar dari jumlah core di server. saya sudah tidak pernah bermain thread di level coding (buat thread secara manual), saya prefer pakai high level library/tools yang sudah accomodate management thread di belakang layar(alokasi thread, komunikasi ke thread pool, assignment, dll). alasannya karena saya prefer delegate hal2 seperti ini dari pada kita sebagai engineer yang harus mengerjakan detailnya. contoh, di JAVA saya pernah pakai PCDP library,di .NET ada TPL yang sediakan high level API untuk parallel programming. either ini CPU atau I/O bound works, harusnya teorinya masih sama. Sedikit tambahan dari pengalaman pribadi, jangan blindly increase jumlah thread secara signifikan. baiknya, naikan jumlah thread secara bertahap sedikit demi sedikut. kemudian lihat performancenya. you can thank me later.
kalau nonton sampai habis, dijelaskan juga sama kang eko kalau multi thread ini bukan solusi yang paling ampuh, makanya dijelasinnya bertahap dari yang level 1-5. multi thread, horizontal/verical scale, queue, reject request, baru yang paling ampuh messege broker
tergantung, kalo cpu bound benar, jumlah thread tidak boleh lebih dari cpu, karena percuma, nanti thread nya gak kerja karena rebutan cpu tapi rata2 aplikasi kita jarang cpu bound, kebanyakan io bound, karena cuma tektokan sama database dan betul, jangan seenaknya naikin jumlah thread, karena bisa makan memory terlalu besar
@@jeckyfreaky saya ga bahas soal ampuh ga ampuh, saya bahas konsep parallel programming. engineering solution itu soal trade-off. ga ada itu paling ampuh atau paling bagus.
@@ProgrammerZamanNowklo I/O bound secara teori jumlah thread at most berapa kali jumlah core mas? saya cuma pernah at most 2 kali jumlah cores. klo diatas itu, performancenya relative menurun.
gak ada aturan juga sebenernya, karena kan tetep walaupun iobound, soal speed proses dan logic, balik lagi ke kode kita masing2, jadi mau gak mau harus tetep di perf test tiap ngerubah setting thread nya
Mantap mas, ini ilmu yg advance di jabarin dalam 30 menit, menurut saya solusi paling enak antara scaling klo harus real-time tapi klo bisa async pake message broker
wah udah lama nich pakai queue, reject, tapi baru sekarang tau kalau proses2 itu solusi backpresure( istilah ini baru tahu, hehehe ). Terima kasih ilmunya Pak.
Apakah MBroker mendukung skenario di mana producer membutuhkan respons dari consumer (misalnya, request-response)? Jika ya, bagaimana mekanisme terbaik untuk mengimplementasikannya agar respons dapat diterima dengan andal dan efisien? Apakah ada contoh penggunaan reply-to queue atau pattern lain yang direkomendasikan?
mantap pak echo materinya. Kalo dari sisi aplikasi sudah dibahas mengenai solusi backpressure. Nah kalo dari aplikasi nya kencang tapi database nya yang sekarang lambat atau tidak mampu menyamai kecepatan aplikasi itu bagaimana ya approach solusi nya pak? Nuhun pak🙏
Pak izin , bahas tentang penjualan website freelance yang di jual ulang oleh pembeli , gimana mengatasi itu pak ? Apa aja yg saya harus pelajari juga , terima kasih pak
Mas Eko, thread ini mengunakan paralel kan ya?,di video go coroutines di jelaskan proses i/o bond seperti pengambilan API di database implementasi thread(paralel) tidak terlalu membantu meningkatkan performa, namun dalam penjelasan ini bisa digunakan meningkatkan performa? Kenapa bisa beda ya mas? Apakah setiap thread itu mengabil data/proses i/o secara bersamaan?
Pak bahas database slow query dong, kasusnya di api sudah RTO, tapi mysql masih running query, alhasil request api berikutnya jadi stuck dan lambat. Mohon solusinya
Nice content pak eko 👏👏👏. Terimakasih banyak utk ilmu2 nya slama ini. Sukses selalu buat channel PZN. Anw, izin bertanya. Ada kemungkinan ga ya ketika implementasi message broker, API yang udah di horizontal scale nge consume message/request yang sama ? Misalnya jadi malah ada 2 server API yang nge proses gitu Atau yg kek gini biasa nya udah dihandle oleh message brokernya supaya ga kejadian?
mau tanya, kalo multi thread gitu, apalagi yg sistem update balance / stock. gmn handle ny y? kalo dr database locking, apakah sanggup database handle sebanyak itu request ny? 🤔
Kalau pake message broker atau queue, misalkan request yg masuk banyak pak, client menunggu response dan ternyata timeout yg otomatis http connectionnya closed. Atau misalkan ketika client request dan dimasukkan ke message broker/queuenya kemudian dikasih response dan http connectionnya jg langsung closed. Cara ngasih response hasil processingnya ke client bagaimana pak?
komen pertama,, cihuy,,, mohon bahas antara uuid dengan autoinrement biasa,, apakah id increment bisa menimbulkan masalah,, karena saya ngalamin, sebuah API tidak mau membuat data baru karena dianggap id sudah ada,, padahal blm ada ketika saya cek di database... thx
yg anehnya ketika membuat di level databse,, tapi ga bisa karena dianggap sudah ada oleh orm nya,,, ada solusi kah untuk ini ? atau ada penjelasan kah? thx@@ProgrammerZamanNow
pak eko, sy juga ada project terkait ini, kalo mau bikin testing terkait backpressure itu gmn kang? kemarin trouble ini, akhir nya solusi memang horizontal scalling biar cepet. nah kondisinya sy bingung untuk testing nya. misal mau bikin 100req/second itu gmn cara testing nya kang ?
Thanks pak eko disini dicontohin misalnya server bisa nerima request 100/s dsb, nah bagaimana kita bisa benchmark server kita untuk dapatin nilai tersebut? thanks pak eko
Nice pak eko. Request pak eko, bahas gimana bikin server database yang zero downtime, saat ada insiden misalnya. Pernah denger sekilas tentang replication, clustering, virtualisasi, dan lainnya apalah itu. Terima kasih.
kalau mau database zero downtime ada caranya om, saya rekomen untuk setup Galera MariaDB Cluster. Syaratnya sediain minimal 4 server, satu server untuk reverse proxy, dan 3 server lainnya sebagai node galera cluster. 4 Server itu harus memiliki minimal 4 NIC, satu mengarah ke public, satu mengarah untuk node cluster, jadi cara kerjanya ketika kita mau koneksi ke Database harus melewati Reverse Proxy bisa pakai NGINX atau HAProxy. kalau minimal node bisa baca raft consensus om. Mas eko bisa bahas zero down time dimulai dari raft consensus tersebut mungkin lebih menarik
nambahin pa untuk nodejs ada child process & multi threads(cluster) default nodejs / expressjs running di 1 threads (apapun cpu nya, 1 core = bisa banyak threads (misal cpu intel i3 gen 3 gen 4, 2 core tapi punya 4 threads) multi threads = menggunakan semua threads (gabung threads berdasarkan jumlah threads yng diinginkan) , kurang significant kalo di nodejs , masih lebih bagus semua threadsnya pake child process (latency nya lebih ringan) child process = menggunakan threads berdasarkan yang dipilih (ini setiap threads gak nungguin threads lain, threads 1 gak nungguin threads 2, tapi threads 2 tetep masuk beban nungguin threads 2 kalo ada antrian berlanjut) biasanya saya kalo misal punya core 8 core 16 threads , 4 threads jadi multithreads, 8 threadsnya child process (trs saya buat child processnya ngurut processnya untuk setiap threads process jadi gak dobel request di setiap threads yg sama dalam waktu bersamaan), sisa threadsnya untuk handle vm, promotheus(node exporter,pm2 exporter), jenkins ssh agent, biar gak terlalu berat kalo di NestJs ada adapter (fastfiy) yang bikin lebih cepet juga CMIIW
Setelah menonton ini, merasa senior 📈
Jadi senior enginner dalam 30 menit
@@ProgrammerZamanNowsaya nontonya 2x jadi 15 menit beres 🤣
Gw malah kena Dunning kruger. Langsung merasa bego 😂
padahal masih pemula. tahu tahu udah jadi SENIOR
Pak buat playlist, course atau tutorial yg bahas senior programmer wajib ngerti gini dong pak
Tambahan dikit buat Horizontal Scaling. Sebenernya selain budget ada constraint lain, yaitu database yang digunakan. Apabila database yang digunakan tidak support horizontal scaling (atau cuma bisa vertical scaling), maka walau discaling sebanyak apapun dari BEnya, tidak akan membantu.
Terus berkarya mas eko. Sepuh seperti apapun tetep harus nonton ini, sekedar reminder back to basics.
Terima kasih videonya pak. Dari ulasannya, imho cuma teknik rejection yang termasuk dalam back pressure, yang lain adalah cara menghandle spike, bukan back pressure itu sendiri.
Pemahaman saya back pressure adalah teknik memberi sinyal ke client bahwa sistem dalam keadaan sibuk. Contoh lain implementasi back pressure adalah 1) menambah delay virtual untuk mengerem rate request client, 2) memberikan informasi di response ke client supaya client menahan request berikutnya supaya jangan terlalu cepat, 3) memberikan informasi di response client untuk mengulang request ke alamat server lain yang tidak sibuk.
tul
saya cuma bisa ucapin terimakasih banyak pak Eko atas ilmunya,, semoga pak Eko diberi keberkahan umur untuk dapat terus berbagi kepada kami yang fakir ilmu..
2:55 Mas cara hitung aplikasi kita bisa handle berapa request per second itu gimana ya?
Asyik. saya masih pemula. tahu tahu join di Programmer Zaman Now. udah jadi SENIOR Programmer
Nanya mas. tolong dikoreksi klo salah, sepemahaman saya, thread ini berbanding lurus dengan jumlah core yang kita punya.
misalkan, saya punya server dengan 2 cores. klo saya buat 100 thread maka ini justru akan memperlambat performance (karena pembuatan thread itu ada overhead costnya)
jadi idealnya, jumlah thread itu relative sama atau sedikit lebih besar dari jumlah core di server.
saya sudah tidak pernah bermain thread di level coding (buat thread secara manual), saya prefer pakai high level library/tools yang sudah accomodate management thread di belakang layar(alokasi thread, komunikasi ke thread pool, assignment, dll). alasannya karena saya prefer delegate hal2 seperti ini dari pada kita sebagai engineer yang harus mengerjakan detailnya. contoh, di JAVA saya pernah pakai PCDP library,di .NET ada TPL yang sediakan high level API untuk parallel programming.
either ini CPU atau I/O bound works, harusnya teorinya masih sama.
Sedikit tambahan dari pengalaman pribadi, jangan blindly increase jumlah thread secara signifikan. baiknya, naikan jumlah thread secara bertahap sedikit demi sedikut. kemudian lihat performancenya.
you can thank me later.
kalau nonton sampai habis, dijelaskan juga sama kang eko kalau multi thread ini bukan solusi yang paling ampuh, makanya dijelasinnya bertahap dari yang level 1-5. multi thread, horizontal/verical scale, queue, reject request, baru yang paling ampuh messege broker
tergantung, kalo cpu bound benar, jumlah thread tidak boleh lebih dari cpu, karena percuma, nanti thread nya gak kerja karena rebutan cpu
tapi rata2 aplikasi kita jarang cpu bound, kebanyakan io bound, karena cuma tektokan sama database
dan betul, jangan seenaknya naikin jumlah thread, karena bisa makan memory terlalu besar
@@jeckyfreaky saya ga bahas soal ampuh ga ampuh, saya bahas konsep parallel programming. engineering solution itu soal trade-off. ga ada itu paling ampuh atau paling bagus.
@@ProgrammerZamanNowklo I/O bound secara teori jumlah thread at most berapa kali jumlah core mas? saya cuma pernah at most 2 kali jumlah cores. klo diatas itu, performancenya relative menurun.
gak ada aturan juga sebenernya, karena kan tetep walaupun iobound, soal speed proses dan logic, balik lagi ke kode kita masing2, jadi mau gak mau harus tetep di perf test tiap ngerubah setting thread nya
Konten bagus ngebahas permasalahan2 d lapangan
Mantap mas, ini ilmu yg advance di jabarin dalam 30 menit, menurut saya solusi paling enak antara scaling klo harus real-time tapi klo bisa async pake message broker
Semoga bermanfaat
wah udah lama nich pakai queue, reject, tapi baru sekarang tau kalau proses2 itu solusi backpresure( istilah ini baru tahu, hehehe ).
Terima kasih ilmunya Pak.
Terimakasiah Pak Eko atas ilmu yang diberikan. Sukses dan sehat selalu. 👍👍👍
Yey dibuatin sama puh sepuh
mantap ilmunya pak, load balance di horizontal scaling sih paling enak, dengan manajemen resiko tentunya
Pernah ngalamin di nestjs, dan alhamdulillah solusinya adalah worker_threads dan observable rxjs pustaka yang bener² penolong disaat itu...
Makasih pak Eko, sangat bermanfaat banget ilmunya dan jarang juga yang bahas materi seperti ini
Apakah MBroker mendukung skenario di mana producer membutuhkan respons dari consumer (misalnya, request-response)? Jika ya, bagaimana mekanisme terbaik untuk mengimplementasikannya agar respons dapat diterima dengan andal dan efisien? Apakah ada contoh penggunaan reply-to queue atau pattern lain yang direkomendasikan?
sering seringin bikin materi seperti ini pak eko
pasti
mantap Pak Eko, ini materi yang ditunggu2
terima kasih
mantap pak echo materinya. Kalo dari sisi aplikasi sudah dibahas mengenai solusi backpressure. Nah kalo dari aplikasi nya kencang tapi database nya yang sekarang lambat atau tidak mampu menyamai kecepatan aplikasi itu bagaimana ya approach solusi nya pak? Nuhun pak🙏
Thanks pak materinya!
ilmu mahal ini, mantap
makasih ilmunya sangat luar biasa
Pake reactive sptnya mudah ditangani
Pak izin , bahas tentang penjualan website freelance yang di jual ulang oleh pembeli , gimana mengatasi itu pak ? Apa aja yg saya harus pelajari juga , terima kasih pak
makasi pak
Mantap pak Eko, saya request materi SQLC golang dong pak
Hi Eko, menarik dengan ucapan "abuse" (21.59-22.00) apa itu dan boleh lampirkan referensi tentang pengertiannya?
Mas Eko, thread ini mengunakan paralel kan ya?,di video go coroutines di jelaskan proses i/o bond seperti pengambilan API di database implementasi thread(paralel) tidak terlalu membantu meningkatkan performa, namun dalam penjelasan ini bisa digunakan meningkatkan performa? Kenapa bisa beda ya mas? Apakah setiap thread itu mengabil data/proses i/o secara bersamaan?
kalo backpressure dari sisi databasenya gimana pak eko?
materi keren 👍
Biasanya bottle neck terjadi di akses storage, bisakah mas Eko bahas detail bgmn mengatasi bottle neck di storage/database? terima kasih
Bisa di bikin vlog lagi
the best bener emg sepuh satu ini
boleh dong pak dibahas lebih detail tentang antrian
Hadir nyimak
good jobs senior
Pak bahas database slow query dong, kasusnya di api sudah RTO, tapi mysql masih running query, alhasil request api berikutnya jadi stuck dan lambat. Mohon solusinya
coba solusi pake indexing, bisa juga pake sharding db
@@rezvanfm sudah mas. Indexing optimasi query sudah. Ini emng karena datanya gede aja.
Saya membagikan dengan Vendor IT Website Kereta Cepat Indonesia Cina~
Silahkan
#tanya
nulis2 nya masih di pen tablet ato di magic trackpad pak?
Nice content pak eko 👏👏👏. Terimakasih banyak utk ilmu2 nya slama ini. Sukses selalu buat channel PZN.
Anw, izin bertanya. Ada kemungkinan ga ya ketika implementasi message broker, API yang udah di horizontal scale nge consume message/request yang sama ? Misalnya jadi malah ada 2 server API yang nge proses gitu
Atau yg kek gini biasa nya udah dihandle oleh message brokernya supaya ga kejadian?
kan message queue, ada juga yang namanya consumer group. jdi aman kalo event driven nya bener
Tergantung desain nya. Biasanya Untuk satu message bisa di setting cuma bisa di consume oleh 1 consumer meskipun ada banyak consumer yang running
@@ibanrama hoo gitu. Sip2 thank you mas
@@TukangCodingSukaGaming ho okee deh. Thank you mas
Setupnya mantap sekarang pak.. Buricak burinong..
eplok cendol
Terbaik!
cuman kalau message brocker itu berarti harus selalu sukses ya?
kalau response failnya apa musti di validate dlu kah di applikasi proxynya.
tapi kalo misal horizontal scale, dia kan bisa ada kemungkinan race condition ga ya? kan bisa jadi dia ngproses di waktu yg sama
mau tanya, kalo multi thread gitu, apalagi yg sistem update balance / stock. gmn handle ny y?
kalo dr database locking, apakah sanggup database handle sebanyak itu request ny? 🤔
ada yang namanya optimistic locking
Jangan lupakan tim infra yg pusing melihat metric per apps nya naik turun drastis (naik menjadi hang, turun menjadi down)
1 menit pertama cuman bilang akan jelasin backpressure lompatin aja ke 01:05
bang klo kayak menambah node di swarm atau pods di kubernetes itu termasuk solusi yang mana?
Horizontal scaling
coroutine 🚀
Pak, kapan bikin css? Saya sudah bisa dasar-dasar javascript sama html tapi masih bingung sama css😅
masih dibuat materinya
@@ProgrammerZamanNow Iya, terima kasih Pak Eko🙏😀
bagian message broker mirip kayak mqtt broker ya?
suka banget euy warnanya...
Sehat sehat kang
Trus kalau requestnya direject, response buat clientnya apa pak Eko?
server sedang sibuk
13:56 lo punya uang lo punya solusi ......... uang >>>> genset
Mantap Pak Eko !!!
Kalau pake message broker atau queue, misalkan request yg masuk banyak pak, client menunggu response dan ternyata timeout yg otomatis http connectionnya closed. Atau misalkan ketika client request dan dimasukkan ke message broker/queuenya kemudian dikasih response dan http connectionnya jg langsung closed. Cara ngasih response hasil processingnya ke client bagaimana pak?
seperti di video saya jelaskan, tidak semua bisa pake message broker, case by case, harus nya fire and forget
@@ProgrammerZamanNow kalau dikombinasikan dgn websocket masih bisa ya pak, asal gak direfresh pagenya
👍👍👍
Horizontal scaling kalo cuman nambah vm gitu gimana?
Maaf oot, Pakai touchpad dan keyboard apa pak?
touchpad: nexian-pad
keyboard: yamada
Sekilas lihat kayaknya magic trackpad + magic keyboardnya apple
Pak cara tau rps dari client brp dan rps server kita mampunya brp gimana ya?
lakukan performance test
Kang mau tanya, untui tau kapasitas requests yg bisa di handle app kita itu bagaimana ya?
lakuin performance test dl
komen pertama,, cihuy,,, mohon bahas antara uuid dengan autoinrement biasa,, apakah id increment bisa menimbulkan masalah,, karena saya ngalamin, sebuah API tidak mau membuat data baru karena dianggap id sudah ada,, padahal blm ada ketika saya cek di database... thx
selama yang membuat auto increment nya di level database, gak masalah, kecuali di level aplikasi, itu baru msalah
yg anehnya ketika membuat di level databse,, tapi ga bisa karena dianggap sudah ada oleh orm nya,,, ada solusi kah untuk ini ? atau ada penjelasan kah? thx@@ProgrammerZamanNow
Apakah ini ada hubungannya sama microservice?
ini lebih termasuk ke concurency / thread kl disimpulkan di penjelasannya itu
pak eko, sy juga ada project terkait ini, kalo mau bikin testing terkait backpressure itu gmn kang?
kemarin trouble ini, akhir nya solusi memang horizontal scalling biar cepet. nah kondisinya sy bingung untuk testing nya.
misal mau bikin 100req/second itu gmn cara testing nya kang ?
apache jmeter
jmeter, gatling, vegeta, dan banyak tool untuk performance testing lainnya
@@ProgrammerZamanNow tool jadul pak ribet setup, coba cek k6 dari Grafana
Thanks pak eko
disini dicontohin misalnya server bisa nerima request 100/s dsb, nah bagaimana kita bisa benchmark server kita untuk dapatin nilai tersebut? thanks pak eko
harus di lakukan performance test
test pke k6 bisa
kalau untuk ngetest api yg kita buat sanggup melayani brp request itu pakai apa ya?
jmeter, gatling, vegeta, dan masih banyak yang lainnya
K6
@@ProgrammerZamanNowhoo baru denger semua istilahnya, oke thx pak eko
Absen
Kelas android sampai expert dong pak eko hehe
pertanyaannya... Berapa kali kata gitu ya disebut?
ayo tebak, nanti dapat hadiah
saya masih mahasiswa tapi saya nonton saja
Nice pak eko.
Request pak eko, bahas gimana bikin server database yang zero downtime, saat ada insiden misalnya. Pernah denger sekilas tentang replication, clustering, virtualisasi, dan lainnya apalah itu. Terima kasih.
Noted
Wah menarik ini kayaknya
up up, kebetulan di project skg kadang ngalamin downtime.
kalau mau database zero downtime ada caranya om, saya rekomen untuk setup Galera MariaDB Cluster. Syaratnya sediain minimal 4 server, satu server untuk reverse proxy, dan 3 server lainnya sebagai node galera cluster. 4 Server itu harus memiliki minimal 4 NIC, satu mengarah ke public, satu mengarah untuk node cluster, jadi cara kerjanya ketika kita mau koneksi ke Database harus melewati Reverse Proxy bisa pakai NGINX atau HAProxy.
kalau minimal node bisa baca raft consensus om. Mas eko bisa bahas zero down time dimulai dari raft consensus tersebut mungkin lebih menarik
Mantaps Kang kok suaranya kaya beda ya ? apakah ini kembaran kang ecko?
lagi serak suaranya
sebelum habis nonton, kirain masalah sakit punggung awkaokwaoawk
app juga bisa sakit punggung
nambahin pa untuk nodejs ada child process & multi threads(cluster)
default nodejs / expressjs running di 1 threads (apapun cpu nya, 1 core = bisa banyak threads (misal cpu intel i3 gen 3 gen 4, 2 core tapi punya 4 threads)
multi threads = menggunakan semua threads (gabung threads berdasarkan jumlah threads yng diinginkan) , kurang significant kalo di nodejs , masih lebih bagus semua threadsnya pake child process (latency nya lebih ringan)
child process = menggunakan threads berdasarkan yang dipilih (ini setiap threads gak nungguin threads lain,
threads 1 gak nungguin threads 2, tapi threads 2 tetep masuk beban nungguin threads 2 kalo ada antrian berlanjut)
biasanya saya kalo misal punya core 8 core 16 threads ,
4 threads jadi multithreads, 8 threadsnya child process (trs saya buat child processnya ngurut processnya untuk setiap threads process jadi gak dobel request di setiap threads yg sama dalam waktu bersamaan),
sisa threadsnya untuk handle vm, promotheus(node exporter,pm2 exporter), jenkins ssh agent, biar gak terlalu berat
kalo di NestJs ada adapter (fastfiy) yang bikin lebih cepet juga
CMIIW
Kan bahas end. To. End di wa
bang bikin tutorial OOP Python dong..
ada suara jedug di videonya pak, kayaknya kena benturan tangan ke meja.
kerekam mungkin, kan mic nya diatas tangan
Kalo cara menangani backpain gimana pak eko ?
Beli kursi yg mahal
Queue cukurukuk...
pak eko itu jualan baju kah?
kukira sakit pinggang wkwk
kirain backpressure sakit punggung wkwkwk