نظرسنجی جالب ایلان ماسک:


اگر کسی پرچم آمریکا رو پاره کنه و یه پرچم دیگه میاره بالا، یه سفر رایگان، یک طرفه ولی اجباری به همون جایی که پرچمش رو برده بالا باید بره

بنظرم دانش تو زمینه بک اند به ۳ قسمت تقسیم میشه، که خیلی مهمه سه تاشو داشته باشیم.

مثلا فکر کنید میخواین یک rest api بنویسید به همراه تست.

قسمت اول بلد بودن فریم ورکی برای اینکاره. مثل پای تست و فست. ولی بلد بودن اینا کافی نیست فقط

قسمت دوم، فلسفه پشت اون موضوعه. که دونستنش خیلی ضروریه. مثلا تو بحث api نویسی کی باید یک اندپوینت post باشه کی put کی patch و .. . یک api چطور باید باشه. Rest api چی داره که بهش میگن restful. و …. یا مثلا برای تست نویسی چی باید تست شه. چقد باید تست نوشته شه. چی باید ماک شه. چی نباید ماک شه.

و قسمت سوم اینکه بدونیم پشت صحنه اینا چطور کار میکنن. قسمت سوم همیشه الزامی نیست چون انتهایی نداره ولی اگه به اندازه کافی قسمت سوم رو نداشته باشین، خیلی وابسته میشین به اون فریم ورکی که دارین ازش استفاده میکنید.


@PyBackendHub

برداشت اشتباه نکنید از حرفم، من نگفتم فقط باید نوشتن api و تست بلد باشین. گفتم سه سطح یادگیری برای هرچیزی هست.
تو یک سطح شما یوزر‌ خوبی هستی با اتکا به یک ابزار خاصی.
تو یک سطح شما میتونی یوزر‌خوبی باشی حتی بدون اتکا به اون ابزار خاص. و میتونی درک کنی که چطوری کار میکنه.
و تو یک سطح شما نه تنها یوزر‌خوبی هستی، بلکه تصمیم گیرنده خوبی هستی چون چرا ها رو درک میکنی.

@PyBackendHub

آموزش پولدار شدن با جنگو

https://www.youtube.com/watch?v=o8u5qcsZZdA

همچین چیزی که یارو زده رو داخل استارت‌اپ‌های خوفناک ایرانی که ۳ روزه از تاسیسشون گذشته ازت میخان تو دو دوماه با ۲ میلیون تومن.

با این ایده که، بابا اینکه چیز خواستی نداره دوتا چارت دیگه

من میگم پیشرفت 🤝

@TorhamDevCH

یک سایتی هست, که ۱۲ فاکتور مهم برای اپلیکیشن های 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

.

بگم دستم خورده یا بزارم فکر کنید؟

#music
برادر چی پخته 😳

از ایرانی‌کارت استفاده نکنید! حداقل روی اکانت ها و پروفایل‌های اصلیتون تنظیمش نکنید. اگه واقعا نیاز به حساب بانکی دارید، توی بانک زراعت ترکیه حساب باز کنید یا یه تریک قانونی بزنید.

خیلی از بچه‌ها میان سراغم سر قضیه Sponsorship گیت‌هاب و اکانت استرایپ رو از ایرانی‌کارت گرفتن، کاشف به عمل اومده که اکانت به نام شخص دیگه‌ای هست و گیت‌هاب زده اکانت طرف رو ساسپند کرده و هیچ‌جوره درست نمیشه مگه اینکه صاحب اصلی اکانت رضایت بده!! (طبق چیزی که گیت‌هاب میگه)

حالا بفرما بگرد صاحب اصلی اکانت رو پیدا کن.. معلوم نیست ایرانه.. خارجه.. 😑

بگذارید برادر بیشتر بپزد 👍

که اینطور

@TorhamDevCH

ویدیو خوبی بود برای یادگرفتن Alembic.

المبیک دقیقا میاد برای شما همون کاره migration های جنگو رو انجام میده ولی برای فریمورک خاصی نیست، بیشتر همراه SQLAlchmey استفاده میشه.

نکته: این داداشمون انگلیسی اسکاتلندی حرف میزنه لحجه داره :)

https://www.youtube.com/watch?v=i9RX03zFDHU

@TorhamDevCh

#music

باید چنل موزیک بزنم مثل ک

این خیلی باحال بود 😂
@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

اتفاقی که میوفته اینه که از اونجایی که فیلد name پرایمری‌کی و پرایمری‌کی ها Read-Only هستن شما نمیتونی آپدیتش کنی و اگه تلاش برای آپدیت کردنش کنی، جنگو میاد یک آبجکت جدید میسازه دقیقا با همون اطلاعات قبلی ولی فقط پرایمری‌کی رو تغییر میده. در نهایت شما دوتا آبجکت Fruit خواهید داشت.
@TorhamDevCH

یک مشکلی که من داخل بعضی از برنامه‌نویسا میبینم و برای خودم هم اتفاق افتاده و برای شما هم خواهد افتاد، اینه که میخان یک چیز جدید توسعه بدن اما نمیدونن چطوری. برای مثال با خودت میگی خوب بریم یک سیستم بانکی بزنیم ولی هیچ ایده ای نداری سیستم بانکی چطوری، چه دیزاینی لازم داره و ...

اینجا چندتا حالت وجود داره.
۱. پشیمون میشی
۲. میری دنبال یکی بگردی که قبلا انجام داده
۳. خودت تحقیق میکنی.

شماره ۱ منم که هیچ وقت پیشرفت نمیکنه.
شماره ۲ شانسی ولی بیشتر اوقات وجوه رو مخی داره برای بقیه.
شماره ۳ اونی که شروع میکنه یادگیری و گوگل و تحقیق زمان خوبی میزاره و چیزهای خیلی خوبی یادمیگیره.

حالا در حالت سوم به نظرم اول میتونه با یوتیوب کردن، گوگل کردن و داکیومنت خودندن تا حد زیادی از ماجرا سر در بیاره. بعدش میشه رفت کدبیس بقیه انسان‌های کره‌خاکی که این کار انجام دادن را خواند. در نهایت به اندازه کافی یادمیگیری و اون حاله و مه که تو ماجرا بود از بین میره و همچی شفاف میشه.
و این هم باید یادتون باشه تو بحثی مثل دیزاین کردن ساختار و اینها دانش و تجربه خیلی مهمه، هرچی بیشتر چیز میز دیزاین کرده باشید بهتر میشید.
@TorhamDevCH

داخل جنگو ۳ نوع 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 فرق میکنه.
تو مثال خود داکیومنت یک فانکشنالیتی اضافه کرده:

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