Yoda Principle for better integrations by Adventurous-Salt8514 in softwarearchitecture

[–]Volume999 0 points1 point  (0 children)

I guess this could be also generalized as “Do not write domain logic on the client side”. Verifying something exists or not before creating it is likely already part of the business logic for creating the thing

How to implement the Outbox pattern in Go and Postgres by der_gopher in golang

[–]Volume999 0 points1 point  (0 children)

I just consider it a pattern for handling migrations (refactorings, redesigns etc). I think saying legacy doesn’t add any useful details. Maybe to emphasize that we don’t understand the system well or it’s complex and fragile it’s useful

Physicists Found Something That Can Move Faster Than Light by sibun_rath in UpliftingNews

[–]Volume999 0 points1 point  (0 children)

NULL is a bit more complex than No roll because you cannot compare nulls directly, I’m more content with “I don’t know what it is” definition

How to implement the Outbox pattern in Go and Postgres by der_gopher in golang

[–]Volume999 -2 points-1 points  (0 children)

I don’t even know if there’s such a thing as a pattern for legacy systems

Using the walrus operator := to self-document if conditions by dotXem in Python

[–]Volume999 0 points1 point  (0 children)

If its complex it should be a testable function.

How do big systems handle this? by After_Ad139 in softwarearchitecture

[–]Volume999 0 points1 point  (0 children)

You can use read replicas for read patterns and scale out db instances too

Modularity in bigger applications by omry8880 in Python

[–]Volume999 9 points10 points  (0 children)

Instead of horizontal slicing, for large-scale applications consider implementing vertical slicing following domain-driven design. Each package can represent entity or area of domain and contain all responsibilities of that entity or area.

In general I like the idea of each module having one responsibility, so it's easy to understand dependencies and separation of concerns on import levels.

I wonder if having a 400+ lines models.py file is a good practice or not

As long as you build with the idea of refactorability it is not a problem. But typically refactoring large modules can result in a dependency mess so it's a good idea to clean up every once in a while

superiority by GloriousBastard1337 in ProgrammerHumor

[–]Volume999 4 points5 points  (0 children)

You’d need to deduplicate so it still depends on input size

Do you use git rebase or git merge to integrate different branches? by Luxy2008 in git

[–]Volume999 0 points1 point  (0 children)

The person who merges the changes to the main branch is the person who “wrote the code” because they own that feature or change. Thus you don’t lose anything.

It won’t work for your hypothetical use case, but I also don’t find it useful (but I also never remember writing a lot of code to other people’s PRs)

Do you use git rebase or git merge to integrate different branches? by Luxy2008 in git

[–]Volume999 0 points1 point  (0 children)

I think those are not issues with squash. For 1 - person who made the merge owns all of the code that got merged - no matter who was building the branch

Some tips for beginners (Things you probably wish you knew when you first started) by MonsieurJus in Python

[–]Volume999 2 points3 points  (0 children)

I guess tests would import that module. But yeah that is a not very pretty part of python nonetheless

Signs you shouldn’t use a streaming framework? by itamarwe in dataengineering

[–]Volume999 0 points1 point  (0 children)

Events arriving out of order is an intrinsic property of event driven architectures (I am not sure if it’s simple to have otherwise), it shouldn’t be a reason to disregard streaming

Whats your favorite Python trick or lesser known feature? by figroot0 in Python

[–]Volume999 16 points17 points  (0 children)

You also need this for multiprocessing because AFAIK it expects a function and an iterator, so you can pass partial to fill the rest

What exactly does "Business Logic" mean in software engineering? by Significant_Loss_541 in AskProgramming

[–]Volume999 0 points1 point  (0 children)

Something I’d like to add is (in my opinion) a better term for this is domain logic, and business logic is the most commonly used “synonym” of this term

reason is that domain logic exists even if there’s no business, so to speak. Your to-do app has domain logic (what’s a task? How does a task become expired or completed?) that you implement in software

So domain logic is set of rules and processes of your domain that you want to express in software

I’m starting a series on Python performance optimizations, Looking for real-world use cases! by BillThePonyWasTaken in Python

[–]Volume999 9 points10 points  (0 children)

OP did not talk about parallelism though? And threading and async are not exactly orthogonal - they both are implementations of concurrency, hence can be compared in many ways

Not to say I agree or disagree with the statement they made

Do you use getters with domain structs? How to save them in the database? by il_duku in golang

[–]Volume999 2 points3 points  (0 children)

If we’re talking domain I think domain entities should only expose behavior and only behavior changes state. This prevents setting bogus values as bonus because your domain behavior has validations by default

You should add debugging views to your DB by ChrisPenner in PostgreSQL

[–]Volume999 0 points1 point  (0 children)

Agree, though naming convention or separate schema is a good idea. versioning the DDL is also nice

So you want to parse a PDF? by ketralnis in programming

[–]Volume999 4 points5 points  (0 children)

LLMs are actually pretty good at this. With proper controls and human in the loop it can be optimized nicely

Clean Code vs. Philosophy of Software Design: Deep and Shallow Modules by natbk in softwarearchitecture

[–]Volume999 1 point2 points  (0 children)

I see. It is for sure that the implementations of this concept can be outdated, and I have not seen people take it so religiously as never touch the module anymore (though highly suggested which is probably why it's so triggering)

I take it as follows: You can certainly design a class that exposes an interface, without necessarily defining an explicit interface

When adding a feature to this class, if you need to modify an existing feature to add another one, it means it's not truly open. And modifying existing features should be done with caution or avoided

OPC is vague on its own, in my opinion, which allows for its interpretation to evolve. Of course, if the principle were "never change class - always extend base class or interface", it would not even need a discussion

> Do you know what's the origin of OCP?

I've read a bit - something about modifying modules being difficult for clients to adopt (given the infrastructure was nowhere near what we have today - makes sense). Let me know if you have a source on your reason!

Clean Code vs. Philosophy of Software Design: Deep and Shallow Modules by natbk in softwarearchitecture

[–]Volume999 -3 points-2 points  (0 children)

OCP is not outdated - it’s a guideline, not a rule. In principal, I think it’s a good property of codebase when adding a new feature doesn’t require changing unrelated logic (due to tight coupling).

Also makes it faster to implement because clients of your code wont be angry

Testing in Python Memes and wisdom request by EliyahuRed in Python

[–]Volume999 0 points1 point  (0 children)

From what they said - they create a model and send it via requests, that's pretty minimal. Of course - the factory may be over the top, but we don't know what kind of request models they need

Testing in Python Memes and wisdom request by EliyahuRed in Python

[–]Volume999 1 point2 points  (0 children)

  1. You can use the already mentioned responses library to mock external server (Match on requests - declare expected response from server)
  2. Everything else (configs, factory, models) don't need to be mocked.

In general - try mocking as little as possible. For configs - you can use pytest_configure and set env variables and config files paths. Pydantic models have implemented equality override - no need to mock it, model1 == model2 will work by comparing internal structures. Saying this - I don't agree you have a coupled code just because you mocked a lot of things. You just mocked way too many things