I do exactly this in my side project. I have a set of rules which put restrictions on which packages and modules can be included from other packages and modules. For example, a high maturity package is not allowed to depend upon a low maturity package. Similarly, a core library package is not allowed to rely on a package that is specific to a particular product or a particular piece of bespoke development. In this way, much of the potential for circular dependencies is eliminated, and the purpose and internet is clearly communicated.
(I don't do this using sourcery though ... I have my own set of rules)
Basically, you have an api class for each Django app, and you use this class for all external interactions. The api class calls the service class, and the service class deals with the Django ORM. I added a view class, which is my DjangoRestFramework layer; so when a request comes in, it's caught by my view class, and passed onto the api class. I have DRF serializers for outgoing data, and pydantic schemas for incoming data. I also have a selector class for read-only views of my data.
It's a lot of typing, but I know exactly where everything is when something goes wrong, or I need to add a small adjustment somewhere, also it's easy for new devs to learn and use. One downside is that an api change require you to touch a dozen files.
Not really, no. But it is pretty straightforward. My projects have:
- apis.py - the "external" surface of the app
- views.py - DRF layer on top of apis.py
- services.py - the layer that writes to the Django ORM
- selectors.py - provides "read-only" views or filters of data
- serializers.py - serialized outputs, using DRF
- schemas.py - pydantic classes that control incoming JSON types
- models.py - Django model declaration
- urls.py - url endpoints, pointing to views.py
- core.py - maybe another file with more business logic, used by apis.py
I have had trouble using Django API Domains interfaces.py, so I left them out. The main point is, figure out the right balance of concise code and separation of concerns for your taste, and your stack. Good luck!
Thank you, that's very helpful.
Do I understand correctly that the REST component uses 2 different data structures? schemas.py for the incoming JSON and serializers.py for the return data?
Yes, according to the way I did it. You could put DRF serializers and Pydantic schema into the same file and call that "serializers.py", or you could just use DRF for incoming form validation.
Similarly, you could collapse "selectors.py" into "services.py". I put read-only operations into "selectors.py" and write operations into "services.py", but you don't have to. I got that idea from this styleguide: https://github.com/HackSoftware/Django-Styleguide which is in the Appendix of the Django Domain API docs.
That's very cool.
Can you tell a bit more about this set of rules?
"For example, a high maturity package is not allowed to depend upon a low maturity package. Similarly, a core library package is not allowed to rely on a package that is specific to a particular product or a particular piece of bespoke development."
I really like these.
I have a general system for representing metadata in source files. (I use YAML documents embedded in block comments).
Some of this metadata gives traceability information for requirements, tests etc.. while other metadata enables me to associate a maturity level with each file.
My build system understands this metadata and uses it to inform e.g. the minimum test coverage that it expects on a file-by-file basis.
The same metadata is used to ensure that all of the other components that a file references are at the same level of maturity or higher.
I also have metadata for each file (partly derived from location in the repository) that gives each file a number which defines it's position in a hierarchy of design elements.
The position in the hierarchy helps to indicate what the purpose of the file is. I use this to make a distinction between those core, foundational, stable design elements upon which other design elements may build, and those more peripheral, ephemeral and 'agile' design elements which can be quickly tailored to meet the needs of a client or partner.
This means that a (hopefully stable) core API component can be prevented from relying upon a (perhaps less stable) bespoke customer-specific component. It also means that there's more freedom in changing and adapting peripheral designs as you can have confidence that it's stability is not something that is going to be relied upon.
Thanks for the detailed description.
That's a really sophisticated system with several cool features.
* minimum test coverage on a file-by-file basis
* various levels maturity
"It also means that there's more freedom in changing and adapting peripheral designs as you can have confidence that it's stability is not something that is going to be relied upon."
That's a big advantage, indeed.
I also like the concept of storing this metadata next to the code in structured comments.
It's helpful to think of this as akin to a DDOS-like attack on the Russian internal security infrastructure.
They've only got so much bandwidth - money, personnel and time - to deal with all of the myriad security issues which keep popping up.
The more people we can reach out to, the more 'leads' the security services will have to investigate, then the less effective they will be at propping up Putin's empire of fear.
Putin holds power because everyone is so afraid. As soon as the security services stop being effective, and people learn that they don't need to be afraid any longer ... then the only thing keeping him in power will begin to evaporate.
It's more than a miniscule chance. And it's not just about the shift in public opinion. It's also about consuming the limited bandwidth that the Russian security services have available to deal with stuff like this.
Think of it like DDOS-ing their internal security apperatus.
I really don't think this is how you change a warmonger's mind. And it's anyway under the assumption that you get enough people to make it a DDOS level thing.
We can allow fear to turn us all into slaves, or we can take simple acts like this to defend our freedom.
Acting together, we can reach out to hundreds of thousands of individuals. The Russian police cannot arrest all who are contacted, and even if they try, all of that time, money and manpower that they pour into policing is time, money and manpower that is taken away from brutalizing people in Ukraine.
So even if someone is arrested; even if they are imprisoned -- they can be proud to know that they have done something tangible and significant to help save lives.
I don't think there is much one can do on their own. Even our relatives can't help because most countries closed their borders and aerospace and tech firms are not inclined to hire Russians right now. I for one could not get any kind of ways to evacuate.
Countries did not close borders to regular citizens. Unless your insist on flying a Russian airline, you can leave and apply for residence or even asylum (if you are against the war, you are under threat of political prosecution).
not exactly true. In retaliation to prohibiting Russian airlines in their airspace, Russia in turn prohibited the airlines of other countries in Russia. So right now you can fly to some Soviet republics, Turkey, Israel, South Korea and that's it I think.
With all the airline shutdowns, payment system sanctions and COVID lockdowns (which are still in effect on the Russian border), the west has done a great job of locking Russians inside Russia, where they have three choices:
1. Protest against Putin and go to prison, in the hope that if Putin is gone the west will drop all sanctions (not very likely).
2. Keep head down.
3. Support the government.
Given that the rest of the world is trying as hard as possible to fuck Russia and random ordinary Russians in every way, I suspect a lot of them will conclude it's us vs them and pick (3). Really a bad set of strategies, in my view. It would be ironic and sad if WW3 was triggered by virtue signalling.
A third take is that this decision has probably taken six months to make, negotiate and finalize and is probably unrelated to the news of the last 2-4 weeks.
If he has thousands of nuclear warheads, he's not just a rat and he's not cornered.
ie. there are still diplomatic ways out of this open to Putin. If he is not open to considering them and feels cornered, it is his own shortsightedness and failing.
It has been said that you should never draw your pistol unless you are going to shoot. I don't know if that's true; but I do think it's unwise to threaten violence unless you are quite sure you are prepared to carry through.
I think Putin is prepared to carry through (he's made the threat more than once). Russia seems to be losing in Ukraine; but they can't be seen to be slinking away with their tail between their legs. So I think there's a good chance Russia will pop a tactical nuke in Ukraine.
For the same reasons, NATO can't be seen to tolerate the popping of tactical nukes in a regional conflict; they would have to retaliate, for fear that their nuclear deterrent be treated as a joke. I haven't any idea how NATO might select their target, though; striking a city would be gross over-reaction, and striking Russians in Ukraine would be rather counterproductive.
> For the same reasons, NATO can't be seen to tolerate the popping of tactical nukes in a regional conflict; they would have to retaliate, for fear that their nuclear deterrent be treated as a joke.
NATO should definitely not respond to nukes with nukes unless Putin drops one on a NATO country. Ukraine is not in NATO. That makes it a first strike, not a retaliatory strike. Putin's propaganda has been that NATO is an aggressor threatening Russia. If NATO strikes Russia in retaliation for a strike on a non-member country that only vindicates him, and you know, leads directly to WWIII
> NATO should definitely not respond to nukes with nukes unless Putin drops one on a NATO country.
Hey, I didn't mean to sound like a cheerleader for global thermonuclear war! I'm just observing that the logic of nuclear deterrence calls for a response whoever Russia attacks. If it becomes clear that Russia can nuke anyone it likes as long as they're not in NATO, then it can march into e.g. Georgia or Armenia with a company of conscripts, and take over, declaring that any resistance will be met with nukes.
Suppose Russia pops a small nuke in Ukraine? Really, that's not going to achieve any major military victory. They'd need a few to end the war in Russia's favour. That would result in clouds of fallout afflicting NATO countries. At some point you'd have to say "that's enough". But at what point? After two? A dozen? Only after the first megaton city-flattener?
I was a member of CND for a year, back in the 80's. I still favour unilateral disarmament. I quit not because I didn't support the goals, but because I was shocked at the political infighting I observed at the Annual General Meeting.
Current agent-based systems are little more than toys ... but this situation is improving very rapidly.