Saya juga setuju. Dalam layanan, DB kadang dinilai lebih penting daripada yang sebenarnya diperlukan, dan terkadang ada investasi desain yang berlebihan seolah-olah jika normalisasi rusak maka akan jadi masalah besar.
Bukan berarti jangan memakai DB, tetapi cukup bagus jika kita menyegarkan cara pandang tentang mengapa kita memakainya dan apa sebenarnya inti mendasar dari sebuah layanan.
Seperti biasa, yang penting adalah keseimbangan.
Benar juga. Saat jumlah pengguna masih belum banyak di tahap awal bisnis, ini bisa dianggap sebagai usulan bahwa alih-alih membeli DB atau membuatnya rumit, bisnis bisa berjalan sampai mapan hanya dengan file I/O dasar.
Menurut saya ini tulisan yang sangat bagus. Terutama materi yang memuat 'angka' seperti itu memang langka. Di zaman ketika sulit menemukan developer yang setidaknya punya 'gambaran kasar' tentang overhead dari kode yang kita buat dan tech stack yang kita pakai, saya membacanya dengan senang hati.
Analogi itu tampaknya tepat. Proyek saya juga pada dasarnya hanya terdiri dari dua hal: Intent manusia dan Snapshot.
Pada akhirnya, saya merasa arah yang harus dituju proyek saya adalah bagaimana menghitung niat manusia (mis. input keyboard, klik mouse) dan memberinya makna tertentu.
Konsepnya memang menarik, tapi dari pengalaman, belum banyak upaya ideal seperti ini yang benar-benar berhasil..
Untuk saat ini, sepertinya Feedly masih yang paling aman, dengan fitur AI yang juga bagus.
Itu adalah isi yang pada dasarnya muncul di sebagian besar buku tentang teknik Agile, seperti Extreme Programming dari Kent Beck dan Scrum dari Jeff Sutherland. Anda juga bisa melihat user story. Kebanyakan orang tampaknya tidak benar-benar memahami bahwa fondasi Agile adalah sprint pendek dan demo untuk beradaptasi dengan cepat terhadap kebutuhan pelanggan.
Saya memahami dan setuju dengan pendapat yang Anda sampaikan.
Jelas ada bagian-bagian yang tidak bisa digantikan oleh kode.
Dalam konteks itu, jika saya jelaskan dengan sedikit berbeda, yang ingin saya sampaikan adalah bahwa kode yang memiliki keterbacaan tinggi membuat kita tidak perlu menghasilkan dokumentasi.
Dokumen yang menumpuk seiring perangkat lunak berjalan dalam jangka panjang juga menambah beban kognitif bagi developer. Intinya adalah mengurangi pekerjaan bolak-balik antara kode dan dokumen.
Saya tidak berpikir bahwa pada akhirnya kita bisa hanya menyisakan kode saja.
Menurut saya, ini bisa berbeda tergantung konteks dan situasi yang dihadapi.
Terima kasih atas komentarnya.
Kalau saya menyampaikan sanggahan ini dengan hati-hati, saya berpendapat bahwa kode tidak bisa menggantikan dokumentasi. Sampai sekarang, programming language masih belum memiliki kekayaan ekspresi dan daya penyampaian bahasa alami, dan secara realistis, siapa yang sempat membaca kode sebanyak itu?
Berharap memiliki kode yang bisa menggantikan dokumentasi memang adalah harapan dan angan-angan, tetapi itu seperti Menara Babel yang tak akan pernah bisa dicapai.
Menurut saya, lebih baik serius mendalami OOAD.
Menulis spec persis seperti yang didiktekan pelanggan.
Saat kebutuhan pelanggan berubah, memeliharanya dengan bantuan alat agar spec bisa cepat diubah.
Menulis spec secara agile.
Inti tulisan itu dari awal adalah bahwa penulis sendiri tidak tahu sebenarnya agile itu apa. Mereka hanya terus bicara bahwa agile punya karakteristik seperti ini dan harus dilakukan begini begitu, tetapi saya belum pernah melihat tulisan yang benar-benar menunjukkan, “ini adalah produk yang dibuat dengan metodologi agile.” Bahkan saat melihat manifestonya pun rasanya masih samar. Mungkin bisa ditunjukkan sekali?
Saya juga setuju. Dalam layanan, DB kadang dinilai lebih penting daripada yang sebenarnya diperlukan, dan terkadang ada investasi desain yang berlebihan seolah-olah jika normalisasi rusak maka akan jadi masalah besar.
Bukan berarti jangan memakai DB, tetapi cukup bagus jika kita menyegarkan cara pandang tentang mengapa kita memakainya dan apa sebenarnya inti mendasar dari sebuah layanan.
Seperti biasa, yang penting adalah keseimbangan.
Di dalam negeri, agile tidak lebih dan tidak kurang dari sekadar alat untuk menekan jadwal para developer.
Oh.. bagus juga. Selama ini belum ada, jadi aku cuma bikin dan pakai aplikasi shortcut saja
Benar juga. Saat jumlah pengguna masih belum banyak di tahap awal bisnis, ini bisa dianggap sebagai usulan bahwa alih-alih membeli DB atau membuatnya rumit, bisnis bisa berjalan sampai mapan hanya dengan file I/O dasar.
Balasan-balasan permatanya juga bonus.
Menurut saya ini tulisan yang sangat bagus. Terutama materi yang memuat 'angka' seperti itu memang langka. Di zaman ketika sulit menemukan developer yang setidaknya punya 'gambaran kasar' tentang overhead dari kode yang kita buat dan tech stack yang kita pakai, saya membacanya dengan senang hati.
Analogi itu tampaknya tepat. Proyek saya juga pada dasarnya hanya terdiri dari dua hal: Intent manusia dan Snapshot.
Pada akhirnya, saya merasa arah yang harus dituju proyek saya adalah bagaimana menghitung niat manusia (mis. input keyboard, klik mouse) dan memberinya makna tertentu.
Saya sempat mau datang menulis setelah melihat peluncurannya, tapi ternyata sudah ada yang menulisnya. Saya penasaran seberapa bagus performanya.
Karena kode lama masih tersisa, Anda bisa memeriksa langsung implementasinya seperti apa.
https://gitlab.com/sebuls/libhwp
Konsepnya memang menarik, tapi dari pengalaman, belum banyak upaya ideal seperti ini yang benar-benar berhasil..
Untuk saat ini, sepertinya Feedly masih yang paling aman, dengan fitur AI yang juga bagus.
rip
Itu adalah isi yang pada dasarnya muncul di sebagian besar buku tentang teknik Agile, seperti Extreme Programming dari Kent Beck dan Scrum dari Jeff Sutherland. Anda juga bisa melihat user story. Kebanyakan orang tampaknya tidak benar-benar memahami bahwa fondasi Agile adalah sprint pendek dan demo untuk beradaptasi dengan cepat terhadap kebutuhan pelanggan.
Saya memahami dan setuju dengan pendapat yang Anda sampaikan.
Jelas ada bagian-bagian yang tidak bisa digantikan oleh kode.
Dalam konteks itu, jika saya jelaskan dengan sedikit berbeda, yang ingin saya sampaikan adalah bahwa kode yang memiliki keterbacaan tinggi membuat kita tidak perlu menghasilkan dokumentasi.
Dokumen yang menumpuk seiring perangkat lunak berjalan dalam jangka panjang juga menambah beban kognitif bagi developer. Intinya adalah mengurangi pekerjaan bolak-balik antara kode dan dokumen.
Saya tidak berpikir bahwa pada akhirnya kita bisa hanya menyisakan kode saja.
Menurut saya, ini bisa berbeda tergantung konteks dan situasi yang dihadapi.
Terima kasih atas komentarnya.
Ini cuma terasa seperti perubahan cara berpikir, tapi kalian semua sensitif sekali ya.
Saya juga harus mencobanya sekali.
Terima kasih atas informasinya yang bagus.
Kalau saya menyampaikan sanggahan ini dengan hati-hati, saya berpendapat bahwa kode tidak bisa menggantikan dokumentasi. Sampai sekarang,
programming languagemasih belum memiliki kekayaan ekspresi dan daya penyampaian bahasa alami, dan secara realistis, siapa yang sempat membaca kode sebanyak itu?Berharap memiliki kode yang bisa menggantikan dokumentasi memang adalah harapan dan angan-angan, tetapi itu seperti Menara Babel yang tak akan pernah bisa dicapai.
Menurut saya, lebih baik serius mendalami OOAD.
Apa maksudnya menulis
specsecara agile?specsecara asal.specpersis seperti yang didiktekan pelanggan.specbisa cepat diubah.specsecara agile.Inti tulisan itu dari awal adalah bahwa penulis sendiri tidak tahu sebenarnya agile itu apa. Mereka hanya terus bicara bahwa agile punya karakteristik seperti ini dan harus dilakukan begini begitu, tetapi saya belum pernah melihat tulisan yang benar-benar menunjukkan, “ini adalah produk yang dibuat dengan metodologi agile.” Bahkan saat melihat manifestonya pun rasanya masih samar. Mungkin bisa ditunjukkan sekali?
BckHWP. Otomatisasi Excel VBA
https://m.blog.naver.com/husky81/222045248589
Gemini CLI sih bakal bagus kalau bisa jalan dengan benar, tapi hampir selalu ngadat.
Akhir-akhir ini saya lebih sering melihat kasus seperti ini.