2 poin oleh GN⁺ 2024-02-10 | 1 komentar | Bagikan ke WhatsApp

GrafanaCON 2024: Daftar hari ini dan pesan tempat Anda!

  • GrafanaCON 2024 adalah acara komunitas terbesar tahun ini, dan pendaftaran telah resmi dibuka.
  • Acara ini menawarkan pengalaman langsung yang hidup dan dapat dihadiri secara tatap muka di Amsterdam pada bulan April.

Pendapat GN⁺

  • GrafanaCON 2024 adalah acara penting bagi orang-orang yang tertarik pada visualisasi data dan pemantauan. Acara ini akan menjadi tempat berkumpulnya komunitas pengguna dan pengembang Grafana untuk berbagi tren dan teknologi terbaru.
  • Acara yang berlangsung di Amsterdam ini diharapkan memberikan kesempatan networking dan pembelajaran bagi para peserta, dengan sesi-sesi yang membantu pemahaman mendalam tentang alat analisis data dan visualisasi.
  • Pembukaan pendaftaran acara ini adalah kabar menarik bagi para pengguna Grafana, dan akan menjadi peluang baik bagi para profesional di bidang ini untuk memperoleh pengetahuan baru dan berinteraksi dengan rekan-rekan industri.

1 komentar

 
GN⁺ 2024-02-10
Komentar Hacker News
  • The Valid method takes a context (which is optional but has been useful for me in the past) and returns a map. If there is a problem with a field, its name is used as the key, and a human-readable explanation of the issue is set as the value.

    • Metode validasi: Menerima context opsional dan mengembalikan sebuah map dengan field yang bermasalah sebagai key serta penjelasan masalah yang mudah dipahami manusia sebagai value. Disebutkan bahwa pendekatan ini pernah berguna di masa lalu.
  • I used to do this, but ever since reading Lexi Lambda's "Parse, Don't Validate," I've found validators to be much more error-prone than leveraging Go's built-in type checker.

    • Parsing alih-alih validasi: Setelah membaca "Parse, Don't Validate" dari Lexi Lambda, ia merasa memanfaatkan type checker bawaan Go jauh lebih kecil kemungkinan menimbulkan error dibandingkan validator.
  • For example, imagine you wanted to defend against the user picking an illegal username. Like you want to make sure the user can't ever specify a username with angle brackets in it.

    • Contoh validasi username: Bayangkan situasi saat ingin mencegah pengguna memilih username yang tidak valid, misalnya memastikan username tidak boleh mengandung angle bracket.
  • With the Validator approach, you have to remember to call the validator on 100% of code paths where the username value comes from an untrusted source.

    • Masalah pendekatan validator: Ada beban untuk selalu ingat memanggil validator di 100% jalur kode ketika nilai username berasal dari sumber yang tidak tepercaya.
  • Instead of using a validator, you can do this:

    • Alternatif selain validator: Mengusulkan metode lain sebagai pengganti penggunaan validator.
  • That guarantees that you can never forget to validate the username through any codepath. If you have a Username object, you know that it was validated because there was no other way to create the object.

    • Jaminan validasi lewat pembuatan objek: Karena validasi dilakukan saat membuat objek Username, tidak mungkin lupa melakukan validasi di jalur kode mana pun.
  • I really like Mat Ryer's work, and I've applied most of the ideas in the 2018 version of this article to all of my Go projects since then.

    • Menyukai karya Mat Ryer: Ia sangat menyukai karya Mat Ryer dan telah menerapkan sebagian besar ide dari versi artikel tahun 2018 ke semua proyek Go miliknya sejak saat itu.
  • The one weak spot for me is this aspect:

    • Menunjuk titik lemah: Ia menyebut bagian ini sebagai satu titik lemah menurutnya.
  • This has always felt wrong to me, but I've never been able to figure out a better solution.

    • Belum menemukan solusi yang lebih baik: Hal ini selalu terasa keliru baginya, tetapi ia belum pernah berhasil menemukan solusi yang lebih baik.
  • It means that a huge chunk of your code has a huge amount of unnecessary shared state.

    • Masalah shared state: Ini berarti bagian besar dari kode memiliki shared state yang tidak perlu dalam jumlah besar.
  • I often end up writing HTTP handlers that only need access to a tiny amount of the shared state.

    • HTTP handler dan shared state: Ia sering menulis HTTP handler yang sebenarnya hanya membutuhkan akses ke sebagian kecil shared state.
  • Nothing against Mat Ryer, as his pattern is the best I've found, but I still feel like there's some better solution out there.

    • Menghormati pola Mat Ryer: Ia menegaskan tidak ada masalah dengan Mat Ryer karena polanya adalah yang terbaik yang pernah ia temukan, tetapi tetap merasa mungkin ada solusi yang lebih baik.
  • one of my biggest pet peeves is when people take a Config object, which represents the configuration of an entire system, and pass it around mutably.

    • Keluhan soal objek Config: Salah satu hal yang paling mengganggunya adalah ketika orang mengambil objek Config, yang mewakili konfigurasi seluruh sistem, lalu mengoperkannya dalam keadaan mutable.
  • When you do that, you're coupling everything together through the config object.

    • Masalah coupling lewat Config: Dengan cara itu, semua bagian sistem menjadi saling terikat melalui objek Config.
  • I've worked on systems where you had to configure the parts in a specific order in order for things to work, because someone decided to write back to the config object when it was passed to them.

    • Masalah ketergantungan urutan pada Config: Ia pernah bekerja pada sistem yang mengharuskan komponen dikonfigurasi dalam urutan tertentu agar bisa berjalan, karena ada yang menulis kembali ke objek Config yang diteruskan kepadanya.
  • Or another case was where I've seen it such that you couldn't disable a portion of the system because it wrote data into the config object that was read by some other subsystem later.

    • Masalah menonaktifkan bagian sistem: Ia juga pernah melihat kasus saat sebagian sistem tidak bisa dinonaktifkan karena bagian itu menulis data ke objek Config, lalu data tersebut dibaca oleh subsistem lain di kemudian hari.
  • The pattern of "your configuration is one big value, which is mutable" is one of the more annoying patterns that I've seen before, both in Go and in other languages.

    • Kritik pada pola konfigurasi besar yang mutable: Menurutnya, pola "konfigurasi Anda adalah satu nilai besar yang mutable" adalah salah satu pola paling menjengkelkan yang pernah ia lihat, baik di Go maupun bahasa lain.
  • I agree with a lot of this, I'll add my own opinions:

    • Setuju dan menambahkan pendapat: Ia setuju dengan banyak bagian dan ingin menambahkan pendapatnya sendiri.
  • I would pass a waitgroup with the app context to service structs.

    • Usulan meneruskan waitgroup dan app context: Ia menyarankan untuk meneruskan waitgroup bersama app context ke struct service.
  • This way the interrupt can trigger the app shutdown via the context and the main goroutine can wait on the waitgroup before actually killing the app.

    • Memakai interrupt dan waitgroup untuk shutdown: Dengan begitu, interrupt bisa memicu shutdown aplikasi lewat context, dan goroutine utama dapat menunggu waitgroup sebelum benar-benar mematikan aplikasi.
  • If writing a CLI program, then testing stdout, stdin, stderr, args, env, etc. is useful.

    • Kegunaan pengujian program CLI: Saat menulis program CLI, menguji stdout, stdin, stderr, args, env, dan sebagainya sangat berguna.
  • But for an http server, this is less true.

    • Pendekatan berbeda untuk HTTP server: Namun untuk HTTP server, hal itu tidak terlalu relevan.
  • I would pass structured config to the run function to let those tests be more focused.

    • Config terstruktur untuk pengujian yang lebih fokus: Ia menyarankan meneruskan config terstruktur ke fungsi run agar pengujian bisa lebih terfokus.
  • I disagree with parsing templates using sync.Once in a handler because I don't think handlers should do template parsing at all.

    • Tidak setuju template parsing di handler: Ia tidak setuju melakukan parsing template dengan sync.Once di dalam handler, karena menurutnya handler seharusnya sama sekali tidak melakukan parsing template.
  • I would do this when the app starts: if the template cannot be parsed, the app should not become ready to receive any requests and should rather exit with a non-zero exit code.

    • Usulan parsing template saat startup aplikasi: Ia akan melakukannya saat aplikasi mulai berjalan; jika template tidak bisa diparse, aplikasi tidak boleh dianggap siap menerima request dan sebaiknya keluar dengan exit code non-zero.
  • I found fx to be a super simple yet versatile tool to design my application around.

    • fx sederhana dan serbaguna: Ia menilai fx sebagai alat yang sangat sederhana namun serbaguna untuk merancang aplikasinya.
  • All the advice in the article is still helpful, but it takes the "how do I make sure X is initialized when Y needs it" part completely out of the equation and reduces it from an N*M problem to an N problem.

    • Saran artikel dan keunggulan fx: Semua saran di artikel tetap berguna, tetapi fx menghilangkan sepenuhnya persoalan "bagaimana memastikan X sudah diinisialisasi saat Y membutuhkannya" dan menguranginya dari masalah N*M menjadi masalah N.
  • I've used quite a few dependency injection libraries in various languages over the years (and implemented a couple myself) and the simplicity and versatility of fx makes it my favorite so far.

    • fx sebagai favorit: Ia telah memakai banyak library dependency injection di berbagai bahasa selama bertahun-tahun, bahkan mengimplementasikan beberapa sendiri, dan kesederhanaan serta fleksibilitas fx menjadikannya favorit sejauh ini.
  • I've recently been playing with ogen:

    • Pengalaman mencoba ogen: Ia baru-baru ini mencoba ogen.
  • Write openapi definition, it'll do routing, definition of structs, validation of JSON schemas, etc.

    • Definisi OpenAPI dan fungsi ogen: Cukup tulis definisi OpenAPI, lalu ogen akan menangani routing, definisi struct, validasi skema JSON, dan sebagainya.
  • All I need to do is implement the service.

    • Implementasi service jadi sederhana: Yang perlu dilakukan hanya mengimplementasikan service.
  • Validating an integer range for a querystring parameter is just too boring. And too easy to mistype when writing it manually.

    • Kekurangan validasi rentang integer querystring: Memvalidasi rentang integer untuk parameter querystring terasa terlalu membosankan dan sangat mudah salah ketik jika ditulis manual.
  • Anyways, so far only been playing, so haven't found the bad parts yet.

    • Penilaian awal terhadap ogen: Sejauh ini ia baru sekadar bereksperimen, jadi belum menemukan sisi buruknya.
  • Great article with lots of interesting ideas. Can't believe I didn't know about signal.NotifyContext. Finally I'll be able to actually rememeber how to respond to signals instead of copy-pasting that between projects.

    • Penilaian positif pada artikel dan signal.NotifyContext: Artikel ini dinilai sangat bagus dengan banyak ide menarik, dan ia tak percaya belum tahu soal signal.NotifyContext. Akhirnya ia bisa benar-benar ingat cara merespons signal tanpa perlu copy-paste antarproyek.
  • I like a lot of what they've done here. My testing looks a bit different however.

    • Suka pendekatan artikel, tetapi gaya testing berbeda: Ia menyukai banyak hal yang dilakukan di artikel ini, tetapi pendekatan testing miliknya sedikit berbeda.
  • srv, err := newTestServer()

    • Contoh kode membuat test server: Menunjukkan contoh kode untuk membuat test server baru.
  • require.NoError(t, err)

    • Contoh kode pemeriksaan error: Menunjukkan contoh kode untuk memastikan tidak ada error.
  • defer srv.Close()

    • Contoh kode menutup server: Menunjukkan contoh kode untuk menutup server setelah pengujian selesai.
  • resp, err := http.Post(fmt.Sprintf("http://localhost:%d/signup/json";, srv.Port()), "application/json", strings.NewReader({ "email": "test@example.com", "password": "p@55Word", "password_copy": "p@55Word" }))

    • Contoh kode request HTTP POST: Menunjukkan contoh kode untuk mengirim request HTTP POST.
  • In my newTestServer, I spin up a server with fakes for my dependencies.

    • Membuat server palsu untuk dependency: Di newTestServer, ia menjalankan server dengan dependency palsu.
  • If I want to test a dependency error, I replace that property with a fake that will return an error.

    • Cara menguji error dependency: Jika ingin menguji error dari dependency, ia mengganti properti tersebut dengan versi palsu yang akan mengembalikan error.
  • I can validate my error paths. I can validate my log entries. I can validate my metric emission. I can validate timeouts and graceful shutdowns.

    • Berbagai hal yang bisa divalidasi: Ia bisa memvalidasi jalur error, entri log, emisi metrik, timeout, dan graceful shutdown.
  • After the server starts, I inspect to determine which port it is running on (default is :0 so I have to wait to see what it got bound to).

    • Memeriksa port setelah server berjalan: Setelah server mulai, ia memeriksa port yang dipakai server (default-nya :0, jadi ia harus menunggu untuk melihat port mana yang terikat).
  • My "unit" tests can test at the handler level or the http level, making sure that I can fully test the code as the users of my system will see it, exercising all middleware or none.

    • Cakupan unit test: "Unit" test miliknya bisa dilakukan di level handler maupun level HTTP, sehingga ia dapat menguji kode sepenuhnya sebagaimana dilihat pengguna sistem, dengan semua middleware aktif atau tanpa middleware sama sekali.
  • I can spin up N instances and run my tests in parallel.

    • Menjalankan test paralel: Ia bisa menyalakan N instance dan menjalankan test secara paralel.
  • I don't write go, but I like these patterns. Feels fairly universal for testable code.

    • Menyukai pola ini meski tidak menulis Go: Ia tidak menulis Go, tetapi menyukai pola-pola ini karena terasa cukup universal untuk kode yang mudah diuji.