یکی از بهترین منبع های یادگیری گیت, خوده داکیومنتشه .

https://git-scm.com/book/en/v2

یک از سرفصل هاش submodule هست که واقعا میتونه مفید باشه براتون مخصوصا برای فرانت کارا و کسایی که js میزنن.

It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.

https://git-scm.com/book/en/v2/Git-Tools-Submodules

@ManiFoldsPython

یه تجربه نهایی هم بنویسم:

+ شرکت درست و حسابی ازتون سفته نمیگیره.
+ شرکتی که حاکمیت درست درش پیاده باشه، بهتون ولکام پکیج میده (حتی بودجه نداشت در حد موس میده)
+ شرکت درست و حسابی مانیتورینگ تون نمیکنه، بلکه جلسه میذاره، تسک میدن، و از خودتون ددلاین میگیرن تسک چه زمانی تموم میشه و شما بهشون گزارش میدید.
+ شرکت درست و حسابی ساعت کاری نداره.
+ شرکت خیلی درست و حسابی تیم های مختلفی داره و شما بعد استخدام اولیه، خودتون انتخاب می کنید در کدوم تیم عضو بشید (این مورد آخر تو ایران پیاده نمیشه😁)

چند تا پست خیلی خیلی خوب مهران گذاشته تو کانالش توصیه میکنم بخونید. راجب کالچر یک شرکت خوب. حقیقت اینه که برای اینکه پیشرفت کنید یکی از مهم ترین فاکتور ها محله کاره. شما ۸ ساعت از روزتون سره کار هستین و شرکتی که کالچر خوب نداره قطعا سمه براتون. هرچقدر سلف استادی کنید ولی بازم نمیتونید تاثیر peer effect و محیط رو نادیده بگیرین. این مدت تو یوتیوب زیاد گشتم راجب فرهنگ شرکت های خوب و اینکه کلا چطوری کارو پیش میبرن. بنابراین تو دو پست میخوام یکم بپردازم به کالچر شرکت خوب. پست اول مقایسه کالچر یک استارت آپ خوب در برابر یک شرکت بزرگ خوب...

۱. رشد شما تو شرکت استارت آپ یا بزرگ متفاوته جنسش ولی دلیل نمیشه تو استارت آپ بیشتر یا کمتر بتونید پیشرفت کنید. بذارین مثال بزنم یکم مقایسه کنم. تو یک استارت آپ خوب شما راحت میتونید تغییر بدین تو روند کاری و با ۱-۲ جلسه به نتیجه برسید ولی تو شرکت های خیلی بزرگ مثل IBM این اتفاق میتونه سال ها طول بکشه.

۲. دست شما تو ابزاری که استفاده میکنید تو شرکت استارت آپ و کلا دپندسی ها بیشتره در نتیجه دامنه یادگیریتون بیشتر میشه در حالی که تو استارت آپ های بزرگ برای اضافه کردن دپندسی به architecture میتونه زمان زیادی طول بکشه.

۳. در عوض عمق یادگیری تو شرکت های بزرگ خیلی بیشتره چون کدتون سخت تر review میشه. مثلا مصاحبه یکی رو میدیدم که تو آمازون کار میکرد و میگفت وقتی اینترشیپ بودم اونجا اولین PR ام ۱۱ بار revision خورد و change request خواسته شد ازم تا مرج شد ولی تو وهمین پروسه کلی یاد گرفتم در حالی که تو محیط استارت آپ طبیعتا به این شدت سخت گیری انجام نمیشه. شرکت های بزرگ همچنین این قابلیت رو به شما میدن که تو scale بزرگ تر و چالش سخت تر کار کنید.


تو پست بعدی راجب مواردی که تو پست مهران بنظرم باید اضافه شه توضیح میدم
@ManiFoldsPython

تو پست دوم خیلی خلاصه بخوام کالچر یک شرکت خوبو بگم:

