Performa menurun, pekerjaan pemeliharaan menjadi lebih sulit, dan saat terjadi gangguan ada banyak titik pengelolaan sehingga pelacakan penyebabnya menjadi sulit.
Ini menimbulkan situasi yang benar-benar berlawanan dengan tujuan asli k8s, yaitu mengurangi titik pengelolaan dan menekan beban kerja operasional.
Ah, setelah membaca artikelnya sedikit lebih jauh, sepertinya saya bingung karena ada pembahasan bahwa editornya menjadi lebih cepat.
tsc menjadi 10 kali lebih cepat. Artinya, waktu transpiling dari ts -> js berkurang sangat banyak.
Saat memuat proyek besar yang dikembangkan dengan ts seperti VSCode, kecepatannya menjadi jauh lebih tinggi. Artinya, logika yang berbagi fungsi tsc, seperti pemeriksaan sintaks ts, juga menjadi lebih cepat.
Bukan berarti VSCode berjalan lebih cepat
Jadi ternyata isinya seperti itu.
Saya jarang memakainya karena Cmd+K di vscode sudah saya ganti menjadi Cmd+R, tapi semua orang terus bersaksi soal peningkatan produktivitas. Huh, apa saya harus pindah juga?
Cerita serupa juga muncul di buku <The Phoenix Project> yang sudah beberapa kali disebut di GeekNews. Semakin mendekati kapasitas 100%, waktu respons akan bertambah secara eksponensial.
Saya sepenuhnya setuju dengan poin yang diajukan dalam tulisan ini, sekaligus setuju dengan masalah yang Anda sampaikan.
Ini juga merupakan poin yang benar-benar sedang saya pikirkan.
Memang berbeda di tiap squad, tetapi jika anggota tim dilibatkan secara aktif dalam sprint planning, masalah yang Anda sebutkan itu tidak benar-benar muncul. Sambil membagikan konteks proyek dan situasi yang berubah di setiap sprint agar mereka bisa cukup menyadari perubahan pekerjaan, saya juga meminta agar pekerjaan dibagi dan dipecah dengan sangat rinci.
Seperti yang Anda katakan, dari sisi pengelolaan, kalau memikirkan progres, pengukuran kecepatan kerja, penanganan situasi tak terduga, dan biaya peluang ketika isi pekerjaan tidak berjalan sesuai maksud, pada akhirnya memang pekerjaan perlu dipecah kecil-kecil agar bisa berjalan dengan baik.
Sebagai seseorang yang bekerja di bidang ilmu hayati, saya ingin membagikan hasil penggunaan singkat saya.
Mode research tersedia dalam 2 jenis.
Quick summary
Waktu yang dibutuhkan sekitar 5~6 menit (berdasarkan 4070 ti super, 16GB, Mistral dan Gemma 3:12b)
Ada gejala halusinasi sehingga Reference dibuat sendiri, tetapi Ref yang ditautkan di dokumen tampaknya memiliki sumber yang jelas.
Ada kecenderungan untuk menjawab pertanyaan dengan fokus pada teknologi baru. Terutama mencoba mengaitkannya dengan AI.
Detailed Report
Waktu yang dibutuhkan sekitar 1 jam (4070 ti super 16GB, Gemma 3:12b)
Ini seperti membuat satu paper ulasan. Namun, ada masalah jumlah Reference berkurang drastis. Meskipun isinya benar, tanpa dasar yang bisa ditunjukkan jadi perlu sedikit perbaikan. (Sepertinya proses iterasi dilakukan untuk meningkatkan kualitas tulisan, tetapi dalam proses ini Ref link tampaknya hilang.)
Namun, jelas memberikan konten dengan kualitas lebih tinggi daripada Quick summary.
Di file config, berbagai pengaturan bisa dilakukan. Database pencarian bisa dibatasi hanya ke PubMed sehingga kualitas materi dapat ditingkatkan lebih jauh. Kita juga bisa mengatur teks yang dicari sekaligus atau berapa banyak chunk yang akan dibuat saat menggunakan RAG.
Mengingat saat ini masih 0.01V, sangat mengejutkan bahwa mesin lokal bisa menghasilkan laporan sampai tingkat seperti ini. Khususnya di bidang ilmu hayati, chatbot sering menggunakan deskripsi yang digeneralisasi, tetapi laporan yang dibuat melalui program ini menggunakan deskripsi yang sangat ilmiah.
Program ini saat ini belum mendukung bahasa Korea. Bahkan jika pertanyaan diajukan dalam bahasa Korea, laporan tetap keluar dalam bahasa Inggris.
Selain itu, saat menerima jawaban sebagai file PDF melalui ekspor PDF, ada masalah bahwa bahasa Korea tidak muncul.
Saya rasa ini akan menjadi alat yang sangat kuat jika masalah Ref yang hilang di tengah pembuatan laporan dan masalah halusinasi bisa diselesaikan.
Kalau harus mengorbankan dukungan regex tetapi hanya 2 kali lebih cepat daripada ripgrep, kegunaannya jadi agak terbatas juga.
Saya sepertinya akan tetap memakai ripgrep yang mendukung regex.
Secara pribadi, dalam beberapa kasus type di ts menjadi sangat rumit... sampai-sampai hampir menyerah (akhirnya langsung pakai any), tapi mungkin itu karena pemahaman saya tentang bahasanya masih kurang, ya? Tergantung situasinya, saya benar-benar sering membuang banyak waktu hanya untuk menghilangkan garis merah.
Kami berusaha menyisakan 80% untuk pekerjaan dan 20% sebagai ruang longgar, tetapi setiap kali tetap bingung harus memakai patokan apa.. Kadang juga terpikir apakah sebaiknya dihitung hanya berdasarkan waktu saja.
Saat sempat tinggal sekitar satu tahun di Shanghai, saya pernah jalan-jalan ke Hangzhou (waktu itu untuk menonton semacam pertunjukan impresi), dan saya merasa kotanya bersih, pemandangan Danau Barat juga indah, jadi benar-benar tampak seperti tempat yang enak untuk ditinggali. Sekarang rupanya tempat itu juga sudah menjadi lokasi yang bagus untuk berbisnis.
Performa menurun, pekerjaan pemeliharaan menjadi lebih sulit, dan saat terjadi gangguan ada banyak titik pengelolaan sehingga pelacakan penyebabnya menjadi sulit.
Ini menimbulkan situasi yang benar-benar berlawanan dengan tujuan asli k8s, yaitu mengurangi titik pengelolaan dan menekan beban kerja operasional.
Ah, setelah membaca artikelnya sedikit lebih jauh, sepertinya saya bingung karena ada pembahasan bahwa editornya menjadi lebih cepat.
tscmenjadi 10 kali lebih cepat. Artinya, waktu transpiling darits->jsberkurang sangat banyak.tsseperti VSCode, kecepatannya menjadi jauh lebih tinggi. Artinya, logika yang berbagi fungsitsc, seperti pemeriksaan sintaksts, juga menjadi lebih cepat.Jadi ternyata isinya seperti itu.
Saya jarang memakainya karena
Cmd+Kdi vscode sudah saya ganti menjadiCmd+R, tapi semua orang terus bersaksi soal peningkatan produktivitas. Huh, apa saya harus pindah juga?Cerita serupa juga muncul di buku <The Phoenix Project> yang sudah beberapa kali disebut di GeekNews. Semakin mendekati kapasitas 100%, waktu respons akan bertambah secara eksponensial.
Saya sepenuhnya setuju dengan poin yang diajukan dalam tulisan ini, sekaligus setuju dengan masalah yang Anda sampaikan.
Ini juga merupakan poin yang benar-benar sedang saya pikirkan.
Memang berbeda di tiap squad, tetapi jika anggota tim dilibatkan secara aktif dalam sprint planning, masalah yang Anda sebutkan itu tidak benar-benar muncul. Sambil membagikan konteks proyek dan situasi yang berubah di setiap sprint agar mereka bisa cukup menyadari perubahan pekerjaan, saya juga meminta agar pekerjaan dibagi dan dipecah dengan sangat rinci.
Seperti yang Anda katakan, dari sisi pengelolaan, kalau memikirkan progres, pengukuran kecepatan kerja, penanganan situasi tak terduga, dan biaya peluang ketika isi pekerjaan tidak berjalan sesuai maksud, pada akhirnya memang pekerjaan perlu dipecah kecil-kecil agar bisa berjalan dengan baik.
Saya tidak paham. Jangankan level akademik, ini bahkan tidak sampai level coding anak SD, jadi kenapa dibagikan...
teknologi baru. Terutama mencoba mengaitkannya dengan AI.Di file config, berbagai pengaturan bisa dilakukan. Database pencarian bisa dibatasi hanya ke PubMed sehingga kualitas materi dapat ditingkatkan lebih jauh. Kita juga bisa mengatur teks yang dicari sekaligus atau berapa banyak chunk yang akan dibuat saat menggunakan RAG.
Mengingat saat ini masih 0.01V, sangat mengejutkan bahwa mesin lokal bisa menghasilkan laporan sampai tingkat seperti ini. Khususnya di bidang ilmu hayati, chatbot sering menggunakan
deskripsi yang digeneralisasi, tetapi laporan yang dibuat melalui program ini menggunakan deskripsi yang sangat ilmiah.Program ini saat ini belum mendukung bahasa Korea. Bahkan jika pertanyaan diajukan dalam bahasa Korea, laporan tetap keluar dalam bahasa Inggris.
Selain itu, saat menerima jawaban sebagai file PDF melalui ekspor PDF, ada masalah bahwa bahasa Korea tidak muncul.
Saya rasa ini akan menjadi alat yang sangat kuat jika masalah Ref yang hilang di tengah pembuatan laporan dan masalah halusinasi bisa diselesaikan.
wkwkwkwk
Saya merasa lelah dengan banyaknya plugin di Obsidian
jadi beralih ke Reflect, dan saya sangat puas
Sejak suatu titik, saya jadi makin jarang menyentuh TS, tapi melihat kabar seperti ini rasanya jadi tertarik lagi, ya?
Jadi, saya memang mengosongkan Jumat sore sepenuhnya untuk waktu pengembangan pribadi!
Saya sangat setuju dengan komentar ini. Ada/sempat ada risiko terjadinya micromanagement pada bagian teknis. Memang tidak mudah.
Kalau harus mengorbankan dukungan regex tetapi hanya 2 kali lebih cepat daripada ripgrep, kegunaannya jadi agak terbatas juga.
Saya sepertinya akan tetap memakai ripgrep yang mendukung regex.
GOAT.. ngeri
Perkembangan Tiongkok benar-benar ngeri ya wkwk
Secara pribadi, dalam beberapa kasus type di ts menjadi sangat rumit... sampai-sampai hampir menyerah (akhirnya langsung pakai
any), tapi mungkin itu karena pemahaman saya tentang bahasanya masih kurang, ya? Tergantung situasinya, saya benar-benar sering membuang banyak waktu hanya untuk menghilangkan garis merah.Kami berusaha menyisakan 80% untuk pekerjaan dan 20% sebagai ruang longgar, tetapi setiap kali tetap bingung harus memakai patokan apa.. Kadang juga terpikir apakah sebaiknya dihitung hanya berdasarkan waktu saja.
Saat sempat tinggal sekitar satu tahun di Shanghai, saya pernah jalan-jalan ke Hangzhou (waktu itu untuk menonton semacam pertunjukan impresi), dan saya merasa kotanya bersih, pemandangan Danau Barat juga indah, jadi benar-benar tampak seperti tempat yang enak untuk ditinggali. Sekarang rupanya tempat itu juga sudah menjadi lokasi yang bagus untuk berbisnis.
Tidak ada pembahasan tentang performa bahasa Korea, tetapi setelah saya coba hasilnya tampak tidak buruk.
Kalau dilengkapi fitur untuk menghindari pencegahan macro, sepertinya akan jadi pemenang di pasar.