The Clean Architecture in Python on HackerTube: recommended by 5 Hacker News commenters across 6 separate months, 2017–2021.
talk · intermediate · evergreen
Brandon Rhodes' PyOhio 2014 talk on applying the Clean Architecture in Python. He shows how this high-level design pattern fits Python's features and addresses maintainability problems in large applications.
HN points to it as a practical way to separate business logic from I/O, which reduces mocking and underlies the functional core, imperative shell idea.
“I'd really recommend this video.”
7 Hacker News comments link this video. Each one links back to its thread.
I'd really recommend this video. I had seen it years ago and just came back to it. It's about changing your architecture, one of the effects of that being changing how you need/use mock. ▶ this video
in “My Python testing style guide (2017)” · View on HN
"Promote I/O to management (where it can't do any damage)" is the actionably good thing i've taken from Brandon Rhoades' talk based on this: ▶ this video Living in a world where people regularly write single functions that: 1. loads data from a hardcoded string path of file location 2. does all the analysis inside the same loop that the file content iteration happens in and 3. plots the results ... that cleavage plane is a meaningfully good one. The rest of the ideas fall into "all things in moderation, including moderation", and can and should be special-cased judiciously as long as you know what you're doing. But oh god please can we stop writing _that_ function already.
in “It's probably time to stop recommending Clean Code (2020)” · View on HN
These are some of my favorites: Clean Architectures in python: ▶ this video Pandas from ground up: [link] How to write actually object-oriented python: [link] It's Time to Learn Regular Expressions: [link]
in “Ask HN: What are some of the best Python related talks that you have watched” · View on HN
This is the same principle of the Clean Architecture. I like how Brandon Rhodes explain how to apply it in Python: ▶ this video
in “Functional core, imperative shell (2012)” · View on HN
I was going to write that I don't have a good pointer, but actually I think the idea is basically the "onion architecture" or "clean architecture". I don't recall if I watched all of this talk, but in general I like Brandon Rhodes' PyCon talks : ▶ this video [link] I don't come from a Java background, but I think that many of these ideas originated in the Java community. They came to Python later (if at all), and it's a little funny to see Go struggling with the same thing. I think I came at it from more of a functional programming perspective, and the style gradually converged with what people were thinking about OOP. I'm not actually of all the details about "clean architecture" and "onion architecture", but they are definitely related to dependency injection. Basically all your effects and state can be instantiated on the "outside" in main() and passed INWARD. But I don't believe it necessarily has to be pure. I encapsulate all my state, but I don't encapsulate all my side effects, like printing to the screen. Some people appeared to like this comment, which is somewhat related: [link] I'm not sure how much this will help, but here is 12K+ lines of code I wrote with zero globals: [link] The main directories to look at are core/ and osh/. The main program imports a lot of stuff and wires it together: [link] (There is a bunch of surface messiness, but the architecture is sound.) I've also written even larger programs with zero globals. Also, I believe that web frameworks are some
in “A theory of modern Golang” · View on HN
For the Python programmers, there is also a better explanation of the same concept by Brandon Rhodes: The Clean Architecture in Python. ▶ this video
in “The Clean Architecture (2012)” · View on HN
I have been researching into several testing approaches and so far in my experience yes fakes are better than mocks. But what is even better is not having to fake or mock stuff especially for testing business logic. One of the problems we get ourselves into is abstracting service io code into functions and calling them from our business logic code. This forces us to mock all the io calls, instead we should be doing the opposite i.e abstracting business logic into discrete functions of pure data in and out and then calling those functions from our io code. This way we can test the business logic independently of the io code. Testing the business logic now becomes quite simple and one can leverage property testing to further boost our confidence in such tests. Many times the ramaining io code is just calling other functions and doesn't need to be tested. Several other ideas that relate to this are hexagonal architecture, Domain Driver Design, clean architecture and functional core with an imperative shell. Some resources to further explore these ideas: Clean Architecture in Python - ▶ this video Why integrated tests are a scam - [link] Boundaries - [link]
in “Prefer Fakes over Mocks” · View on HN