تو کامنتا خیلیا راجب software architecture میپرسن.
من خودم به شخصه یک کتاب واحدی تاحالا پیدا نکردم که همرو بخواد کامل و خوب توضیح بده. پس بنظرم برای هر کدوم باید یک کتاب جداگونه بخونید که آشنا شید. مثلا خودم اخیرا 2 کتاب گرفتم که یکیش راجب DDD هست و یکیش راجب EDD. هروقت تموم کردم و دیدم خوب بوده باهاتون به اشتراک میذارم اسمشو

اما برای اینکه بتونید out of box خلاصه وار با بعضیاشون یک آشنایی دو خطی داشته باشید که حداقل بدونید چه drawback ای دارن و کجا باید از چی استفاده شه و هرکدوم چطوری operate میکنن (در حد یک schema خیلی جنرال و کلی) میتونید مقاله زیر رو بخونید.

https://nix-united.com/blog/10-common-software-architectural-patterns-part-1/

خیلی قشنگ 10 تارو خیلی خلاصه وار توضیح داده.
@ManiFoldsPython

وقتی رو پروداکشن تست میزنی
@ManiFoldsPython

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

چرا؟

چون شجاعت، جسارت، و همّتِ «در معرض گذاشتن»ت بالا می‌ره. و اگه جنبه‌ی باخت داشته باشی، به‌جای ۱۰ تا مورد مثلاً ۳۰ تا رو اپلای می‌کنی. (خصوصاً اگه مثل اپلای کاریابی یا پیام اول دیتینگ، کم‌هزینه یا رایگان باشه.)
چرا نمی‌کنیم؟

آناتومی ریجکشن ۲ تا بخش عمده داره: نرسیدن و قضاوت‌شدن.

معمولاً خود نرسیدنه خیلی فاجعه نیست و از اول هم مثلاً ۱۰٪ احتمال و امید بوده. منتهی درد بزرگ اون وقتیه که حس می‌کنی لخت جلوی یه جماعتی ایستاده‌ای که کامل بهت زل زده‌ن و بعدش هم بهت گفته‌ن تو خوب و کافی نیستی!
این درد وقتی خیلی بزرگتر هم می‌‌شه که:
۱. توضیح و فیدبک‌ای داده نشه. و مغز انسان شروع کنه هزار تا فرضیه بسازه و به همه خصلت‌ها و توانایی‌هاش دونه‌دونه شک کنه.
۲. شاهد موفقیت بقیه در همین رقابت باشی. و ببینی اپنا پذیرفته‌شده‌ن. و مغزت می‌گه: «ببین پس ۱۰۰٪ مشکل از تو بوده!»

راه حل؟

در زمینه‌ی نرسیدن: یادت باشه که تو شیر هستی و نه آهو! و فقط کافیه یکی‌شون بشه. و وقتی شد دیگه کسی نمی‌دونه و یادش نمیاد و اصن مهم نیست که آیا این یکی از ۱۰ تا بوده یا یکی از ۱۰۰ تا! پس تو ۱۰۰تات رو بزن. 💪

در زمینه‌ی حس قضاوت شدن و ناکافی بودن:
یادت باشه تو نسبت به خودت یه نظری داری، بقیه هم یه نظری دارن. این وسط هم شناخت اونا از تو محدود هست، هم شناخت تو از نیازها و بارم امتحانی اونا!

پس اولاً بپذیر که فقط خودت کامل خودتو می‌شناسی، و ثانیاً کمک بخواه.

این کمک خواستن برای بهبود (مثل مصاحبه تمرینی، مرور رزومه، ویرایش تقاضانامه/SoP، فیدبک روی پروفایل عمومی) خیلی مهم و‌ مؤثره. و درسته ممکنه این درخواست هم با خودش یه نیمه‌ریجکشن بیاره، منتهی می‌ارزه یه ریسک کمی بکنی تا شانست رو در مسابقه اصلی هی بالاتر و بالاتر ببری!

دمت هم گرم.✌️

