• 0 Posts
  • 24 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.




  • Recently switched to a new contract, which resulted in me switching from IDEA Ultimate to vscode. This picture is terribly accurate.

    In intellij I usually do code reviews by checking out the code and comparing the branch to origin/main to step through the changes. Just a right click menu option to compare branches.

    I took for granted that this is just a thing IDEs should do, so I looked in vain for a while before googling it and finding out I need a plugin for that. (If I’m wrong please help me find the button, I still believe it must be in there somewhere. Surely the owners of GitHub can compare branches?)





  • 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.




  • “They simply go through the whole table”… that’s the problem. A full table scan should be avoided at all costs.

    Learn: how to run and read an explain plan, indexes, keys, constraints, and query optimization (broadly you want to locate individual records as quickly as possible by using the most selective criteria).

    You also need to learn basic schema design and to familiarize yourself with normalization.

    Avoid processing huge result sets in your application. The database is good at answering questions about data it contains. It isn’t just a big bucket to throw data into to retrieve later.


  • I’ve always been one of the developers at work that people bring their Spring questions to. Usually I just change the logging level and read the errors. Quite often it will tell you what you need to do or give you a good hint at least.

    Another “trick” is reading the official documentation. There is a lot of cruft out there, so go straight to the source.

    It’s really a great framework but they do give you many guns to shoot yourself in the foot with.