Threads for LiamHz

  1. 2

    I’m preparing for my first ever technical interview* for an internship at a computer graphics R&D lab.

    Planning to:

    • Do a mock interview with a CTO mentor / friend of mine
    • Write documentation for myself on my real-time rendering engine
    • Review concepts in C++ / computer graphics / linear algebra

    Any tips on how to prepare would be greatly appreciated. What I have to go off is that “they’ll deep dive into your projects and code samples to understand why you made the decisions that you did.”

    * = 1 hour Zoom call scheduled for 2 weeks from now

    1. 2

      I recently started to write an article about collecting and processing event logs, with a primary focus on collecting request logs from web servers. Any pointers on this topic are warmly appreciated.

      The point of the article is to compare different methods; e.g. logrotate, syslog, journald, s6-log, etc. Many articles out there describe how to configure logging, but not that many articles explains the philosophy behind the various methods. (No draft to share at this moment since the draft is not yet fully digitized.)

      1. 2

        I’m very interested in reading this. Feel free to send me your draft if (once it’s digitized) if you’d like some early feedback :)

        1. 1

          Cool! I’ll gladly let you read the draft when it’s in a tolerable state. How can I reach you?

          1. 1

            I’ve DMd you

            1. 1

              I didn’t even know that there is a DM system here. That’s great. TIL!

        2. 2

          I’m also interested by that! Draft or released version, I’m in to read both :)

        1. 3

          I’m taking part in a community college writing class that ends tomorrow.

          I’ve started a blog on computer security tips for regular folk. I want to cover the theory and practices of topics everyone should know. I’ve started with two-factor authentication and I’ll be reading this article out loud tomorrow: Feedback welcome! The class has some constraints (500 words max, low readability complexity).

          I have an about page. The gist of it is there but it’s full of typos:

          My goal is to start a newsletter, finish 10-ish articles, wrap it up in a cheap / free ebook, market it a little to see if there is a market.

          1. 3

            Your illustrations are great, and the writing’s really clear!

            One suggestion from me: right now, if you’re somebody who already know the gist of how 2FA works, you won’t learn anything new from this article. Making brief mention of novel 2FA techniques (e.g. ambient sound) or flaws with widely used 2FA systems (e.g. SMS vulnerabilities) would mitigate this problem - which is especially important if you’re planning to turn this into an ebook, where people will know of some concepts but not others.

            1. 1

              One suggestion from me: right now, if you’re somebody who already know the gist of how 2FA works, you won’t learn anything new from this article.

              This is a good point. My intended audience for this blog and the book are non-computer-experts who probably aren’t familiar with two-factor-authentication. I’m working on making this more clear in the blog’s about section, but I’m not sure how to make this clear in the articles themselves.

              However even for non-experts I do want to make people aware of SMS vulnerabilities. I’m careful in the article to pretend 2FA only involves “phone codes” that an “app” shows, but I don’t go into details. I wonder how to go into details with alienating beginners.

          1. 1

            Well, I’ll give it a shot. I wrote a blog post I know Python basics, what next? last week. Feedback and suggestions welcome.

            I’m also currently updating Ruby Regexp book. You can get all my books for free currently if you feel generous enough to review 100 page books:

            1. 2

              Nice post, I can see myself referring back to this later :)

              Reducing the number of resources you link to would make me more likely to actually commit to using one of them - because then I’d feel more ‘confidant’ that it’s a good choice. Linking to just a single python exercise website, and then walking through what one is like or what you’d learn from solving them would be (imo) an improvement.

              On that note, including some of the information from those resources in your post itself would be great.

              In your article, you write:

              “Knowing how to debug your programs and how to write tests is very important. Here’s some resources:

              and then link to 7 pages. I’d find this section more useful if you showed a code example of debugging in Python, talked about how you’ve found using something like pdb useful, or even quoting the “jpeg parser” debugging story from StackOverflow (that you currently link to) in its entirety.

              In general, I’d focus in a bit more in each section by linking to less resources, and giving more information on “why” somebody might want to commit to going through a specific resource (or category of resource).

              1. 2

                Thanks a lot! All good points, I’ll try to reduce the number of links per section (one problem is I myself don’t have much experience with those resources, mostly just collected from seeing them often recommended).

                including some of the information from those resources in your post itself

                I feel this will make the post a lot better, thanks. This would also require lesser number of resources, otherwise the post will become too long from all the quotes and descriptions.

            1. 2

              I just finished writing Fundamentals of the Vulkan Graphics API: Why Rendering a Triangle is Complicated.

              I’m going into my freshman year of college (i.e. haven’t had “technical” writing feedback before) and this is my first technical piece of writing, so feedback on clarity / flow / engagement would be appreciated.

              1. 1

                I liked your intro. It made it immediately relatable to anyone else.

                My one suggestion is that I wouldn’t hide the code sample. It’s an important part of the article and nearly everyone should be expanding it anyway. I’m not sure it’s worth the extra click to reveal it. That’s somewhat subjective advice though so others may disagree.

              1. 2

                So has anyone made an “opengl” level api on top of vulkan?

                1. 3

                  The WebGPU api is a higher level, easier to use layer on top of Vulkan, Metal and DX12. Native WebGPU libraries are available for Linux, MacOS, Windows, Android and iOS, plus the API will also be natively supported by javascript in web browsers, and it will be the standard GPU API for WebAssembly programs executed either inside or outside of a browser. There are two open source library implementations with a C language interface: Dawn, made by Google, written in C++, and wgpu, made by Mozilla, written in Rust. The API is still a work in progress, partially implemented, the design not yet complete. It is hoped to be finished at the end of this year. WebGPU is a portable API (write once, run anywhere), and only supports features that exist in Vulkan, Metal and DX12. It is not as powerful as Vulkan, and there will be a significant lag between bleeding edge features becoming available as Vulkan extensions, and those same features becoming available as WebGPU extensions (if they ever do). However, WebGPU is a more modern API than OpenGL, with a similar philosophy to Vulkan (asynchronous command queues), and with higher performance than OpenGL.

                  1. 2

                    Yep! GLOVE can be used as an intermediate layer between OpenGL ES and Vulkan.

                    This also means you can run OpenGL ES applications on macOS like so: OpenGL –> (GLOVE) –> Vulkan –> (MoltenVK) –> Metal

                  1. 11

                    I invested a lot of time into learning OpenGL and I was really bummed out when Apple dropped OpenGL support and more and more devices and programs started to use Vulkan. The fact that it takes 1000+ lines to render a triangle always turned me off. However, this article made the subject approachable.

                    This article is intended to be a concise overview of the fundamentals of Vulkan. It was written for somebody who knew Vulkan but has forgotten many of the details (i.e. future me).

                    I have never used Vulkan before, but the article made sense from start to finish. It sure made me feel like I knew Vulkan but forgot many of the details! I’m more likely to dive into Vulkan development now.

                    It’s good to see that Vulkan addresses my biggest gripe with OpenGL, the “global state hell”, by making command buffers and their corresponding synchronization primitives explicit.

                    1. 6

                      Your comment on OpenGL “global state hell” is spot on. I’ve found that once I’ve gotten past the initial boilerplate setup, developing in Vulkan is much more enjoyable and easier to debug than OpenGL.

                      P.S. I’m glad you enjoyed my article :)