[Loc0m0]

اینم رودمپه software architect هست که کامنت کردن
https://roadmap.sh/software-architect

چقدر مثال امروز real python قشنگ بود

Explicit is better than implicit.
Flat is better than nested.
Beautiful is better than ugly.

https://realpython.com/zen-of-python/

@ManiFoldsPython

یکی دیگه از کاربرد های fingerprinting میتونه request limit باشه.

تو هر api شما نیاز دارین برای gateway سرویس هاتون یک لیمیت بنویسید که کسی شما رو ddos نکنه.
یکی از راه حل های ابتدایی استفاده از IP Address هست. البته بخاطر وجود CGNAT عملا راهکار جالبی نیست چون هکر میتونه پشت CGNAT قایم شه که شما وایت لیست کردین و همچنان سیستمتون رو پایین بیاره.

پس برای یک راهکار safe باید چیکار کرد؟

1. برای روتر های private: از authentication header استفاده کنید و ریت لیمیت رو روی اون بذارین. در حالی که میتونه راه حل بنظر مناسبی باشه ولی هکر میتونه تعداد زیادی کاربر بسازه و با JWT هر کدوم بازم اسپم کنه. پس بازم راهکار کاملی نیست.

2. برای روتر ثبت نام: لیمیت کردن و حساسیت رو سرویس ثبت نام به ازای هر آی پی بدون داشتن وایت لیستی برای CGNATکه به طور periodic بلک لیست کنه اون آی پی رو و بعد چند ساعت دوباره بتونه حساب کاربری بسازه.

3. برای روتر پابلیک : استفاده از browser fingerprinting برای تشخیص دیوایس کاربر و گذاشتن ریمیت لیت روی ترکیب GPU fingerprint (مثل webgl یا webtrc) و IP بدون هیچ وایت لیستی. همین تکنیک میتونه رو روتر ثبت نام هم پیاده شه تا حساسیت روتر ثبت نام رو روی CGNAT کم کنه.


راهکار سوم راهکاریه که ddos shield ها ازش استفاده میکنن مثل cloudflare. راهکار بهترش اینه که خودتون مدل کاستومایز و فینگرپرینت مخصوص خودتون داشته باشین یا از سرویس پرمیومشون استفاده کنید که فایل جاوا اسکریپتشو تند تند آپدیت میکنن و به اطلاعات ویزیتور ها هم دسترسی میدن.


از نمونه سایت هایی که از راهکار سوم استفاده میکنن:
Sony Entertainment
Apple Store
Youtube


برای دیدن browser fıngerprint خودتون به این صفحه برین
@ManiFoldsPython

تجربه شخصی خودم از روند مصاحبه و نصیحت هایی که به مانی 3 ماه پیش میکردم 😁

1. OVERENGINEER AS MUCH AS YOU CAN
اولین و مهم ترین چیز همینه. این تجربم برمیگرده به مصاحبه اولم. لایو کدینگی که یک ساعت بود ولی 2 ساعت و نیم طول کشید 😂😂. آخر لایو کدینگ هم که 95درصد کدو نوشته بودم منو متوقف کرد و گفت کافیه. به من یک کدی نشون داد که همون کاری که من میخواستم بکنم رو تو 15 خط کد پایتون میکرد. من گفتم ریجکت شدم تموم شد رفت. پس فرداش آفر کاریش اومد و الان تو همون شرکت کار میکنم. گفت اگه رو پروداکشن اینطوری overengineer کنی دارت میزنم :)). شما با overengineer کردن تو لایو کد چلنج یا assigement مهارتتون رو show off میکنید و طبیعتا اجازه میده بهتون که نسبت به بقیه کاندید ها که تلاش داشتن KIS رو رعایت کنند جلو بیفتین و اون طرف متوجه شه که شما از کجا میاین (ترجمه I see where you're coming from😁) ریپوش اینجاست. اینکه چرا انتخاب شدم هم خوش یک سکشن جداست.


2. Try new technologies, don't be afraid of rejection
اینکه قبلا جنگو کار کردین ولی برای fast اقدام نمیکنید اشتباهه بنظرم. اگه اشتیاق کار کردن با اون استکو دارین حتما اپلای کنید. ملاک استخدام فقط بلد بودن و تسلط رو اون تکنولوژی نیست خیلی وقتا شانس اینو دارین رو تکنولوژی آفر بگیرین که شاید خیلی روش مسلط نیستین و صرفا آشنا هستین در صورتی که تو job requirement نوشته مسلط. مثال بارزش دوباره از خودم میزنم. من همیشه rest کار کردم. کل بک شرکتی که داشتم براش اپلای میکردم graphql بود و خیلی تاکید داشت روی تجربه با graphql. تو مصاحبه اول اصلا اشاره نکردم به اینکه هیچی از graphql بارم نیست. تو مرحله assignment یک هفته داکشو خوندم. شاید باورتون نشه ولی جاب آفر از اون پوزیشنم گرفتم :)) . پس دلیل نمیشه شما یک چیزی رو بلد نیستین تو آگهی بهش اشاره شده اپلای نکنید. تهش اینه که با اون تکنولوژی آشنا میشین.

