1) Meragukan kredibilitas tulisan: terasa seperti pemasaran/konten buatan AI
Inti
“Ini terlalu rapi seperti drama penuh pelajaran moral” → muncul kecurigaan bahwa kalimatnya dioptimalkan sebagai ‘moral play’ yang disukai HN
Di isi utama ditempeli banyak sekali tautan ke materi berbayar, jadi sentimen “jangan-jangan ini cuma tulisan sales” cukup kuat
Gaya penulisan yang kebanyakan daftar/emoji juga ditunjuk sebagai sinyal “AI slop (konten AI asal jadi)”
Kutipan tajam soal fakta (terjemahan)
“Kelihatannya keseluruhan tulisan ini cuma dibuat untuk menjual materi berbayar yang ditautkan. Dan terasa seperti AI slop dengan semua daftar itu.”
(teks asli: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)
Komentar singkat
“Sebelum bicara isinya benar atau salah, bau jualan + bau AI-nya terlalu kuat” adalah reaksi nomor satu.
2) Kritik pada leadership/arsitek: masalahnya bukan teknologinya, tapi ‘struktur pengambilan keputusan’
Inti
“Tim berisi 4 orang kok ada arsitek?” sendiri sudah dianggap sebagai tanda ada yang melenceng
Terutama ada pandangan kuat bahwa arsitek yang tidak menulis kode/peran DevOps yang terpisah adalah ‘bottleneck + optimasi CV’
Nadanya: yang menghancurkan perusahaan bukan microservices, melainkan “struktur di mana tidak ada yang benar-benar bertanggung jawab atas deployment/operasi/penanganan masalah”
Kutipan yang menohok (terjemahan)
“Arsitek yang tugasnya menetapkan ‘aturan’ dan ‘pattern’ tanpa benar-benar mengimplementasikan apa pun hampir selalu ide buruk. Fokus saja kirim produk... Kalau orang yang bahkan tidak menulis 10 baris kode memonopoli keputusan, hasilnya bakal berantakan.”
(teks asli: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)
Komentar singkat
Pandangan bahwa yang jadi masalah bukan MSA, melainkan ‘desain peran yang punya wewenang mengambil keputusan tetapi tidak punya tanggung jawab’ cukup kuat.
Ada komentar yang memang tidak percaya pada framing “bangkrut karena arsitektur”
Poin utamanya: kalau PMF/permintaan/customer lock-in lemah, pakai stack apa pun startup bisa gagal
Detail seperti “pelanggan langsung pergi cuma karena dua hari lebih lambat?” juga dipakai untuk menyindir: jangan-jangan value produknya memang lemah sejak awal
Mereka juga menyorot kontradiksi internal tulisan: bilang “MSA membunuh startup”, tapi kesimpulannya “selamat?” → memicu kecurigaan ada dramatisasi naratif
Kutipan tajam soal fakta (terjemahan)
“Yang membunuh startup itu produk yang tidak diinginkan orang. Ini sama tidak masuk akalnya dengan bilang Python vs Go yang membunuh startup Anda.”
(teks asli: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)
Komentar singkat
Sudut pandang “arsitektur cuma kambing hitam, penyebab sebenarnya bisa jadi pasar/produk/arus kas” jelas memang ada.
4) Insight teknis: saran berbasis pengalaman soal monolith vs MSA (bagian yang benar-benar membantu)
Inti
“MSA punya pajak biaya tetap (kompleksitas operasional)” → banyak pengalaman yang bilang ini bisa fatal untuk tim kecil
Kata kunci utamanya: Premature distribution(distribusi terlalu dini), modular monolith/modulith, “boundary harus ‘didapatkan’ dulu”
Kondisi ketika MSA memang diperlukan juga dijelaskan dengan realistis: saat skala tim membesar dan konflik/deployment/masalah organisasi benar-benar mulai muncul
Sebaliknya, untuk isu performa/skala, ada juga saran bahwa biasanya solusinya bukan “pakai MSA”, tapi cek dulu algoritme/bottleneck/sharding/partitioning
Kutipan yang menohok (terjemahan)
“Yang membunuh startup itu bukan microservices, melainkan ‘distribusi terlalu dini’. Sistem dipecah sebelum boundary yang nyata muncul, jadi yang dibayar hanya biaya latensi dan koordinasi. Mulailah dari modular monolith, dapatkan boundary-nya dulu, baru ekstrak.”
(teks asli: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)
Komentar singkat
Pelajaran yang benar-benar mendapat resonansi dari komunitas adalah ini: “Mulailah dengan monolith, dan pisahkan jadi service hanya ketika boundary-nya muncul ‘secara alami’.”
Ringkasan komunitas dalam satu kalimat
Sebagian besar setuju dengan “kita bukan Netflix”, tetapi pada saat yang sama kecurigaan bahwa tulisan ini sendiri mungkin merupakan narasi yang menjual penyakit ingin jadi Netflix (= pemasaran/AI) juga cukup kuat.
Sepertinya ungkapan "beralih ke masalah struktural" agak terlalu abstrak.
Yang ingin saya sampaikan dalam tulisan itu adalah
Before: "labeling = melibatkan manusia = biaya berbanding lurus"
After: "labeling = pipeline = setelah pembangunan awal, biaya variabel diminimalkan"
Artinya, masalah biaya satu kali diubah menjadi masalah pembangunan sistem.
Ungkapan "membuat model kerja baru" juga tepat!
Lebih tepatnya, ini bisa dikatakan sebagai "menggantikan tenaga kerja manusia dengan software pipeline" hehe
Halo, terima kasih sudah membaca tulisan ini dengan antusias!
Saya setuju dengan poin yang Anda sampaikan. Benar bahwa VLM memiliki performa yang lebih baik daripada YOLO, sehingga kesalahan prediksi YOLO dapat menyebabkan hilangnya informasi penting. Namun, kami tetap memasukkan tahap crop karena alasan-alasan berikut.
Pertama, masalah biaya. Jika seluruh gambar langsung digunakan pada VLM, biaya akan meningkat tajam karena pemrosesan gambar beresolusi tinggi. Ini adalah alasan terbesar kami memperkenalkan proses crop.
Kedua, masalah kecepatan pemrosesan.
Untuk memproses dataset berukuran besar dalam waktu yang realistis, peningkatan kecepatan seperti ini sangatlah penting.
Ketiga, peningkatan akurasi.
Crop justru meningkatkan akurasi penilaian VLM. Dalam gambar penuh, sering kali ada latar belakang yang kompleks, banyak karakter, teks, dan ornamen lain sekaligus, sehingga VLM bisa bingung menentukan objek mana yang harus dinilai. Misalnya, bisa muncul situasi yang tidak jelas apakah itu karakter pada poster di latar belakang, boneka utama, atau karakter lain di sampingnya. Sebaliknya, dengan crop, hanya objek target yang dipisahkan dengan jelas, sehingga VLM dapat fokus menilai objek tersebut saja.
Tentu saja, masalah false negative atau false positive dari YOLO tidak sepenuhnya hilang. Namun, kami mengurangi dampaknya dengan menetapkan confidence threshold YOLO ke 0.5 untuk meningkatkan recall, lalu menyaring false positive pada tahap filtering CLIP dan verifikasi oleh Verifier. Selain itu, karena kami memproses data dalam skala besar, meskipun ada sebagian objek yang terlewat, secara statistik kami tetap bisa memperoleh data berkualitas tinggi dalam jumlah yang memadai.
Pada akhirnya, tujuan kami adalah membangun pipeline yang praktis dengan menemukan titik keseimbangan antara biaya, kecepatan, dan akurasi, dan tahap crop memberikan efek positif pada ketiga aspek tersebut.
Halo winterjung, terima kasih telah tertarik pada pekerjaan saya. Untuk tingkat kepercayaan, saya menggunakan nilai confidence yang dikembalikan langsung oleh VLM (GPT-4o). Seperti yang Anda sampaikan, ada keterbatasan karena dasar perhitungan confidence dari GPT-4o tidak jelas dan tidak dapat direproduksi. Namun, dari sudut pandang praktis, dengan asumsi bahwa confidence yang dikembalikan VLM cukup akurat, saya mengimplementasikannya agar pada tahap verifikasi terakhir (Verifier), keputusan apakah perlu diverifikasi ditentukan berdasarkan threshold.
Saya sama sekali tidak tahu bahwa token input gambar pada model gpt-4o-mini ternyata terlalu mahal. Terima kasih sudah memberi tahu saya. Saya langsung menerapkannya ke kode, hehe
Ini adalah tulisan yang menjelaskan arsitektur tentang bagaimana produk sebenarnya disusun.
Saya merapikan tulisan ini sekalian setelah menstabilkannya ke versi 1.0 dan membereskan docs.
Beralih sepenuhnya ke bahasa C3 juga bagus. Ini adalah proyek yang mempertahankan sintaks bahasa C dengan perubahan seminimal mungkin sambil menambahkan fitur-fitur modern, jadi migrasinya juga mudah.
Apa bedanya diskusi itu dengan issue? Issue bukanlah “bug”. Baik itu bug, usulan fitur, maupun PR… jika ada hal yang perlu didiskusikan, itu adalah issue.
Jika tidak layak untuk didiskusikan, tinggal tutup saja.
Hmm... rasanya ada yang aneh.
Tulisan ini sepertinya ditulis oleh AI.
1) Meragukan kredibilitas tulisan: terasa seperti pemasaran/konten buatan AI
Inti
Kutipan tajam soal fakta (terjemahan)
Komentar singkat
2) Kritik pada leadership/arsitek: masalahnya bukan teknologinya, tapi ‘struktur pengambilan keputusan’
Inti
Kutipan yang menohok (terjemahan)
Komentar singkat
3) Sudut pandang bisnis: apakah benar penyebab kegagalan startup itu MSA?
Inti
Kutipan tajam soal fakta (terjemahan)
Komentar singkat
4) Insight teknis: saran berbasis pengalaman soal monolith vs MSA (bagian yang benar-benar membantu)
Inti
Kutipan yang menohok (terjemahan)
Komentar singkat
“Mulailah dengan monolith, dan pisahkan jadi service hanya ketika boundary-nya muncul ‘secara alami’.”
Ringkasan komunitas dalam satu kalimat
Sebagian besar setuju dengan “kita bukan Netflix”, tetapi pada saat yang sama kecurigaan bahwa tulisan ini sendiri mungkin merupakan narasi yang menjual penyakit ingin jadi Netflix (= pemasaran/AI) juga cukup kuat.
Karena Amerika Serikat masih punya IPv4 yang cukup. Negara kita juga begitu.
Router iptime memang tidak mendukung IPv6, kan.
Melihat harga IPv4 rasanya cuma bisa menghela napas, padahal katanya sudah cukup...
Ternyata lebih bisa dipakai dari yang dibayangkan, tapi karena dukungan pihak ketiga di Mac lebih baik jadi akhirnya tidak dipakai juga.. haha
Terima kasih atas masukannya yang bagus!
Sepertinya ungkapan "beralih ke masalah struktural" agak terlalu abstrak.
Yang ingin saya sampaikan dalam tulisan itu adalah
Before: "labeling = melibatkan manusia = biaya berbanding lurus"
After: "labeling = pipeline = setelah pembangunan awal, biaya variabel diminimalkan"
Artinya, masalah biaya satu kali diubah menjadi masalah pembangunan sistem.
Ungkapan "membuat model kerja baru" juga tepat!
Lebih tepatnya, ini bisa dikatakan sebagai "menggantikan tenaga kerja manusia dengan software pipeline" hehe
Halo, terima kasih sudah membaca tulisan ini dengan antusias!
Saya setuju dengan poin yang Anda sampaikan. Benar bahwa VLM memiliki performa yang lebih baik daripada YOLO, sehingga kesalahan prediksi YOLO dapat menyebabkan hilangnya informasi penting. Namun, kami tetap memasukkan tahap crop karena alasan-alasan berikut.
Pertama, masalah biaya. Jika seluruh gambar langsung digunakan pada VLM, biaya akan meningkat tajam karena pemrosesan gambar beresolusi tinggi. Ini adalah alasan terbesar kami memperkenalkan proses crop.
Kedua, masalah kecepatan pemrosesan.
Untuk memproses dataset berukuran besar dalam waktu yang realistis, peningkatan kecepatan seperti ini sangatlah penting.
Ketiga, peningkatan akurasi.
Crop justru meningkatkan akurasi penilaian VLM. Dalam gambar penuh, sering kali ada latar belakang yang kompleks, banyak karakter, teks, dan ornamen lain sekaligus, sehingga VLM bisa bingung menentukan objek mana yang harus dinilai. Misalnya, bisa muncul situasi yang tidak jelas apakah itu karakter pada poster di latar belakang, boneka utama, atau karakter lain di sampingnya. Sebaliknya, dengan crop, hanya objek target yang dipisahkan dengan jelas, sehingga VLM dapat fokus menilai objek tersebut saja.
Tentu saja, masalah false negative atau false positive dari YOLO tidak sepenuhnya hilang. Namun, kami mengurangi dampaknya dengan menetapkan confidence threshold YOLO ke 0.5 untuk meningkatkan recall, lalu menyaring false positive pada tahap filtering CLIP dan verifikasi oleh Verifier. Selain itu, karena kami memproses data dalam skala besar, meskipun ada sebagian objek yang terlewat, secara statistik kami tetap bisa memperoleh data berkualitas tinggi dalam jumlah yang memadai.
Pada akhirnya, tujuan kami adalah membangun pipeline yang praktis dengan menemukan titik keseimbangan antara biaya, kecepatan, dan akurasi, dan tahap crop memberikan efek positif pada ketiga aspek tersebut.
Halo winterjung, terima kasih telah tertarik pada pekerjaan saya. Untuk tingkat kepercayaan, saya menggunakan nilai confidence yang dikembalikan langsung oleh VLM (GPT-4o). Seperti yang Anda sampaikan, ada keterbatasan karena dasar perhitungan confidence dari GPT-4o tidak jelas dan tidak dapat direproduksi. Namun, dari sudut pandang praktis, dengan asumsi bahwa confidence yang dikembalikan VLM cukup akurat, saya mengimplementasikannya agar pada tahap verifikasi terakhir (Verifier), keputusan apakah perlu diverifikasi ditentukan berdasarkan threshold.
Saya sama sekali tidak tahu bahwa token input gambar pada model gpt-4o-mini ternyata terlalu mahal. Terima kasih sudah memberi tahu saya. Saya langsung menerapkannya ke kode, hehe
Rasanya seperti mengkritik hanya demi mengkritik.
Ini adalah tulisan yang menjelaskan arsitektur tentang bagaimana produk sebenarnya disusun.
Saya merapikan tulisan ini sekalian setelah menstabilkannya ke versi 1.0 dan membereskan docs.
Beralih sepenuhnya ke bahasa C3 juga bagus. Ini adalah proyek yang mempertahankan sintaks bahasa C dengan perubahan seminimal mungkin sambil menambahkan fitur-fitur modern, jadi migrasinya juga mudah.
Ini adalah panduan penjelasan untuk Show GN: 자연어 명령을 Intent → Effect → Snapshot으로 실행하는 AI Task 데모 yang Anda unggah di ShowGN.
Apa bedanya diskusi itu dengan issue? Issue bukanlah “bug”. Baik itu bug, usulan fitur, maupun PR… jika ada hal yang perlu didiskusikan, itu adalah issue.
Jika tidak layak untuk didiskusikan, tinggal tutup saja.
Makanya saya tidak suka iklan..
Saya sempat memasangnya di laptop Galaxy Book tahun lalu, tetapi mungkin karena masalah kompatibilitas, perangkatnya terus mengalami freeze.
Rich - library Python untuk memformat terminal agar terlihat mewah memang yang terbaik.
Kalau hanya butuh fitur tabel, ada juga yang seperti PrettyTable atau Tabulate.
Kelihatannya praktis, kalau untuk Python ada apa ya?
Wow, menarik juga kalau mulainya dari Jepang. Kukira hal seperti ini bakal lebih dulu terjadi di Eropa atau Amerika Serikat.
Tahun lalu ada banyak peningkatan pada HiDPI dan HDR, sekarang sepertinya dukungannya malah lebih baik daripada Windows.