کاش گیت undo داشت.
انواع مختلفی از روش ها که میتونید باهاشون آندو کنید
https://ohshitgit.com/

تا حالا شده شروع کنید به ادیت کردن یا اضافه کردن یه فیچر به کد، و یهو یادتون بیاد ای بابا چرا یه برنچ جدید نساختم و ادیتامو روی master انجام دادم؟
تنها کاری که باید قبل از کامیت کردن بکنید اینه که همون موقع برنچ جدید رو بسازید:

git checkout -b newBranch

link

حالا اومدید و تغییرات رو کامیت کرده بودید. اونوقت چیکار میکنید؟
میتونید از این سوال جوابتون رو بگیرید

اگه حوصله ندارید مقاله‌ی فوق العاده زیبای فوق را بخوانید
این ویدئو را ببینید

https://youtu.be/qT8NyyRgLDQ

Monorepo vs Multirepo

https://kinsta.com/blog/monorepo-vs-multi-repo/

سعی میکنم توی پست بعدی یه نمونه واقعی از multirepo که توی یک پروژه واقعی استفاده کردم رو شرح بدم، و همچنین اینکه چجوری مدیریتش کردم

ادامه پست قبل...

توی یکی از پروژه‌ها، قرار شد سیستم چند تا سرویس داشته باشه،
یک سرویس بک‌اندAPI، یک سرویس بات تلگرام، یک سرویس فرانت‌اند، یک سرویس payment.
توی پروداکشن قرار بود همه این سرویس‌ها به هم وصل بشن، و خب بهترین و ساده ترین راه برای مدیریت این سرویس‌ها این بود که هر کدوم ریپازیتوری خودشون رو داشته باشن، چون ممکن بود افراد مختلفی بخوان هرکدوم رو بزنن(که همشون رو هم خودم زدم).

چون همه اینا باید با هم بالا باشن،
اولین چیزی که به ذهنم رسید این بود که یه اسکریپت بنویسم که بیاد همه اینا رو یک به یک از گیت کلون کنه، و بعد اجراشون کنه.
که خب این مشکلات خودش رو داره:
اول این که بعد از نصب اولیه، برای اپدیت هر پکیج باید جدا اون رو از گیت pull بکنی.
دوم این که هر کدوم از این‌ها خودشون یه ریپوی جدا هستن و جدا باید مدیریت بشن، جدا از هم اجرا بشن(هر کدوم از پروژه ها یه Dockerfile داشتن) و کلی مشکلات کوچیک و بزرگ دیگه.

کاری که در نهایت انجام دادم چی بود؟ استفاده از git submodules

برای این کار اومدم یه ریپازیتوری مادر، مثلا به اسم Main ساختم، و تمام سرویس ها رو به عنوان ساب ماژول به این ریپازیتوری اضافه کردم.
توی ریپازیتوری مادر از docker-compose استفاده کردم که میومد تمام Dockerfile های داخل هر ساب ماژول رو برمیداشت و از روی اون پروژه ها رو اجرا میکرد، به علاوه اون تمام دیتابیس‌ها و سرویس‌های مورد نیاز دیگه رو هم قبل از اونا بالا میاورد.

حالا یه مشکل دیگه که اینجا پیش اومد، آپدیت کردن هر ساب ماژول بعد از اپدیت شدن ریپوش بود.
مثلا وقتی من یه اپدیتی روی ریپازیتوری بک‌اند میزدم، اون نسخه ازش که توی ریپوی مادر بود آپدیت نمیشد.
که خب یه راه خوب هم برای این پیدا کردم.

از ورکفلوهای گیتهاب اکشنز استفاده کردم، یه ورکفلو برای ریپوی مادر، یه ورکفلو برای هرکدوم از سرویس‌ها:
۱. ورکفلوی سرویس‌ها:
کاری که میکردن این بود که هر وقت چیزی به برنچ master پوش شد و تست‌ها پاس شدن، یک آدرسی رو صدا کنه.

۲. ورکفلوی ریپوی مادر:
اون آدرسی که گفتم صدا میشه مربوط به این بخشه، هر وقت اون ادرس صدا میشد، ورکفلوی ریپوی مادر اجرا میشد و میومد ساب‌ماژول ها رو آپدیت میکرد.

میتونید از این لینک دقیق ببینید چجوری کار میکنه.

تمام این کارا روی ریپازیتوری های گیت‌هاب اتفاق میوفتاد.

حالا سمت سرور چی؟
برای دفعه اول فقط کافیه ریپوی مادر رو مثلا اینجوری کلون کنید:

git clone git@github.com:Username/Main.git --recurse-submodules

بعد از اون برای آپدیت پروژه ها توی سرور فقط کافی بود این شکلی ریپوهارو اپدیت کنم:
git submodules update —remote
و اینجوری هم ایمیج های داکر رو بیلد کنم و سرویس ها رو بالا بیارم:
docker-compose up —build

به همین سادگی!

(اگه فرصتش رو داشتم یه نمونه پروژه‌ دموی این شکلی میسازم و لینک گیتش رو اینجا قرار میدم)

نوشتن یه پروژه با قابلیت اضافه کردن پلاگین
https://www.youtube.com/watch?v=fY3Y_xPKWNA

اگه میخواید یه نمونه واقعی ببینید میتونید pytest رو ببینید:
https://github.com/pytest-dev/pytest

و پلاگین pytest-cov براش:
https://github.com/pytest-dev/pytest-cov

اگه فکر میکردید
from some_module import some_func
اینجوری ایمپورت کردن توی پایتون سریع تر و memory efficentتره، یجورایی اشتباه فکر میکردید:
https://youtu.be/ZWCyNz0fUsc

دیروز این پست رو توی یه کانال تلگرامی دیدم که اومده بود و کد رو ریفکتور کرده بود.
حالا تو پست بعد چند تا نکته برای بهتر کردنش هم از نظر پرفورمنس و هم از نظر خوانایی میگم و باهم دوباره ریفکتورش میکنیم

از اینجا بخونید:
https://virgool.io/@ebrahimisina/refactoring-a-python-example-fuswxtotm4zs

jless — a command-line JSON viewer

خیلی باحال میتونید داخل ترمینال یه جیسون ویور داشته باشید :)🔥

🔹 linux
🔸 mac

🔗 jless.io

#json #linux
@alirezabashi_98 🚀

یه برنامه‌ای هست به اسم reflector برای arch linux که میاد به شکل خودکار و در پس زمینه میرور‌های خوب برای آپدیت رو پیدا میکنه و لیست میرورهای pacman رو خودش بروز میکنه.
آموزش راه‌اندازیش اینجاست:
Automatically update Arch Linux mirrors by Josh Sherman
https://joshtronic.com/2021/03/14/automatically-update-arch-linux-mirrors/

(نمیگم استفاده چون یه بار راه بندازید دیگه کار میکنه)

بحث rate limit هم جالبه. ایده اینه که یه سرور (یا کلا خدمت دهنده) داریم که به یکسری مشتری می‌خواد خدمت بده، اما نمی‌خواد یه مشتری زیاد از منابع استفاده کنه که سر سرور شلوغ بشه و به بقیه منابع نرسه. برای همین میان یه محدودیت می‌ذارن که مثلا هر اکانت می‌تونه روزی ۶۰۰۰ تا توییت بخونه یا ۲۰۰ تا توییت بنویسه یا این ip صد بار در روز بیشتر آب و هوا رو چک نکنه.
حالا الگوریتم‌های مختلفی که باهاش rate limit پیاده‌سازی می‌شه چیا هستن؟
https://nordicapis.com/different-algorithms-to-implement-rate-limiting-in-apis/