۰. مهم ترین فاکتور داشتن پروداکته. شرکتی که خودش پروداکت نداره احتمال قوی تست نویسی نمیکنه و اصلا اهمیتی به محصولی که میده بیرون نمیکنه.
۱. داشتن کد ریویو خوب. نمونشو تو پست بعدی باهاتون تمرین میکنم که ببینید تو چه عمقی باید کد ریویو انجام شه.
۲. دادن وقت به شما برای انجام تسکاتون. هر شرکتی که ددلاین فشرده میذاره و ازتون انتظار داره سریع یک فیچر رو تحویل بدین تو بازه زمانی کوتاه کالچر خوبی نداره و جای پیشرفت زیادی ندارین
۳. دادن فرصت برای خوندن داکیومنت. اگه تو شرکت کدی دارین وارد کد بیس میکنید که واقعا نمیدونید چطور کار میکنه و شرکت هم این قضیه رو داره پروموت میکنه بدونید جالب نیست واقعا 🙂
۴. ارتباطات قوی. اینکه بتونید از همکارتون فیدبک بگیرین و تیم لیدتون درواقع منتورینگ انجام بده هم فرایند مهمیه.
۵. اهداف مشخص. شرکتی که نمیدونه هدف و پلنش تا ۳ ماه آینده چیه جای پیشرفت زیادی نداره. فریم ورک های زیادی برای این قضیه اومدن و خیلی محبوب شدن.
۶. داکیومنشن خوب. شرکتی که داکیومنت خوب انجام نمیده و وقتی تو یک PR داره تغییری تو سیستم ایجاد میکنه ولی این داکیومنت نمیشه خیلی سریع تبدیل به اسپاگتی کد میشه
۷. استقبال از input شما جهت بهتر شدن
۸. در باز روی تغییر! پروداکت خوب و بیزنس خوب هر روز تغییر میکنه. پروداکتی که خیلی تغییر نداره دیگه مرده. همیشه میشه یک پروداکت رو از دیروزش بهتر کرد. البته منظورم over-engieering نیست. منظورم اینه که شرکتی که در برابر تغییرات مقاومت میکنه بنظرم کالچر خوبی نداره و جای پیشرفت زیادی ندارین چرا که همیشه روند تکراری میشه.


@ManiFoldsPython

ایراد کد زیر چیست؟ فکر کنید این تابع قراره یک جایی از سیستم بک اندتون استفاده شه. قراره آدرس یوزر رو از یکی از سرویس های اینترنالتون از طریق پروتکل http بگیره. چه ایرادی میتونید تو این کد پیدا کنید؟

from httpx import AsyncClient, HTTPError
from some_module import AddressNotFoundError, UserServiceException, UserId
from pydantic import BaseModel

class Address(BaseModel):
     location: str
     house_num: int

async def get_address(user_id: UserId) -> Address:
     client = AsyncClient()
     try:
           resp = await client.get("http://user_service/v1/user-address", params={"user_id": user_id})
           if resp.status_code == 404:
                raise AddressNotFoundError(text=resp.text)
           return Address(**resp.json())
      except Exception as error:
            raise UserServiceException

(resp.text)

 from error

@ManiFoldsPython

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

بریم داک httpx رو ببینیم
Usage
شما هر وقت دارین از کد httpx استفاده میکنید پشت صحنه داره یک کانکشن پول میسازه. اگه از کانتکس منیجر استفاده کنید این کانکشن پول بسته میشه. همچنین میتونید خودتون هم .close رو صدا بزنید. چون متودش async هست پس تو مجیک متود del نمیتونه قرار بگیره و وقتی رفرنسش پاک شه همچنان کانکشن پول شما باز میمونه و این اصلا خوب نیست.

مشکل دومی که این کد داره استفاده نکردن ایده آل هست از کلاینت. بحث اینجاست که اگه کانکشن پول خیلی مهمه که بسته شه پس چرا فورس context manager رو حتما فورس نکرده به یوزر؟‌دلیلش اینه که شما باید از پترن سینگلتون استفاده کنید و یک کلاینت بسازین. و از اون کلاینت همه جای اپلیکیشنتون استفاده کنید! اینطوری تمام درخواستای شما داره با یک کلاینت ارسال میشه و دیگه مجدد handshake نمیکنید و یک سری state ها ذخیره میشه که تو بحث نتورک و پرفومنس به شدت بهتر میکنه.
رفرنس

کسی که کد مینویسه داره از یک لایبری جدید استفاده میکنه باید داکیومنتشو بخونه. باید بدونه بست پرکتیسش چیه. باید از چالش های و مشکل هاش آگاه باشه. باید advance usage اش رو بدونه. کار رو نباید ماستمالی کنه.
کسی که review هم میکنه نباید بگه این کد قیافش خوشگله پس کد خوبیه, باید مسلط باشه رو یوزکیس لایبری هایی که اضافه شده و بدونه چطور کار میکنه. اگه نمیدونه بره وقت بذاره و یاد بگیره و بخونه بعد بیاد ریویو کنه.

@ManiFoldsPython

یک مشکل سومی هم داره که اصلا کسی بهش اشاره نکرد. و اون استفاده از متود GET هست!
بحث اینجاست که اگه شما بخواین مشکل دوم رو حل کنید یک ابجکت سینگلتون میسازین و همه جای اپلیکیشنتون اونو پاس میدین. ولی این آبجکت خودش mutable هست و internally داره mutate میشه درسته؟

