Saya tidak mengerti kenapa metodologi diperlakukan seperti kitab suci. Menurut saya, penulis aslinya juga sama-sama dogmatis, hanya arahnya saja yang berbeda.
Begitu memilih SQLite untuk server produksi, sejak saat itu kita harus terus-menerus memikirkan kapan harus pindah.
Dulu biaya DB itu sendiri (biaya pembelian server, IDC, biaya lisensi, dll.) mahal sehingga layak dipertimbangkan,
namun sekarang katanya bisa dibangun hanya dengan sekali klik, jadi apakah benar masih perlu dipikirkan?
Pesan yang tersisa bagi kita juga besar hanya dari upaya mendobrak pengambilan keputusan yang vertikal dan perbaikan berulang dalam siklus pendek saja (tentu saja hal yang sama juga berlaku untuk teknik/alat manajemen proyek).
Kesimpulan yang 'mengatakan bahwa agile sendiri tidak mampu memberikan wawasan baru, serta menggiring seluruh orang yang membela agile sebagai fanboy agile yang buta' tampaknya agak berlebihan.
Saya membacanya dengan baik. Termasuk yang Anda tulis di blog. Saya tidak yakin apakah analogi ini tepat, tetapi saya jadi berpikir bahwa alasan tutorial pertama hampir semua bahasa adalah Hello World!, dan proses belajar web development di masa lalu sambil membuat forum dan toko online, pada akhirnya sejalan dengan apa yang Anda katakan. Dulu saya pernah berpikir seperti ini: jika memiliki teknik yang cukup untuk membuat forum dan toko online, maka sebagian besar web pada dasarnya bisa diimplementasikan. Dan pada akhirnya, pemrograman itu pada dasarnya hanya memiliki input dan output.
Kesimpulannya terasa agak berlebihan. Komersialisasi atau formalisasi mungkin bisa jadi masalah, tetapi bukan berarti alat seperti sprint atau backlog sudah tidak berguna. Itu juga membantu membentuk budaya rapat yang lebih horizontal dan berfokus pada tujuan. Memang benar SDD menjadi lebih penting, tetapi karena spesifikasi itu sendiri bisa ditulis dengan cepat secara kolaboratif bersama AI, itu tetap agile. Hanya saja sprint dua minggu dipersingkat menjadi beberapa jam; esensi iteratif untuk terus menyempurnakan tetap sama, menurut saya.
Tulisan yang bodoh. Intinya justru spec. itu sendiri harus ditulis secara agile... Agile adalah soal cepat berubah dan beradaptasi terhadap kebutuhan pelanggan.
Karena orang-orang yang punya kesalahpahaman seperti ini tentang agile dan imajinasi setengah matang, baik agile maupun budaya pengembangan jadi berjalan ke arah yang salah.
Dalam ukuran tertentu, semua orang itu agile. Rasanya belum pernah ada zaman seperti sekarang, ketika kita bisa merilis secepat ini dan menerima umpan balik.
Karena bukan berarti kita sama sekali tidak perlu membaca kode, dari sudut pandang ini ungkapan bahwa kode lebih penting daripada dokumentasi tampaknya memang valid. Dan karena dokumentasi sebagai instruksi harus dibaca oleh LLM sebagai pihak yang mengimplementasikan, dari sudut pandang ini saya juga setuju. Jadi kesimpulannya, bukankah keduanya sama-sama penting pada saat yang sama?
Masalah produk yang dihasilkan LLM saat ini adalah utang teknis yang menumpuk pada tahap operasional. Untuk operasional yang berkelanjutan, developer harus terlibat pada kode, dan untuk itu, setidaknya sampai sekarang, saya pikir kode masih harus bisa menggantikan dokumentasi.
Masalahnya bukan karena libhwp adalah alasan yang menentukan, melainkan kelompok sampah itu yang lebih bermasalah. Tidak ada subjeknya; kalau membaca itu lalu marah, ya itu kamu.
Saya mungkin belum memahaminya dengan tepat, tetapi rasanya saya kira saya menangkap inti nuansanya.
Terima kasih.
Saya tidak mengerti kenapa metodologi diperlakukan seperti kitab suci. Menurut saya, penulis aslinya juga sama-sama dogmatis, hanya arahnya saja yang berbeda.
Begitu memilih SQLite untuk server produksi, sejak saat itu kita harus terus-menerus memikirkan kapan harus pindah. Dulu biaya DB itu sendiri (biaya pembelian server, IDC, biaya lisensi, dll.) mahal sehingga layak dipertimbangkan, namun sekarang katanya bisa dibangun hanya dengan sekali klik, jadi apakah benar masih perlu dipikirkan?
Tulisan ini sendiri tidak lincah!
Saya setuju.
Pesan yang tersisa bagi kita juga besar hanya dari upaya mendobrak pengambilan keputusan yang vertikal dan perbaikan berulang dalam siklus pendek saja (tentu saja hal yang sama juga berlaku untuk teknik/alat manajemen proyek).
Kesimpulan yang 'mengatakan bahwa agile sendiri tidak mampu memberikan wawasan baru, serta menggiring seluruh orang yang membela agile sebagai fanboy agile yang buta' tampaknya agak berlebihan.
Akan bagus kalau codex juga mendukung token OAuth seperti claude.
Saya membacanya dengan baik. Termasuk yang Anda tulis di blog. Saya tidak yakin apakah analogi ini tepat, tetapi saya jadi berpikir bahwa alasan tutorial pertama hampir semua bahasa adalah
Hello World!, dan proses belajar web development di masa lalu sambil membuat forum dan toko online, pada akhirnya sejalan dengan apa yang Anda katakan. Dulu saya pernah berpikir seperti ini: jika memiliki teknik yang cukup untuk membuat forum dan toko online, maka sebagian besar web pada dasarnya bisa diimplementasikan. Dan pada akhirnya, pemrograman itu pada dasarnya hanya memiliki input dan output.Kesimpulannya terasa agak berlebihan. Komersialisasi atau formalisasi mungkin bisa jadi masalah, tetapi bukan berarti alat seperti sprint atau backlog sudah tidak berguna. Itu juga membantu membentuk budaya rapat yang lebih horizontal dan berfokus pada tujuan. Memang benar SDD menjadi lebih penting, tetapi karena spesifikasi itu sendiri bisa ditulis dengan cepat secara kolaboratif bersama AI, itu tetap agile. Hanya saja sprint dua minggu dipersingkat menjadi beberapa jam; esensi iteratif untuk terus menyempurnakan tetap sama, menurut saya.
Tulisan yang bodoh. Intinya justru
spec.itu sendiri harus ditulis secara agile... Agile adalah soal cepat berubah dan beradaptasi terhadap kebutuhan pelanggan.Karena orang-orang yang punya kesalahpahaman seperti ini tentang agile dan imajinasi setengah matang, baik agile maupun budaya pengembangan jadi berjalan ke arah yang salah.
Omong kosong apa ini
dikira orang pakai db karena performa?
Tautannya salah mengarah ke domain
com.Ini tautan pengumuman terkait.
[Pemberitahuan] 04/16 (Kam) Terjadi isu akses layanan ▶ Selesai ditangani
Kita bisa saja hidup tanpa kulkas, tapi pasti ada ketidaknyamanan.
Kalau bisa pakai kulkas, tidak ada alasan untuk tidak memakainya.
Benar juga, ternyata bukan Apache 2.0
Terima kasih!!
Lisensinya berbeda dengan gemma4 yang asli.
Parahnya, ini sepertinya yang paling sering saya lihat...
Wah, waktu saya melihatnya pada tahun 2020, belum banyak library yang bisa menangani HWP, tetapi belakangan ini jumlahnya meningkat secara eksplosif.
Dalam ukuran tertentu, semua orang itu agile. Rasanya belum pernah ada zaman seperti sekarang, ketika kita bisa merilis secepat ini dan menerima umpan balik.
Karena bukan berarti kita sama sekali tidak perlu membaca kode, dari sudut pandang ini ungkapan bahwa kode lebih penting daripada dokumentasi tampaknya memang valid. Dan karena dokumentasi sebagai instruksi harus dibaca oleh LLM sebagai pihak yang mengimplementasikan, dari sudut pandang ini saya juga setuju. Jadi kesimpulannya, bukankah keduanya sama-sama penting pada saat yang sama?
Masalah produk yang dihasilkan LLM saat ini adalah utang teknis yang menumpuk pada tahap operasional. Untuk operasional yang berkelanjutan, developer harus terlibat pada kode, dan untuk itu, setidaknya sampai sekarang, saya pikir kode masih harus bisa menggantikan dokumentasi.
Masalahnya bukan karena
libhwpadalah alasan yang menentukan, melainkan kelompok sampah itu yang lebih bermasalah. Tidak ada subjeknya; kalau membaca itu lalu marah, ya itu kamu.