daenney (192)

Signed up 224 days ago

  • I love this! There's so many Go projects that barely have a description, let alone a usage example, in their README's. GoDoc's great but to get a feel for what a library does and how to get started browsing through that isn't that great of an experience.

  • Does anyone have any insights into those benchmarks? I'm always a bit weary of them since they're not often representative of real-world use cases. I'm also curious if anyone has any insight in what might be slowing down gRPC so much? Considering it's coming from Google I would expect that to be rather snappy.

  • Though I agree with what the author writes I'm a bit disappointed that only that's done is tear down this concept but not really provide good alternatives or examples of how it (c|sh)ould be done instead. Just passing in the logger as an argument is a possibility which is hinted at but there might be other options too that are worth exploring.

    The quote at the end "Loggers should be injected into dependencies. Full stop." is one possible way, but simply stating that with no examples would probably leave a lot of people wondering what that's all about. For completeness, the possible solution is in an early post of the author, here: https://dave.cheney.net/2017/01/23/the-package-level-logger-anti-pattern

  • Is it just me or are half of the slides empty?

  • Has anyone taken this course and can they testify to the quality of it? There's a lot of these courses that aim to teach you different things bundled up together but it's hard to know if those teaching actually do a good job of it upfront. I'm also curious about how up to date the React part is since that ecosystem is evolving so rapidly and this was published a year ago.

  • This is a really interesting read. Even if you'd design it differently, it's insightful and clear as to why they made the choices they did and everyone can learn something from it.

  • > Another issue was regarding FFMPEG and m3u8’s open source licenses and dealing with the possibility of a sudden license change.

    I'm not quite sure I follow there. Any existing code's license wouldn't be able to be changed. Contributors could agree to let their contributions be licensed under a dual/new/different license going forward but it won't just close up on you. This is also not something that would happen suddenly. FFmpeg has no CLA that do things like copyright assignment so changing the license would require approval from all contributors. Open source licenses is exactly what allows you to reuse, share and build on top of each other's expertise. If you want to develop your own implementation fine, but this argument seems rather weak to me.

  • I came across this article myself when I needed to figure out some stuff around using GCS, it's very useful and (still) accurate.