پس خوب نیست اگه من بیام موقع استفاده از get استفاده کنم. به جاش باید از متود send استفاده کنم. فرقشو نمیدونید؟
متود send یک آبجکت میگیره به نام Request. متود سند تفاوتش اینجاست که دیگه نمیاد از دیفالت هدر و کوکی که کلاینت داره استفاده کنه و میاد از کوکی و هدری که شما تو آبجکت request میسازی استفاده میکنه. پس خیلی قابل پیشبینی تره. و حتی تو لایبری هم توصیه شده اینطوری استفاده کنیید.
https://www.python-httpx.org/advanced/#request-instances

و یک مشکل دیگه هم به وجود میاد. این گلوبال دپندسی خودش state داره و داره internaly همیشه mutate میشه. یعنی چی؟ شما به یک سایت درخواست بزنی کوکی اش ست میشه رو کلاینت.

برای این میتونید از قابلیت Transport لایبری httpx استفاده کنید و اونجا بذارین که این کلاینت اصلا mutate نشه چرا که این کلاینت global dependency شده الان

https://stackoverflow.com/questions/69916682/python-httpx-how-does-httpx-clients-connection-pooling-work


@ManiFoldsPython

من با poetry خیلی حال میکنم ولی امروز این پکیجو دیدم بیشتر باهاش حال کردم. (pdm)

مزیتش نسبت به poetry ؟
از کانوشن پایتون برای Pyproject و pep 621 استفاده میکنه یعنی پروژتون دیگه وابسته نمیشه به اینکه حتما باید poetry رو نصب کنید.

https://github.com/pdm-project/pdm

@ManiFoldsPython

بنظرتون سخت ترین بحثی که یک برنامه نویس باهاش سروکله میزنه چیه؟
منظورم تو کد نویسیه.
@ManiFoldsPython

کامنتا جالب و متنوع بودن. نظره خودم هندل State هست. این موضوع به عنوان یک بک اند کار, شما رو اذیت میکنه. به عنوان فرانت کار بازم اذیتتون میکنه. حتی به عنوان دوآپس هم اذیتتون میکنه اگه چیزی که دارین دیپلوی میکنید خودش state داشته باشه (مثلا وب سوکت) یا بخواین اپی که state داره رو scale کنید. بنظرم همیشه بزرگ ترین چالش ها همین state بودن.

https://medium.com/97-things/behavior-is-easy-state-is-hard-b272356cf867
From my experience, the hardest bugs to solve are the ones caused by inconsistent state.

این مقاله رو داشتم میخوندم جالب بود. ولی با تیکه آخرش مخالفم و این قضیه state فقط به mutability object ربط نداره بلکه حالتیه که ما انتظار داشتیم باشه ولی تو واقعیت اونطوری نیست. تو واقعیت میتونه ناهماهنگی بین state چند سرویس باعث باگی بین اون سرویسا بشه. بذارین مثال بزنم:

فکر کنید ۳ تا سرویس دارین. سرویس A داره سفارشات رو میگیره, و ثبت میکنه. سرویس B پرداخت هارو پردازش میکنه از کردیت کارت مشتری. و سرویس C موجودی کالا رو به روز میکنه. هندل کردن این state که کالا یکی از موجودیش کم شه وقتی سفارش میاد و اگه پرداخت fail شه یکی زیاد شه و برگرده به حالش میتونه مثالی باشه از state management تو سطح چند تا سرویس که اگه باگی این وسط پیش میاد ممکنه پیچیده باشه troubleshoot کردنش.البته این یک مثال ساده ۲ خطی بود ولی امیدوارم context ماجرا رو فهمیده باشین.

سوالی که پیش میاد اینه که چیکار کنیم؟ یک سری دیزاین پترن های Behavioral وجود دارن که کارشون هندل state هست به روش های مختلف و در ادامه دوره دیزاین پترن از امشب از Creator pattern به سمت Behavioral pattern میریم و مثال واقعی تر میزنم براتون.
یک چیزی که تو کل دوره گفتم اینه که بد ترین کاری که میتونید کنید اینه که به جای اینکه دیزاین پترن رو درک کنید و بفهمیدش سعی کنید سریع همه جا ازش استفاده کنید. دیزاین پترن در واقع به شما قدرت حل مسئله به روش های مختلف رو میده و میتونید از ابعاد خارج از کدتون هم بهش نگاه کنید همیشه.

@ManiFoldsPython

به بخش دوم, قسمت هفتم پلی لیست دیزاین پترن رسیدیم 🎉

همیشه مدیریت state و رفتار کد هامون سخت بوده. دیزاین پترن های Behavioral به ما کمک میکنن که بتونیم بین آبجکت هامون ارتباط قوی تری داشته باشیم و state رو داخل کدمون بهتر هندل کنیم. نکته مهم دیزاین پترن ها به طور کلی اینه که کانپست پشتشون رو درک کنید به جای اینکه فقط سعی کنید theoryشون رو حفظ کنید و تکرارشون کنید.