3. THINK, THEN CODE
این از همه مهم تره. مهم ترین چیز critical thinking هست براشون. اینکه شما صرفا هدفتون انجام اون تسک نباشه. هدفتون هدف اون تسک باشه. حتی نیازی نیست از راهی که اشاره شده تو داکیومنت assignment برین. مثلا برای همین graphql پجینشن میخواست که من از راه حلی که خودش معرفی کرده بود نرفتم چون بنظره من اورلود نتورک داشت. راه حلشو تغییر دادم و یکی از دلایل اصلی قبول شدنم همین بود. یا اینکه مثلا درخواست رو نگفته بود async بزن ولی من درخواست اول رو sync میزدم که ببینم چند تا آیتم داریم بگیریم بعد به تعداد درخواست ها همرو تو سری دوم باهم async میزدم (که network efficient هم باشه و الکی اسپم نکنه). سورس کد ریپو. همه اینا نشون داد که به صورت مسئله حسابی فکر کردم. تو پوینت اولم فقط OVER-ENGINEER نکردم به صورت مسئله هم حسابی فکر کردم. سعی کردم تا جایی که میشه efficient باشه حتی شده با نقض داکیومنت assignment. هیچ شرکتی دنبال کسی نیست که فقط کپی پیست کنه یا فقط کاری که بهش میگن رو انجام بده و تک بعدی باشه, کد نویس ایده آل کسیه که خیلی فکر میکنه و میتونه راهکار نو و بهتر از راهکار قدیمی بده. با وجود اینکه من سابقه کار fastapi به صورت حرفه ای نداشتم یا graphql بلد نبودم چون صرفا thinker بودنمو خوب نشون دادم تونستم به این موفقیت برسم. از نمونه ریجکتیم هم بخوام بگم باید بگم یک assignment ام ریجکت شد و حتی فیدبک هم نگرفت چون خوب روش فکر نکرده بودم و صرفا کاری که بهم گفته بودن رو به ساده ترین شکل ممکن پیاده سازی کردم (انگار که رفع تکلیف باشه).


The most damaging phrease in the language is 'its always been done this way' - Grace Hopper

@ManiFoldsPython

یک اصلاحیه هم بکنم، تو over engineering همیشه باید در راستا بهتر شدن کد باشه،
یعنی مثلا پروتکل بنویسید برای هر کلس template ای که دارین مینویسید، حتی اگه یک بار ازش استفاده میکنید.

از داک استرینگ و دیتا کلس استفاده کنید
جای نوشتن query خام مثلا از orm استفاده کنید (تسکه کلا دو query داشت)

دیزاین داشته باشه کدتون، حتی اگه دیزاین داشتن نیاز نبوده و واسه دیزاین داشتن کد خیلی‌ کم بوده (مگه کد ۱۵ خطی رو دیزاین میدن بهش؟ بله، تو روند استخدام باید بدید که نشون بدید مهارت کافی دارین برای نوشتن کد production quality)

