Sometimes I swear my brain does the same thing(short lived things like people names, no need to put that in memory) 🤣

Mostly c/c++/c# but also know some python and rust.

This is just for self educarion/exploration. Nothing critical.

Even you said your rule of thumb is "not strictly true" which is my point. Is there some way to check those cases? Like I can verify the type of a variable returned by a function. Like if I get people's ages from a database but some one stored them in a text field instead of an numeric field. When I get the data back I can verify the type before I try to say average the ages.

A simple idea of what I'm thinking is let's say you're doing very precise calculations which need to very accurate so a co-worker makes a custom double class and returns that from their special add function. Since it's an instance of a custom class it's likely stored on the heap. Naming is hard though so your coworker named it Double instead of double. So you look at your code and think Double is a primitive so should be on the stack but it's actually on the heap. Even simpler example, primitive types are stack based except for string which is heap based. These are easy mistakes to make but could have performance and memory implications. So a way of verifying assumptions would be useful.

Very true, and GDB will tell you this.

Another commenter said that checking if the variable's memory address is in the stack region or heap region, and that is true, but I also wanted to mention that sometimes stack variables live short enough that they're simply stored in a register instead of actually put in memory.

Is this a general curiosity looking for a rule of thumb that mostly works or do you need to know with certainty? What language?

A simple rule of thumb for C/C++ could be that malloc/new/dynamically allocated variables are in heap and variables whose size is known at compile time and have local scope are stack. This is not strictly true, but it's simple and mostly true.

Depending on how much detail/special cases you want to get in to, it's possible for a variable to not be in or referencing/pointing to either the stack or heap. I'll leave scenarios where this may occur as exercise for the reader. ;)

I don't see that in the sourceware or gnu documentation but I may be missing it (gdb is incredibly complex and documentation in long and detailed). It's 1am here so investigation into this will have to wait till tomorrow.

info proc mappings should show you the memory regions mapped for stack and heap, then you can compare the address of your variable to those.

Most of those will give me a memory address but is there a way to know if that address is stack or heap?

I recommend checking out the documentation for the following GDB commands:

info variables
info locals
info args
info address
info proc mappings

If your code is open source, you could try posting code links and questions to relevant communities here on Lemmy.

Edit: You might attract users and collaborators that way, as well.

When things feel overwhelmingly big I usually refactor. The answer for me is usually folder by feature. Refactoring should be a natural part of the engineering cycle. You've learned a lot while getting to the point you are, and the structure reflects the outdated perspective.

Also don't go out of your way to reuse logic. It's a lot cheaper to adjust code that only has one dependency. If the duplication starts hurting, then consider converging. I usually start writing how I'd like to use the new code, then implement it to fit.

Hope my two cents helped

it's all about managing abstraction. if things are similar enough you can make them derive behavior from the same base. with composition, you can build capabilities separately and then compose them into objects. so if the ResourceManager has an Inventory, so could the CraftingBill. if the ResourceManager has a Request and a Send method, break that out into a RequestHandler and give one to everything that should be able to do requests.

When working with an ECS implementation, game objects are usually just numbers. all the capabilities are separate functions that are associated to the game objects in a list. i'm not saying that you should be using an ECS if you aren't, but i am saying that modelling your systems so that new things can be built from small, common parts makes it way easier to expand. usually at some point you realise you don't even have to build new behaviors.

that said, try to keep it strictly hierarchical. like stones in a pyramid, you should only depend on things that are below or next to you. if you start creating relations to things further up the chain, your architechure might need rethinking. good news is that if you're modular enough you can junt move things around.

You're only going to get so far by asking people for specific guidance. At some point you'll need to either try stuff, get stung, and learn from it, or work on a big project with people more experienced than you, even if just a bit more experienced. Preferably both.

It shows a level of technical maturity that you're asking.

Also to answer your original questions, you mostly have to exercise in recognising situations where certain design patterns would be appropriate to use.

For certain application types though (games, design apps, data analysis apps, etc.), there are already popular design patterns that exist and are used all the time. Look at how other applications use them.

I'm admittedly not sure if I get what you want to do with the crafting bills.

But if you mean that the reservations, delivery requests and resource checking are modular for each bill, you can make a generic bill that takes in a class of type reservation, delivery request and any other bill class attribute you want to be modular.

That way, you might not need to check for specific cases for each combinations.

Glad to help. Have fun!

That clarifies things, thanks! I’m definitely interested setting up a proper homelab

I know it’s overkill :) Wanted my README to have 1 installation command instead of 2 for easy review. Also showcase skills that go beyond Junior level.

Initially I decided against kubernetes but since podman already has it integrated, why not? This way, I eliminate the need for podman-compose install. My app is part of the portfolio, has 3 containers for frontend, api and database. Didn’t finish the personal website yet, lol.

Didn’t know about docker swarm and I definitely want fancy :)

You need to be able to pull or build the images on the other machine. At a company you would use a private container image registry on something like GitHub, GitLab or JFrog.

Setting up a GitLab instance is a really cool homelab project that can also go on your portfolio.

Develop on your workstation, push to the registry on machine B, pull from that and run on machine B

first: why do you even need k8s just for your portfolio website? what features does it provide which is useful to you?

you have to install minikube on your old laptop to be able to run pods etc

tbh you dont need k8s, plain docker container would do and if you want to be fancy use docker swarm :)

One important thing to think through is how your resulting data structure will be used and how each layer and its overhead fits in.

