• 0 Posts
  • 80 Comments
Joined 2 years ago
cake
Cake day: August 7th, 2023

help-circle


  • Clear concise code that reads like documentation is the ideal. Good function and variable names, formatting, and encapsulation play into this. Tests should document and describe the system.

    If it still isn’t clear what the code is doing, and I’m all out of ideas (or time) for refactoring, a well placed, accurate comment is fine. It needs to be kept up to date like any other artifact in the project.

    It’s harder to keep comments accurate than code, since code can be executed and tested. I use them sparingly; when I’ve otherwise failed to write clean code, or the code is just so complex that it needs to be described.

    Comments are just another tool in the toolbox. If they add clarity to the situation, by all means, use them.

    If you can think of an expressive variable name that lets you skip a comment eg “employeeCount”, instead of “e” // number of employees, do that.





  • Reverse engineering the server is reverse engineering the whole game. It’s going to require skilled engineers and a significant time investment. It may be possible, but not practical.

    Also, the client will likely verify it is talking to a legitimate server by checking a certificate, so you may also have to hack the client too.

    At some point you’re better off making your own game with hookers and blackjack.


  • I ran it for a while, and loved it. Cinnamon is sleek and feels polished. The installation is really fast and not bloated with garbage software.

    Everything generally works, and the interface feels familiar.

    It is Ubuntu/Debian under the hood, so compatibility with most software is good. Bleeding edge drivers may run into issues, but most of them work with a little fiddling.

    It’s worth a try. If nothing else toss it on a USB drive and give it a test drive.




  • I recently drove eight hours on a trip. It’s brutal, but you’ll be fine.

    • download offline maps on your phone
    • get lots of music, podcasts, and things to keep entertained
    • stop every few hours to stretch your legs, use the bathroom, and maybe get something to eat
    • be aware of your route. Think about where you can stop. Be ready for construction and other unexpected delays.
    • check your tire pressure before you leave (especially the spare!)
    • make sure you have basic stuff like a jack and jumper cables
    • make sure you have your license, insurance, and registration
    • if you can afford it, dashcams are nice to have









  • It sounds like you need your own API with some sort of persistent store. You may be able to reuse what you’ve done as the view layer?

    If this were something I was going to tackle, I’d start by identifying the types of users (authors, admins, users, etc.)

    Then I’d think about the kinds of workflows those users are going to need to do. E.g. admins can edit or delete anything, authors can alter their own content, users can only view data, etc.

    Now with some loose requirements in mind, start thinking about how to solve the problems for your users. This is when you start evaluating what technology might be a good fit for your problem domain.

    You could probably throw together a trivial API that only you can publish to fairly quickly if that is sufficient for what you are trying to do. I dare say chatgpt can spit out a simple rest API in whatever language you like quickly and pretty accurately.

    I wouldn’t chase making a static website tool dynamic. That will almost certainly end in heartbreak.