ولی اینکه بخواین الکی کد عجیبی به پروژتون اضافه کنید که به هیچ دردی نمیخوره و فقط complicate ترش میکنه اونوقت اصلا اونکارو نکنید. Over engineer باید در جهت بالا رفتن کیفیت کد باشه
@ManiFoldsPython

یک سایت خیلی باحال امروز پیدا کردم

https://mockmate.com/
ماک میت!
یک AI بهتون سوال میده و با ویدیوباید جواب بدین و نهایتا بهتون امتیاز میده. تا 10 سوال طبق نوشته خوده پلتفورم رایگانه. تست نکردم ولی جذاب بود برام 😁 اگه کسی تست کرد ممنون میشم کامنت کنه.
@ManiFoldsPython

2 شگردی که میتونید با پاینداتیک انجام بدید

1. ساخت parser از رو json. کاری نداره واقعا. فقط باید json schema اش رو ببینید و از روش بسازید. حتی بنظرم خیلی نایس میشه که یک لایبری پیدا شه بیاد از رو json schema کد pydantic بده 😁 شایدم خودم نوشتم :))


2. ساخت query. مثلا میتونید هرچی تو parser یا schema pydantic اتون انتخاب کردین به طور خودکار تو response parserتون هم ادد شه 🤯 مثل متود get_selects که اینجا نوشتم

@ManiFoldsPython

حتما این ویدیو رو ببینید تا متوجه بشید چرا کلاه برداری میشه و آدمایی مثل ماهان تیموری، دنیا جهانبخت و همین «جاوا اسکریپت کوچیک شده جاوا است» خودمون، چطور طعمه پیدا می کنند.

اگر نمیتونید گوش کنید، خلاصه اش اینه:

۱. هالو بودن از چهره مشخص نمیشه، پس باید کاری کنی تا افراد هالو خودشونو معرفی کنند.

۲. دلیل اینکه یه نفر با ۵ میلیون فالور میاد یه حرف کاملا مضخرف میزنه اینکه اگر، از اون ۵ میلیون، ۵۰۰ نفر به اون پست خیلی مضخرف واکنش نشون بدن، یعنی قطعا هالو هستن و میشه اونا رو دوشید.

۳. این رفتار الزاما نشاندهنده هوش کلاه بردار نیست. میتونه یه رفتار غریزی باشه که در طی زمان جواب داده.

@siliciumir

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

ما ایرانیا همیشه دنبال shortcut ایم. از بچگی میخواستیم به نت وصل شیم باید 100 ترفند و قلق میزدیم که وصل شه. کلی محدودیت های مختلف داشتیم که بازم باید با قلق دورشون میزدیم. بزرگ تر شدیم تو راهنمایی یاد گرفتیم جای اینکه کتاب درسی رو بخونیم بریم جزوه بخونیم. کلاغ سبز و این شرو ورا :)). بزرگ تر شدیم همین shortcut شد نکته کنکوری. شد کلاس کنکور. چیزایی که اصلا تو خارج نمیبینید شما.

ترم اول دانشگاه بودم رفتم سره کلاس گفتم استاد جزوه چی خوبه مثلا بگیریم؟ شاخ درآورد :)). گفت مگه کتاب چشه؟ همین موضوع سره ابزار هایی که استفاده میکنیم داره. ویندوز میخوایم نصب کنیم باید کرک باشه. هر برنامه ای بخوایم نصب کنیم یا اوپن سورسه یا کرک. کلا همیشه دنبال مسیر کج و غیر استاندارد بودیم و خواهیم بود. نسل ما اینطور بار اومده متاسفانه.

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

همین خصلتمون باعث شده که کلا این کاسبی این آدمای دلال و آرزو فروش و یک شبه پول دار شو بگیره.

@ManiFoldsPython

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

https://github.com/tiangolo/fastapi/tree/master/docs_src

