Sepertinya itu diimplementasikan dengan radix sort di CUDA; saya juga pernah punya pengalaman mengimplementasikan hal yang sama sebagai referensi.

Saya juga merekomendasikan situs web https://cursor.directory/ untuk Cursor rules.

Mungkin karena kebanyakan belajar dari komentar seperti itu...........? 🥲?
Komentar seperti "yang begini sih harus kamu kerjakan sendiri" juga bejibun di SOF maupun reddit..? 🥲???

Oh, ini seru juga.

Saya kira mereka benar-benar mengimplementasikan editor gambar sendiri, tetapi ternyata hanya memakai library open source sederhana dan cuma melakukan beberapa pengaturan saja.

https://github.com/scaleflex/filerobot-image-editor

Saya sempat bingung ini ngomong apa, lalu langsung ngakak. "Sepertinya dia tidak begitu paham untuk apa LLM itu" wkwk.
Apa kita sedang menuju era di mana orang dibayar untuk ngoding, tapi pekerjaannya malah tidak dikerjakan ya..

Saya sering sekali melihat klaim bahwa penggunaan AI membuat kemampuan developer junior menurun, jadi rasanya akan menarik kalau ada tulisan terkait yang membahas apakah memang benar begitu.
Tulisan yang bagus, saya membacanya dengan senang hati :)

https://github.com/addyosmani/filter

Ini Wilson!

Cursor memang bagus, tapi... buat saya yang bekerja di beberapa perangkat
cukup disayangkan karena tidak ada fitur sinkronisasi pengaturan.

Katanya ada trik dengan menyinkronkan extension atau file pengaturan itu sendiri
dari network drive lewat symbolic link,
tapi di VSCode sinkronisasi bisa dilakukan cukup sekali klik, jadi rasanya agak merepotkan kalau harus melewati proses seperti itu.

Sudah ganti dari VS Code yang saya pakai 5 tahun, dan bagus.

Keren. Kalau sqlite melakukan hal seperti ini, rasanya bakal benar-benar heboh. Tentu saja, bersama celah keamanan juga.

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.

Saya tidak paham. Jangankan level akademik, ini bahkan tidak sampai level coding anak SD, jadi kenapa dibagikan...

• Sebagai seseorang yang bekerja di bidang ilmu hayati, saya ingin membagikan hasil penggunaan singkat saya.

Mode research tersedia dalam 2 jenis.

1. 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.

2. 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.

wkwkwkwk