Ngobrolin Dokumentasi
Ringkasan Episode
Bantu KoreksiEpisode ini membahas pentingnya dokumentasi dalam pengembangan software. Para host berdiskusi tentang berbagai jenis dokumentasi, mulai dari dokumentasi teknis untuk developer hingga dokumentasi untuk onboarding dan hand-over project. Mereka juga membahas tantangan yang dihadapi developer dalam menulis dokumentasi dan bagaimana AI dapat membantu proses ini. Diskusi mencakup best practices untuk membuat dokumentasi yang baik, termasuk pentingnya memasukkan dokumentasi sebagai bagian dari definition of done dalam sprint. Contoh-contoh dokumentasi bagus seperti Astro dan GitLab juga dibahas, serta peran technical writer sebagai profesi khusus dalam membuat dokumentasi berkualitas.
Poin-poin Utama
- •Dokumentasi sering diabaikan oleh developer karena dianggap tugas yang membosankan, padahal sangat penting untuk hand-over dan onboarding
- •AI dapat membantu menulis dokumentasi, tetapi tetap perlu dicek karena bisa menghasilkan informasi yang tidak akurat (halusinasi)
- •Perusahaan remote/distributed seperti GitLab cenderung memiliki dokumentasi yang lebih baik karena budaya menulis yang kuat
- •Dokumentasi sebaiknya dimasukkan ke dalam task list dan definition of done, bukan dikerjakan di akhir project
- •Engineering documentation minimal harus mencakup: setup lokal, tech stack, credential management, dan kontak untuk akses
- •Compliance seperti SOC 2 mewajibkan dokumentasi yang lengkap, terutama untuk enterprise client
- •Technical writer adalah profesi khusus yang fokus pada pembuatan dokumentasi berkualitas tinggi
[Music]
[Telolet]
Halo, halo.
Halo, selamat datang.
Halo, oh udah pake telolet lagi ya?
- Karena kondisi itu. - Telolet, telolet, telolet, telolet, telolet.
- Semangat dong, semangat. - Gimana nih kabar-kabar?
Kabar-kabar, mudah-mudahan baik ya.
Eh, lihat dulu ada timnus. Oh timnus kemarin ya, aman ya.
- Gak ada kemarin. - Aman.
Kali ini internasional breaknya, gak ada yang gemtrop.
Ada sering ya, ini pindah-pindah dual.
Iya, karena kan dia melihat ada ini, ada acara ngobrolin gue, jadi sebaiknya dipindah.
Gak mau bersaing.
- Serah deh. - Siapa yang pindah mereka?
Iya, takut pendengar atau penonton yang nge-bunuh semakin sedikit.
- Oh, bisa, bisa. - Oh, karena kasihan ya.
- Kasihan. - Kasihan, lebih kekasian ya.
Selamat malam Mas Riki, halo-halo.
Iya, aduh. Gimana-gimana? Lagi pada sibuk, capek?
- Capek. - Capek mah.
- Capek ya. - Capek ya gimana lagi.
Kan sudah dibilang, ini kan Q3, Q3 itu adalah Q quarter dimana semua orang.
- Eksekusi. - Eksekusi.
- Eksekusi ya. Oh, pantes kan. - Eksekusi baru, slowing down.
Oh, pantesan banyak ini ya, banyak galian itu ya, galian di jalanan gitu jadi bikin macet ya.
Kalau galian di jalanan itu biasanya dibongkar dulu, nanti yang ngerjain vendor lain yang urusannya.
Bajenya ke capek kan?
Iya, di garing, ke buka lama, loh, kok mana curhat sih.
Eksekusi kan, di eksekusi, nanti Q4 baru planning lagi, ya kan?
Lihat transkrip lengkap (1225 segmen lagi)
Iya, Q4 diplanning bajetnya buat nutuk, terus kerjanya di Q3 tahun depan.
- Aduh, nggak selesai-selesai ya. - Selesaikan sama aku dulu lah, Pak.
Iya, gimana teman-teman yang ada di YouTube dan juga di LinkedIn, kabarnya mudah-mudahan sehat, mudah-mudahan tetap sibuk ya.
Kalau sekarang, untung jaman sekarang kalau sibuk bersyukur ya, masih ada kesibukan.
Masih ada kerjaan.
Masih ada kerjaan, masih diberikan rezeki ya, jadi dinikmati saja.
Berbahagia lah orang sibuk sih.
Ini, Anaknya Prof.
Prof. Wilbur?
Anaknya Profesor, siapa? Profesor.
Esther, Esther.
Oh.
- Iya kan? - Anak kandung atau anak?
Surabaya kan? Kok anak sih?
Anak kuah, anak murid.
Masiswa, masiswanya Esther.
- Oke, oke. - GDG Surabaya, GDG Surabaya.
- Bener kan? - Asik, bener-bener.
Bener ya.
Semoga semuanya sibuk terus, amin.
Semoga semuanya dapat kesibukan lah ya, ada yang dikerjain ya.
Lebih bahaya kalau lagi nggak ada yang dikerjain ya.
Wah itu bahaya, tanda-tanda.
Ngeri.
Ntar jadi pengantara.
Aku masih aman, aman sampai akhir tahun.
Oke.
- Terus bisa napas ya. - Berusaha tau, berusaha tau.
Sampai akhir tahun.
- Sampai akhir tahun ya. - Projeknya aman, aman.
Ya, politik lah, politik.
- Ya, jadi malam ini... - Kalau gitu refaktor aja.
Kodenya direfaktor aja, jadi nggak kelar.
Bilang ini waktu ini kita refaktor.
Jadi tahun depan tuh, eh ternyata yang direfaktor belum kelar.
- Jadi harus diperpanjang. - Perpanjang, tapi nggak digaji.
Re-write semua dari awal pakai RAS.
Pinggal aja, pinggal.
Itu, technical depth, technical depth.
Dikin technical depth.
Jadi nggak bisa dipecat.
Iya.
Harus diutangnya dilunasi dulu.
Pinjol lagi.
Oke.
Sebelum kita ngelantur ke mana-mana ya.
Jadi malam ini, akhirnya setelah sekian lama ditunda ya.
Topik tentang dokumentasi akhirnya muncul juga ya.
Karena kita manfaatin hak veto diketatur.
Iya, diketatur.
Akhirnya kita bahas tentang dokumentasi.
Nah, dokumentasi ini sebenarnya,
sebelum kita bahas tools-nya,
ada banyak tipe kan.
Ada banyak tipe juga scope-nya apa, isinya apa, gitu kan.
Macam-macam ya.
Dan biasanya,
dokumentasi ini adalah
mau buat developer ya.
Paling males ya, nulis dokumentasi.
Kayaknya sekarang udah agak berubah ya dengan adanya AI.
Ya bener gak sih?
Tetep aja, kalau gak ada kewajipannya kayaknya
kayak 9 dari 10 developer gak bakal bikin dokumentasi juga sih.
Termasuk gue, gue belum pernah bikin dokumentasi di kerjaan.
Kecuali end of.
Kayak wrap up suatu project atau prototype,
disuruh bikin, baru bikin.
Kalau yang dengan Sukarela bikin dokumentasi sendiri kayaknya belum pernah ya.
Tapi setidaknya,
kalau pun diwajibkan, eh tolong dong bikinin dokumentasi.
Males-malesan pakai AI lumayan membantu kan.
Dibandingkan dulu yang harus ngetik sendiri.
Membantu, tapi kayak mempecahkan masalah dengan masalah gak sih
kalau misalnya developer-nya malas ngecek lagi.
Nah, AI-nya di awal juga harus dilihat.
Segeras-geras bener, cuma ada nyelit-nyelit halu.
Jadi kayak,
nah sekalinya orang lain, developer lain atau client setelah handover atau apa-apa,
yang dipakai terus kejadian itu yang halu.
Bahaya ya.
Bener juga ya.
Jadi pisau bermata dua ya.
Walaupun kita bisa dibantu,
tapi kita harus lebih teliti untuk ngecekin satu-satu.
Ada satu hal,
kalau di kantor tuh pakai AI, boleh.
Tapi bahasanya gini,
apapun yang tulis AI dan kita sampaikan kembali,
ingat apa yang kita sampaikan itu adalah tanggung jawab kita.
Ownership-nya adalah kita, bukan si AI.
Iya, betul.
Jadi apapun yang kita utarakan, dan itu misalnya hasil dari AI,
kita gak bisa bilang,
"Gua pakai chat GPT, generate ini, hasilnya begini."
Nggak bisa.
Jadi apapun yang kita katakan adalah onernya kita,
meskipun pakai chat GPT atau pakai jam AI.
Termasuk juga model kan.
Yang dipayroll kan kita.
Cuma saya berarti kan harus di-enforce ya.
Itu kan kayak kesadaran.
Oke, itu kerjaan kita.
Emang kita pakai tools apapun kan,
bahkan sebelum AI, linter atau autocomplete atau apapun,
itu tools yang membantu kita,
yang jawabnya kita karena yang kerja adalah kita.
Cuma kan sekarang dengan adanya AI, auto-generate docs,
yang kuantitasnya besar banget,
kualitasnya entah, berarti kan kayak harus ada pipeline
buat ngecek kualitas si dokumentasi itu.
Minta AI yang lain untuk ngecek hasil AI yang lain.
Untuk ngecek AI yang lain.
Agent versus agent.
Ya pokoknya apa yang kita commit, ya baik itu kode, dokumentasi,
atau proposal atau apapun, itu adalah tanggung jawab kita.
Kan kita nggak bisa tiba-tiba nyalahin,
"Wah saya pakai kursor nih, kursornya salah, nggak mungkin kan?"
Itu kan yang salah tetap kita.
Salah mungkin karena kita nggak ngecek.
Bukan mungkin karena kita ngecek,
karena memang nggak ngecek pastinya.
Kalau ngecek, udah pasti nggak salah ya.
Belum tentu juga sih.
Udah ngecek, diperbaiki, terus masih salah, gimana?
Ya berarti kan itu kan kode kita.
Iya, pokoknya itulah tanggung jawab kita.
Kita nggak bisa menyalahkan AI,
walaupun kita bayar AI untuk melakukan sesuatu ya.
Tapi ya seperti itu kan ada di fotonya.
Sama semuanya kayak ini juga sih,
kayak dalam struktur organisasi,
kalau misalnya yang melakukan kesalahan itu anak buah atau tim,
yang salah itu tetap pemimpinnya kok.
Kenapa di-prove?
Kenapa di-prove atau kenapa nggak ada sistem di-check.
Kenapa bisa masuk production, segala macam ya.
Saya pernah kayak sebuah, contohnya news atau media gitu ya.
Meskipun yang nulis jurnalisnya,
tapi kalau itu misalnya defamation gitu ya, kasus.
Yang dituntut itu bukan si penulisnya kok, CEO.
Pemeretnya, CEO-nya atau pemeretnya editorialnya itu yang dituntut.
Maksud penjara ya, kalau menang atau kalau kalah,
yang dituntut ya pemimpin redaksi itu sudah kayak gitu hukumnya.
- Jadi itulah tanggung jawab pemimpin,
makanya pemimpin kan gede gajinya ya.
- Resikonya. - Resikonya juga gede.
Nah makanya kenapa dokumentasi itu penting.
Jadi bisa mengetahui. Atau gini dulu deh,
mau saya cek ombak dulu.
Kalau kalian beli sesuatu nih, beli sesuatu.
- Baca dokumentasi aja. - Beli...
- Beli di Ikea lah, yang standard Ikea lah.
- Handphone, handphone, handphone. - Beli Ikea, beli kulkas.
- Handphone, handphone. - Handphone.
Handphone itu terlalu umum ya. - Nggak pernah baca sih.
- Nggak pernah baca saya juga.
Tapi kalau ya kayak sesuatu barang yang lucu-lucu lah gitu.
Kalian baca nggak sih ini ya instruksi buku manualnya dulu?
- Baca.
- Kalau beli lagu harus baca bukunya, kalau nggak nggak bisa sendiri.
- Iya, perhatikan. - Ikea udah sama kan.
- Ikea udah sama. - Bukan kode, itu kita butuh buku dokumentasi
kalau harus merakit kan. Merakit atau merekomen.
- Elektronik kan pasti disetakkan buku kecil, instruksi manual gitu kan.
- Lebih ke, apa, in practice, lebih ke biar kalau dijual,
apa jual second, harganya bisa lumayan.
- Karena box-nya masih ada. - Dokumentasi masih ada.
- Nggak, nggak dituduh hasil maling.
- Jadi ya itulah gunanya dokumentasi. - Instruksi penggunaan.
- Sebenarnya kalau software itu hanya kita sendiri yang kerjakan,
atau hanya sekumpulan. - Nggak perlu dokumentasi.
- Kayak 3 orang, dokumentasi sih. - Belum perlu.
- Belum perlu, tapi kalau misalnya sudah banyak.
- Tapi kan pengguna dokumentasi kita juga di masa depan.
Kalau 6 bulan lagi kita lupa cara pakainya.
- Ya, justru itu. Kan sering sekali kita mengalami.
- Kita juga bisa jadi pengguna dokumentasi kita sendiri,
walaupun solo project. - Betul, betul.
Kan sering sekali kita mengalami, kita lupa gimana cara melakukan sesuatu,
terus kita googling, terus yang tiba-tiba yang muncul adalah artikel
yang kita buat berapa tahun yang lalu.
- Atau stack overflowing yang pernah kita tanya.
- Sekarang udah jarang ya? Sekarang udah pada tanya L.A.A. ya?
- C.G.P.T. - Atau C.G.P.T. nya
atau Jemenanya mereferensi ke stack overflowing yang pernah kita tanya
beberapa tahun yang lalu. - Iya, bisa jadi juga.
Bisa aja. Mungkin agak berbeda antara yang tadi Ivan sebutkan,
kayak produk-produk hardware kali ya, hardware ya.
Perangkat keras yang barangnya bisa dipegang dan dilihat.
Itu biasanya dokumentasi itu wajib ada.
Walaupun software juga begitu ya, wajib ada.
Tapi kalau yang hardware ini, misalkan kayak tadi
furniture lah atau mainan atau apa yang butuh dirakit,
kalau misalkan kita udah ikutin dokumentasi terus hasilnya Zong,
itu kita bisa minta balik kan atau kita tuntut lah dalam tanda kutip ya.
Pokoknya saya udah ikutin nih, tapi hasilnya begini gitu.
Bisa yang jualan bisa jadi rugi kan,
gara-gara dokumentasinya salah misalkan.
Tapi kalau software harusnya juga begitu.
Cuman pada kenyataannya tidak seperti itu.
- Software itu kan dokumentasi banget diperlukan
kalau misalnya kalau di agensi ya saat mau hand over,
kita harus kasih dokumentasinya.
Atau kalau saat sedang bekerja,
on-boarding, off-boarding, dokumentasi itu penting.
Atau testing, dokumentasi-dokumentasi.
- Ya. - Kalau.
- Nah, makanya. - Nah, lanjut, lanjut, lanjut.
- Kalau dokumentasi. - Oh, lanjut.
- Iya, lanjut. - Iya, maksudnya ada lagi dokumentasi yang lain.
Contohnya PHP doc, JS doc itu kan bisa sudah di-code, bisa di-generate.
Itu lebih cara developer documentation.
Itu aja sih sebenarnya.
Nah, kan sebenarnya dokumentasi itu term yang umum ya.
Term yang umum dan luas banget.
Tapi kalau dokumentasi kode, berarti kan itu implikasinya lah.
Kayak imply kode itu bakal dipakai oleh orang lain.
Atau mungkin dipakai oleh kita di masa depan setelah kita lupa,
kita nulis kode mengkonsumsi lah.
Mengkonsumsi kode itu kode yang ditulis.
Nah, kan makanya itu tadi pas nulis doc,
nulis topic di Google Docs,
jadi dapet ide, mikir.
Ternyata dokumentasi itu macem-macem juga ya.
Kalau kita publish library di NPM yang bisa di-install orang,
itu ada dokumentasinya.
Dan berarti target user-nya kan adalah siapapun yang meng-install library itu.
Either bisa beneran di-push ke public,
atau bisa aja kan itu internal package di-konsumsi teman kerja kita sendiri.
Atau kayak yang Irfan bilang tadi, onboarding junior, koder baru.
Berarti kan dia harus bisa pakainya.
Atau kalau bikin framework, misalnya framework atau meta framework.
Misalnya React, Swelt kan itu ada dokumentasinya juga
buat developer yang bakal pakai kode itu,
yang mengkonsumsi kode itu.
Jadi bukan end user juga kan si developer-nya pakai React,
Swelt buat bikin kode mereka sendiri juga.
Apa lagi meta framework kayak Next.js, Sweltkit.
Ada fitur-fiturnya yang bisa dipakai.
Terus bahasa pun masing-masing bahasa.
Javascript, ECMAScript, yaitu PHP, dan lain-lain.
Ada dokumentasinya juga.
Terus tambah ribet lagi kalau udah service atau product
yang ada unsur kodenya kayak misalnya apalah Wix.
Gue sekebanyakan Wix tadi pas luis contoh.
Itu kan sebetulnya service yang dijual sebagai no code ya.
Apalah drag-and-drop, tapi prakteknya ada ekosistemnya,
ada kayak plugin-pluginnya, dan sebetulnya ada API-nya juga,
ada unsur kodenya.
Jadi dokumentasinya itu gabungan cara pakai Wix
sebagai drag-and-drop with Wix Site Builder,
tapi plus ada fitur-fitur kodingnya.
Ternyata luas banget ya dokumentasi.
Luas, luas.
Kalau kayak service ya tadi yang ekivalen dengan kita beli hardware,
kayak kita beli software, software as a service,
atau software kalau kita beli Windows gitu ya,
dalam kotak CD gitu.
Tapi yang bukan bajakan yang asli itu pasti ada dokumentasinya kan.
Itu wajib, itu wajib.
Mas Risa beli yang mana biasanya?
Saya nggak pakai Windows.
By the time gue pakai Mac OS, udah gratis.
Terus dulu pas masih pakai Windows.
Pernah pakai software resmi nggak ya yang beli pakai CD gitu?
Kayaknya belum pernah ya.
Software yang beli, ya beneran software beli, ya beli lisensi.
Jadi kayak udah software as a service atau beli lisensi,
terus nanti kita install,
terus masukin license code-nya.
Itu pernah beli yang sering lah, enggak sering.
Kalau saya dulu beli sih CD-nya, tapi di gejayan gitu, di Jogja.
Itu dibajakan.
Itu bajakan, Pak.
Eh, masa sih tulisannya ori kok.
Itu kan, FCKGW, FCKGW.
Tulisannya ori.
Sampai apal.
Ini ori nggak, Mas? Ori katanya.
Berarti saya diboongi, saya diboongi berarti.
Belum tahu ya, kalau belum tahu nggak apa-apa ya.
Pampet itu setelah beberapa tahun gitu,
tiba-tiba kayak shooting, langsung tutup semua gitu,
langsung berubah jadi tokoh apa.
Padahal dulu tuh kayak satu jalanan penuh,
kayak CD-CD aneh gitu.
Tiba-tiba langsung berubah.
Jadi kalau di kampus dulu, ya banyak kan,
ya di mana-mana ya, ada di Ratu Plasa,
ada di Banggandua, kalau di Jakarta ya.
Itu software bajakannya dalam bentuk CD itu kita beli kan.
Kita beli satu software atau ada kompilasinya.
Terus saya main-main ke Jogja, bukan beli lagi,
bisa disewa.
Udah banyak kan.
Iya, kalau di Jogja banyakan sewa sih.
Kacau banget.
Iya, kan jadi lebih murah.
Betul.
Terus dia bisa muter-muter terus kan.
Maksudnya, sewa udah banget ini, udah.
Nah, terus itu bisa sewa.
Jaminannya tuh M atau Sim.
Nah, terus kalau tulat, kayak tulat beberapa hari,
ada dendanya kayak tani 100 gitu sehari atau berapa.
Nah, kalau orang-orang yang pas lagi harus balikin,
nggak ada duit buat bayar rendah,
kan malah jadi tambah lama tuh.
Nggak balik-balik.
Tapi kan tinggal kartu mahasiswa, jaminannya kartu mahasiswa tahu.
Di rental A, tinggal KTM.
Terus ilang atau nggak bisa balikin,
pokoknya nggak ada duit bayar rendah.
Terus perlu rental lagi, rental B, tinggal SIM.
Ilang atau nggak bisa bayar rendah lagi, jadi nggak bawa KTM, nggak bawa SIM, kemana-mana.
Tolong teman-teman yang nonton jangan ditiru ya,
karena jaman dulu.
Udah nggak bisa ditiru, udah nggak ada lagi.
Sudah nggak ada lagi.
Jadi ceritanya cerita masa lalu kok.
Tempatnya udah berbeda.
Pekosistemnya udah berbeda kan.
Tapi kan sudah berbeda kasus.
Iya.
Nggak, cuma mengingatkan bahwa
kalau dulu kita mau beli yang resmi pun nggak bisa.
Satu, mahal.
Kedua, dimana belinya?
Nggak ada.
Nggak nyampe kayak Indonesia belum nyampe.
Yang resmi-resmi, gitu.
Iya.
Hanya yang bisa beli software asli itu ya perusahaan-perusahaan.
Kalau nggak, kalau dulu yang,
kalau kasus, kalau OS,
bisa beli resmi itu kalau kayak misalnya beli...
Dari kampus?
Bukan kampus, atau di toko komputer.
Maksudnya toko komputer ada yang emang include Windows resmi,
license resmi, itu harganya lebih mahal.
Tapi kadang toko yang sama juga nawarin,
dijual dengan Linux doang nih.
Tapi sambil diinstallin bajakan,
lebih murah, ya terserah, terserah.
Itu kan pilihan untuk beli ya.
Kalau misalnya orang yang kantoran atau apalah,
mungkin orang yang teladan banget,
nggak mau pakai produk inegal,
mau beli yang apa?
Sama Windows, sama OS resmi ya bisa.
Dia dapat apalah semua dokumennya.
Kalau sekarang mungkin udah nggak ngalamin ya,
udah cendung lebih gampang untuk...
Aksesibel lah, udah lebih mudah diakses,
informasi udah banyak,
orang jualan di belahan dunia sana kita bisa beli, gitu ya.
Paling sekarang mentok-mentoknya itu ya, apa?
Joinan, family plan.
Family plan, ya.
Kriminal itu kan nggak bisa dibasmi ya.
Dimana ada opportunity,
orang pasti manfaatin.
Emang family plan nggak ada resmi ya?
Bukan, family plannya nggak apa-apa,
tapi kan itu dibuat untuk orang yang tinggal di satu rumah.
Beneran, family.
Kalau ini kan dimanfaatin buat patungan
orang yang sebenarnya tinggalnya jauh-jauh.
Bukannya kita semua bersaudara dari jaman Mabi Adam gitu.
Bukan berkeluarga.
Bukan berkeluarga.
Bukan berkeluarga, persaudara.
Contoh, persaudara yang di-abuse.
Kursor.
Kursor aja di-abuse kan, abis itu dijual.
Iya, dijual.
Kan jadi di-markup.
Kan jadi murah banget tuh kalau yang family plan yang ya berapa sih, gitu.
Nah, terus dijual di-markup.
Iya, kursor.
Mengaku anak kampus, gitu kan.
Akhirnya di-ban Indonesia sempat di-ban, kan.
Masa.
Ada sih.
Ada juga joki Google One yang jualan Google One.
Enggak tahu gimana caranya.
Ada free buat student ya setahun.
Nah, gitu kita tinggal kasih.
Tapi harus email baru.
Entah gimana di gafetarin sebagai ada email student-nya.
Enggak tahu.
Enggak beli soalnya.
Oke, kita udah melenceng kemana-mana.
Ada dari temen-temen ada contoh dokumentasi yang baik dan benar gak?
Menurut temen-temen.
Yang pernah dibaca, pernah dilihat, itu.
Kalau saya.
Kalau saya yang paling legendaris ya.
Salah satu dokumentasi yang legendaris adalah Stripe.
Dokumentasinya Stripe.
Korteks.
Ini.
Korteks apa ini?
Korteks kan dokumentasinya bagus.
Oh saya gak tahu, gak lihat dokumentasinya.
Stripe adalah salah satu dokumentasi yang jadi panutan.
Yang jadi referensi banyak dokumentasi yang lain.
MDN?
MDN, iya MDN.
Misalkan apa ya?
Satu bersatulah dilihatnya.
Ini Stripe kan produknya banyak ya.
Berarti.
Biasanya tuh ada API ya.
API.
Nah ada contohnya di sebelah kanan tuh biasanya ada contohnya kalau gak salah.
Kalau masuk dipakai kita masukin API.
Ya kayak gini, terus nanti returnnya apa.
Bagus lah.
Salah satu yang terbaik lah.
Ini kayaknya pattern, salah satu pattern yang umum ya.
Kalau buat produk yang punya API, punya SDK.
Spotify juga kurang lebih kayak gini sih.
Kayak gitu.
Spotify SDK.
Oh iya.
Developer.spotify.com
Developer.spotify.com
Kayaknya banyak dokumentasi yang bagus sekarang.
Ya sekarang udah sangat bagus.
Coba yang web API.
WordPress bagus.
WordPress bagus.
React juga bagus.
Nah dokumentasi sendiri ada macem-macem ya.
Jadi ada Getting Started.
Ada konsep kayak filosofinya.
Ada tutorial.
Ada how to.
Itu berbeda-beda.
Dan biasanya kalau dokumentasi umumnya tuh dipisah antara yang...
Kalau gue sih, gue gak tau nih ada nama resminya atau enggak, gue bilangnya natural language, bahasa manusia, sama API reference-nya.
Kalau API reference-nya sih emang istilahnya selalu reference sih.
Kayak yang di Spotify itu yang di kiri-bawah reference gitu.
Ya reference ya bener-bener.
Kayak album data structure-nya apa, metode-nya apa, yang ya gitu lah.
Konya teknis. Nah kalau yang di atas tuh kan ada overview, Getting Started, Konsep itu kan kayak lebih ke sisi manusianya lah.
Nah natural language-nya lah, gak tau itu istilahnya apa.
Tapi itu kayaknya pola yang umum deh.
Umum ya, umum, betul-betul.
Jadi ada how to, how to itu bagaimana kita melakukan sesuatu.
Jadi bukan urutan.
Kalau tutorial kan urutan.
Dari awal mulai sampai akhir diikutin gitu kan.
Konsep itu ya...
Kalau how to itu kadang terlalu banyak namanya recipe kalau how to.
Iya, recipe, bener, recipe.
Keren lihatnya.
Ya, dan terakhir ada reference.
Biasanya itu, ya...
Kalau reference ya kode-nya beneran, apa?
Bureau kayak data-nya, bentuknya gimana, model-nya gimana, metode-nya apa aja.
Iya.
Apa? WordPress ya?
WordPress.
Handbook.
Handbook ya?
Iya.
Ini, team, handbook.
Developer.Wordpress.org.
Di situ ada theme, ada macem-macem.
Iya.
Book editor, themes, plugins.
Ada API refresh.
API refresh ya, maksudnya ya.
Reference itu kode-nya.
API itu bukan best API ya.
Jadi cuma...
Iya, tolong dibedakan ya.
Tolong dibedakan.
Bukan hanya API.
Kamu harus dibedakan satu episode sendiri deh.
API itu maksudnya mengkomunisikan...
Iya ya, bahas API gitu ya.
Apa itu API?
Belum kan? Belum pernah kan?
Belum, belum, belum, belum.
Karena saya banyak ketemu junior, API-nya apa dan apa.
API-nya apa, maksudnya apa?
API.
Oh, gitu ya.
API itu bukan API.
Tapi kan sebetulnya itu kayak miskom penggunaan istilah aja kan.
Istilah.
Kalau lagi konteksnya ngomongin X, itu berarti API itu dianggap sebagai blablabla.
Tapi kalau misalnya beneran apa lah, yang udah spesifik.
REST API atau GraphQL API.
Ya, kalopun kita cuma ngomongin API.
Ya, bisa dimengerti sebagai itu kayak misalnya apa ya.
Kita lagi pake postman gitu.
Ya, API itu kan berarti REST atau GraphQL atau swap atau semacamnya.
Nah, itu kelihatannya perlu dibahas deh.
Ya, ya.
Perlu, perlu.
Udah dicatat.
Oke.
Oh, itu tuh kayak semacam client sama server gak sih?
Orang bilang client itu kan bisa macam-macam ya.
Kalau orang front-end yang bilang client adalah browser kan.
Kalau misalnya apa kode server site, ya itu udah gak dianggap client.
Client site itu beneran yang di browser web API.
Tapi kalau kita lagi mengkonsum, ya itu mengkonsum service misalnya REST API.
Client itu kan ya bisa aja server site yang mengkonsumsi si REST API itu.
Nah, itu juga menarik.
Ya, gitu.
Dokumentasi.
Ya.
Setiap kali ada ini.
Kenapa, Ivan?
Go ahead, sorry lanjut.
Kayaknya setiap perusahaan yang bekerjanya secara terdistribusi atau remote itu biasanya dokumentasi bagus.
Karena mereka habit atau menulis di dalam perusahaan itu diwajibkan dan sangat terlatih gitu.
Contohnya GitLab.
GitLab ini salah satu perusahaan distributed kan, remote gitu kan.
Ini juga dokumentasinya bagus.
Kalau di tempat kerja gue, kan proyeknya macam-macam.
Proyek yang dokumentasinya bagus adalah yang apa, periode kerjanya sedikit cepat.
Maksudnya dan bakal di hand over.
Jadi di one to one ti dari awal.
Misalnya kerjanya 6 bulan, 3 bulan atau 6 bulan.
Ini beneran harus siap buat di hand over.
Dan gak ada waktu tambahan buat nanti nulis docs.
Jadi setiap, ya sprint lah 2 minggu sekali harus ada docs-nya.
Tapi kalau project yang in house internal, ya udah gimana kalian atur.
Ya kan ada stand up ya.
Ada stand up tiap hari karena timnya kecil.
Ya selalu ketemukan ya udah gimana caranya kalian urus.
Cuma kalau di hand over ke pihak lain ya kan itu beneran harus rapih masing-masing setelah selesai.
Ya kayak nulis, kayak bikin di konfuensinya juga.
Iya itu salah satu tipsnya juga.
Jadi kalau temen-temen mau punya dokumentasi yang bagus,
masukkan ke dalam task list.
Jangan jadi sebagai definition of done-nya udah sama dokumentasi gitu.
Gak cuma sampai softwarenya jadi, testingnya jalan, dan lain-lain gitu.
- Tapi biasanya... - Dipan?
- Biasanya apa? - Bagusnya idealnya sih begitu.
Idealnya. Ya kan kita ngumpulkan idea.
- Kenyataannya di lapangan. - Tapi misalkan sebagai klien,
sebagai klien juga misalkan bisa aja kita bilang kan, "Saya mau deliverable-nya sampai dokumentasi loh.
Kalau dokumentasinya nggak lengkap saya nggak mau bayar."
Biasanya itu udah tersirat, nggak dibilang.
Terus akhirnya kita di diskon-diskon-diskon.
Tapi di akhir project, dokumentasinya mana? Udah siap belum?
Kalau nggak ada dokumentasinya gimana saya bisa kerjain?
Kita harganya sudah di diskon banyak tapi nggak masuk dokumentasinya, nggak bisa.
Biasanya begitu.
- Oh gitu ya, triknya gitu ya. - Sekalah, suka-dukanya.
Konsultan software house.
Cuma kalau kasusnya kayak agensi gitu, software house, end-usernya kan,
ya tergantung end-usernya siapa mungkin, dokumentasinya juga bisa beberapa layer kan.
Kalau yang paling dasar kan cuma kayak hostingnya dimana dan ngakses hostingnya
seperti HWS, GCP, dan lain-lain infrastrukturnya kayak gimana, tech-technya apa.
Terus kalau mau jalanin apa yang di-install.
Cuma kan kodenya sendiri ya bisa aja, nggak didokumentasiin kayak plugin-pluginnya apa juga mungkin nggak kan.
- Cuma kayak backup, infra. - Getting static itu nggak ada sih sebenarnya.
Kalau tempat saya yang wajib itu kan meskipun nggak diminta klien atau gimana,
untuk kita sendiri biasanya langsung setup engineering documentation.
Jadi engineering apa, dokumentasi yang kita ini,
ya hal-hal yang krusial, misalnya onboarding deh paling utama sih untuk onboarding.
Jadi anggap aja kalau misalnya ada tim yang baru masuk atau kita mau hand-over
ke tim yang lain, project itu, ya minimal yang baik kalian lihat kan onboarding documentation.
Setupnya gimana, minimum requirement, stack-stacknya apa aja.
Terus situs URL-nya tuh admin-adminnya gimana.
Terus biasanya kan terpisah-pisah tuh ada di One Password.
Untuk semua detail-detail credential API-nya kan ada di One Password.
Terus kemudian cara setup lokalnya, terus GitHub repo-nya dimana,
dan siapa yang harus dihubungi untuk nambahin aksesnya.
Terutama kalau kayak agensi contohnya yang sudah ada, ini apa namanya?
Ada, kok lupa ya, SOC 2 itu apa sih? SOC 2, kayak ada credential-nya gitu.
Standarisasi, standarisasi. Jadi tempat saya itu sudah standarisasi SOC 2.
Sama satu lagi compliance-nya apa lagi, satu lagi yang satu untuk US, satu untuk Eropa.
Saya lupa namanya, satu lagi. Nah itu sudah ada.
Jadi kita policy-nya itu kayak zero trust policy gitu.
Jadi hanya boleh akses yang kita berkepentingan saja di saat kita perlukan.
Dan diberikan akses se-minimum mungkin.
Makanya kalau nggak ada engineering documentation ini, bingung dah tuh.
Kalau misalnya project di hand over ke tim lain, ini gua mau minta akses ke siapa?
Kalau ada di dokumentasi, oke minta aksesnya ke si ini.
Udah, jadi kan hand over-nya ini tinggal kasih kayak dokumentasi, ini baca aja sendiri semua.
Beres deh, nggak perlu banyak tanya.
Apalagi kalau sudah compliance-compliance gitu.
Wah itu memang udah wajib kali ya.
Eh bukan kali, emang udah wajib, titik. - Sudah wajib iya.
Kalau nggak, nggak lewat compliance, nggak cair ya invoice ya.
Kalau untuk urusan enterprise client, pasti kalau kita nggak ada compliance-nya kayak kita SOC2 gitu.
Kalau enterprise client sudah kalau udah nggak ada SOC2-nya, udah pasti nggak lolos di tahap awal.
Udah lolos seleksi untuk ininya, pitching-nya.
Nah ini kita udah ngomongin isinya ya, isi dari dokumentasi, baik itu tipe-tipenya, jenis-jenisnya.
Eh bentar, nanggung satu lagi. - Kenapa?
Gua belum ngomongin, itu dokumentasi yang bagus.
Astro, favorit. - Oh iya, benar Astro.
Contoh, misalnya contohnya. - Astro. Sekarang udah banyak sih ya.
Dan apa namanya, kayak yang menuliskan dokumentasi ini ada namanya technical writer loh.
Jadi memang profesinya khusus. - Profesi khusus ya.
Kalau di Astro ini, ya mungkin di framework lain juga ya.
Cuma kalau yang gue tau dan gue lihat di Astro, emang ada semacam maintainer lah.
Pokoknya yang full, yang di hire buat running, buat ngelid dokumentasi sih.
Ya kalau yang full request dokumentasi, ya bisa siap aja, maksudnya volunteer.
Cuma ada yang in charge, ada yang ngelid kan.
Dan kayak di discord mereka, itu kayak ada satu channelnya sendiri buat docs.
Jadi kayak bener-bener di, apa ya, bener-bener dipikir lah.
DX atau UX. UX buat orang yang membaca docs untuk pakai Astro.
Ya, jadi istilahnya developer experience ya, kalau ini ya, secara umum gitu.
Baik itu penggunaannya, terus juga, apa namanya, car, penggunaan,
maksudnya cara penggunaan dokumentasinya, atau penggunaan tools-nya sendiri.
Itu juga termasuk ke DX-nya. - Sama kayak informasi architecture sih.
Kayak kalau misalnya, ngebagi-baginya gimana, kayak tutorial itu.
Part 1, 2, 3, terus kayak apa lah, konfigurasi, apalagi ini kan agak rumit ya.
Udah meta framework, mereka punya templating language sendiri,
bisa pakai UI library, macem-macem, itu kan ribet banget.
Jadi kayak harus di-mapping dengan rapih, dan itu nggak di delegasi,
nggak cuma pakai AI kayak masukin ke chat GPT nih, bikin dokumentasi untuk library ini,
beneran pakai human gitu, dan yang gue lihat di discord-nya mereka beneran kayak ngebahas,
"Oh, kalau wording-nya begini, atau kalau pembagiannya begini, nanti bisa dikira gini-gini."
"Oh ya, gimana kalau gini, kayak beneran dipikir kayak kita mikir kode, kayak kita mikir architecture kode."
Nah, ini untuk dokumentasinya beneran mereka mikir architecture penyampaian informasi. Gila sih.
- Iya, emang kerjaannya itu kan, si orang-orang yang developer advocate, developer, misalnya,
Evangelist, Defrel, ya itu emang kerjaannya itu kan ya.
Kalau teman-teman ingat di beberapa episode yang lalu ya, yang kita kedatangan 2 Defrel dari Google ya,
itu kan kerjaan mereka ya, bikin tutorial, gimana caranya,
contoh gimana caranya menjelaskan sebuah konsep yang rumit,
tapi bisa dicerna dengan baik buat orang yang mungkin belum pernah tahu.
- Kalau yang pernah ikut acaranya Om Yohan waktu di Jogja, inget nggak yang web Ankov di Jogja?
- Ankov, iya Ankov. - Iya, iya. Di Jogja kan ada kedatangan abang Robert Nieman, sih.
- Robert Naiman. - Iya. Dan dia kan yang nulis web MDN kan zaman dulu, waktu awal karir.
- Oh iya, betul. Dari Mojila, iya dia awalnya Mojila ya. - Iya.
- Oke, sudah untuk dokumentasi-dokumentasi menarik kontennya. Sekarang kita masuk ke tools-nya.
Iya. Kalau di kerjaan, pada pakai apa di kantor? Nggak ada ya, Eka jarang ya?
- Swagger, Swagger. Bukan gue yang bikin sih, yang bikin API-nya pakai Swagger.
- Eka sebagai konsumer yang membaca ya, membaca. Swagger ini tools untuk dokumentasi API reference ya.
Dan lumayan otomatis ya. - Asal dimasukin ke swagger.json ya.
Dia menggenerasi UI dari situ kan. Ada endpoints apa aja, argument-nya apa aja.
Kita bisa masukin kalau butuh out API key, kita masukin API key, bisa langsung di-running.
- Bisa dicoba di situ juga ya, di halaman itu ya. - Iya.
Ada contoh yang ini nggak ya, yang jalan ya? - Baca dokumentasinya Swagger aja itu.
- Oh iya benar juga. - Read the docs.
- Nah itu dia spek-nya kan. - Iya.
- Kok nggak ada ya? Mana ya? Pengen lihat hasilnya ini. Ini, open API specification.
Ini penjelasannya sih. Dia nggak ada yang running. Apa ini?
No bukan. Anyway, ini Swagger juga ya cukup umum ya digunakan.
- Swagger bisa testing kayak postman nggak? Kayaknya nggak ya?
- Bisa. - Oh bisa ya Swagger?
- Bisa jadi server juga ya. Bisa. - Bisa jalanin testing ya?
- Oh ini bentar, ini contohnya Swagger demo-nya, ini nih demo site-nya. Ini paling sering dipakai Pet Store.
- Oh Pet Store. - Pasti sering lihat itu, pasti pernah lihat.
- Bisa ada server-nya ya. Bisa dijalankan server.
- Try out. Execute. ORCC 1. Nah hasilnya ini, jurnalnya.
- Kalian masih pakai ID tuh masih pakai integer nggak sih?
- Nggak pakai UID. - UID lah, hati-hati ya. Karena mudah ditebak ya.
- UID satu, si admin. UID satu.
- Terus misalkan mau post, kita masukin data-datanya juga bisa di sini.
- Kalo kalian punya REST API, kayaknya Swagger atau alternatifnya apa, gue lupa namanya. Kayaknya harus wajib punya.
- Ada yang baru yang kayak alternatif Swagger tapi UA-nya bagus banget.
Cuma itu asal punya ya, berarti asal ada semacam gitu. Lupa namanya apa tapi kayak wow.
- Kalo postman gitu, ini termasuk bagian dari API documentation? Iya ya?
- Bisa juga sih. Karena kita bisa create. Bisa bikin contoh.
- Ya bikin contoh. Terus kayak kan kalo postman ada kayak bisa di-arrange folder-foldernya kan.
Terus bisa dikasih informasi kayak markdown textnya gitu lah. Terus kan sekarang kalo postman,
dia punya service apa sih kayak cloud kan, kayak hosted. Yang ponnya kita bisa publish, terus bisa kita share ke tim member.
Jadi ya sebetulnya kalo... - Funksinya mirip ya funksinya ya.
- Secara funksi ya bisa berfungsi sebagai dokumentasi, walaupun belum tentu semua penggunaan postman
pasti jadi docs. Tapi dokumentasi bisa menggunakan postman.
- Oke. Enaknya kalo misalnya apa namanya, misalnya projeknya di transfer tuh dari agensi sebelumnya.
Ternyata agensi sebelumnya punya kalo bikin REST API documentation dia pake Swagger.
Jadi JSON-nya sudah ada. Jadi tinggal pake JSON definitionnya itu dari Swagger JSON-nya itu tinggal pake di Swagger.
- Karena pake spesifikasi OpenAPI. - Iya, OpenAPI.
- Bagusnya standarisasi. Disitulah pentingnya. Nah, ketemu ntar. Buka deh scalar.com Swagger tapi versi modern.
KUI-nya tuh yang wow. - Tapi gratis juga?
- Nah itu kode, maksudnya apa? Itu bisa ada kode open source-nya, ada github-nya itu.
- Oh iya open source berarti ya? - Kayaknya mereka nyediain, mereka nyediain hosting juga.
Cuma yang nggak usah juga nggak apa-apa. - Iya biasanya gitu ya, nyediakan cloud-nya.
Tapi kalo mau di hosting sendiri ya silahkan. - Ini sama kayak Swagger? Ini sama persis kayak Swagger cuma versi modern aja.
- Versi modernnya ya. - UI-nya ya buat anak-anak siat cn seneng lah.
- Wah ini ada dokusaurus disini. Nanti kita akan omongin tentang gini satu.
- Iya itu ada integrasinya matang-matang. - Alicia JS.
- Eh ada Alicia JS? - Ada. Alicia JS di Indonesia terkenal loh, banyak yang ini.
- Gimana kabar dia sekarang? Balik lagi ke Thailand ya? - Nggak tau ya. Kapan? Bangkok Jazz.
- Tunggu diundang sama. - Tunggu diundang. Free one user, oh ini buat hosting-nya ya.
- Kalo cuma mau pake itunya mah di github-nya aja itu, Google github-nya.
- Footernya lucu banget foto yang bikin ya. Oh dia nyontek ini, nyontek Amazon, amazon.com kan kayak gini kan awalnya.
- Oh iya, si Jeff Bezos. - Yes, Jeff Bezos ya.
- Di garasi ya, dulu tuh kayak bikin... - Wah ini keren ini.
- Ini keren nih. Kalo swagger kan vibe-nya itu vibe Java banget ya, Java.
- Ya sesuai jamannya. - Sesuai jamannya. Warnanya, pemilihan warnanya ya, ya gitu lah ya.
Tapi ya kalo dibilang secara user experience ya oke-oke aja ya. Cuman saya belum pernah sih mencoba ini kayaknya menarik ya.
- Apa tuh, si Scalar.com ya? Aku juga belum pernah sih. - Scalar.com. Belum pernah juga.
- Dia pake OpenMPI juga, jadi harusnya kalo... - Bisa migrasi ya.
- Kalo mau buat dokumen seperti FSD, apakah ada... FSD apa?
- Gak tau. - Fokus, oh bukan fokus.
- FSD apa? Tolong Mas Muhammad Imran, tolong ditulis kepanjangan dari FSD.
Dinya dokumen. - SC itu software.
- SC itu software ya. Yang saya tau, ERD, itu diagram ya. - Itu diagram.
- Tapi dokumentasi juga. - Itu kan bagian dari dokumentasi ya.
- UML, dokumentasi juga kan UML ya. - Modeling language.
- Modeling language, iya. Tapi buat dokumentasi biasanya. - Biasanya untuk mendokumentasi kan, biasanya database ya.
- Functional Specification Document.
- Oh saya biasanya pake Google Doc. - Saya biasanya pake Markdown.
- Aku pake Confuense. - Aku pake Confuense karena emang...
- Emang dari gua juga dari kantor ya. - Emang dari gua juga dari kantor ya.
- Iya emang. - Jadi biasanya gini, di Engineering Doc itu juga ada fungsionalnya.
- Maksudnya ada dokumentasi yang terpisah namanya fungsional juga.
- Tapi cuma saya seumur-umur baru pake Functional Spec Document itu paling dua project.
- Itu pun karena features-nya banyak banget. Nah karena features-nya banyak banget.
- Per feature itu yang akan menjadi satu epic ya. Satu feature akan jadi satu epic.
- Nah di feature-nya itu dijabarkan. Mulai dari overview lah pastinya ya.
- Terus data arkitekturnya, terus kemudian user interaction-nya sekira-kira seperti apa ceritanya.
- Kayak story-nya, kayak gimana cara dia pakai. - User story.
- Iya. - User story. - Kira-kira. Jadi sebelum jadi tiket deh.
- Jadi kan ini epic ya. Jadi satu epic itu satu feature. Nah feature-nya itu dijabarkan panjang gitu.
- Tapi cuma pakenya sekali dua kali. Cuma dua kali kayaknya itu pun di company yang lama.
- Sebentar. Ini berarti kita ngomonginnya design document kan. Dokumen yang kita buat sebelum software-nya jadi.
Sementara selama kita ngomongin tadi, kita ngomongin, ya itu juga semua sebuah dokumentasi sih ya.
- Iya bagian dari dokumentasi dong. - Benar-benar.
- Kalau yang dari tadi kita bicarakan setelah software-nya jadi.
- Setelah software-nya jadi. Untuk menggunakan software-nya. Operasi-nya kan.
- Iya. Ya jadi benar, nggak salah. Itu benar dokumentasi. Tapi mendokumentasikan konsep design yang mau kita buat.
Yang mau kita coding lah. Yang mau kita coding itu kayak gimana sih gambarannya.
- Kayak data flow-nya apa? - Flow-nya. Betul.
- Ya model-modelnya apa? Data structure-nya gimana gitu. - Ya biasanya kalau pakai metode tertentu.
- Ya PRD ya. PRD. - PRD. Ya PRD. Specification. Sekarang kan si AI kan udah mulai itu kan.
- Spec Driven Development. - Yang baru tuh. Spec Kit.
Cuma balik ke pertanyaan tadi kan. Berarti kalau mau buat dokument seperti FSD, apakah ada software-nya?
- Ada. LLM. - Hah? Masa?
- Kayak itu buat bantuin, itu buat asisten. - Iya misalnya kita nge-tickle language.
Tapi maksudnya LLM-nya yang udah di-custom ya. Entah rep atau sistem instruction atau apa.
Ya di-breakdown dengan kayak format-format apa? Itu yang proper kan. Terus kalau kita...
- Tidak kan? Kebanyakan kan? - Bukan. Bukan format text-nya. Tapi maksudnya apa? Kayak pointer-pointernya.
- Kalau FSD misalnya standard-nya. - Pointer-pointernya. Header-headernya.
Harus ada apa gitu kan. Ada bagian-bagiannya kan. Kayak babnya, chapter-chapternya atau apalah.
Nah ya itu tadi software-nya LLM. Tapi kan kita harus ngejelasin juga kan.
Yang tau kan cuma kita. Yang mau bikin planning-nya tuh kayak gimana. Cuma biar format-nya sesuai FSD.
Ya pakai LLM. Gatau. Cuma ada software khususnya atau enggak. Gatau sih. Karena belum pernah.
Kaisa bilang bikin dokumentasinya di isu GitHub sama GitHub Project.
- Itu juga salah satu yang saya komendasikan juga. - Oh ya enak tuh. Wiki.
- Wiki bisa... - Kita wiki. Tapi berbayar ya. Harus berbayar ya kalau nggak salah wiki itu ya.
- Masa? Kalau GitHub Project sih free ko? - Maksudnya itu untuk private repo. Private repo maksudnya.
Kalau GitHub Project itu kayak kan, ya nggak harus kan kan sih. Maksudnya ada kayak format-nya apa tuh kayak waterfall juga bisa.
- Cuma enggak, kayak ada board-board-nya. - Trello lah. Trello. Kayak Trello.
Tapi ada view-nya yang lain. Yang view bisa timeline juga.
Jadi ada ide kita harus bahas project management tools kayak Trello, Asana, Jira, Basecamp.
- Oh banyak ya. - Iya.
- Kalau GitHub Project itu kelebihannya adalah dia bisa connect ke lebih dari satu repo.
Misalnya kita punya, apalah repo-nya kepisah. Kita nggak pakai menu repo nih. Kita punya API, kita punya service lah.
Kita punya service, kita punya front-end-nya macem-macem, dan itu nggak satu repo.
Kita project bisa connect ke itu semua. Terus kayak satu item bisa jadi satu issue. Jadi gampang.
Ya buat project management, kalau emang pakai GitHub, deploy-nya ke GitHub, membantu banget sih.
Terus kalau isunya udah di-close, misalnya udah, udah di-merge, ada pull request.
Ya, issue kan nyambung ke pull request. Kalau pull request-nya udah di-merge, otomatis nge-close issue.
Di project-nya juga jadi di-margin. - Nah, kadang males nggak sih kalau misalnya,
oke ini pertanyaan yang paling sering. Dimana sih dokumentasi harus hidup?
- Kalau di teori, Mas, sedekat mungkin sama. - Sedekat mungkin sama kodil.
- Kalau di teori. - Nah, itu dia.
- Idealnya. - Idealnya begitu. Karena di project, saya ada satu project yang sedang saya inisiatifkan
untuk membiassakan menulis dokumentasi, dan salah satu keputusan dengan teman-teman,
malas banget kayak punya sistem yang berbeda untuk menuliskan dokumentasi.
- Jadi kita... - Harus ada yang enforce. Jadi kayak continually setiap nge-update Twitter,
harus ada tiket lagi satu, dan harus saling ini nggak bakal bisa di-close sebelum tiket itu udah beneran up-to-date atau nggak.
Karena kalau nggak up-to-date, malah bukan memudahkan, bikin sulit, kan?
- Iya, kalau dokumentasi di tempat berbeda, artinya ya proses approval-nya di sana kan beda lagi.
Artinya di sini dan pekerjaan koding dan pekerjaan dokumentasi adalah di dua environment beda, dan itu akibatnya jadi susah.
Nah, ini lagi uji coba, kita lagi uji coba, membuat dokumentasi itu di dalam repository itu sendiri.
Artinya, misalnya ada satu modul per folder ya. Modul itu kan per folder.
- Di dalam folder itu... - Ada readme.md-nya. - Ada readme.md-nya dan ada how-to-nya. Jadi kita buat readme.md sama howto.md.
Jadi kalau ada plugin baru atau ada yang edit plugin itu atau modul itu, dan kira-kira...
Oke, let's say ada penambahan field, dia harus meng-update readme.md-nya dengan howto.md-nya.
Artinya diperbarui. Nah, terus kemudian ada satu sistem saat nge-build, ngambil md-nya itu untuk dibuild jadi markdown.
Jadi satu kayak dokusaurus gitu deh. Nah, tools itu belum ada saat ini. - Nge-build md dibuat jadi markdown. Itu gimana tuh?
- Sorry, maksudnya jadi saat... - Dibuat jadi situs. - Sebenarnya sudah markdown tertulis, tapi kan markdown-nya itu kan belum di-render. Belum jadi HTML, maksudnya, sorry.
- Dibuat jadi front-end. Dibuat jadi front-end. - Jadi ada markdown to HTML conversion-nya untuk ditampilkan.
- Nah, itu tuh solusinya di komen paling bawah, Mas Kaisa. Nah, ya udah, pake GitHub Action, ya nggak harus dokusaurus ya, terserah.
Pake tools apapun yang bisa terima markdown, ya udah, di-copy aja semua. Apa mau saya, ya define file apa aja yang di-copy, masukin, terus build reposan dunia.
- Nah, pertanyaannya si dokusaurus, ini saya belum jadi, karena baru selesai ngobrol sih seminggu lalu. Bisa nggak sih dokusaurus itu kayak langsung membuat seksyen-seksyennya dan ngambil source-nya itu dari...
Kan dokusaurus kan akan ada di dalam repo, tapi di, mungkin di root folder yang terpisah gitu ya. Nah, coba kau masuk ke docs gitu, contohnya.
- Docs. - Atau try demo atau gimana lah? Nah, kan ada Getting Started. Let's say kita, hanya saya nggak pake Getting Started atau apa, karena Getting Started ini markdown-nya terpisah sendiri deh.
Yang saya butuh itu adalah how-to-nya dari tiap modul itu, degenerate mungkin di dalam guides gitu ya. Ada modul A, modul B, modul C, modul D gitu.
Nah, kontennya itu ngambil dari folder yang terpisah, jauh gitu ke dalam-dalam modul.
Dokusaurus kayak Nxt.js ya? Per entity sendiri. Routing-nya file structure-nya.
Jadi sepertinya, contohnya dokumentasi react deh. - Oh itu pakai dokusaurus ya? - Pastinya. Karena sama-sama Facebook meta ya.
- Oh iya ya, dokusaurus punya meta ya? - Iya. Mereka bikin dokusaurus untuk men-support si react-nya, dokumentasi react-nya.
Kita contohnya ini ya. Duh, kok kesini? Apa ini? Release. Kok release? - Klik kode, code, packages kali ya? Nggak tahu.
- Oh mono-repo ya? - Ada docs nggak? - Coba di dalam react-dom ya. Ada docs nggak?
- React-dom. - Coba berburu react-doc.
Ada rygmy doang, rygmy buat Github. - Mungkin nge-repo terpisah. - Docs, script. Gimana ya? Tapi ini ada, oh ini react-nya ya. Salah, salah, sorry.
- Yang-yang nggak open source docs-nya. Nggak mungkin ya? - Open, kan ada itu, translator. Kita kan udah ada episode translate react kan.
- Oh liat aja disitu. - Gua dulu pertama kali contribute open source itu translation react-dom.
- Itu docs contributor tuh dibawah tuh. - Huh? - Docs contributor paling bawah. - Oh docs contributor.
Ada Mas Liza nggak situ? - Nggak ada. - Oh nggak ada. - Nggak ada. - Nggak ada. - Ngarap deh.
- Translation tuh ada translation. Next translation. - Translation. Nah kalau di Indonesia-nya mungkin masih, kemungkinan masih ada.
- Ada tuh. - Lali-nya kedokumentasinya ya. Lali-nya kedokumentasi. Contribute. Nah ini.
Ini dia. Kan? Terpisah kan? Ini adalah docusaurus harusnya, coba kita lihat di package. Dokusaurus. Mana? Nggak ada ya? - Docsets.
- Docsaurus. Nggak ada. - Kayaknya nggak open source ya. - Nggak pake docusaurus. - Namanya docsets. - Huh? Docsars.
- Entah sih tadi ada, ada tulisannya docs. - Docs. Mana docs? - Di package-nya. - Oh bentar.
Docs website-nya tuh ini, bentar. Udah ketemu github.com/reactjs/react.dev.
Kepisah. Ini repo yang berbeda jadi nggak otomatis. Apa kita kontribusi translation di situ, tapi mungkin di-compile. - Oh di-compile lagi ya.
- Ini pakai next.js? - Iya. - Oh bukan docusaurus ya? - Bukan. - Wah aku kecewa. - Tertipu. - Tertipu ya. Apa yang docusaurus?
- Nggak tahu. - Tadi aja tanya docusaurus. Tanya sih docusaurus-nya siapa ini-nya. Siapa klien-nya. Siapa yang pake gitu. - Ada tanya apa, use by, blablabla.
- Banyak kayaknya use by-nya. - Banyak. Cuma mungkin bukan read. - Terus? Mana dia? - Supabase. Nah supabase tuh supabase. Supabase.
- Supabase. - Coba buka supabase. - Supabase supabase supabase. - Docs. Ini udah banget ya. - Keren ya. Sebenernya docusaurus ya. Mau coba ah.
- Maksudnya mau coba seriusin. Dipake di kantor. - Kalau pertanyaan yang tadi. Yang perkara bisa nggak ngambil file markdown di lokasi sembarang tapi direpo yang sama.
Itu solusinya sih salah satu. Salah satunya si starlight-nya Astro. Jadi starlight itu. Jadi mereka tuh dogfooding lah. Menggunakan produknya sendiri.
Kan tadi kita udah bahas tuh. Astro bikin docs-nya niat. Astro bikin tim maintainer Astro. Bikin dokumentasi Astro.
Pakai Astro. Nah tapi pakai Astro itu kan heavily modified ya. Dikasih ini itu. Maksudnya biar bisa ada sidebar-nya yang tadi.
Sidebar lah. Terus fitur-fitur apa. Bisa pakai MDX. Bisa pakai markdown. Nah jadi mereka bikin plugin khusus. Jadi starlight itu sebetulnya bukan apa ya.
Ya tetap pakai Astro. Cuma plugin khusus yang ngasih macem-macem fitur tambahan yang memudahkan bikin situs dokumentasi.
Jadi kalau misalnya ada orang iseng pengen bikin situs dokumentasi Astro colosan. Astro biasa. Gak pakai starlight. Ya bisa-bisa aja kalau mau.
Tapi kalau pakai starlight tuh kayak udah dimudahkan banget. Jadi gampang banget. Nah hubungannya apa sama pertanyaan yang tadi.
Apa sidebar-nya itu. Jadi itu kan plugin. Jadi emang Astro udah ada ekosistem plugin-nya kan. Nah ini Astro tuh plugin khusus.
Nah sidebar yang di samping itu bisa dikustom kayak misalnya ya bisa auto. Kalau auto tuh kita tinggal mention folder-nya aja.
Maksudnya folder-nya apa. Dia ngambil semua markdown di dalam folder itu. Tapi kalau misalnya kita mau manually misalnya dalam satu folder nih.
Kayak di kanan yang kebuka components, using components, card, link card. Mungkin kan kita punya sebetulnya in practice misalnya kita bikin UI component library ya.
Kan kita punya folder cards, link cards, kodenya di dalam situ. Tapi masing-masing ada markdown filenya sendiri.
Itu misalnya kita pengen mengkustom masing-masing halaman di sidebar. Ngambil data source-nya dari file mana juga bisa dikustom.
- Oh gitu. - Iya punya kaya likasnya mas lah.
File 3. Coba coba file 3.
- Mana ini? - File 3 ya.
- Keren, keren. - Oh ya dia udah ngasih component-component yang emang khusus. Maksudnya emang helpful.
Bisa di deploy saat build ya berarti ya?
Nah kalau di deploy itu sih si Starlight-nya sendiri nggak punya opini ya. Dia kan cuma plugin Astro.
Kita mau deploy-nya gimana atau bahkan misalnya yang kaya...
Hasilnya apa? Ini static file hasilnya?
Static site kaya SSG Astro. Jadi ini essentially website Astro aja sih.
Nah kayak kalau strateginya Kaisa tadi kan misalnya kerjanya sebetulnya direpulain.
Tapi misalnya mau publish. Jadi justru sih situs dokumentasinya itu nggak diutakatik secara manual.
Maksudnya nge-pull. Misalnya kalau kaya pake trick yang tadi, berarti pake guitar actions buat nge-copy file-file-nya di pindah di-copy ke situs dokumentasinya.
Atau sebetulnya kalau misalnya cuma tanda kutip bikin misalnya UI component library.
Kalau gue bilang lah jadikan satu repo aja juga bisa kan.
Kan buat publish pasti ada comment sendiri, publish component library-nya.
Nah buat publish dokumentasi, bikin comment sendiri.
Jadi maksudnya kalau emang Greenfield project lah dijadiin satu repo.
Tapi kalau udah tranjur pisah repo ya, tinggal di-copy aja file-nya.
Oh ini nih bagian apa yang tentang kontennya.
Light sidebar at links and link groups.
Oh bisa diatur di ini ya.
Jadi config semua ada config-nya kalau misalnya apa.
Pokoknya lupa sih ini pakai yang mana, yang jelas bisa auto, ngambil dari isi set folder, bisa di-custom.
Menarik, menarik.
Soalnya Astro itu emang kayak docs bikin dokumentasi adalah kayak bagian besar dari kerjaannya mereka.
Bikin docs-nya tuh mereka lihat banget jadi plugin.
Jadi bikin Starlight untuk docs ini juga kayak reflect apa yang mereka kerjain di dokumentasi Astro.
Astro memang bagian dari iman.
Bagian dari kerjaan.
Starlight ya salah satu yang bagus.
Tapi sebenarnya Starlight ini sudah dianggap sebagai plugin buatannya Astro ya berarti ya.
Dulu kan kayaknya buatan komunitas bukan sih?
Enggak sih emang dari awal ya direponya Astro.
Tapi sebelumnya kayak belum bisa di-install lah.
Lebih ke DX-nya belum segampang sekarang.
Ya tapi kan namanya project open source emang komunitas kan bisa contribute.
Tapi yang ngelit tim Astro-nya sendiri.
Starlight ini ya salah satu yang ini.
Dulu saya sebelum tahu ada Starlight saya pakenya kit docs.
Karena dulu kan pakenya spelt ya spelt kit kan.
Kit docs ini juga menarik tapi sayangnya sudah sempat nge-trend.
Sudah nge-trend, sudah nge-dementan lagi, sudah 2 tahun, nganggur.
Dan dulu kayaknya sempat 2-3 tahun lalu lah.
Ada banyak kan dulu storybook masih loaded banget.
Dan semua orang bikin kayak storybook tapi untuk swell.
Storybook untuk view.
Macam-macam bukan cuma kit docs apalagi ya.
Nah ini juga cukup bagus.
Cuman sekarang kayaknya sudah Starlight sudah oke banget.
Gimana coba mau nunjukin apa silahkan.
Iya lagi buka dulu.
Ini ada satu yang menurut saya, kok hilang sih.
Jadi di WordPress itu ada satu project namanya WPCLI.
WordPress command line.
Dan yang kerennya kita lihat sama-sama aja ya.
Share screen.
Ini juga dokumentasi yang unik.
Dan dipaksa untuk dokumen.
Sudah lihat.
- Loading. - Sudah.
- Screenception. - Ini namanya WordPress LI ya tadi ya.
WordPress command line.
Dan dokumentasinya itu tentu ada kayak gini kan.
WP admin, WPC, segala macem nih.
Itu komen-komennya yang list of available comments ya.
Iya terus kalau kita masukin nanti apa global parameternya segala macem dan cara pakenya gimana.
Zoom in by the way.
Contohnya yang paling, ya user deh.
WP user gitu ya WP user.
Dan di dalam WP user kan masih ada banyak user get, user exist, user delete, segala macem, user list.
Nah.
Dan bisa langsung kelihatan apa aja option-optionnya.
Nah sebenarnya yang menariknya dari WPCLI ini.
Kita pun kalau mau extend WPCLI, mau bikin command line-nya kita sendiri, kita dipaksa untuk punya.
Apa namanya punya PHP doc-nya yang sesuai dengan formatnya mereka.
Supaya bisa jalan kodanya kita.
Dan langsung kalau kita WPCLI, misalnya WP user list --help gitu, --min-min-help. Langsung kelihatan.
Langsung muncul.
Sample-sample atau option-option apa yang kita tambahkan di itunya dia.
Di komennya dia.
Itu yang menurut saya desainnya dari yang buat ini.
Keren sih, jadi apa namanya, karena dipaksa jadinya dokumentasi dulu sebelum bisa komennya jalan.
Dan itu perfect banget, karena komen line kan karena text-based.
Jadi ya, di awal suruh masukin apa nama komennya apa, argumentnya apa aja.
Itu kan udah self-contained ya, berarti semacam self-contained.
Kalau ini gak kita buat, ini gak jalan, si komennya gak jalan.
Oh, nice.
Oke.
Kalau CLI, kalau aplikasi terminal itu memang ngedesainnya pakai dokumentasi kayak tadi.
Bikin misalkan CLI --help. Nah itu bikin itunya.
Bikin list of komennya, optionnya, contohnya, sama aja peganti mock-up.
Kalau di screen kan ada screen index, ada detail, ada macem-macem kan.
Kalau di CLI ya karena gak ada GUI, jadi ya desainnya dalam bentuk text tadi.
Jadi dokumentasinya dibuat sebelum kita develop, gitu.
Cuma kalau itu tadi bagusnya, kalau misalnya gak ada dokumentasinya, dia gak mau jalan kan.
Berarti kayak...
Contoh ini kita lihat ya, ini WP create new post, kita cari yang...
WP... Eh, salah.
Kita cari WP post, WP post, WP post.
WP post, kalau create new post itu berarti create. Create, WP post, create.
Nah, lihat, ininya sama kan, kiri dan kanan list-nya, option-nya.
Kita tutup aja ini, kita gedein.
Nah, kiriran kalian ini kan sama persis.
Nah, bahkan page ini pun degenerate dari komen ini.
Jadi beneran kerjanya sekali, terus dipakai buat kode dan buat docs.
Iya. Dan kodenya baru bisa jalan kalau dokumentasinya benar.
Gitu.
Nah, itu salah satunya yang saya suka dengan konsep berpikir si maintainer atau si inventor-nya ini awal-awal.
- Dokumentasi first. - Kayak model semacam pi-doc.
Itu dong, Python documentation. Jadi, sama kayak JS Docs kan yang bisa di-generate sebagai dokumentasi,
terus juga kodenya bisa dijalankan. Benar nggak sih?
Mana ya?
Why Docso? Nggak kelihatan contohnya ya.
Nah, karena saya terinspirasi itulah saya pengen sebenarnya, ya mungkin nggak sampai se-extreme itu.
Karena module nggak seperti CLI ya. Jadi, module itu minimal kode.
Satu bungkus, satu encapsulasi, ya satu kode, satu dalam module, semuanya di situ.
Kode di situ, dokumentasi di situ. Bagaimana ditampilkan, ya itu proses build.
Nah, itulah rencana saya. Dan Starlight ini kemungkinan besar akan saya coba.
Nah, cuma kalau Starlight itu kan tetap terpisah ya, walaupun bisa diakalin.
Kalau yang salah satu, maksudnya apa ya, approach lainnya, ya storybook sih, kalau UI ya.
Kalau storybook kan emang apa paketnya buat UI component.
Beda, cuma maksudnya fungsionalitas tools-nya beda, storybook.
Tapi, approach-nya sama kan, storybook itu, ya kan kita, kapan ya, udah pernah kan episode storybook?
Storybook udah.
Ya, dia nggak bisa.
Kalau misalnya kita pakai type script, definition, interface, terus bahkan argument, masing-masing argument-nya.
Kalau di type script interface-nya kita ngasih description, itu kan otomatis di generate, auto generate tabel component ini.
Property-nya apa aja, itu kan dia otomatis generate tabel itu.
Dan, apa, bisa juga pakai stories dari MDX kan, jadi itu kan kayak maksa.
Ya, walaupun maksanya bukan kayak WPCLI tadi, cuma memudahkan garis miring maksa buat nge-dokumentasiin kode UI component.
Itu approach-nya.
Gak apa-apa sih dipaksa opinionated, saya suka kalau dipaksa oleh opinionated, tapi hasilnya itu keren.
Kalau diikutin jadi keren, nah itu saya suka begitu tuh.
Kayak awesome, kayak awesome list.
Ya kan, itu yang punya awesome list itu ini banget kan.
Saklek banget, kalau nggak sesuai dengan standard awesome list itu, dia nggak akan terima.
Ya, karena kalau itu sih, itu kan sebenarnya free-form content ya.
Kalau nggak ngikut template atau nggak ngikut standard, makin berantakan.
Cuma kalau kayak storybook ini kan nggak bisa di-enforce ya, karena bukan kayak kalau WPCLI bisa dibikin kalau nggak ada itu-nya,
apa, dokumentasinya nggak jalan.
Kalau ini ya harus custom lah, bikin husky atau apa lah, dibikin nggak bisa commit misalnya kalau belum ada storybook MDX-nya.
Cuma yang biasa, ini kan udah difasilitasi untuk itu kayak auto-generate minimal misalnya UI komponen,
property-nya apa aja, optional atau nggak, jenis komponennya, string atau number atau array atau apa,
terus deskripsinya apa, itu kan udah otomatis dibikinin, degenerate tabel dokumentasinya.
Yes, ini lebih ke UI-dokumentasinya, UI-Docs.
Khusus buat UI-dokumentasinya.
Degun dari dokumentasi juga, betul.
Kalau pakai IDE-nya enak, PAP-Docs comment bisa di-collapse, bisa di-tampilkan atau di-hide ya, di-sembunyain ya.
Ya, PAP-Docs, GS-Docs, dan lain-lain ya.
Semua Docs, Docs, Docs.
Apa lagi yang perlu kita bahas? Tutorial Kit, perlu nggak? Tutorial Kit udah pernah sih, tapi ini lebih ke tutorial ya, walaupun.
Gimana caranya supaya semangat nulis dokumentasi dan tetap up to date sih?
Oh iya, sama versening. Versening itu juga susah itu.
Contohnya ya kalau misalnya kita punya, ya ini kalau produk ya.
API versi 1, API versi 2 gitu ya.
Iya, kalau punya produk, contohnya kayaknya React ada deh, React 16, React 17 kan beda tuh ini dokumentasinya.
Iya pasti, pasti beda. Ada yang baru, Laravel, atau apa, itu biasanya dia ada pilihan, loh kok nggak ada?
Coba di DocuSaurus tadi ada. DocuSaurus nih itu, ada Versi-Versi Tanari, ada Archive-nya.
Oh wait, DocuSaurus pake DocuSaurus kan? Jognya nggak?
Nggak.
Iya dong. DocuSaurus pake MSGS.
DocuSaurus, DocuSaurus pake DocuSaurus kan?
Mana Docs? Nggak ada.
Dia pake itu yang.
Website. Docs.
Dia pake website.
Ini MDX semua ya? Docs-nya itu.
Gua bingungnya MDX ini kadang, ya MDX itu.
DocuSaurus dong, ini jalanin DocuSaurus.
Ini script ngapain nih DocuSaurus adalah DocuSaurus?
Itu supaya bisa yang dibawahnya itu loh jalan start DocuSaurus.
Oh oke oke oke.
Oh di Starlight ada plugin-nya.
Starlight juga ada ya versinya ya?
Nggak, by default nggak.
Oh by default nggak ada.
Sejauh ini, cuma ada community plugin-nya.
Oh, ada community plugin, menarik menarik.
Oke.
Seru ya, bahas dokumentasi ya.
Jangan cuma dibahas, tapi dimulai.
Nggak, maksudnya UI ada Docs-nya, API ada Docs-nya.
Terlalu luas ya.
PHP Dokumentor tuh jaman dulu yang saya pake tuh.
Dokumentor.
PHP Dokumentor namanya.
Apa tuh?
Iya untuk nge-generate PHP Doc kita, PHP Doc terus kalau misalnya kita punya kelas-kelas-kelas,
bisa di-generate jadi PHP Doc jaman dulu.
Oh buat nge-extract si PHP Doc-nya ya?
Iya.
Based on kode yang, kode kita kan.
Itu ada PHP Doc belum, oh iya coba.
Iya yang tadi.
Oh gitu, coba components atau documentation.
Nah dokumentasinya dia pakai PHP Doc nggak ya?
Oh nggak ya, beda lain.
Ini bukan, ini bukan documentation.
Hasilnya yang kayak, apa ya, ya kayak masih table-table jaman dulu lah.
Difference.
Nggak modern.
Itu namespace itu, namespace PHP Dokumentor kayak tadi.
Huh?
Namespace?
Baik, baik, baik.
Nah gitu tuh, yang, ya itu, nah iya.
Oh iya.
Udah lumayan.
Rapi.
Sudah rapi ya.
Gimana masanya nggak estetik, kalau PHP interface, emang kayak gitu deh.
Kalau menurut gue sih Laravel salah satu situs dokumentasi yang nggak pernah berubah.
Tapi ya mungkin dibagusin tapi sedikit nggak terlalu signifikan.
Cuma apa ya, helpful sih, gampang nyari informasi.
Yang baca juga developer, nggak perlu cantik-cantik.
Ya tapi kalau yang enak dipandang kan lebih ini ya, estetik.
Bukan, maksudnya kalau, kan beda kan Astro kan yang baca juga developer, yang baca dokumentasi Astro kan.
Cuma maksudnya udah lebih banyak bells and whistles-nya.
Kalau Laravel sih cukup straightforward gitu pokoknya, dari dulu nggak terubah.
Tapi tergantung ini juga, tergantung sama yang bikin tools-nya.
Contohnya kalau Vue.js itu biasanya desainnya bagus-bagus.
Dokumentasi di Vue.js apa ya?
Ada kan yang bagus dia?
Pina apa?
Bukan apa ya?
Nux?
Nux itu kan meta framework-nya.
Coba ya, Vue Documentation.
Vue Press ya?
Vue Press.
Kayak WordPress ya?
Oh belum pernah pakai ya?
Press.
Introduction.
Iya, Vue.js.
Nah ini dokumentasi juga.
Ini ada versinya.
Ini mirip dokusa urus ya style-nya.
Ya, betul, betul.
Benar, benar, benar.
Ini kan Write Documentation Block in Markdown.
Ini punya Vue.js.
Kalau lihat reference-nya, tuh sama kan.
Merip-merip juga tuh.
Itulah.
Kayaknya sudah bikin ini standardnya ya.
Iya, Laravel.
Sama kan, mirip-mirip.
Makin established, kayak PSP, Laravel.
Kalau tiba-tiba style-nya diubah banget, orang malah bingung kan.
Jadi emang, ya maksud saya walaupun mungkin sekarang kayak apa ya.
Orang install pakai PNPM, pakai Yarn, ada tab-tab-nya.
Mungkin ya nambah fitur kayak gitu.
Cuma overall, strukturnya sama tampilannya.
Kayaknya justru yang bagus, yang benar mah gak usah diutak-atik lagi.
Karena orang udah terlalu kebiasa.
Selalu ada topik di sebelah kiri dan topik untuk khusus page ini di sebelah kanan ya.
Itu tipenya tadi sama ya. Starlight, terus ini, ya kan?
Terus tadi Viewpress.
Walaupun kayak udah muscle memory gak sih.
Jadi ekspektasinya kiri itu navigasi halaman, kanan navigasi internal dalam halaman itu.
Internal page.
Topik-topik di page tersebut ya.
Seribunya mirip-mirip aja. Viewpress juga tadi mirip banget sama dokusaurus ya.
Oke, oke. Ada lagi yang mau dibahas?
Apa tuh? Filament, ada komen. Filament pakai Doctum.
Filament pakai Doctum.
Filament kayaknya Laravel ya.
Filament tuh sendiri. Filament gak pakai.
VHP ini. Laravel, Astro, Laravel Development.
Livewire tuh. Livewire berarti Laravel.
Nah, Filament pakai Astro dokumentasinya.
Gak pakai Laravel.
Itu kalau menurut komen paling bawah, di komen paling bawah.
Filament pakai Doctum.
And by the way, Filament ganti pakai Astro.
Itu absurd juga.
Ganti pakai Astro dokumentasinya, jadi dia gak pakai produknya dia sendiri.
Menarik ya. Lucu juga ya.
Oke. Tadi gak kelihatan ya.
Saya share ini tapi gak share screen.
Filament documentation ini.
Ini pakai Astro. Coba apa ya? Action button.
Oh iya tuh, iya kan Filament.
Iya, mirip banget sama.
Oh, jadi dia pakai Starlight ya?
Iya, mungkin.
Wow.
Oh iya, Starlight ini.
Kalau search, bisa search gimana? Coba search.
Pake Algolia.
Pake Algolia standard sih.
Setelah lagi sudah bisa pakai chatbot ini.
Pastinya.
Pasti.
Dari si Starlight-nya.
Itu pattern yang udah mulai umum? Belum ya.
Udah ada sih, kalau di apa?
Ada beberapa.
Itunya Gemini API, misalnya punya Google atau di Cloud API, pokoknya semua produk Google sih udah ada ya.
Kan sebenarnya itu relatif gampang kan? Tinggal konten docs-nya dimasukin ke LLM aja.
Jadi kita bisa nanya pakai natural language ke AI docs itu.
Iya.
Oke, cukup ya, membahas tentang dokumentasi. Tadi kita udah bahas tipe-tipe dokumentasi,
terus bahas tools-nya juga, ada yang dokumentasi dibikin sebelum bikin programnya,
ada yang dibikin setelah, gimana cara nge-enforce, gimana tips supaya dokumentasi tetap up-to-date.
Wait, ada satu yang ketinggalan, terakhir banget ya, nggak usah dibahas panjang-panjang lah.
Ada komunitas-nya dong, aneh banget, berita writethedocs.org.
Komunitas apa?
Komunitas untuk buat dokumentasi.
Sampai ada conference-nya.
Wow.
Iya, dan aktif.
Ada conference-nya.
Aktif.
Wow.
Ada ya, aku nggak tahu.
Menarik ya.
Di Indonesia belum ada ya, belum nyampe ya.
Ada Slack, ada local online, hit-up.
Salah disurvey, tuh, gua total itu, salah disurvey.
Siapa tau gua ganti banting stir, jadi tukang lulus dokumentasi aja.
Cuma ini nanti terlusur sama AI.
Ya gitu, pokoknya udah nggak usah dibahas.
Pokoknya kalau kita tertarik sama komunitasnya ya buka sendiri website-nya.
Oke, sebelum mudahan, seperti biasa, topik minggu depan.
Ayo, ada yang punya ide.
Topik minggu depan.
Kalau tadi saya udah masukin API sama project management tools.
Kita mau sort by.
Kita mau halloween belum ya?
Halloween mau, baru ada satu.
Cerita horor ku.
Cerita horor baru ada satu.
Nanti aja lah.
Jangan lupa ya temen-temen, kalau punya kisah horor.
Kita belum bikin form submit anon ya. Nanti kita masukin di...
Nanti masukin.
Oke, kita bahas apa berarti, dokumentasi sudah...
Beda buku.
Beda buku lagi mau.
Buku apa?
Buku yang ada yang udah submit udah galam.
Buku yang ada yang udah submit udah galam.
Aku belum punya nih bukunya.
Atau buku yang lainnya nggak apa-apa?
Beda bukunya teknis banget.
Engga, itu teknis, cuma maksudnya ringan kok.
Tapi gue baru belajar dikit sih, belum lama beli.
Atau yang lain, hoisting, pure function.
Udah kan ya?
Udah, pure function, hoisting, udah.
Bahas reporting.
Itu belum sih? Oh iya, kita bahas kemarin apa? Carrying.
Carrying.
API versioning.
File upload strategy.
Waduh, banyak amat.
S3 sign url upload file.
JWT. Oh JWT menarik sih.
Bahas tentang JWT.
Token.
Token, ya maksudnya cara.
JSON web token?
Iya JSON web token.
Boleh.
Mau, JWT?
Boleh.
Jawa teks, boleh.
Boleh ya.
Biasanya minggu depan kita bahas.
Itu sign url sekalian deh terus.
Sign url, JWT.
Itu satu topik itu berarti?
Ya bisa.
Sama sekali gue secara ini aja.
Apa namanya?
Communication.
Securing communication.
Sign url upload file.
Komunikasi antar?
System, misalnya dari browser ke server.
Atau dari server to server.
Sign url upload file.
Komunikasi antara client dan server ya.
Securing communication.
Ya autentikasi dan lain-lain ya.
Refresh token.
Ya, tulis aja dulu.
Refresh token.
Apa lagi?
Itu udah jadi satu ya.
Access token, refresh token.
Ya, oke.
Jadi minggu depan kita bahas tentang JWT.
Untuk malam ini.
Kita tutup dulu.
Terima kasih buat semuanya.
Selamat malam.
Selamat istirahat.
Sampai jumpa minggu depan.
Bye bye.
Deskripsi asli dari YouTube
🗣️🕸️ Selasa malam waktunya #ngobrolinWEB! Mari membahas tentang berbagai alat untuk membuat dan menampilkan dokumentasi. Tentu saja bersama Ivan dan Eka. 🔔 Akan mulai mengudara pukul 20:00WIB ya. Yuk mari diramaikan! Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
20 Nov 2024
Ngobrolin Alat Dokumentasi
Episode ini membahas tentang dokumentasi dalam pengembangan software, mulai dari konsep dasar, jenis-jenis dokumentasi, ...
28 Mei 2025
Ngobrolin Google I/O
Episode Ngobrolin WEB ini membahas secara lengkap tentang Google I/O 2025, dengan fokus utama pada berbagai pengumuman t...
4 Des 2024
Persiapan DevFest Surabaya
Episode ini membahas persiapan dan agenda DevFest Surabaya 2024, acara tahunan Google Developer Group (GDG) Surabaya yan...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .