Ngobrolin Alat Dokumentasi
Ringkasan Episode
Bantu KoreksiEpisode ini membahas tentang dokumentasi dalam pengembangan software, mulai dari konsep dasar, jenis-jenis dokumentasi, hingga berbagai tools yang dapat digunakan. Diskusi dimulai dengan pengenalan Documentation System yang terdiri dari empat jenis utama: Tutorial (learning-oriented), How-to Guides (problem-solving oriented), Explanation (teoretical/conceptual), dan Reference (API documentation). Episode mengulas berbagai tools populer seperti Docusaurus (React-based), Starlight (Astro-based), Storybook (untuk UI components), Swagger/OpenAPI (untuk API documentation), dan Google Code Lab (untuk step-by-step tutorial). Topik penting yang dibahas meliputi best practice "Docs as Code" di mana dokumentasi ditempatkan dalam reposisi yang sama dengan kode untuk memudahkan tracking, version control, dan code review, serta diskusi tentang bagaimana dokumentasi modern juga perlu dikonsumsi oleh AI tools seperti Cursor dan Copilot.
Poin-poin Utama
- •Documentation System terdiri dari empat jenis: Tutorial (belajar step-by-step), How-to Guides (solusi masalah spesifik), Explanation (konsep/filosofi di balik teknologi), dan Reference (dokumentasi API/sintaks)
- •Docusaurus adalah framework dokumentasi berbasis React yang paling populer (go-to solution) dengan fitur SSG, blog, dan dukungan MDX
- •Starlight adalah template dokumentasi berbasis Astro dengan best practices dari dokumentasi Astro sendiri, mendukung multi-lingual termasuk bahasa Indonesia
- •Storybook adalah tool khusus untuk dokumentasi UI components dengan fitur autodocs, accessibility testing, dan visual testing, mendukung berbagai framework
- •Swagger/OpenAPI Specification adalah standar untuk API documentation yang berfungsi sebagai "kontrak" antara front-end dan back-end developer
- •Best practice "Docs as Code" menyarankan dokumentasi ditempatkan dalam repo yang sama dengan kode untuk tracking, version control, dan menghindari dokumentasi terbengkalai
- •Google Code Lab menawarkan format step-by-step tutorial yang user-friendly untuk workshop, dapat ditulis menggunakan Google Docs dan dikonversi menjadi HTML
- •Dokumentasi modern tidak hanya untuk manusia tetapi juga untuk dikonsumsi oleh AI tools, sehingga struktur heading dan semantic markdown menjadi semakin penting
(musik)
(Tinggalkan ringtone)
Halo-halo, selamat malam.
Weee!
Right on time!
(musik)
Permintaan Irfan kemarin minggu lalu.
Weee!
(tertawa)
Halo, Les.
Pasti Eka ini lagi half time ini ya, makanya.
Saya akan nontonin.
(tertawa)
Kenapa tim Les selalu live hari Selasa gitu ya?
Karena sebenarnya hari Selasa itu udah jatahnya kita.
Ngobrolin web.
Ngobrolin web.
Kenapa tim Les selasa juga?
Bingung ya.
Selalu bentok ya.
Tapi menang ya.
For sementara satu kosong untuk Indonesia ya.
Menang, satu kosong bagus ini.
Satu kosong mainnya bagus.
Tapi Indonesia harus menang sampe akhir masa.
Maksudnya telur pertandingan sisa harus menang.
Maksudnya supaya bisa lolos.
Ya, realistik.
Kelihatannya kayak gimana ya.
Cuma kalau menang.
Lihat transkrip lengkap (2582 segmen lagi)
Agak realistik tapi ya.
Cuma put up some fight lah.
Maksudnya lihat tiket jangan.
Main bagus lah.
Minimal main bagus.
Ya.
Mau menang atau kalah.
Maksudnya kalah terhormat lah ya.
Kalah dengan usaha.
Yes.
Kalaupun gak lolos, tapi ngasih yang terbaik.
Nah.
Hidup Indonesia.
Menang aja.
Sudah ada yang nonton nih Damar.
Kenapa kamera?
Ada apa dengan kamera kita?
Something wrong?
Damar, Damar, Damar, Damar.
Tapi Damar ini apa namanya?
Dia komennya itu jam 19.18.
Sekitar 45 menit lalu.
Engga.
Sebelum mulai, pas baru mulai.
Sebelum live.
Ada apa dengan kamera?
Mohon info, mohon info.
Mungkin gak sengaja masa biasanya nyalain kamera.
Eka nonton gak yang lawan Jepang kemarin?
Engga, gak nonton.
Itu nyebelin banget.
Gak nontonnya gara-gara lagi ada Tim Bimmer lagi.
Rik banget.
Berarti gara-gara Eka gak nonton jadi kan.
Gara-gara Eka gak nonton dia.
Kambing hitam.
Alat dokumentasi maksudnya kamera gitu.
Oh.
Oh iya benar juga ya.
Saya baru nyadar.
Benar, benar, benar.
Engga, engga.
Kan tadinya mau tulis ngobrolin dokumentasi.
Tapi kan sebenarnya kita ngomongin tools kan.
Usia itu kan bahasa Indonesia-nya kan alat.
Jadi saya tambahin alat dokumentasi.
Jadi kalau sedikit salah persepsi mohon maaf ya.
Jadi ya itu dia.
Malam ini kita akan bahas tentang...
Memang musim mangga.
Emang musim mangga?
Minggo sticky rice.
Lagi dimana-mana nih mangga?
Bayang-bayang ya.
Minggo sticky rice ya.
Minggo sticky.
Emang nih Jogja gak ada gitu jualan mangga?
Apa?
Ya ada lah.
Kenapa gak ada mangga?
Sedih banget.
Ivan kan juga dulu laman Jogja kali.
Masa gak ada mangga.
Seumur-umur Jogja gak pernah makan mangga ya.
Eka nya gak ke pasar magu Harjo kali.
Ya ngapain orang tinggalnya dekat pasar banding?
Salah.
Bring Harjo, bring Harjo.
Bring Harjo.
Ya jadi mumpung lagi hal time.
Nonton ngobrol di web dulu.
Nanti kalau udah mulai.
Buka dua-duanya.
Kasih kabar ke kita ya.
Kalau ada gitu ya.
Kita gak boleh buka soalnya.
Komen kunci.
Ya kita gak boleh buka bahaya.
Nanti gak konsen.
Nanti diband.
Nanti diband.
Gak boleh ngobrolin bola.
Oh iya.
Nanti kalau udah 2-0 kabarin ya chat.
Oke.
Oh iya.
Kalau gak 2-0 gak boleh kabarin ya.
Oh gak boleh.
Kita gak mau denger tuh.
Kemarin tuh.
Kita mau denger good news aja.
Pas lawan Jepang kemarin.
Itu lagi tim dinner.
Di suatu restoran.
Cuma bagian dari gedung.
Nah sebenernya tuh teman nomber.
Itu gak enak banget.
Bener orang Tia.
Akhirnya kalah lagi ya.
Kalau menang sih seneng ya.
Susah banget.
Kalahnya cukup ini ya.
Nah waktu di tim dinernya ada foto-foto gak?
Ada.
Nah maksudnya foto-foto ini pakai alat dokumentasi.
Bagian dari dokumentasi.
Alat dokumentasi.
Ngomongin alat dokumentasi ya.
Kita kan mau ngobrolin tentang itu.
Nah sebenernya sebelum ke arah sana.
Ini juga salah satu topik yang kita ambil dari
dari GitHub kita.
Yang salah satu cukup tinggi sih.
Lumayan ini ya.
Lumayan banyak yang vote ya.
Dokumentasi ini.
Jadi kalau teman-teman punya topik boleh langsung di kirimkan kesini.
Jadi nanti ada yang vote, ada yang kasih komentar dan lain-lain.
Tadi saya melihat ada yang submit mas Irfan.
Oh ini basic web security.
Baru lihat nih 11 jam yang lalu.
Tapi kayaknya menarik ya.
Tuh udah ada referensinya tinggal bahas.
Enak ya.
Kita meng-outsourcekan kerjaan kita.
Gini nih.
Tinggal kita bahas.
Kalau perlu panggil orangnya ya.
Jadi kita dari sini ada salah satu saya sih.
Kan idea dari teman-teman juga kan ya.
Kayaknya sempat dari itu yang Slidoo atau apa.
Bukan yang Slidoo.
Oh dari Slidoo kita pindahin kesini ya.
Iya.
Jadi nextnya kesini aja.
Nah ngomongin dokumentasi lagi.
Kalau apa namanya.
Sebelum kita mulai ke tools untuk membuatnya.
Nah dokumentasi itu.
Kalau misalkan teman-teman bikin dokumentasi.
Atau baca dokumentasi tentang library atau framework.
Itu biasanya ada bagian-bagiannya.
Ada 4 biasanya.
Yang paling umum ya.
Jadi dia modelnya itu disebut sebagai documentation system.
Disini.
Jadi ada tutorial.
Kemudian ada how to.
Ada explanation, ada reference.
Reference ini kayak API.
Kayak syntax ya.
Code ya.
Maksudnya bisa di auto-generate ya.
Betul.
Dari JS doc misalkan.
Atau dari documentation generation yang lain.
Nah kalau.
Dan ini masing-masing juga ada bagian-bagiannya misalkan.
Tutorial itu adalah learning oriented.
Jadi kita belajar berdasarkan.
Luh ada iklan.
Berdasarkan.
Kayak apa ya.
Step by step.
Mulai install dulu.
Terus generate.
Terus abis itu di edit yang mana gitu ya.
Kalau how to itu.
Kalau biasanya kita mau.
Past base ya.
Misalnya authentication.
Misalnya kita punya meta framework.
Authentication.
Atau membuat routing.
Atau how to.
Redirect.
How to.
Yang bisa mencakut.
Satu atau beberapa fitur dari.
Si library atau framework.
Itu kali ya.
Jadi misalkan awalnya kita ikutin tutorial.
Terus kita bikin aplikasi sendiri.
Terus kita bingung nih.
Gimana cara bikin autentikasi.
Gimana caranya ngecek.
Apakah username passwordnya benar atau salah.
Dan lain-lain.
Biasanya ada di how to guides.
Terus kemudian kalau yang explanation.
Kenapa misalkan.
Filosofinya kali ya.
Kenapa framework ini muncul.
Tujuan dibuatnya apa.
Gitu-gitu ya.
Atau mungkin termasuk juga decision.
Kenapa routingnya.
Design architecture.
Kenapa pakai cara kayak gini.
Karena itu mengatasi masalah.
Kayak htmx itu ada kan.
Waktu itu kita lihat.
Itu kan kayak ada penjelasannya.
Tentang atar belakangnya.
Betul.
Docs ini kan ada referensi.
Yang tadi kan referensi. Terus example ini kayak tutorial.
Example ini kayak how to ya.
Kalau example kan demo ya.
Demo.
Kadang-kadang dia jadi satu.
Nggak semuanya terpisah.
Misalnya dia jadi satu seperti ini.
Nanti tiba-tiba disini ada tutorial.
Atau apa gitu.
Apalagi yang
build ya.
Salah satu contoh yang dokumentasinya
lengkap dan detail banget.
Ya, kayak core concept.
Ini kan penjelasan ya.
Mungkin ini tutorial.
Nah, ini tutorial ada di bagian sini.
Jadi nggak mesti terpisah.
Tapi biasanya yang API
yang penjelasan
yang ini, yang referensi, biasanya ada sendiri dia.
Terpisah.
Maksudnya, dari
ada
ada sectionnya itu coba
kembali ke bagian yang tadi.
Kan itu
yang di tengah itu kan
practical step di atas, theoretical
di bawah. Terus
yang sebelah kiri untuk
belajar. Untuk studying.
Untuk megerjakan sesuatu.
Jadi kalau misalnya mau
cari apa?
Mau buat tutorial atau
dokumentasi yang
langsung
langsung, pokoknya
pengen langsung bisa dipakai,
praktek langsung untuk kerja gitu.
How to, ya, berarti how to guide.
Langsung, kalau belum
kayak contohnya gitu. Yang tadi kayak
mau bikin button,
gimana, langsung ini contohnya, begini
caranya. Nah, sedangkan kalau mau
lebih
dalam lagi, ya maksudnya
kalau mau belajar lebih dalam, ya berarti
kita kan belajar lebih dalam, berarti
ke sebelah kiri.
Nah, maksud dari
bagan ini, sebuah
dokumentasi yang
baik,
yang best practice-nya adalah
kalau semua
dokumentasi
yang kita buat ini mencakup
section ini.
Jadi, tergantung user-nya. Kalau datang
itu, ah, gue pengen tahu
kalau pengen mau pakai Astro,
baru mulai
aja harus belajar teorinya, kan malas
banget, ya, pengen tahu dulu ini hasilnya
kayak gimana sih? Ya, langsung ke how to.
Pengen dapat bayangan gambaran
yang cepat aja bentuknya kayak gimana.
Tapi begitu sudah
nyampe.
Untuk pengen tahu
kenapa kayak gini, kenapa
gitu, kenapa kok
ini bagian yang beda,
apa aja.
Betul. Jadi,
sebisa
mungkin kalau bikin dokumentasi
yang kita buat untuk
produk, ya, mencakup
empat hal ini.
Semuanya. Oh ya, how to
guides. Itu sering disebut sebagai
recipe ya, kelihatannya. Salah satu
yang pakai termini recipe
itu Astro tuh, itu contohnya bagus
deh, coba di private chat.
Recipe. Ada di sini? Recipe.
Ada, ada. Scroll aja
ke bawah. Recipe. Oh, ini recipe
and resource ya?
How to recipes. Nah, terus menariknya
mereka punya dua macam
official recipes. Itu ya,
maksud saya yang official di Docs.
Tapi user
saya, community bisa
submit juga. Community recipes.
Community. Oh, ada di sini ya.
Ya. Tinggal submit di
GitHub. Dokumentasi ini
engineering sendiri ya.
Maksudnya. Iya.
Terpisah dari
dari core
core programmer, core
developer-nya, terpisah
dari implementation
implementator-nya.
Ini kayak satu ilmu sendiri
gitu.
Technical engineering,
technical writer bahasanya kali ya.
Filos ininya. Profesinya.
Iya, iya. Kalau untuk
nulis kontennya, iya.
Tapi kalau untuk
develop maksudnya untuk naro
dimana
ada yang bilang, disarankan
satu repos supaya
ikut, apa ya, ketika
release ada atau ada fitur baru,
dia ikut ke update juga. Bisa langsung
ditrack ya? Iya, bisa langsung ditrack gitu.
Kalau dibikin di repos sendiri
jadi kayak silo
aja terpisah. Ini ada
ininya nggak? Ini ada kayak drop
down, si Astra ini ada drop down
versi-versinya nggak sih? Kayak versi
yang berapa sebelumnya?
Di kanan atas?
Nggak ada.
Gak kayak Laravel.
Yang ada Laravel, ya kan?
Apa? Yang pertama
identik.
Banyak sih. Cuma yang pertama gue inget.
Perversi.
Karena pernah juga kayak
nemu sebuah dokumentasi, dicobain
contohnya kayak WordPress,
itu yang blog editor-nya,
yang Gutenberg itu.
Yang dirilis, yang versi
terakhir. Terus gue cobain,
"Oh nggak bisa, ternyata gue punya
core WordPress-nya masih
ketinggalan." Dan itu kan sudah
yang maksudnya function itu belum ada.
Jadi kadang suka
lagi kan ada yang berbeda,
yang berbeda, underscore,
tuh tuh versi itu. Jadi
kalau misalnya masih pakai
versi 5, ya mungkin dokumentasinya
berbeda. Kalo nggak salah
dokusorus ada deh.
Kita ngomongin tools, ya. Salah satunya dokusorus.
Yang dipakai di React.
React.dev ya.
Pakainya dokusorus ya?
Kayaknya.
Aduh, nggak ada ya?
Ternyata nggak.
Oh, dia
pakai ini, versiannya pakai
subdomain.
Banti kan dia sudah
dililis, di-read-only,
dibuat jadi read-only,
repo-nya atau branching-nya.
Kayak serangnya ya.
Dokusorus.
Coba kita lihat dokusorusnya ya.
Ini salah satu tools yang
terkenal juga. Tuh, ini kan ada di sini.
Dokumentasi dokusorus pakai dokusorus ya?
Iya kali.
Itu
buat tools banget kalo ternyata nggak
pake.
Apa istilahnya?
Dogfooding.
Pemakan makanan
anjing sendiri.
Itu aneh.
Mungkin di-disable kali ya
sama react-nya ya. Jadi nggak pake fitur
ini ya. Jadi ini dokusorus kan
dia ada ternyata ininya,
versi-versinya.
Bisa dipake atau nggak?
Ya.
Masih ada.
Masih ada versi satunya.
Go by example juga cukup populer.
Go by
example.
Ini
dokumentasi juga ya.
Oh, ini contoh yang tadi.
How to.
Iya bener.
Tapi ini lebih ke topik-topik.
Example atau recipe?
Example.
Coba aja klik salah satu.
Your parsing. Ini kayak
contoh code ya.
Contoh code ya. Oh iya, ini
berarti kayak recipe tadi ya. Yang how to ya.
Change logs
termasuk dokumentasi nggak?
Termasuk kayaknya.
Termasuk.
Tapi biasanya malah
di satu halaman tersendiri ya.
Biasanya kan ada.
Coba deh. Karena
di repo
misalkan kayak github gitu dia ada kan.
Nah, kalau contohnya kayak yang react nih.
Yang react, dia
ngasih link ke
change log-nya di masing-masing versi.
Nah, scroll ke bawah.
Nah, itu releases
atas.
Atau sedikit. Nah, iya.
Lari-nya kan kayak change
log, MD kan?
Lari-nya ke MD.
Jadi di-release-nya
di repo-nya, tapi tetap di-link
dari website docs-nya.
Jadi maksudnya bukan cuma
major, tapi per minor
sama
bug fix-nya juga ke-track.
Ini change log
yang bagus tuh begini nih.
Change log yang paling worst yang pernah gue
nomorin itu adalah
anak Android tuh. Menyakit jahantung.
Kenapa emang.
Ada aplikasi
di Android atau di
Play Store ya, Play Store.
Atau bahkan kayak
dulu, jaman dulu Samsung
nyembunannya
boleh lah ya, Samsung jaman dulu
kalau misalnya dia ada update
terus tulisan update-nya
minor bug fixing.
Dia cuma tulis minor bug fixing.
Poin kedua, performance
improvement.
Tapi emang kalau di
App Store dan di Play Store itu
buat change log ya. Bukan buat
kayak informasi buat end-user gitu.
Kan end-user kalau tau.
At least ada link
ada link-nya yang menuju
list lengkap dong, kalau misalnya itu
OS update.
Oh iya sih, kalau OS iya ya.
Maksudnya harus ada technical
reference.
Di Play Store sih ya.
Kalau di Play Store sih ya.
Kalau Windows
juga ada
list-nya, KB apa
KB apa gitu. Banyak banget
list-nya itu.
Bukan change log sih
deskripsi update yang seriusnya
sama kode-nya.
Yang summary-nya ada di bagian
update screen-nya, tapi begitu di click
ada link-nya yang menuju
list lengkapnya ada.
Di website.
Nah itu dikomen, kalau change log
isinya pantun, itu kan yang kayak
sebenarnya bukan change log sih, itu kan kayak
deskripsi Play Store gitu kan, biasanya
apa yang berubah. Cuma biasanya
kan dibikin lucu-lucuan kan.
Ya lucu-lucuan, bagi dari
lucu-lucuan. Ini nggak tau nih,
ini beneran atau
becandaan?
Nggak kelihatan nggak? Nggak kelihatan ya?
Wah makin kecil.
Ini mungkin
open image, new type.
Sengaja kali biar dibahas.
Sengaja ya, biar viral ya.
Highlight this please.
ID only.
ID only.
As usual.
Ini kan kayak brief-nya,
copywriter-nya kan.
Udah bukan technical lagi mulai.
Ini change log,
bukan kan sebenarnya kan,
deskripsi aja kan.
Kalau mau udah taruh change log juga
terlalu teknis nggak sih?
Kalau app store
gitu kan buat umum kan.
Iya, ini kan
emang maksudnya nggak harus bullet point
gitu juga nggak apa-apa kan.
Sebenarnya mau paragraf atau apa.
Kalau misalkan
yang lagi heboh
itu bang yang migrasi ke
Eras kan, ditaro lah di sini.
Peningkatan ke rumah 487 kali.
Waduh, rame
nanti.
Rame nanti tuh.
Itu yang bangnya ada
gedung-gede-nya di Bintaro
itu kan.
Malas dilanjutin.
Boleh sebut
initial kalau nggak apa-apa?
Apa lagi
kalau pantunya ini
buat lucu-lucuan ya.
Buat menarik perhatian kali ya.
Lebih ke buat menarik perhatian.
Karena yang baca adalah end user
dan apalagi kalau di Play Store
aplikasinya kan closed source.
Jadi yaudah lah.
Yang paling enak itu isi
upgrading,
dokumentasi upgrading-nya.
Banyak breaking change-nya, banyak list-nya.
Itu initial-nya tuh.
Namanya apa lah ini?
Initial itu.
Initial-nya emang namanya.
Emang kepanjangannya apa?
Gak tahu.
Itu bukan initial, kependekan.
Sudah pada tahu.
Berarti pada ngikutin semua ya
perkembangan.
Perkembangan drama.
Jadi salah satu tools yang udah kita
lihat tadi ya, salah satunya adalah
yang paling...
yang paling banyak dipakai ya.
Maksudnya paling
bukan banyak dipakai sih.
Paling go-to.
Bukan nama perusahaan, tapi
go-to
documentation framework
kali ya.
Udah lama ada.
Kalau ada yang mau bikin
dokumentasi, yaudah pakai docusaurus aja.
Betul. Karena satu,
yang udah lama ada. Yang kedua, dia menggunakan
React. Yang adalah userbase-nya
cukup besar. Jadi yang paling banyak.
Otomatis dipakai.
Kalau misalkan di perusahaan kita pakai React, terus
kita bikin dokumentasi, ya kita carinya
yang React-based dong. Gitu kan.
Jadi salah satunya adalah
yang docusaurus ini.
Kalau di Indonesia ada
docusaurus tau gak sih?
Apa itu?
Dulu banget ada brand
docusaurus yang jualan alat-alat itu.
Alat-alat untuk
happy birthday.
Ketinggalan.
Enggak, belum-belum. Kita baru ini
bahas sedikit-sedikit.
Baru mulai tools pertama, docusaurus.
Saya taunya cuman
swager. Oh iya, swager juga salah satu
dokumentasi ya.
Tapi kan itu cuman buat reference ya.
Tadi kan ada
codenya, ada bagannya.
Itu cuman buat, mana itu?
Yang kanan bawah.
Reference, yes.
Swager JSON.
Kalau yang reference ini lagi
itu si PHP doc.
Iya, JS doc, PHP doc.
Yang dia generate dari
function-function atau
metode-metode yang ada di kode kita
kan ya. Swager.net
Enggak.
Swager itu umum ya. Generic ya.
Buat semua bahasa kan ya.
Bisa buat apa aja?
Sambil dibuka aja. Swager.io.
Ini untuk API documentation.
Kalau kita bikin API
kita bisa bikin
API. Masih pernah lihat lah.
Pasti pernah lihat bentuknya kayak gini nih.
Udah umum banget.
Tuh.
Ya, mungkin
di awal
dari dulu kan ya. Gatau ya.
Dulu kan ada PHP doc,
ada JS doc, itu kan dulu dari
Java ya. Java doc ya.
Awalnya ya.
Terus diadoptik
ke bahasa-bahasa yang lain. Mungkin ini.
Itu language agnostic kok.
Deep Tools
yang saya, ini adalah Sarata Tools
yang saya pakai untuk mendamaikan
antara front-end dan back-end.
Tuh.
Supaya tidak terjadi perang.
Udah. Agree ya.
Ini dokumentasinya ya.
Agree ya. Ini kontrak ya.
Saya terima parameternya ini.
Integer.
Deal.
Gak, gue yang lain.
Emang kayak gitu sih.
Kalau di tim gue juga yang pertama
dibahas. Itunya dulu.
Sepakat dulu sama kontraknya.
Nanti ya.
Soalnya kan asing ya. Udah yang penting
deal dulu. Ini pokoknya
gak boleh pada bubar,
gak boleh pada pergi sebelum
setuju. Buat ngerjainnya
nanti ya udah. Gue mau berenang dulu
langsung karena pusing. Ada yang mau jemput
anak dulu, ngapain sambil dikerjain?
Aga nanti-nanti, gak apa-apa.
Yang penting jangan ekstrim, ngilangnya.
Boleh ngilang, tapi
harus sepakat kontraknya dulu.
Ya, kontrak.
Harus sepakat kontraknya.
Terus, ya.
SPK, SPK, SPK.
Apa tuh SPK?
Surat pengambilan keputusan gitu.
Surat, surat kan.
Surat apa kendaraan gitu
kalau deal untuk mau beli kendaraan.
Ini suratnya lah, perjanjian kerja.
Perjanjiannya, perjanjiannya.
Karena kan kita kan tidak
waterfall kan ya. Jadi gak
nunggu orang baik yang selesai dulu.
Nanti kalau misalnya
gak cocok ya, tinggal salah-salahin aja.
Salah-salahin siapapun yang bikinnya
gak sesuai kesepakatan.
Enaknya pakai Swagger ini bisa
bisa generate dummy.
Dummy, ya.
Kalau skema nya udah jadi bisa generate dummy.
Ada kemehnya otomatis kan.
Iya.
Ini menarik.
Apa? Swagger adalah salah satu yang
apa ya, yang kayak
tools wajib kali ya.
Iya, tools wajib kali.
Kalau buat apa,
udah ada tim front and back end,
nah itu wajib. Kalo masih sendirian
kayaknya belum ya.
Kalo masih single fighter mah,
ya,
sepakat dengan diri sendiri aja.
Sepakat dengan diri.
Apakah bisa gak sepakat dengan diri sendiri?
Ya kan ada peperangan
batin.
Oke, ini
buat apa, ini adalah salah satu
tools yang buat reference tadi ya.
Jadi kalo misalkan API
atau SDK
documentation ya, ini
pakai Swagger.
Apa, open API
specification ya.
Terus tadi kita lagi bahas
dokusaurus, nih
dokusaurus. Oh ada yang baru tau juga ya.
Padahal dokusaurus udah cukup lama ya.
Ya kan
walaupun udah sering liat, mungkin kan
gak tau itu dibikinnya pake.
Light mode dong, bosen banget sama
dark mode.
Wah.
Kayak di belakang kuliah,
apa kena sinar matahari.
Gak ada gray mode gitu ya?
Gak ada, setengah-setengah
gak ada ya.
Mendingan dark lah.
Nah, cara installnya
ya standar lah ya.
Cara installnya, pake NPX Create
dokusaurus, terus
ada temp-tempnya juga loh dia.
Inesquise TypeScript
terus konfigurasinya.
Nah, saya mau liatin project
structure, jadi kalo misalkan
aplikasi
atau website-nya ini.
Apa ini?
Aplikasinya ini
kita ada bloknya juga.
Biasanya kan
sebuah tools kayak React itu kan
ada blog, ada documentation,
ada apa lagi gitu ya?
Ya, dua itulah ya biasanya ya.
Nah, disini ada
dipisahkan berdasarkan
folder, jadi kalo ini untuk bloknya
jadi si dokusaurus ini juga sebenernya bisa
buat blok sih.
Kayak ada section-sectionnya ya, bisa pakai section.
Blok ini ya untuk
markdown file yang isinya
adalah
article, kalo docs itu
juga markdown.
Tapi
dia bisa
ditampilkan di sidebar.
Terus apalagi ada pages, ini
standarnya
SSR kali ya.
Ada pages
terus
dia semua
kayak ini kan, pakai static side
generator bukan dia?
Oh iya, SSG, betul-betul, dia SSG.
Tapi bisa jalan langsung ya.
Kalo gak dibuild, dia jalannya
diserve langsung ya.
Kalo dibuild, dia jadi
static side, ada di folder
build, nanti tinggal dipus
aja ke GitHub pages, atau ke
Vercell, atau Netlify, atau
mau ke FTP, ya silahkan ya.
Gitu.
Jadi, kira-kira
seperti itu. Dan ini juga sebenernya
bisa digabungin sama
aplikasi kita.
Lu pakai Monorepo ya?
Monorepo?
Oh, ya itu tadi.
Kayak dibahas
tadi di awal, jadi satu
repo sama kodenya sendiri.
Sama kodenya kita, jadi
supaya bisa lebih mudah
track gitu. Jadi satu ya.
Terus, selain dokusaurus, ini kan
yang react-base ya, yang react ya.
Ada apa lagi yang react-base?
React-base, Astro.
Oh Astro.
Kalo Astro itu,
kalo gak salah, ini dibuat dengan
static. Gak, gak react sih, sebenernya gak
bukan react. Bisa, bisa react, bisa.
Bisa gak ya.
Jadi, latar belakangnya
si Starlight itu,
Starlight itu yang sebenernya
Astro sih.
Dokumentasinya
Astro itu kan, niat
banget bikinnya. Jadi kayak
niat dan community
apa? Ya, sama kayak
open source dan community
run gitu. Ada maintainernya
yang lead, tapi
kontribusinya dari community
dan di discord-nya tuh kayak ada
satu channel sendiri
buat
kayak ngulik explore docs-nya,
termasuk fitur-fiturnya, segala macem.
Jadi, konon sih banyak yang nanyain
apa?
Nanyain sama nge-forging situs
dokumentasinya Astro.
Nah, dari situ dibikin kayak
ini template. Ini sebenernya ya
Astro site jadi kayak starter
atau template untuk dokumentasi
berdasarkan best practices yang
dipakai di dokumentasinya
Astro. Itu
kan gue dulu sempet, apa,
sering, karena lagi
seneng-senengnya Astro, sering di discord-nya
Astro. Jadi kayak sampai
sidebar-nya kayak gimana yang
tadinya sidebar-nya cuma satu, terus jadi
ada sidebar di kiri, di kanan, itu aja
kayak beneran dibahas banget
per sidebar-an.
Mirip-mirip ya, nggak jauh
beda lah ya.
Orang-orang yang familiar ya.
Sama kayak multi-lingual.
Ya, template multi-lingualnya tuh kayak
ya apanya, udah well thought of.
Oh, ada bahasa Indonesia.
Wow.
Ini yang pasti bikin
ini nih, fans-nya Muse.
Lagu Starlight ya.
Gatau ya lagunya.
Gatau.
Enggak sih.
Nggak, kan Astro kan temanya luar angkasa.
Jadi dokumenkasi.
Dokumenkasi
namanya Starlight.
Starlight.
Oke, ini
sebentar.
Kok jadi bahasa Indonesia?
Malah nggak enak ya. Karena nggak biasa sama
kata-kata. Nggak biasa, nggak biasa.
Nggak biasa sama terminal. Oh, dia pakai
pages aja ya. Jadi ini adalah
ini kan Astro. Ini AstroSight.
Astro hanya Astro ya.
Berbeda dengan ini kan. Ini agak beda
strukturnya kan.
Iya, karena Dokumenkasi kan
kayak bikin framework sendiri.
Tapi khusus untuk dokumentasi
kalau Starlight itu
nggak, maksudnya nggak bikin framework
terpisah, cuma
AstroSight dengan best practices
dan kayak fitur, kayak komponen-komponen
UI yang lazim dipakai
buat situs dokumentasi.
Yang buatan Anvoo.
Ada nggak ya?
Feedpress. Ini, Feedpress bukan?
Oh, Feedpress.
Buka-buka coba.
Anvoo Universe.
Anvoo Universe. Berarti ini
sama ya modelnya ya. Di SRC
Content Docs. Ada Markdown.
Terus kalau kita bikin pages
yang berbeda, pages
gitu ya. Kalau mau block, berarti kita
bikin content/block kali ya.
Oh, gitu. Oh, iya, iya.
Ya kan dia file-base
router kan?
Tapi itu kan content docs ya kan?
Pages kan. Oh, pages berarti sendiri ya.
Oh, iya.
Pages itu special.
Special ini.
Special page.
Nah, itu makanya ada custom.Astro.
Custom page maksudnya.
Oh, custom page.
Nah, itu diarahinnya juga tetap
balik ke AstroDocs lagi. Jadi kayak
kelihatan yang nggak bikin sesuatu
patternnya. Gak ada yang special gitu ya.
Itu kata mas
Josh Pring. Mas Yombing. Itu
storybook buat dokumentas itu juga
react-based itu storybook.
Itu juga udah masukin tuh di Docs
tadi.
Storybook.
Ini berhubung
si Astro ini dia content
apa ya? Framework yang fokus
ke content kan. Jadi
Markdown, Frontmatter,
dan lain-lain itu udah pakai punya dia aja.
Berbeda dengan React kan. React kan
cuma komponen library.
Jadi harus dibikin
sebuah framework lagi.
Iya, si DocuSaurus ini yang
pakai MDX dia.
MDX Markdown.
Kalau disini dia
pakai Markdown biasa.
Ada MDX juga ya?
Ada tadi boleh MDX.
Bisa pakai MDX.
Ya, ya, ya.
Bisa, bisa.
Terus
satu lagi. Kita bahas satu lagi.
Ada dulu saya pernah pakai
yang dari SpellKit namanya
Kit Docs.
Kit Docs ini
mirip-mirip juga kan.
Ini SpellKit.
Dari SpellKit.
Jadi dia
bikin...
manual.
Terus
pakai Markdown juga.
Ya, ini pakai SpellKit.
Dia template-nya
SpellKit sebenarnya.
Kalau kita lihat disini kan.
Yang ini.
Enggak, nggak official.
Ini
buatan dari SpellKit.
SpellKit itu kalau nggak salah, dia selain
bikin Kit Docs, ada bikin apa lagi ya dia?
Kalau cuma dua ini.
Dua jester.
Tapi sayangnya, Kit Docs ini
udah setahun nggak update.
Jadi nggak tau nih.
Dia nggak ke-update ke Spell5 jadinya.
Oh iya ya.
Itu berarti salah satu
pertimbangan juga ya. Makanya mungkin banyak
orang yang pilih dokusurus aja ujung-ujungnya.
Karena ya udahlah trusted
kemungkinannya cukup besar bakal
dimaintain terus.
Starlight juga gitu.
Kalau spell-nya sendiri,
dokumentasi spell-nya sendiri pake apa?
Ya pake spell.
Dokus alurus.
Oh kalau playground-nya, tutorial-nya
baru pake tutorial Kit ya.
Kalau dokumentasinya
ini kayaknya bikin sendiri ya.
Cari aja. Harusnya kan ada
di GitHub kan. Cari aja.
Oh untuk documentation site-nya.
Pake JSON?
Oh nggak bisa kelihatan disini ya.
Di docs. Ada nggak?
Folder docs atau apa gitu.
Itu ada documentation tadi.
Di spell.
Spell def.
Atas atas.
Nah ya.
Updated 2 jam yang lalu.
Oh.
Ini mah jangan kuatir.
Nggak tahu dibawah.
Itu kali ya. Di apps.
Apps apps.
Nah itu kit.
Swell def.
Swell.dev.
Tadi apa?
Tadi apa ya
yang ininya?
Docs.
Swell.dev/docs
Berarti beda ya.
Beda ya.
Itu tapi betul. Swell.dev.
Itu berarti yang bawah. Swell.dev itu.
Yang folder ke terakhir.
Content.
Docs.
Iya ini dia.
Spell.
Coba index-nya apa isinya?
Title.
Docs.
Iya. Markdown.
Spell kan. Introduction.
Overview.
Markdown.
Ada prometer juga.
Tapi...
Dependensinya.
Kita lihat.
Ya pakai Swell lah.
Ya kali yang lain gitu.
Nggak ada ya.
Iya itu Swell.js.
Blablabla.
Namespace-nya.
Dia bikin sendiri berarti ya.
Dia bikin sendiri.
Nggak seru ah.
Bisa jadi drama.
Bisa jadi drama.
Ya.
Nah coba buka feedpress deh.
Ini kan universe-nya Swell.
Feedpress itu ternyata yang buka.
Yang bikin.
Mas Evan Yu.
Bukan.
Anfu.
Cuma Evan Yu.
Universe.
Evan Yu Brother.
Oke.
Terus.
Ini.
Documentation. Mana?
Quick start.
Sama juga.
Ini kayaknya pakai...
Semuanya rata-rata begini ya.
Ini kayaknya pakai Astro.
Nggak begini.
Dokumentasi itu memang begini ya.
Maksudnya best practice-nya.
Harus menu di kiri.
Terus di kanan itu apa?
Content-nya.
Ada section-section di halaman itu.
Ya karena kalau bikin beda lagi.
Nanti apa?
Harus.
Belajar lagi.
Nah ini ada guide. Ada reference kan.
Betul.
Ada versi.
Ada drop-down versinya juga.
Drop-down?
Oh ini.
Cuma nggak bisa milih ya? Bisa nggak sih?
Nggak ada.
Dia cuma kasih tahu versi sekian.
Ada multilingual.
Ini ada light.
Feedpress ya.
Feedpress ini kan
tapi bukan cuma buat
dokumentasi kan.
Dia lebih kayak
Astro kan sebenarnya jatuhnya kan.
Fast content centric websites.
Cuma tadi di
landing page-nya.
Marketing copy text-nya.
Tadi nyibut-nyebut
documentation. Markdown to beautiful
box in minutes.
Walaupun nggak dipakai buat dokumentasi ya
dia positioning-nya gitu.
Ya Astro juga kan sebenarnya Starlight
itu kan AstroSight.
Jadi ya in a way Astro bisa
dianggap sebagai tools
buat bikin documentation site.
Walaupun ya bukan cuma buat itu.
Iya benar.
Oke.
Nah ini kalau
kita mau lihat routing-nya
gimana. Struktur folder-nya lah.
File, structure,
docks.
Ini ya udah ada.
Oh ya file structure ya.
Sama di
sebelah gini juga.
Lebih simple ya, langsung di bawah docks dah.
Semuanya di situ aja.
Nggak ada SRC, content,
something-something ya. Ini ada guide.
Oh guide yang ini.
Kalau mau bikin beda folder,
bikin aja folder di dalamnya gitu.
Nggak mesti docks gitu.
Oh ada pattern-nya.
Ini dia.
Kalau
dokumentasi dia slash docks
gitu ya.
Sudah goal belum?
Udah, brace.
Astro brace 2-0.
Wah, huri.
2-0.
Ini kita FOMO.
Kita FOMO.
Nonton satu babak doang.
Bagus lagi mainnya.
Lanjut, lanjut, lanjut.
Wah, ini simple ya.
Simple ya.
Next-nya ada tools apa lagi?
Itu tadi
storybook.
Oh, storybook, betul.
Storybook.
Kalau nggak salah,
Spark juga bikin dia ya.
Storybook ya?
Storybook versi Spark.
Ini Saudi Arabia yang ngalahin Argentina kan?
Ya.
Kita ngalahin.
Eh, nggak boleh jengawa doang. Sejauh ini
masih lagi
ngalahin.
Yang round pertama malah
kita nahan imbang
di sana kan, pas main tandang.
Pas dilatih mancini lebih
gokil. Anyway.
Anyway.
Fokus, fokus, fokus.
Storybook ini
sebetulnya agak beda dikit
positioning-nya dibanding yang lain
semua. Tadi kan ada Swagger tuh
yang
buat reference, tapi reference
API-nya. Ini tuh
bisa dibilang agak mirip
kayak gitu, tapi buat UI component.
Jadi sebenarnya dokumentasi untuk
UI component, tapi dokumentasinya
nggak se-holistic,
nggak se-menyeluruh yang dibagian
tadi. Karena ya udah, sebetulnya
kalau by default, cuma
ya cuma komponen-komponennya
sama kayak variasi prop-nya,
kombinasi-kombinasi
prop-nya, prop dan state dari
komponen itu sendiri.
Tapi sebetulnya kalau mau
dibuat dokumentasi yang lebih
lengkap, itu ada
fiturnya. Bentar mana ya?
Bagus deh. Itu
recommended banget. Tapi ini
kayak
fitur yang opsional sih.
Wait.
Apa tuh? Dari storybook?
Iya.
Wait, cari ini-nya dulu.
Ah, kok lama sih?
Kapan terakhir
teman-teman pakai storybook?
Baru ya?
Masih pak. Masih maintain?
Masih?
Soalnya beberapa tahun
yang lalu ya, nggak tahu sekarang, mudah-mudahan sih udah
cepet ya. Berapa tahun yang lalu
setup-nya itu lambat banget.
Lambat banget. Masih lambat.
Oh masih.
Ya,
tergantung kalau komponennya
ratusan dan permutasi
props-nya ratusan juga,
mungkin lambat. Tapi kalau cuma buat
yang simple-simple, ya
puluhan lah.
Udah jauh lebih cepet kok.
By default, sekarang pakainya fit.
By default, sekarang pakainya
fit.
Semua akan pindah ke fit pada waktunya.
Refactor semua,
refactor.
Coba buka link yang
autodocs deh.
Autodocs.
Ini bagian dari storybook
juga ya berarti ya?
Iya, fiturnya. Salah satu fiturnya.
Nah, itu pakai MDX.
Cuma kelebihan-nya adalah
jadi storybook itu kan
pakai namanya format
.stories.tsx
atau .jsx.
Jadi dia ngambilnya,
itu tuh ada contoh preview button-nya
yang biru, itu preview-nya
langsung ambil dari kode
komponen kita sendiri. Jadi kayak
dijadikan satu.
Karena ini orientasinya UI ya,
front-end. Jadi komponennya gimana,
langsung dokumentasinya di situ.
Props-nya itu ngambil,
table props-nya itu ngambil dari
TypeScript definition
komponen itu sendiri.
Nah, terus kita bisa nambahin sendiri
pakai MDX.
Nah, itu ponenya udah
disediain komponen-komponennya,
kita bisa nambahin sendiri pakai
MDX.
Cuma storybook itu
karena saking banyak fiturnya,
agak overwhelming. Kalo baru
pakai tuh overwhelming banget.
Banyak banget variannya
kayak buat track, buat view, buat
macem-macem. Jadi mungkin itu agak turn-off ya
kalau misalnya belum pernah pakai.
Terus ngeliat gitu kayak banyak banget.
Tapi sebetulnya itu useful banget dan bagus
kalo emang niat, kalo emang
kita nyeniat pengen bikin dokumentasi yang
lengkap itu bisa
mendukung banget.
Jadi bisa ada accessibility test-nya juga, kan?
Bisa. Test-nya macem-macem.
Visual test bisa,
accessibility test bisa,
jazz, enggak tau ya,
kalo Vtest belum pernah coba
jazz testing, dimasukin kesitu
jadi satu tab juga bisa.
Jadi kita nulis test route-nya
saya biasa.
Kita ngetik jazz biasa,
cuma ada add-on-nya, ya kita bisa
ngeliat di satu tempat aja, gitu.
Bisa contohnya yang dari WordPress blog
yang full misalnya
yang sedang masih di-mainting untuk
Gutenberg blog.
Gutenberg?
Ya, misalnya blog editor-nya
si WordPress, seluruh
komponen yang
yang sah
ada di sini, gitu.
Bisa contohnya kalo misalnya
langsung aja ke komponen deh
yang di bawah, yang
apa ya?
Cuma nih sebelum ke komponen,
ini juga bagus di storybook
sebetulnya buat komponennya sendiri,
tapi ini bisa dokumentasi
yang tadi kan ada apa?
Explanation ya, atau apapun yang jelasin
pake kata-kata, gitu.
Itu bisa kayak docs, introduction,
itu pake MDX, kita ngetik aja,
ngetik kata-kata biasa, jadi bisa jadi satu
dengan relatif, gampang,
mudeh.
Nah, lanjut.
Bisa turun ke, bawa ke komponen aja
kayak contohnya kayak button, kayak apa
yang ada.
Bawa-bawa button group aja,
itu coba, ada nggak
button-nya? Button mungkin
yang primary itu kan ada variation
tuh. Button kalo di
button kalo di
drop-down lagi,
di kiri, di kiri,
karena ada variation tuh, primary,
default, itu
props-nya, jadi kalo misalnya pencet primary,
tuh code is poetry itu
primary-nya gitu, control-nya
ada props-nya dia terima,
itu semua,
dan accessibility.
Bisa diganti-ganti juga langsung, apa?
Itu tuh props-nya kita
bisa nyoba-nyoba, misalnya kalo
itunya true, jadi
kayak gimana.
Terus accessibility,
ke tab accessibility,
nah, pass,
terus bisa
bisa dicek ya, kalo nggak
pass, itu gimana.
Kalo masih violation, WCAG
pasal berapa yang kena?
Pasal berapa.
Terus kalo,
batah component ini bisa
menerima actions apa?
Itu bisa di tab actions.
Ada tab-nya tuh, actions
kanan.
Terus belanya accessibility?
Nggak ada.
Oh, kosong ya, kalo kosong-kosong.
Itu buat men-stimulate
apa? Kayak apalah
input, kalo diklik jadi gimana,
itu kayak ada simulasinya gitu.
Buat interactive UI.
Ini apakah
si storybook ini
berada di satu repo sama
project kita atau terpisah?
Satu repo. Jadi,
semua, ya, jadi, waktu dia
jadi kalo misalnya,
jadi
storybook ini satu repo.
Jadi waktu si
contohnya kayak actions button ini kan
ada componentnya sendiri
di package-package yang lain.
Jadi waktu nge-generasi
storybook ini langsung ngambil
atau nge-import dari package
yang itu dipake di dalam
storybook ini.
Jadi kalo disana update,
kalo disana update, waktu kita nge-generasi
storybook, auto-update semua.
Tapi sebetulnya, ya,
bebasi, meant to be, kayak
dimaksudkan buat jadi satu repo.
Karena, ya, biar co-locate aja.
Kayak kita nulis, bikin UI
component, bikin testing,
bikin dokumentasi, ini disebutnya
story kalo disini, itu kan kayak satu
kesatuan ya, harusnya idealnya.
Tapi prakteknya sebenernya misalnya
kita publish component
sebagai masing-masing.
Misalnya setiap component jadi satu
package, satu library gitu, misalnya
kita nge-import
di story-nya juga bisa-bisa aja sih.
Maksudnya itu dengan gampang, nggak ribet.
Jadi di file.stories.tsx itu
kita nge-import
UI component yang mau
didokumentasiin. Jadi sebetulnya
mau beneran literally dalam
satu repo, atau pake
monorepo system kayak apalah
yarn workspaces atau
PNPM atau semacamnya,
atau literally kepisah, tapi
kita nge-import UI componentnya
dari PNPM itu
tiga-tiganya bisa-bisa aja.
Tapi kan
pada saat kita ngejalanin ini kan lumayan
berat kan ya. Itu apakah
dijalani, nggak dijalani terus-menerus
kan, pada saat proses
development?
Ya di CI/CD,
jadi mungkin saat release, update
sekalian.
Sama bisa juga,
ya itu kan tergantung juga misalnya
kalau kita bikin component baru,
nggak kita test development,
si test runner-nya
jalan terus, kita kayak sambil
nge-save-nge-save, kita ngetik sampai
itu benar. Nah kadang gue malah
pake storybook ini karena males
maksudnya misalnya bikin
component react ya, daripada
bikin kayak satu halaman,
terus buat ngetest tampilan
componentnya, ya bikin
componentnya sambil nyalain storybook
aja, terus sambil bikin button.
Ya jadi apa, itu kita
liat button yang kita bikin
langsung di situ.
Dan nggak tahu sih
kalau yang baru nih,
terutama begitu punya covid,
nggak kerasa berat sih.
Maksudnya
kalau bisa ngejalanin kita sehari-hari
pake apa gitu, Next.js, misalnya
nge-develop pakenya Next.js
atau semacamnya, itu
pasti cukup mumpuni
buat nyalain storybook.
Jadi kayak
sell storybook deh, dibayarkan ya.
Ada alternatifnya nggak sih
di storybook? Ada librarynya gratis.
Ada banyak, tapi kayak
nggak pernah ada yang take off deh.
Di open source kan,
cuma kalau mau pake
cloud-nya dia aja bayar.
Bayar, cuma kalau
dihosting dia dan pake
visual testing dari mereka.
Jadi storybook itu project dari
perusahaan yang namanya
Chromatic. Nah yang commercial tuh
Chromatic-nya. Storybook-nya itu
project open source. Nah Chromatic-nya itu
di visual testing. Chromatic-nya
gampang banget.
Sayangnya waktu saya udah coba
udah suka gitu, terus
client-nya nggak approve
budget. Ya.
Ya, nggak bisa main.
Pindah deh
ke persi.
Sama aja.
Persi ya masih
bisa lah. Lebih masuk akal
harganya, kata client-nya.
Oke. Oh jadi
untuk
tools
dokumentasi visualisasi
seperti ini, itu
si storybook masih
paling populer ya. Belum ada
yang masih de facto-nya lah.
Masih go to-nya
lah ya. Masih go to
kalau misalnya mau bikin component
library, ya
go to-nya masih suka storybook sih.
Kan dulu, pas masih...
react doang.
Kenapa?
Components masih bisa
react doang kan ya?
Enggak. Enggak. Enggak. Enggak.
Components.
Asli gue pernah bikin buat custom
elements.
Bisa semua.
So far gue coba
masih react, jadi gue nggak tahu.
Jadi ada yang unofficial
bentar cari deh.
Frameworks.
Anfu nggak bikin Anfu?
Coba cek dulu
siapa tahu dia bikin.
Atau dia dengerin
podcast kita, ntar lagi jadi
tuh. Tapi bukan Anfu
sih. Nggak, maksudnya
framework yang disupport
oleh apa?
Storybook
officially adalah
ini.
Ada tadi kan
di depannya?
Betul. Ada.
Storybook.
Storybook.js.org
slash docs slash
get started.
Ada semua. Ada 7.
Ada 7 lagi nih?
Iya. Ada listnya tuh dibuka di private chat
nih.
Nah, itu
lengkap ada. Jadi apa?
Dari bahasanya, yang atas ada react, view, angular,
blablabla. Terus ada kayak
variasi-variasinya. Ada
react native.
Wow.
Spell, spell kit, web
web, web, web, web, web, web.
Tapi ini udah berubah jauh
sih dari terakhir dicoba.
Ya, apa? Drop down yang more. Itu deh.
Diklik more. Atas
more.
Nah, tuh.
Lengkapkan. HTML biasa aja bisa.
Coba react quick solid. Ini yang baru ya.
Oke.
Dulu
apa bedanya race.js dengan
react ya?
Nggak, ini kayak contoh jadi
starter site-nya aja jadi
gampang. Nggak usah nambah-nambahin sendiri.
React, react polosan.
Nggak pakai framework.
Oke, oke.
Nice.js ada nggak sih yang pakai
spell?
Siapa tahu?
Siapa tahu mereka bikin
framework agnostik gitu ya?
Ya, yang framework agnostik ya ini doang nih.
Nah, dulu ada nih namanya
apa, kompetitornya
storybook namanya
Lado. Waktu
storybook masih lelet, sempat
cari-cari alternatifnya yang cepet kan.
Nah, salah satu yang pernah dicoba
Lado. Cuma nggak tahu nasibnya
gimana akhirnya.
Oke.
Kayaknya pernah lihat juga.
2024.
Masih aktif nggak?
Last week masih-masih aktif.
Masih itu?
Iya, ada daftar.
Tapi secara fitur, secara fitur
kayaknya kurang ya.
Makanya jarang.
Ya, nggak se-extensive storybook.
Tapi kalau emang pengen yang simple aja
beneran literally cuma buat
ngedokumentasiin dan nampilin daftar
komponen, ya bisa sih.
Cukup. Cuma abis
storybook pindah ke feed dan
jadi nggak lambat, gue ngerasa
itu fast enough
for my needs.
Ya udah, akhirnya nggak pakai Lado lagi.
Nggak sempat pakai, maksud saya.
Terus sempat cari juga yang
kayaknya Skotelinski deh yang bikin.
Bukit namanya.
Ya, bukit.
Tapi sudah di archive.
Jadi udah nggak
dikembangin lagi. Ini aja baru coming soon
tapi udah keburu di archive.
Kayaknya nggak dilanjutin.
Nah, iya sih, belum berkembang.
Ya, malas dia.
Kayaknya tadi nyari-nyari juga.
Iya, mungkin karena itu juga tadi alasannya.
Ya, mungkin akhirnya dia pakai storybook.
Jangan-jangan storybook-nya udah cepet.
Storybook-nya udah cepet-cepet.
Akhirnya, ya udahlah, nggak usah lah, nggak pahin.
Bukannya sekarang
orang sudah mulai berali, daripada bikin
sendiri, pakainya v0
gitu.
Jadi komponennya ambil yang sudah ada.
Walaupun kodingannya dari v0 kan
butuh ngedokumentasiin
untuk usage-nya.
Kasih dokumentasinya ke v0.
Ini loh komponen
Gombol dari sini.
Baca aja, Nana.
Tapi ini poin yang menarik juga.
Baru ingat kemarin itu ada
dibahas di podcast yang lain
di JS Party, kalau nggak salah.
Jadi, kalau dulu
misalkan kita punya
produk atau punya library
framework dan lain-lain, itu kan
kita bikin dokumentasinya.
Untuk dibaca oleh pengguna kan.
Orang.
Nah, sekarang berhubung tools AI
udah semakin banyak, kayak kursor
udah bisa mengkonsumsi
dokumentasi.
Jadi, dokumentasi itu bukan hanya diperuntukkan untuk
orang, tapi untuk AI juga.
Tapi untuk LLM.
Jadi, ada pemikiran kesana
bahwa, ah, si dokumentasi ini
nanti akan dikonsumsi oleh
LLM atau co-pilot
atau kursor atau apapun.
Ada, ada, apa namanya, ada insight.
Ada
dimensi tambahan lah, gitu.
Mungkin aja
nggak perlu dibedain.
Tapi juga mungkin struktur
dan lain-lainnya harus diperhatikan juga, gitu kan.
Kalau orang kan masih bisa nyari
lompat-lompat, kan. Kalau misalkan si
si AI kan, ya
belum tentu, nggak tahu juga
gimana cara kerjanya.
Untuk, pada saat dia membaca
dokumentasi itu kan, pakai RAG ya,
salah ya.
Kalau si kursor kan, ya.
Jadi,
semakin penting.
Si dokumentasi ini semakin penting.
Bukan cuma buat kita
yang baca, tapi buat
dikonsumsi oleh AI.
Sama itu, berarti yang penting
kita misalnya nulis di markdown kan, ya.
Kalau, kadang kan
orang nulis semantiknya kurang
bagus ya, kurang rapih.
Yang penting secara visual jelas.
Cuma berarti, kalau untuk
dikonsumsi AI, mungkin makin
penting misalnya kayak header-nya,
section-sectionnya itu harus pakai
apalah, itu yang
tepat. Terus
heading-nya kayak heading level H1,
H2, H3-nya, mesti betul.
Harus lebih konsisten, ya.
Harus lebih disiplin, gitu ya.
Nggak boleh sembarangan level
keberapa jadi ngaruh
understanding-nya dia
atau konteksnya dia jadi berubah,
gitu mungkin ya.
Nah, pengalaman
teman-teman pakai
udah pernah bikin
dokumentasi dan pakai apa?
Biasanya.
Manual aja kah?
Misalkan kayak tadi
siapa spell tadi
ya udah bikin aja, di sebelah kiri
taro sidebar, terus dia
akan for loop markdown
yang ada, terus tampilin,
gitu. Sederhananya kan
gitu ya.
Atau sudah pakai
tadi banyak yang belum tahu juga ya, doku
sorus banyak yang belum tahu,
baru tahu sekarang.
Teman saya ada
bikin
dokumentasi pakai
elder.js.
Elder, tapi bikin
sendiri.
Tapi ini buat
altis
situs yang kita pakai
produk yang
saya bekerja.
Dia pakai
elder.js,
membaca
semua dari beberapa repo,
terus kemudian generate
markdownnya,
kasih times, jadi deh
pakai elder.js.
Oh, ada yang pakai Notion
juga? Ya bisa aja sih,
nggak ada masalah sebenarnya.
WordPress juga banyak yang pakai.
Iya, pakai WordPress.
Cuma nggak enaknya kan kalau pakai
WordPress kan?
WordPress code block bisa nggak sih?
Bisa, bisa aja. Biasanya pakai
WordPress. Tetapi kan nggak enaknya
kalau misalnya kayak
kalau kita pakai
misalnya
untuk komponen kayak
storybook atau tadi yang docu sorus,
bisa jadi
readme-readme-nya itu
bisa kita susun, nggak mesti
di folder docu sorus. Tapi readme-nya itu bisa
berasal dari perkomponen
yang kita. Masih-masing repo,
masing-masing folder. Masing-masing package-nya
kita lebih tepatnya. Misalnya plugin atau
package-nya kita,
kita ada readme-nya sendiri. Nanti dari
waktu kita build,
nge-source dari seluruh
readme yang kita punya
di dalam project
dan ngebentuk sebuah aplikasi sendiri.
Jadi, nulisnya
cuma satu tempat. Kalau misalnya
kalau misalnya kita pakainnya
WordPress atau
yang lain yang terpisah, ya
aplikasi
dokumentasinya sendiri
untuk engineer, terus
yang untuk
publik,
nulis lagi, gitu kan. Jadi
double effort.
Dua kali kerja.
Itu
kekurangannya
kalau kita menggunakan
entah itu repo atau web
yang berbeda, atau
pakai tools seperti Notion
dan lain-lain.
Karena ketika
produk kita atau kode kita
berubah, misalkan ada update,
ada tambahan fitur, ada
apa namanya, ada
release yang baru,
itu nggak ke-track.
Nggak ke-track kalau dokumentasinya harus update
juga. Terpisah.
Terpisah. Jadi, semakin
menyulitkan, kecuali
kalau ada tim khusus
yang
handle, atau tetap
aja sih. Tetap
lebih disarankan secara best practice adalah
dia berada di satu tempat supaya
ketika ada update, ini dokumentasinya
juga berasa butuh
untuk di-update.
Nah, ada satu lagi nih, dokumentasi
yang totally different tuh, yang
buatan Google.
Tau? Tau? Tau?
Google Code Lab.
Google Code Lab.
Oh iya, itu unik ya.
Bisa dibilang,
itu kan how-to.
Oh iya, tutorial-nya.
Kan bisa step-by-step.
Iya, format Google Code Lab ini
saya breakthrough lah, menarik.
Bisa nulisnya pakai Google Doc
lagi.
Hah? Iya.
Kalau
ada formatnya ya dari Google Doc,
terus itu tinggal jadi generic,
jadi code lab.
Ada tutorialnya code mana ya?
Google Code Lab.
Jadi yang khas itu kan
format code lab itu adalah
multi-step-nya ya. Sebetulnya
sih, kalau overall kan
nggak beda jauh dari
tadi-tadi yang markdown
base yang kita bahas kan.
Cuma ini tuh kayak ada step-by-step
nya gitu, sama ada indikator
step-nya. Coba cari aja.
Ini random example.
Start.
Ini, ini, ini.
Ini tools untuk
nge-generate code lab.
Lo kok nggak jalan?
Stora saya telat banget ya?
Enggak.
Enggak ya? Enggak.
Saya putus-putus soalnya ini-nya.
Ini tutorial, nggak
step-by-step ini ya?
Itu kok nggak kayak code lab
pada umumnya?
Bukan.
Bukan.
Cari yang web aja.
Web semua. Ini kan udah
kategori web nih.
Oh iya.
Paski, paski.
Ada nggak paski?
Enggak ada.
Mana disini carinya?
Itu
filter webnya di close dulu coba.
Oh ini, ini, ini.
Ini ya?
Sebelah kiri ya?
Harusnya
muncul tuh kan.
Step-stepnya.
Kalau ada teman-teman yang mau bikin
begini.
Ada yang mau bikin gini.
Tools-nya ada tuh.
Di chat ya.
Bisa gen Anda sendiri.
Oh, baru tahu Anda.
Ada formattingnya.
Dia pakai STL-80.
Enggak pakai laptop ya?
Google Doc.
Oh, tetap ya harus ya?
Iya.
Enggak pakai Google Doc.
Nulis seperti biasa. Semua orang bisa
collaborate.
Generate.
Publication pakai zip ya.
Nanti jadinya ini kok.
Jadinya
HTML kok.
Bazel ini apa?
Bazel kan tools,
kayak tools monorepo-nya Google kan?
Oh iya, iya, iya.
Benar, benar, benar.
Dan nggak tahu kenapa, kalau buat
step-by-step itu, formatnya
Codelapse itu
secara mental,
secara sikis kayak ngebantu banget buat
bikin itu, terasa
less overwhelming.
Bahkan dengan, nggak tahu, apa, pendapat
gue sih, bahkan dengan, maksudnya dengan
konten yang sama nih, cuma pakai satu halaman
kayak markdown yang ada
section-sectionnya, ada
apa, yang tadi yang sebelah kanan, sidebar kanan
on this page, itu jadi kerasa
wah, panjang, berat.
Cuma kalau dipecah-pecah
kayak formatnya Codelapse itu
jadi kayak lebih
misalnya kita mau ngasih workshop atau apa,
itu kayak lebih user-friendly aja.
Iya sih,
benar.
Dan ini contohnya, misalnya
walaupun langkah-langkahnya banyak,
itu kayak jadi lebih simple
aja.
Iya, karena kan satu langkah itu
yaudah sih, ini aja gitu, jadi kita nggak
wah, ini panjang banget
gitu ya.
Cuma mental
ini aja.
Ya, tadi kita ngomongin soal
apa namanya,
dokumentasi yang apa,
mengomentari, ada yang
menggunakan notion, ya itu bukan
sesuatu yang salah, tapi
kalau buat developer, ada
artikel yang menarik, namanya
Docs Ask Code, jadi
sebisa mungkin dokumentasi
di apa,
di trade sebagai
code juga.
Kalau bisa dijadikan satu sama codenya.
Jadi,
ke track, ada question controlnya,
terus formatnya ya
markdown yang
paling ini ya, paling
sering digunakan,
terus bisa di code review, dan bisa
di test juga.
Di test dalam artian, misalkan nih, kita punya tutorial
atau punya dokumentasi yang
menjalankan kode.
Dan ketika
sebuah API berubah,
terus kodenya nggak jalan,
itu gimana ngeceknya kalau di notion, bingung kan,
harus copy paste manual, oh ini nggak jalan,
ini ganti, gitu. Tapi kalau misalkan
di, ya
mungkin ada tools tambahan ya, pokoknya
di kode, kita bisa
bikin testnya untuk menjalani,
untuk mengevaluasi
code block, code block,
apakah code blocknya masih jalan, sesuai
dengan API yang
baru atau nggak, kalau
sesuai ya, nggak perlu
di apa, nggak perlu di update,
kalau nggak sesuai, mungkin CI-nya
error, jadi harus di update juga.
Itu kelebihannya sih
di situ ya.
Sama kalau ke pisah, kayak misalnya pakai notion,
itu makin, kalau pas lagi baru
dibikin, itu kan kita masih fresh
bagian ini, misalnya apa,
kode yang ini, dokumentasinya
di sini, halaman ini atau
section ini, kode yang itu,
di section itu
atau halaman itu, coba lihat
kalau udah 6 bulan.
Terus misalnya kita nambah fitur baru
di kode, nah berarti kan
abis itu kayak ada beban mental
pas kita mau update docs kan,
aduh ini mana yang diganti,
nambahinnya di sebelah mana, kayak
hal-hal yang dibilang
teknis, itu kan belum masuk teknis ya, itu
non-technis, nambahinnya di mana,
halaman mana, section mana, itu kayak udah
pikir malas duluan kan.
Iya,
betul. Itulah yang kadang-kadang
yang sering kali membuat
dokumentasi, project dokumentasi
terbengkalai.
Terbengkalai, gara-gara
harus ke sana. Cepet urusin ya.
Cepet ngurusin ya,
jadi sebisa mungkin
semakin dekat ke kode, semakin bagus.
Gue memang
code lab yang gue bikin, ada yang mau liat
ini gak gue drive formatnya.
Mau dong.
Mampung
nemuk nih, mampung nemuk.
Waktu itu, gue juga
sempet
translate PWA ya, kalau gak salah.
Itu pakai code lab juga gak ya?
Jadi,
gue bikinnya gini nih,
pengenalan WordPress untuk
pemula. Pernah
ada di game Jakarta
lah gitu, jadi gue cuma
karena
dia bilang, Mas
Ivan ngadain workshop ya, pengenalan WordPress
untuk pemula, tetapi
satu hari ada 3 sesi
workshop. Gue gimana
ngajarin orang, 3 sesi
workshop. Ya
ujung-ujung gue bikin
konsep, ya udah, gue bikin
code lab-nya, gue sediain laptop-nya,
terus gue suruh aja mereka
ikutin satu-satu,
dan gue jadi instruktor jalan-jalan
bantuin satu-satu, gitu.
Kasih kupon nanti, jadi
tinggal ngikutin ini, sampe
terakhir mereka sudah punya satu
resepnya mereka sendiri, pulangnya,
jadi
workshopnya cuma kayak 1,5 jam,
gitu, ikutin
jadi kontennya
sudah ada.
Wait, ini kok malah jadi kayak agak nyambung sama
topik minggu lalu gak sih?
Apa? Mix dengan
tools buat bikin
slide atau presentasi. Kan sebenernya
in a way, kalau buat pengguna use case yang ini,
itu kayak overlap ya?
Cuma, ini fokus ke
protect. Maksudnya, itu langkah-langkahnya
beneran bisa sambil diprotekin.
Iya, betul.
Google Docs-nya mana?
Ini kan di GitHub ya,
gue post ke GitHub,
github.io, yang
hasil akhirnya kan index.html
doang nih begini.
Hasil akhirnya.
Setelah dibuild.
Dan,
tadaaa!
Ini formatnya.
Sebenernya dia sudah ngasih formatnya,
gue tinggal clone template-nya.
Hal-hal yang di sini tinggal diisi saja.
Yang ini kan
auto build ya,
table of contents.
Menarik ya.
Tinggal ini, tinggal gue isip.
Ini hal satu.
Ini dia convert jadi HTML ya.
Ini dia convert langsung jadi image loh,
otomatis. Ini semua
image-image yang ada di sini.
Gue tinggal masukin file-file di sini.
Pas kita build, dia masukin ke
static assets atau
jadi file-file.
Kekurangannya nggak bisa video.
Jadi kalau mau ada video, jadi GIF aja.
Embed all.
GIF, GIF.
Jadi tinggal
pen-time
nulis di sini,
dan bisa minta
kan bisa masukin durasi
juga nih, berapa lama kira-kira durasinya.
Nanti dia counting itu durasinya.
Ada durasi soalnya di atas.
Oh, terus di total ya?
Ya.
Kalau di paling
depan, kayak
kok nggak ada lagi. Tadi ada sih di atas.
Kalau misalnya di refresh itu ada di atas dia.
Wow!
Ya, tinggal
nulis.
Ya, ya.
Ujung-ujungnya tinggal nulis sih.
Tinggal mainin di konten
aja. Jadi nggak usah
maksudnya nggak usah mikir
markdown, segala macam.
Alternatif pakai code lab ini sebenarnya
menarik juga sih kalau memang mau
bagi
untuk
seorang yang kita mau
ngasih untuk penulis kontennya itu
less technical.
Jadi nggak perlu tau
markdown format.
Biar nggak suruh gitcon, gitcon, blablabla.
Ya.
Berarti sama juga dong kasusnya
kayak tadi ada
yang pakai notion,
kalau orang yang nulis dokumentasinya itu
less technical.
Ya, notionnya bisa dijadiin ini juga kan.
Bisa dijadiin
site juga kan, public site juga kan.
Sama.
Ya, bisa juga di import ke markdown juga bisa sih sebenarnya.
Iya.
Ya.
Dan
terus terangnya solusi ini
jauh lebih mudah buat saya waktu
saya kerjain ini kayak
sistem kebut 2 malam
istilahnya.
Kayak 2 hari lagi mau event,
baru saya mulai
mau pakai tools apa ya, gitu loh.
Lebih cepat ya, karena
kita fokus ke kontennya,
kontennya aja ya.
Iya, kepikiran,
udah mau pakai docusaurus, mau pakai ini,
belum ada tutorial kelihatan, saya belum tau.
Mau pakai docusaurus, atau mau pakai
WordPress. Kalau WordPress, nyari
themes-nya. Aduh, ribet ya.
Pakai apa ya? Pakai apa? Terus
Google Code Lab juga deh, karena udah
pernah tau pakai Google Code Lab, pernah pakai.
Ya udahlah, cepat aja
yang penting konten kan, yang sampai
saat tutup workshop itu
sebenarnya peserta nggak peduli kita mau
pakai. Yang penting mereka bisa
next, next, next, next, jadi sebenarnya kan.
Ya udah.
Code Lab deh.
Ini tutorial ala
SwiftUI, yang mana ya?
Boleh share
URL-nya mungkin,
tapi disamarkan URL-nya.
Kalau langsung URL nggak bisa.
Nah, ini menarik juga nih.
Kalau
buat collaborate antara
front-end dan back-end, lebih cepat pakai
tools kayak Notion nggak sih, dibandingkan
kalau push
atau commit dulu?
Kalau front-end, back-end,
developer sih.
Kalau front-end, back-end, ya swagger tadi.
Kalau dari pengalaman pribadi ya,
maksudnya pengalaman kerja
ya nggak apa-apa, maksudnya code-nya nanti
push deploy belakangan kan nggak
apa-apa sebetulnya.
Kalau pengalaman, pertama
bikin kontraknya dulu di swagger.
Terus
jaman dulu
juga saya pernah pakai
yang namanya Faker.
Jadi ada satu
dummy generator yang sudah
bisa dibikin.
Kita import skema-nya kita ke Faker
itu, nanti
si front-end itu tinggal
pakai endpoint dari Faker.
Jadi di REST API.
Sembari kita build back-end.
Dan kalau sudah jadi,
saat nyambunginnya,
mudah-mudahan yang terjadi adalah
clog.
Jadi tinggal mereka ganti
REST API endpoint
atau GraphQL endpoint-nya,
idealnya
nggak ada bug.
Idealnya langsung connect idealnya.
Meskipun yang
terjadi adalah dari
back-end,
contohnya
data kan kita nggak bisa
selalu tebak. Kalau pakai Faker
selalu ada data-nya.
Meskipun dibilang string
selalu ada.
Jadi kalau pakai Faker itu
misalnya string 150 karakter
dia bakal random
bisa antara 100 atau 150.
Sedangkan saat
kenyataannya
bisa jadi kosong.
Atau bisa jadi lebih.
Jadi
bug-nya itu
banyak yang kenanya
misalnya kayak data-nya nggak ada,
kalau kosong jadinya.
Ternyata kalau kosong alkohilnya
nul atau apa yang beneran
anis-rektif.
Jadi nul, jadi kenapa kan error.
Nah, itu back-end sih
terus yang terjadi.
Itu diware scope dokumentasi sih.
Itu scope endpoint testing.
Kalau itu kan
konteksnya, ya, lanjut-lanjut.
Ya, jadi masalahnya
banyak di sana tuh
setelah kena konten
nyata, terjadilah
bang.
Nggak semuanya Faker bisa
ditercaya.
Betul. Konteksnya kan API
documentation. Gimana kalau
misalkan, ya tadi, tutorial
documentation.
Atau how-to atau apa. Tapi
ada kolaborasi antara front-end sama
back-end.
Umumnya
umumnya
biasanya
kolaborasinya tuh
sering terjadi
dari
si front-end
butuh data
yang
belum ada.
Yang sering terjadi seperti itu.
Contohnya
telah dapat feedback
dari klien, "Oh, di table ini
kolom ini kayaknya salah
sedikit. Lebih bagus kolom ini diganti
data-end ini."
Dan ternyata di rest API
endpoint-nya belum ada data itu.
Jadi
harus minta back-end,
merubah outputnya.
Jadi biasanya
sering seperti itu.
Kalau untuk hubungan
antar back-end dengan front-end.
Kalau kolaborasi
bikin dokumentasi
antara back-end sama front-end.
Belum pernah sih gua.
Dokumentasi itu
milik
beda ini ya,
beda divisinya.
Biasanya defrel ya, defrel.
Lead yang bikin.
Oh, lead. Terus.
Kalau gua malah
belum punya pengalaman
bikin apa pun bikin kode yang
kita pakai orang banyak.
Kerja di tim kecil, keuntungannya adalah
ya karena
yang kode literly cuma 3 orang.
Ya, yang...
Ya, baca aja tuh kode.
Di awal ada kontraknya,
habis itu
mungkin yang
head-to-head sama notion di komentar
di pertanyaan awal tadi,
karena konteksnya kerjaan,
pakai tiket
Gira.
Pakai confluensi, ya nggak harus Gira.
Jadi pakai apapun misalnya.
Buat tracking ya.
Masing-masing orang, front-end, back-end,
ada tiketnya sendiri-sendiri.
Apapun yang relevan
sama kode spesifik kita,
itu taruh di tiket
yang bukan kode ya.
Kalau kode, ya baca sendiri.
Kalau misalnya
props-nya apa aja,
kalau misalnya UI, ya
di JSDoc atau TypeScript Definition-nya
aja. Lagi-lagi karena timnya kecil,
silahkan baca sendiri. Tapi kalau konteks,
ada sesuatu
yang harus dijelasin,
taruh aja di tiketnya.
Terus terakhir, paling ujung banget,
end-to-end testing doang.
Jadi di awal ada kontrak,
di akhir ada end-to-end testing,
kalau ada notes
tentang yang
subjektif, masing-masing gimana kita
develop atau mungkin ada sesuatu yang
tricky atau apa,
update komen-komenan di
tiket JIRA, dan ya itu pokoknya
antara kontrak di awal,
end-to-end testing di akhir,
di tengah-tengah antara tiket JIRA sama
baca kode.
Karena timnya kecil, run-end, back-end-nya
ya baik-baik aja. Tapi belum tahu
kalau 1, timnya besar banget,
dan 2, bikin product
yang dipakai,
bikin library yang dipakai orang banyak.
Nah, itu kan udah rumit lagi.
Itu kan udah diluar
pure perkara kolaborasi
front-end, back-end juga kan, kalau dipakai
orang banyak, use-case-nya banyak,
nah itu baru lebih ribet.
Kalau bikin product
yang dipakai oleh end-user,
terus
pernah bikin dokumentasinya,
ngalamin nggak?
Oh, pernah sih,
tapi dalam skala kecil banget.
Ya, yang bisa di-install
orang, gitu kan.
Itu pas heketonan-heketonan astro
yang menang setengah, apa?
Menang setengah dia.
Menang setengah dia.
Itu bikinnya,
ya bikinnya simple sih,
cuma,
tapi udah cukup memenuhi yang koden
tadi, kayak sintaksinya apa aja,
kenapa dibuat kayak gini,
sama cara pakenya, kayak step-by-step
tutorial, yang nggak ada cuma recipe,
atau how-to. Tapi kan,
kalau itu karena cukup simple,
ya nggak ada kolaborasi
kayak front-end, back-end, atau team-team
yang beda, kan? Orang bikin,
cuma bikin library simple,
bikinnya juga sendiri, ya udah, cukup
straightforward.
Hmm, iya, iya, iya.
Jadi intinya, supaya
ke-track ada, misalkan ada
sesuatu yang special case dan lain-lain,
dokumentasinya ke-track itu, entar
pakai jira, pokoknya
di-track aja, entar pakai jira,
atau tulisan serupa, misalkan
GitHub issue juga bisa, kan?
GitHub issue, itu bisa
dijadikan dokumentasi juga,
atau discussion, atau project.
- Dan jajan lebih sering nggak terdokumentasi
sih, kalau apa, konteks pribadi,
ya apa, janjian
meeting aja udah,
ngobrol doang. - Di GitHub ada
ada wiki soalnya.
- Oh iya, di GitHub ada wiki.
- Wiki ada. Kalau pakai jira,
juga ada konfluensinya, kan, buat bikin
doks, kalau... - Aduh, capek banget,
pakai konfluensi. - Formatinya nggak enak,
kalau bikin tabelnya, kayak...
itu tabel, itu ekspektasinya, kan,
kalau pakai arrow atau tap, itu pindah
sel. Ini nggak pindah sel
atau manualnya gitu.
- Oh iya.
Iya. Nah, ini ada
apa, informasi dari Damar, sudah
dilengkapi. Ini emang Apple
gila sih, bagus banget sih,
kalau ngeliat dokumentasinya.
Mana dia? Duh, kok hilang? Ini.
Nah, ini ya.
Tunggu.
Di bawah ini.
Iya. - Wow.
Apa flashnya
secara visual,
tuh kayak visueli peeling.
- Ini tulisnya apa?
Kita nggak bisa lihat ya, nggak open source ya.
Ini closed source.
Oh iya,
kalau teman-teman, apa,
punya... - Ini pakai swift buatnya,
apa mas?
- Swift web kali.
- Wasm, wasm.
- Ini beneran apa?
- Nggak tahu.
- Ini bener.
Wasm, wasm.
Refresh. Eh?
Nggak ada wasm.
- Nggak ada.
Itu CSS doang kali.
- Pakai view.
- Buat tiko pasang, sungguh bisa.
- Iya.
Buat teman-teman yang punya, apa,
perangkat Apple, yang
Macbook, atau Mac mini, atau
apa, yang
desktop itu,
kalau bingung ya, bingung mau
belajar apa, teman-teman bisa
belajar Swift, si Apple
itu menyediakan namanya Playground.
Ini seru banget.
Kayak main game. Ini bagian dari
tutorial juga kan ya.
Jadi kita belajar kode, sambil
main game, itu bisa di install, ada
di App Store, tinggal download gratis kok.
Di tablet juga ada.
Jadi kalau mau belajar, bingung mau belajar
bahasa apa, belajar Swift dari sini.
- Maksudnya gue bisa kasih anak gue main ini dong.
- Exactly.
- Nanti tiba-tiba jadi developer Swift.
- Nggak apa-apa.
- Terus ngata-ngatain
developer web.
- Nggak apa-apa.
- Dengan kakak sama bapaknya sendiri.
- Oh, pakai view katanya.
Yang tadi pakai view.
Keren juga ya.
Nah ini.
Dan dia kayaknya
target audience-nya itu
anak-anak soalnya game kan.
- Iya, mereka
sedang berusaha mengubah
generasi.
- Iya.
- Nanti dia disuruh jalan kesini
dengan pakai kode
gitu, pokoknya keren lah.
- Niat banget ya. Ini kayak butuh
skill tersendiri buat apa?
- Lego, Lego kan ada juga kan?
Lego begini.
- Dan udah beyond yang tadi
kadren dokumentasi kan, sebenarnya ini tutorial.
Tapi kayak tutorial yang udah
ekstra banget yang butuh skill tersendiri kan
buat nge-breakdown
Swift itu sendiri.
Kan kalau tutorial basic Swift atau
getting started with Swift
itu pasti banyak. Tapi ini nge-breakdown
dalam format game yang
menarik buat banyak orang, termasuk
anak-anak atau orang yang awam loading
udah skill set tersendiri itu kayaknya.
- Yang jelas ini yang bikin
kontennya bukan developer sih.
Ada kolaborasi sama
- Technical writer.
- Ada technical writer. - Atau kayak apa sih?
Kayak human-centric design, blablabla.
Itu loh yang punya yang jenis-jenis
yang title-nya aneh-aneh.
- Ada
- Instructor something gitu.
Instructor apa gitu. Ada itu istilahnya tuh.
Jadi dia memang tugasnya untuk
mendesain sebuah
pembelajaran dari A sampai
Z sampai Finis.
Dari start sampai Finis bentuknya
terus pasti aset-asetnya
ini yang susah kan.
Susah dibikin gitu.
Terus jalan ceritanya
dan lain-lain. Jadi ya
memang ini
udah di luar ranah kita.
Tapi ya, patut dicoba.
Karena tutorial juga bagian dari tutorial.
-
Gue tadi barusan ngomong soal Lego
juga ada Lego education kan.
Begitu liat harganya
kok mahal.
- Pendidikan itu
investasi mahal.
- Tidak. Lagipun kok sih. Apa tadi
technical writer, blablabla.
- Tapi nggak lima ribu dolar juga kan.
Ada sih yang
900an atau 200an dolar.
Tapi lima ribu dolar.
- Legonya sendiri ada costnya.
Itu buat tadi yang kayak
expertisnya
blablablanya mahal.
- Ini masalah wipe-nya tadi.
Karena dia ada
layout shift-nya banyak banget.
Waktu gue buka di mobile.
Yang muncul dulu itu
yang lima ribu dolar.
Ah, lima ribu dolar.
Tapi setelah dibiarin, baru
muncul yang lain-lain.
- Yang 100 dolar. Nah itu
CLS-nya bukan CLS karena kesalahan
nggak ngerti. - Emang sengaja kali ya.
- Orang
by now.
Segampang itu.
- Iya. Ini juga salah satu
problem ya. Kalau pakai notion
atau apapun di luar kode yang dibuat
back-end atau front-end
atau apapun biasanya suka beda.
Makanya semakin dekat kodenya
dengan dokumentasi itu semakin bagus.
Jadi dia menghindari hal-hal seperti itu.
Oke.
- Cukup.
Cukup dan kita menang 2-0.
- Iya.
Tapi kartu merah satu.
- Oh.
Kartu merah tuh di hitungnya
nggak boleh mainnya. Berapa kali sih?
Satu kali atau dua kali ke depan?
- Dua.
Kartu kuning dua kali,
satu kali.
- Oke deh. Kalau gitu
terima kasih buat semuanya
yang sudah ikut Nimrung malam hari ini.
Ada banyak
tools yang bisa kita cobain
untuk ke depannya. Apalagi
kalau teman-teman yang butuh buat dokumentasi
untuk internal ataupun untuk end user.
Kita ketemu lagi minggu depan dengan
topik yang berbeda. Selamat malam.
Selamat istirahat. Sampai jumpa.
- Bye bye.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://ksana.in/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
12 Sep 2025
Ngobrolin Dokumentasi
Episode ini membahas pentingnya dokumentasi dalam pengembangan software. Para host berdiskusi tentang berbagai jenis dok...
6 Sep 2023
Ngobrolin AI
Episode ini mengambil sudut berbeda dari kebanyakan pembicaraan soal AI: bukan apakah ia akan menggantikan kita, melaink...
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...
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 .