Hey, Eric. I just wanted to thank you for reaching out to me a while ago when I was unable to post on my own Substack. Your kind attention gave me the will to keep trying, and I am now posting somewhat regularly. The technology part of it annoys me still; but the thought of your cleverness with subjects beyond my comprehension let’s me relax and enjoy my English major’s sensibility and write to my heart’s content. Katharine
P.S. I never figured out what I was missing before. All of a sudden I was able to post. And then some of my previous musings became published as well. Mysterious but welcome.
Thanks for sharing that! I think with platforms like this at some point you just need to jump in and start using it. You start to figure out which parts work for your use case, and which parts are irrelevant. The whole newsletter vs blog/website distinction takes some getting used to. With a blog or website we write and then people show up to read. Publishing a new post feels somewhat lighter because yes it's public, but we can always edit the post as needed.
With a newsletter, it goes out to everyone all at once. That definitely takes a bit of getting used to, and it makes it a little harder to just jump in and see how things work.
Hey, Eric. I just wanted to thank you for reaching out to me a while ago when I was unable to post on my own Substack. Your kind attention gave me the will to keep trying, and I am now posting somewhat regularly. The technology part of it annoys me still; but the thought of your cleverness with subjects beyond my comprehension let’s me relax and enjoy my English major’s sensibility and write to my heart’s content. Katharine
P.S. I never figured out what I was missing before. All of a sudden I was able to post. And then some of my previous musings became published as well. Mysterious but welcome.
Thanks for sharing that! I think with platforms like this at some point you just need to jump in and start using it. You start to figure out which parts work for your use case, and which parts are irrelevant. The whole newsletter vs blog/website distinction takes some getting used to. With a blog or website we write and then people show up to read. Publishing a new post feels somewhat lighter because yes it's public, but we can always edit the post as needed.
With a newsletter, it goes out to everyone all at once. That definitely takes a bit of getting used to, and it makes it a little harder to just jump in and see how things work.
I'm glad to hear it's working for you now. :)
Yes ran into this(urls.py) and similar issues(with setting.py) when I was starting with Django.
So I don't touch setting.py
create conf/settings/ folder with settings_local.py & settings_prod.py files
------------------------------------------
from .base_settings import *
THIRD_PARTY_APPS = ['debug_toolbar']
PROJECT_APPS = ['']
INSTALLED_APPS = INSTALLED_APPS + THIRD_PARTY_APPS + PROJECT_APPS
-------------------------------------------
on same lines urls.py
-------------------------------------------
urlpatterns = [
path('admin/', admin.site.urls),
]
app_urlpatterns = [path('synths/', include('synths.urls')), path('string/', include('synths.urls')),]
project_urlpatterns = [path('', include('pianos.urls')),]
urlpatterns = urlpatterns + app_urlpatterns + project_urlpatterns
--------------------------------------------
I've certainly seen some approaches like this. Where did you pick up these patterns?
I almost don't touch settings.py, just override it another settings file.
Other thing is List or Array might not be clean or clear way to represent certain collection of or related settings.
Enums can make it less cluttered.
----------------------------------------------------------------
from enum import Enum
CLIENT_CODE = 'AT-EU'
ENV = 'dev'
PORT = "9090"
ENDPOINT_PREFIX = f"https//:{ENV}.{CLIENT_CODE}.oursucess.com:{PORT}"
class END_POINTS(Enum):
INVENTORY = f"{ENDPOINT_PREFIX}/inventory"
INVOICES = f"{ENDPOINT_PREFIX}/invoices"
RETURNS = f"{ENDPOINT_PREFIX}/returns"
PEND_REFUND_REQUESTS = f"{ENDPOINT_PREFIX}/pending-refund-requests"
REFUND_REQUEST_PAID = f"{ENDPOINT_PREFIX}/refund-request-paid"
def __str__(self):
return str(self.value)
------------------------ usage of setting > print(END_POINTS.RETURNS)
if you need all the endpoint settings> print(END_POINTS._member_names_)
settings.py overide with some variations is fairly common.
if not I am no wrong cookiecutter for django does something like this too. And often when using docker there is setting_docker.py which is similar.
urlpatterns = urlpatterns + app_urlpatterns + project_urlpatterns
is my way of doing things, others might be doing similar stuff.