Like for example, I once used a data structure that ended up being an array of maps to store a series of chunks of arbitrary data. It would parse each line of data into key/value pairs in a map/dictionary and then add that as an entry for the array. It was slow.

It was much faster and used less RAM when I changed it to a map of arrays, since each line would have the exact same pieces of data in a file, it just wasn't certain what would be in any given file. This meant that there was only one place where all the map overhead was stored, and each entry in the arrays corresponded to the same entry in the other arrays.

I'd also suggest a design where you don't care what the actual implementation is outside of the module that needs to do the storing itself. The main thing you need is a unique addressing system to ensure that a) each piece of data has a predictable label/address to find it and b) each label/address only points at the relevant data.

Eg, if you end up using an SQL database, you don't want to be writing SQL queries into your crafting system, but to use identifiers that you pass into the storage module where it builds the queries (or even better, uses stored procedures so the queries themselves are also stored on the database, which is faster and more secure). Then, you can decide later on down the line that instead of an SQL database, maybe you should use the new DreamStorage that uses the brainpower of those foolish enough to be early adopters of brain chip technology to do table lookups in constant time as long as it doesn't involve math. If you do modularization correctly, you should just be able to swap them out by matching the interface, regardless of what the implementation is.

If there's a hierarchy built into the way the data is organized, try to abstract it (eg something like "level0.level1.level2.item", where you can split the levels by "." when you need to). You should be designing the data structures for what your algorithms need to do with the data, not based on how you intend to store that data. Then the control flow side extracts the data each function needs and provides it to the function and then handles the result accordingly.

That said, don't worry too much about getting it perfect. Experience is going to be your biggest ally, so go ahead and make mistakes and learn from them. There isn't likely a solution that will trivialize everything. I usually just aim for "have a good idea of what all the blocks need to do, ideas on how they will do it, and how they will fit together" with my designs.

Since you have a sequence of keys, go with a trie data structure. The key will be a string of "worktype|region|job".

You can encode/decode the individual keys from enums to integers (vice-versa for decode).

but since you said you want it to be simple and want this for a game you probably can go with any SQL database as they are reliable and support locking so you don't have to worry about parallel access later.

While databases have struck fear in the hearts of many developers, it's really just a structured way of storing (sometimes large amounts of) information.

From a naming perspective, a database is essentially a collection of tables, each of which you can think of as a simple list of rows, each row containing a collection of fields, each not unlike a single spreadsheet with a label at the top of each column.

Like a spreadsheet, you can decide what types of values are permitted in each field (column).

In spreadsheets you can refer to a row by its row number, which breaks down as soon as you sort a sheet, database tables can similarly be ordered, or not, depending on the requirements.

A query returns one or more rows as required.

You can relate two tables if you want to by having both tables have a field with the same definition and value, and then query the information together, linked by that common field. You can link many tables together if your data requires it.

For example, you might have a list of job types, with information that's specific to each job of that type. By storing those types in their own table, you don't need to duplicate the information for every single job stored in another table.

Essentially that's pretty much all there is to it.

If you get into bigger and more complex stuff, you'll come across a thing called an index, which tracks one or more field values across one or more tables, for the purpose of making retrieval faster, but until you hit a thousand rows, you're unlikely to need them.

Disclaimer: This is a summary of 40+ years of database experience and it's purposefully written to simplify concepts. It doesn't get into different database engines, but at this stage that likely won't matter much.

The underlying purpose of a database is to ensure data integrity, in other words, to make sure that a telephone field contains a telephone number and not an email address by accident. It's also intended to minimise the amount of data duplication and associated resource use, like memory, disk and network. Finally it provides mechanisms for multiple simultaneous users and associated conflicts.

Have fun!

I would double down on sqlite for your case. If you are using python, the sqlite3 module is included, but looking at your pseudocode you are probably looking for Godot-SQLite instead. I have no idea what the #python line is supposed to be doing in the first line of your code snippet, besides confusing me.

SQL is old, and it shows. "Proper" relational database design is a black art, as is optimizing SQL queries, but speaking from my own early experience, you'll be doing 95% with INSERT, SELECT, UPDATE, DELETE, anyway, with an occasional simple JOIN. This is absolutely manageable and somewhat worth learning, as you're basically custom building your own data structure according to how you plan to use it most easily. This SQL with sqlite tutorial seems solid to me.

Beware LLM output. Wild guess is you'll be sent off on a tangent to normalize your schema, unconditionally use synthetic, unique integer IDs everywhere, and other "best practices" that may not be necessary, and only complicate your structure beyond the point of understanding. Then it'll be hell to use. Solid groundwork goes a long way, and you can always change things up when you realize "Damn, I'd love to have in that tuple for a really simple query!"

Give it a try. Creating your own data structures in the way you want can be really rewarding in itself.

If you're gravitating towards a NoSQL database to avoid SQL, you're basically using dicts again, and will have to learn a different query language, anyway. This may be a more approachable option for you IF your data structure isn't very nested and uses few complex types, like arrays.

And yes, you absolutely will find dozens of things to slap into a DB once you got a taste of it, and there's little reason not to. Save your settings in there, debug info, events… everything can be a table if you're brave enough. :)

ugh i was hoping this wasnt going to be the answer because its another thing to learn. I need something easy to learn would that be sqlite.

If I have a database should it be explicitly for the job queue or can I look at storing other things in it? Like I may want to store event history.