داک سورسی که سبا درست کرده بینظیره. تقریبا خودش یک کاوریج کامل از فریم ورکشه با مثال های مختلف


@ManiFoldsPython

یک لایبری خیلی مناسب و مدرن به جای celery برای scheduling که dependency کمی داره, کدبیس کم حجم و کاوریج 96 درصدی که statement-based scheduler هارو هم ساپورت میکنه مثل:

every("10 seconds") 

با قابلیت ساپورت async, sync, parallel threading و multiprocess

فقط dependency injection رو یک مقدار عجیب برطرف کرده که هنوز متوجه نشدم چرا, ولی خب همین موضوع حتی تو بقیه لایبری های مشابه هم نیست.

https://rocketry.readthedocs.io/en/stable/index.html

دیروز با یک pen tester راجب بست پرکتیس های JWT صحبت میکردم و اینکه کلا چطور میشه هم مزیت های JWT رو داشت و هم به نحوی امن پیاده سازیش کرد, JWT همونطور که میدونید stateless هست یعنی نیازی به هیت به دیتابیس نداره. برای microservice و SOA هم بهتره چون overhead خیلی کمتری داره براشون و fault tolerance خیلی کمتر میشه.

چند تا از بست پرکتیس های JWT
1. طول عمر اکسز توکن بسیار کوتاه باید باشه, ماکسیموم 10 دقیقه.

2. قابلیت لاگ اوت که رفرش توکن invalid میشه. بلک لیست میشه تو دیتابیسی مثل redis. اکسز توکن نباید بلک لیست شه وگرنه اساس JWT زیر سوال میره. هکر اگه توکن رو دزدید و لاگین کرد قطعا شما خیلی دیرتر از 10 دقیقه متوجه میشین. وقتی متوجه شدین رفرش توکنی که هکر ساخته رو black list میکنید.

3. خود payload و claim ها نباید حاوی اطلاعات محرمانه باشن. بهترین کار همون user id هست چون خیلی پرایوت نیست و تو زدن query هم دیگه نیازی به جوین نخواهیم داشت.

4. روتیت کردن secret key به صورت periodic مثلا هر 3 ماه یا 6 ماه یک بار

5. استفاده از الگوریتم امن و غیرقابل پیشبینی

6. استفاده از UUID تو user id. اینطوری حتی سکرت کی هم لو بره کار هکر قطعا سخت خواهد بود😅

@ManiFoldsPython

سمت فرانت تنها کاری که باید انجام بدین که مربوط به JWT میشه:

فرش توکن اصلا نباید تو local storage ذخیره شه چون تو بک آپ browser هست و کلا دسترسی بهش غیر ممکن نیست. به جاش باید تو کوکی ذخیرش کنید تحت همچین ویژگی هایی:
prefixes (e.g. __HOST-)
attributes (Secure, HttpOnly, SameSite)

برای پایین آوردن تایم بیلدتون از poetry با داکر میتونید از همچین داکرفایلی استفاده کنید

FROM python:3.11.3

WORKDIR /src

COPY pyproject.toml poetry.lock* ./

RUN pip install poetry \
&& poetry config virtualenvs.create false \
&& poetry install --no-interaction --no-ansi

COPY . .

ENV PYTHONPATH=/app:$PYTHONPATH

EXPOSE YOUR_PORT

# handle deploy here
CMD ["make", "deploy"]

اینطوری وقتی بیلد بگیرین تا زمانی که پکیج جدیدی اضافه نکرده باشین پکیجا رو دوباره اینستال نمیکنه.
میتونید pip install poetry هم نزنید و از ایمیج خودش استفاده کنید. ولی فرقی نمیکنه از نظره تایم بیلد خیلی.

@ManiFoldsPython

توصیه میکنم حتما بخونید و یاد بگیرین اگه با Microservice یا SOA سروکله دارین

https://opentelemetry.io/docs/getting-started/dev/

