Binette

u/Binette@lemmy.ml
72 posts · 1.1k comments

Recent posts

Recent comments

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.

Well yeah, people are changing frontends and warned others that Tesseract has that kind of blocklist and they don't support it. If people that used the tool didn't find out until now, it's mostly a communication issue from the dev. And to the user that knows none the wiser, opinions that they would've accessed if not for using Tesseract are essentialy not available. The option to turn it off is essentially hidden, and the user can't find out that information is being blocked (as seen by the reaction it caused in the threadiverse). It's censorship by omission of information. Even if they had good intentions, the way they went about it failed to communicate what the blocklist was about, and that information was being blocked in the first place.

It's also just kind of a silly thing to implement in a client. That's the perspective the memes are coming from. Usually, blocklists should be left to the instance administrators or users. The client should only easily allow such a list to be available.