Forwarded from Python BackendHub (Mani)
Python BackendHub
بنظرم دانش تو زمینه بک اند به ۳ قسمت تقسیم میشه، که خیلی مهمه سه تاشو داشته باشیم. مثلا فکر کنید میخواین یک rest api بنویسید به همراه تست. قسمت اول بلد بودن فریم ورکی برای اینکاره. مثل پای تست و فست. ولی بلد بودن اینا کافی نیست فقط قسمت دوم، فلسفه پشت اون…
برداشت اشتباه نکنید از حرفم، من نگفتم فقط باید نوشتن api و تست بلد باشین. گفتم سه سطح یادگیری برای هرچیزی هست.
تو یک سطح شما یوزر خوبی هستی با اتکا به یک ابزار خاصی.
تو یک سطح شما میتونی یوزرخوبی باشی حتی بدون اتکا به اون ابزار خاص. و میتونی درک کنی که چطوری کار میکنه.
و تو یک سطح شما نه تنها یوزرخوبی هستی، بلکه تصمیم گیرنده خوبی هستی چون چرا ها رو درک میکنی.
@PyBackendHub
تو یک سطح شما یوزر خوبی هستی با اتکا به یک ابزار خاصی.
تو یک سطح شما میتونی یوزرخوبی باشی حتی بدون اتکا به اون ابزار خاص. و میتونی درک کنی که چطوری کار میکنه.
و تو یک سطح شما نه تنها یوزرخوبی هستی، بلکه تصمیم گیرنده خوبی هستی چون چرا ها رو درک میکنی.
@PyBackendHub
⚡5
TorhamDev | تورهام 😳
آموزش پولدار شدن با جنگو https://www.youtube.com/watch?v=o8u5qcsZZdA
همچین چیزی که یارو زده رو داخل استارتاپهای خوفناک ایرانی که ۳ روزه از تاسیسشون گذشته ازت میخان تو دو دوماه با ۲ میلیون تومن.
با این ایده که، بابا اینکه چیز خواستی نداره دوتا چارت دیگه
با این ایده که، بابا اینکه چیز خواستی نداره دوتا چارت دیگه
😢8
Forwarded from Python BackendHub (Mani)
یک سایتی هست, که ۱۲ فاکتور مهم برای اپلیکیشن های software-as-a-service رو نوشته. و توصیه میکنم بخونیدش حتما.
https://12factor.net
تو قسمت کانفیگ یکیش اینه:
Config varies substantially across deploys, code does not.
دقت کنید ببینید چطوری تغییر کرد. یعنی چی دقیقا این؟
یعنی این پترن اشتباهه:
deploy_env = "local" / "dev" / "staging" / "prod"
اپلیکیشن شما با تغییر deploy_env نباید تغییر کنه. اپلیکیشن شما یک کانفیگ داره که آگاه نیست که قرار کجا ران شه. پس چیزایی مثل prod.env اشتباهه. دلیلش هم تو سایتش نوشته:
In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.
پس شما هرچیزی که میخواین کانفیگ شه رو کانفیگ پذیر میکنید. دیگه اینکه debug=false باشه یا true تو deploy برمیگرده به آپریشن. بهتره مقدار دیفالت نذارین اگه چیزی که دارین کانفیگ میکنید خیلی مهمه.
و نکته بعدی که بسیار مهمه, پوش کردن .env به ریپو نباید اشکالی تو ci/cd شما بکنه. حواستون باشه چه فایل هایی رو دارین شیپ میکنید به پروداکشن. فایلی مثل .env فایلی نیست که شیپ کنید. اینکه چطور env variable ها ساخته میشن روش های مختلفی وجود داره, ولی ساختنش با یک فایل .env و اضافه کردنش به گیت ایگنور اصلا روش منطقی نیست. چون تو scale شما خیلی اذیت میشین. هر scale horizontally که بخواین انجام بدید باید ssh کنید به سرور و اون فایل .env رو اضافه کنید 🤦♂️
تجربه توسعه هم بد میکنه. روش های زیادی برای انجام این کار هست. مثل استفاده از kustomize یا secret manager کلادی که ازش استفاده میکنید یا hashicorp vault یا .... . اینکه چه روشی انتخاب میکنید مهم نیست. مهم اینه که تو حالت اول stateless باشه یعنی بتونید خیلی راحت scale horizontal انجام بدید. در درجه دوم اینکه implicit نباشه(مثل deploy env) و کاملا مشخص باشه چی داره کانفیگ میشه. و در درجه آخر و حالت خیلی ایده آل یک حالت versioning و ورژن کنترل داشته باشه.
@PyBackendHub
https://12factor.net
تو قسمت کانفیگ یکیش اینه:
Config varies substantially across deploys, code does not.
دقت کنید ببینید چطوری تغییر کرد. یعنی چی دقیقا این؟
یعنی این پترن اشتباهه:
deploy_env = "local" / "dev" / "staging" / "prod"
اپلیکیشن شما با تغییر deploy_env نباید تغییر کنه. اپلیکیشن شما یک کانفیگ داره که آگاه نیست که قرار کجا ران شه. پس چیزایی مثل prod.env اشتباهه. دلیلش هم تو سایتش نوشته:
In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.
پس شما هرچیزی که میخواین کانفیگ شه رو کانفیگ پذیر میکنید. دیگه اینکه debug=false باشه یا true تو deploy برمیگرده به آپریشن. بهتره مقدار دیفالت نذارین اگه چیزی که دارین کانفیگ میکنید خیلی مهمه.
و نکته بعدی که بسیار مهمه, پوش کردن .env به ریپو نباید اشکالی تو ci/cd شما بکنه. حواستون باشه چه فایل هایی رو دارین شیپ میکنید به پروداکشن. فایلی مثل .env فایلی نیست که شیپ کنید. اینکه چطور env variable ها ساخته میشن روش های مختلفی وجود داره, ولی ساختنش با یک فایل .env و اضافه کردنش به گیت ایگنور اصلا روش منطقی نیست. چون تو scale شما خیلی اذیت میشین. هر scale horizontally که بخواین انجام بدید باید ssh کنید به سرور و اون فایل .env رو اضافه کنید 🤦♂️
تجربه توسعه هم بد میکنه. روش های زیادی برای انجام این کار هست. مثل استفاده از kustomize یا secret manager کلادی که ازش استفاده میکنید یا hashicorp vault یا .... . اینکه چه روشی انتخاب میکنید مهم نیست. مهم اینه که تو حالت اول stateless باشه یعنی بتونید خیلی راحت scale horizontal انجام بدید. در درجه دوم اینکه implicit نباشه(مثل deploy env) و کاملا مشخص باشه چی داره کانفیگ میشه. و در درجه آخر و حالت خیلی ایده آل یک حالت versioning و ورژن کنترل داشته باشه.
@PyBackendHub
12factor.net
The Twelve-Factor App
A methodology for building modern, scalable, maintainable software-as-a-service apps.
Forwarded from Sadra Codes
از ایرانیکارت استفاده نکنید! حداقل روی اکانت ها و پروفایلهای اصلیتون تنظیمش نکنید. اگه واقعا نیاز به حساب بانکی دارید، توی بانک زراعت ترکیه حساب باز کنید یا یه تریک قانونی بزنید.
خیلی از بچهها میان سراغم سر قضیه Sponsorship گیتهاب و اکانت استرایپ رو از ایرانیکارت گرفتن، کاشف به عمل اومده که اکانت به نام شخص دیگهای هست و گیتهاب زده اکانت طرف رو ساسپند کرده و هیچجوره درست نمیشه مگه اینکه صاحب اصلی اکانت رضایت بده!! (طبق چیزی که گیتهاب میگه)
حالا بفرما بگرد صاحب اصلی اکانت رو پیدا کن.. معلوم نیست ایرانه.. خارجه.. 😑
خیلی از بچهها میان سراغم سر قضیه Sponsorship گیتهاب و اکانت استرایپ رو از ایرانیکارت گرفتن، کاشف به عمل اومده که اکانت به نام شخص دیگهای هست و گیتهاب زده اکانت طرف رو ساسپند کرده و هیچجوره درست نمیشه مگه اینکه صاحب اصلی اکانت رضایت بده!! (طبق چیزی که گیتهاب میگه)
حالا بفرما بگرد صاحب اصلی اکانت رو پیدا کن.. معلوم نیست ایرانه.. خارجه.. 😑
🤨10👍2❤1
ویدیو خوبی بود برای یادگرفتن Alembic.
المبیک دقیقا میاد برای شما همون کاره migration های جنگو رو انجام میده ولی برای فریمورک خاصی نیست، بیشتر همراه SQLAlchmey استفاده میشه.
نکته: این داداشمون انگلیسی اسکاتلندی حرف میزنه لحجه داره :)
https://www.youtube.com/watch?v=i9RX03zFDHU
@TorhamDevCh
المبیک دقیقا میاد برای شما همون کاره migration های جنگو رو انجام میده ولی برای فریمورک خاصی نیست، بیشتر همراه SQLAlchmey استفاده میشه.
نکته: این داداشمون انگلیسی اسکاتلندی حرف میزنه لحجه داره :)
https://www.youtube.com/watch?v=i9RX03zFDHU
@TorhamDevCh
YouTube
Alembic Introduction - Migrations and Auto-Generating Revisions from SQLAlchemy Models
This video introduces Alembic, which is a migration package in Python for managing changes to your databases.
We'll look at how to setup a Migration Environment and define revisions with upgrade and downgrade operations. We'll also look at how to integrate…
We'll look at how to setup a Migration Environment and define revisions with upgrade and downgrade operations. We'll also look at how to integrate…
❤1👍1
This media is not supported in your browser
VIEW IN TELEGRAM
این خیلی باحال بود 😂
@TorhamDevCH
@TorhamDevCH
😁14👍2🤣2
سوال جنگویی:
اگه یک مدل داشته باشیم به شکل زیر:
بعد بیاییم این کد رو اجرا کنیم:
اومدیم یک آبجکت ساختیم و ذخیره اش کردیم. بعد فیلم name که پرایمریکی بود رو آپدیت کردیم و ذخیرش کردیم.
حالا سوال اینه، در این لحظه چه اتفاقی میوفته؟ آیا ارور میخوریم یا ابجکت آپدیت میشه یا اتفاق دیگه ای میوفته؟
@TorhamDevCH
اگه یک مدل داشته باشیم به شکل زیر:
from django.db import models
class Fruit(models.Model):
name = models.CharField(max_length=100, primary_key=True)
بعد بیاییم این کد رو اجرا کنیم:
>>> fruit = Fruit.objects.create(name="Apple")
>>> fruit.name = "Pear"
>>> fruit.save()
اومدیم یک آبجکت ساختیم و ذخیره اش کردیم. بعد فیلم name که پرایمریکی بود رو آپدیت کردیم و ذخیرش کردیم.
حالا سوال اینه، در این لحظه چه اتفاقی میوفته؟ آیا ارور میخوریم یا ابجکت آپدیت میشه یا اتفاق دیگه ای میوفته؟
@TorhamDevCH
👍4
TorhamDev | تورهام 😳
سوال جنگویی: اگه یک مدل داشته باشیم به شکل زیر: from django.db import models class Fruit(models.Model): name = models.CharField(max_length=100, primary_key=True) بعد بیاییم این کد رو اجرا کنیم: >>> fruit = Fruit.objects.create(name="Apple") >>> fruit.name…
اتفاقی که میوفته اینه که از اونجایی که فیلد name پرایمریکی و پرایمریکی ها Read-Only هستن شما نمیتونی آپدیتش کنی و اگه تلاش برای آپدیت کردنش کنی، جنگو میاد یک آبجکت جدید میسازه دقیقا با همون اطلاعات قبلی ولی فقط پرایمریکی رو تغییر میده. در نهایت شما دوتا آبجکت Fruit خواهید داشت.
@TorhamDevCH
@TorhamDevCH
👍13❤2
یک مشکلی که من داخل بعضی از برنامهنویسا میبینم و برای خودم هم اتفاق افتاده و برای شما هم خواهد افتاد، اینه که میخان یک چیز جدید توسعه بدن اما نمیدونن چطوری. برای مثال با خودت میگی خوب بریم یک سیستم بانکی بزنیم ولی هیچ ایده ای نداری سیستم بانکی چطوری، چه دیزاینی لازم داره و ...
اینجا چندتا حالت وجود داره.
۱. پشیمون میشی
۲. میری دنبال یکی بگردی که قبلا انجام داده
۳. خودت تحقیق میکنی.
شماره ۱ منم که هیچ وقت پیشرفت نمیکنه.
شماره ۲ شانسی ولی بیشتر اوقات وجوه رو مخی داره برای بقیه.
شماره ۳ اونی که شروع میکنه یادگیری و گوگل و تحقیق زمان خوبی میزاره و چیزهای خیلی خوبی یادمیگیره.
حالا در حالت سوم به نظرم اول میتونه با یوتیوب کردن، گوگل کردن و داکیومنت خودندن تا حد زیادی از ماجرا سر در بیاره. بعدش میشه رفت کدبیس بقیه انسانهای کرهخاکی که این کار انجام دادن را خواند. در نهایت به اندازه کافی یادمیگیری و اون حاله و مه که تو ماجرا بود از بین میره و همچی شفاف میشه.
و این هم باید یادتون باشه تو بحثی مثل دیزاین کردن ساختار و اینها دانش و تجربه خیلی مهمه، هرچی بیشتر چیز میز دیزاین کرده باشید بهتر میشید.
@TorhamDevCH
اینجا چندتا حالت وجود داره.
۱. پشیمون میشی
۲. میری دنبال یکی بگردی که قبلا انجام داده
۳. خودت تحقیق میکنی.
شماره ۱ منم که هیچ وقت پیشرفت نمیکنه.
شماره ۲ شانسی ولی بیشتر اوقات وجوه رو مخی داره برای بقیه.
شماره ۳ اونی که شروع میکنه یادگیری و گوگل و تحقیق زمان خوبی میزاره و چیزهای خیلی خوبی یادمیگیره.
حالا در حالت سوم به نظرم اول میتونه با یوتیوب کردن، گوگل کردن و داکیومنت خودندن تا حد زیادی از ماجرا سر در بیاره. بعدش میشه رفت کدبیس بقیه انسانهای کرهخاکی که این کار انجام دادن را خواند. در نهایت به اندازه کافی یادمیگیری و اون حاله و مه که تو ماجرا بود از بین میره و همچی شفاف میشه.
و این هم باید یادتون باشه تو بحثی مثل دیزاین کردن ساختار و اینها دانش و تجربه خیلی مهمه، هرچی بیشتر چیز میز دیزاین کرده باشید بهتر میشید.
@TorhamDevCH
👍29❤1
داخل جنگو ۳ نوع Model inheritance داریم. یعنی مدلهای دیتابیس میتونن به سه شکل از هم دیگه ارث بری کنند.
۱. Abstract base classes
۲. Multi-table inheritance
۳. Proxy models
که فعلا با دوتا اول کار ندارم و احتمالا بدونید چی هستند. ولی سومی همیشه برای من گنگ بود که چی هست و چیکار میکنه. ولی داشتم داکیومنت جنگو میخوندم که رسیدم به توضیح پروکسیمدل و تمام، بهترین توضیحی بود که خوندم و تا آخر یادم خواهد ماند :)
if you only want to modify the Python-level behavior of a model, without changing the models fields in any way, you can use Proxy models.
اگر فقط و فقط میخوایید تو لول فانکشنالیتی مدل تغییر ایجاد کنید. مثلا فانکش foobar میخایید یک تغییر بدید برای نسخه جدید ولی میخوایید نسخه قدیمی باقی بمونه میایید از پروکسی استفاده میکنید.
حالا شما یک مدل دارید دقیقا با همون مشخصات ولی فانکشنالیتی فانکشن foobar فرق میکنه.
تو مثال خود داکیومنت یک فانکشنالیتی اضافه کرده:
@TorhamDevCH
۱. Abstract base classes
۲. Multi-table inheritance
۳. Proxy models
که فعلا با دوتا اول کار ندارم و احتمالا بدونید چی هستند. ولی سومی همیشه برای من گنگ بود که چی هست و چیکار میکنه. ولی داشتم داکیومنت جنگو میخوندم که رسیدم به توضیح پروکسیمدل و تمام، بهترین توضیحی بود که خوندم و تا آخر یادم خواهد ماند :)
if you only want to modify the Python-level behavior of a model, without changing the models fields in any way, you can use Proxy models.
اگر فقط و فقط میخوایید تو لول فانکشنالیتی مدل تغییر ایجاد کنید. مثلا فانکش foobar میخایید یک تغییر بدید برای نسخه جدید ولی میخوایید نسخه قدیمی باقی بمونه میایید از پروکسی استفاده میکنید.
حالا شما یک مدل دارید دقیقا با همون مشخصات ولی فانکشنالیتی فانکشن foobar فرق میکنه.
تو مثال خود داکیومنت یک فانکشنالیتی اضافه کرده:
from django.db import models
class Person(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=30)
class MyPerson(Person):
class Meta:
proxy = True
def do_something(self):
# ...
pass
@TorhamDevCH
👍4❤2⚡2
TorhamDev | تورهام 😳
داخل جنگو ۳ نوع Model inheritance داریم. یعنی مدلهای دیتابیس میتونن به سه شکل از هم دیگه ارث بری کنند. ۱. Abstract base classes ۲. Multi-table inheritance ۳. Proxy models که فعلا با دوتا اول کار ندارم و احتمالا بدونید چی هستند. ولی سومی همیشه برای من گنگ…
یک نکته رو باید در نظر داشته باشید که ساخت یک مدل پروکسی یک تیبل جدید داخل دیتابیس نمیسازه و از همون مدل قبلی استفاده خواهد کرد. تو این مثال مدل MyPerson دقیقا روی همون تیبل دیتابیسی که مدل Person کار میکنه کار خواهد کرد، پس اگه یک چیزی رو اپدیت کنید و بسازید و ... روی همون تیبل دیتابیسی انجام میدید که اگر با Person انجام میدادید.
@TorhamDevCH
@TorhamDevCH
👍3
👍8