What is OpenTelemetry?
A short explanation of what OpenTelemetry is, and is not.
Microservices architectures have enabled developers to build and release software faster and with greater independence, as they were no longer beholden to the elaborate release processes associated with monolithic architectures.

As these now-distributed systems scaled, it became increasingly difficult for developers to see how their own services depend on or affect other services, especially after a deployment or during an outage, where speed and accuracy are critical.

Observability has made it possible for both developers and operators to gain that visibility into their systems.

@ManiFoldsPython

میخوام این چند روز مطالبو اختصاص بدم به opentelemetry و نحوه استفادش با FastAPI و کانفیگش. چون وقتی یک چیزیو توضیح میدم خودمم خوب متوجه میشم 😅

پارت یک

اولا که opentelemetry چیه؟ یک پروژه Cloud Native Computing Foundation هست که شامل یک سری ابزار و API و استاندار میشه که کار رو برای دولوپر ها و SRE ها راحت تر میکنه تا از سرویس هاشون راحت instrument (معادل فارسیش رو نمیدونم) بکنند و بتونند با دیتایی که جمع میکنن سیستم هاشون رو بهتر درک کنند و راحت تر دیباگ کنند.

کل دیتا جمع آوردی شده از 3 روش بدست میاد:
1. متریک: شامل اعدادی میشن که تو یک سری بازه زمانی خونده میشن. مثلا سی پی یو یوسیج یا ارور ها یا تعداد درخواست. این برای ارزیابی پرفومنس سیستم تو یک نگاه سریع استفاده میشه.

2. لاگ: رکورد های اتفاقاتی هستند که تو سرویس رخ میدن. اینفورمنیشن خیلی کاملی نسبت به حوادث میدن به ما. میتونه یک query که به دیتابیس زده میشه باشه یا هرچیزی که لاگ میندازین خودتون یا لایبری که ازش استفاده میکنید لاگ میندازه.

3. تریس:تو تریس ما از یک activity یک درخواست که تو سیستم میره رکورد میگیریم. خب شاید بگین این که شد همون لاگ؟ نه, تو تریس ما بسیار استراکچر منظم تری داریم و کاربردش اصلا با کاربرد لاگ یکی نیست. مثلا شما به یک external service درخواست زدین. تمام درخواست هایی که به اون external service میزنید رو با یک context manager فقط تو تریس همون سرویس ذخیره میکنید. این باعث میشه مثلا متوجه شین یکی از سرویس هاتون خیلی داره ارور میده چون کلی تریس اون سرویس فیل شده از سرویس های مختلف بدون اینکه لاگ هارو نیاز باشه بخونید حتی!

with tracer.start_as_current_span("authentication"):
     ...

مثلا اینجا اومدم از سرویس authentication یک چیزی رو دریافت کنم. جای اینکه لاگ بندازم درخواست های به اون سرویس رو, موقع زدن کانکشن به اون سرویس یک context manager باز میکنم. این باعث میشه که تو دیتابیس هم هرچی fail بخوره زیر کانکتس منیجر تحت عنوان سرویس authentication رکورد شه نه سرویسی که داره درخواست میزنه. این کار باعث میشه همین که برم تو داشبورد جای اینکه ببینم مثلا 10 تا سرویسم همشون دارن ارور میدن, یک سرویس درواقع داره ارور میده رو 10 سرویس مختلف و داشبورد خودش traceback کرده چون tracer ای فیل شده که authentication بوده.

دو مورد دیگه هم تو trace هست که تو لاگ نیست,
یکیش اینه که timing information داره. یعنی دقیقا مشخص میکنه یک درخواست از چه سرویسی رفته به چه سرویس دیگه ای و چقدر تو هر سرویس بوده. پرفومنس همه سرویس هاتون رو اینطوری میتونید مشخص کنید. (خیلی خفنه نه ؟)
دوم اینکه trace ID و span ID داره که خب طبیعتا هر تریس ممکنه چندین span داشته باشه و با چند سرویس در کنش باشه. این باعث میشه مسیری که اون درخواست طی کرده هم ببینیم.

@ManiFoldsPython