تو این ویدیو قراره بپردازیم به دیزاین پترن observer و بررسی کنیم یوزکیسش رو, دیزاین پترنی که خیلی جاها استفاده شده و حتما خودمون هم ازش استفاده کردیم, مثل سینگال در جنگو یا عوض شدن توکن در فایربیس یا ارتباط وب هوک با یک سیستم دیگه.

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

لینک گیتهاب دوره دیزاین پترن; جزوه و مثال های دوره همه اینجا ذخیره خواهند شد.
https://github.com/ManiMozaffar/design-101

@ManiFoldsPython

به نظرتون یک فانکشن در چه صورتی خوبه؟ چه فاکتوری وجود داره که میگین عجب فانکشن خوبی؟ مثلا به قول مارتین بیشتر از ۱۴ خط باشه bad smell عه؟ 😁
@ManiFoldsPython

تو کامنتا تا حدی اشاره کردن, نظره خودم:

اینکه بخواین با خط کش کدتونو اندازه بگیرین بنظره من ملاک کلین کدی نیست. مثلا میگن اگه اول فانکشن if بیاد پس function بدیه. اوکی متوجهم چرا اینو میگن چون میتونست شرطه به نحوی تو خود arg ها بیاد ولی یک وقتا پیش میاد. یا مثلا میگن اگه ۳ تا nested بخوره پس فانکشن بدیه. اینا هیچکدوم objective نیستن و ممکنه پیش بیان و کاملا هم منطقی باشن و ملاک تمیز بودن کدمون نیست.

ملاک تمیزی یک فانکشن بنظره من, چهار چیزه:

۱. Composable بودن اون تابع
اگه متوجه نشدین لینک زیر رو بخونید
https://en.wikipedia.org/wiki/Function_composition_(computer_science)

۲. فقط یک کار انجام بده.

۳. وقتی signature و اسم فانکشن رو برای اولین بار میخونیم و مقایسش میکنیم با کد فانکشن, سورپرایز نشیم!

۴. ساید افکتی نداشته باشه که از رو اسم و signature فانکشن مشخص نباشه.

@ManiFoldsPython

یکی از جاهایی که خیلی میتونید یاد بگیرین github هست
برین یک لایبری خوب
یک pr که داره مرج میشه
دیسکاسشنش رو بخونید
یک لایبری رو برین که متوجه discussion اش بشید. مثلا ML نباشه
مثلا اگه بک اند کارین میتونید برین PR های جنگو و فست و فلسک و سلری و غیره رو بخونید.

اینطوری باعث میشه هم
۱. کالچر review کردن رو یاد بگیرین
۲. کلی چیز یاد میگیرین از maintainer های اون لایبری
۳. خوده اون لایبری هم دیپ تر میشین. مثلا اگه سلریه بروکر هارو دیپ تر میشین.

سعی کنید PR های بزرگو بخونید نه اونی که یک خط مشکل داکو رو درست کرده 😁 از تایتل ‍PR و تعداد دیسکاسشن هاش مشخصه.

@ManiFoldsPython

در قسمت هشتم پلی لیست دیزاین پترن
تو این قسمت State Pattern رو بررسی کردیم, توضیح دادم که چرا این پترن خیلی خوبه و میتونه encapsulation تمیزی بهتون بده برای هر state از context و سیستمتون و البته گفتم چرا design pattern ناقصی هست و ضعفش چیه که مقدمه ای شد برای ویدیو بعدی, پترن Type State که بنظرم بهترین ویدیو این پلی لیسته خواهد شد.

لینک ویدیو:
https://youtu.be/wGAzhp8ljAk

لینک گیتهاب دوره دیزاین پترن; جزوه و مثال های دوره همه اینجا ذخیره خواهند شد:
https://github.com/ManiMozaffar/design-101


@PyBackEndHub

کاربرد گروهو میخوام تغییر بدم
به گروهی برای رفع مشکل و بحث در خصوص Backend Engineering و پایتون

مرجعی هم بشه که بتونید کلا سوالات flask یا kafka یا rabbitmq یا FastAPI یا ORM هرچیز دیگه ای که ممکنه براش community پیدا نکنید. لینک:

https://news.1rj.ru/str/PythonFellow

خوشحال میشم جوین شید. قانون خاصی نداره به جز حفظ احترام اعضای گروه.

@PyBackEndHub

Rebrand کردیم
اشتباهی لیو ندین 😅
ManiFoldsPython سابقیم :))
بهتر شد؟ بنظره خودم اره.

@PyBackEndHub

https://github.com/airtai/faststream

این لایبری رو برای کار کردن با بروکر ها چند وقت پیش معرفی کردم و الان داره به جاهای خیلی خوبی میبرسه جوری که وسوسه شدم ازش استفاده کنم 👌

@PyBackEndHub