نحوه ذخیره کردن slug تو یکی از پکیج های معروف جنگویی رو با هم ببینیم.

1. if self._state.adding and not self.slug:
- قسمت اول چک کردن یعنی self._state.adding اگر در حال ساختن یک شی جدید در دیتابیس باشیم مساوی با True هستش همچنین اسلاگ هم باید None باشه.

2. self.slug = self.slugify(self.name)
- این خط یک slug جدید را بر اساس فیلد name با استفاده از تابع slugify تولید می‌کند.

3. using = kwargs.get("using" or router.db_for_write(type(self), instance=self))
- این خط مشخص می‌کند که داده‌ها باید در کدام پایگاه داده ذخیره شوند، با استفاده از router.db_for_write.
(درباره B router بعدا توضیح میدم)

4. kwargs["using"] = using
- این خط، پارامتر using را در kwargs قرار می‌دهد تا در ادامه به super().save منتقل شود.

5. try: ... except IntegrityError:
- این بلوک try/except یک تراکنش atomic را برای ذخیره داده‌ها ایجاد می‌کند.
- اگر خطای IntegrityError (مانند تکراری بودن slug) رخ دهد، بلوک except اجرا می‌شود.

6. slugs = set(...)
- در صورت رخ دادن `IntegrityError`، این خط تمام `slug`‌های موجود در پایگاه داده که اولشون شبیه به اسلاگ ما هستش رو بازیابی می کنه.

7. while True: ... i += 1
- این حلقه یک slug جدید تولید می‌کند تا زمانی که یک slug منحصر به فرد پیدا شود.- slug جدید با افزودن یک شماره انتهایی به slug قبلی تولید می‌شود (مانند my-slug-1, my-slug-2, و غیره).

8. return super().save(*args, **kwargs)
- بعد از یافتن یک slug منحصر به فرد، شیء با فراخوانی متد save پایه ذخیره می‌شود.

9. else: return super().save(*args, **kwargs)
- اگر شیء در حال به‌روزرسانی است (نه ایجاد)، متد save پایه بدون هیچ تغییری فراخوانی می‌شود.

این کد به این دلیل طراحی شده است تا یک slug منحصر به فرد برای هر شی ایجاد کند، حتی اگر نام‌های مشابهی در پایگاه داده وجود داشته باشد. همچنین از تراکنش‌های اتمیک برای حفظ یکپارچگی داده‌ها در طول عملیات ذخیره‌سازی استفاده می‌کند.

چند تا سوال خوب تو سطح میدلول به بالا برای Back-end developer(python & django)

1. چگونه از race condition در برنامه‌های چند نخی (multi-threaded) یا چند کاربره (multi-user) جلوگیری می‌کنید؟ از چه تکنیک‌ها یا ابزارهایی استفاده می‌کنید؟

این سوال از متقاضی می‌خواهد تا درک خود را از مفهوم race condition و راه‌حل‌های آن نشان دهد. او باید به مواردی مانند قفل‌ها (locks)، عبارات F در Django ORM، عملیات‌های اتمیک (atomic) و همچنین استفاده از سیستم‌های صف (queuing systems) اشاره کند.

2. برای بهینه‌سازی پرس‌وجوهای پایگاه‌داده در Django چه تکنیک‌هایی را پیشنهاد می‌کنید؟ مزایا و معایب هر یک را توضیح دهید.

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

3. چگونه می‌توانید از حملات (Cross-Site Scripting یا XSS) و حملات (Cross-Site Request Forgery یا CSRF) در برنامه Django خود جلوگیری کنید؟

این سوال از متقاضی می‌خواهد تا دانش خود را در زمینه امنیت وب و جلوگیری از حملات رایج نشان دهد. او باید به مواردی مانند استفاده از django.utils.html.escape برای خروجی‌های HTML، تنظیمات SECURE_BROWSER_XSS_FILTER و `X_FRAME_OPTIONS`، استفاده از توکن‌های CSRF در Django، و همچنین تکنیک‌های دیگر مانند اعتبارسنجی ورودی‌ها اشاره کند.

4. چگونه از یک وضعیت deadlock در برنامه‌های چند نخی یا چند کاربره جلوگیری می‌کنید؟ راه‌حل‌های پیشنهادی شما برای مدیریت deadlock چیست؟

این سوال از متقاضی می‌خواهد تا درک خود را از مفهوم deadlock و راه‌حل‌های آن نشان دهد. او باید به مواردی مانند جلوگیری از اشتراک منابع، اولویت‌بندی درخواست‌ها، استفاده از الگوریتم‌های پیشگیری از deadlock مانند الگوریتم بانکر (Banker's Algorithm)، و همچنین استفاده از تایم‌اوت‌ها (timeouts) اشاره کند.

5. چگونه می‌توانید از مشکلات مربوط به حافظه در برنامه‌های Python خود جلوگیری کنید؟ راه‌حل‌های پیشنهادی شما برای مدیریت حافظه چیست؟

این سوال از متقاضی می‌خواهد تا دانش خود را در زمینه مدیریت حافظه در Python نشان دهد. او باید به مواردی مانند استفاده از ژنراتورها (generators) و ایتراتورها (iterators) برای پردازش داده‌های بزرگ، آزادسازی منابع به موقع، استفاده از کتابخانه‌های مدیریت حافظه مانند `tracemalloc`، و همچنین تکنیک‌های دیگر مانند پروفایل‌گیری (profiling) و بهینه‌سازی الگوریتم‌ها اشاره کند.

6. چگونه می‌توانید از مشکل N+1 Query در Django ORM جلوگیری کنید؟ راه‌حل‌های پیشنهادی شما برای این مشکل چیست؟

این سوال از متقاضی می‌خواهد تا درک خود را از مشکل N+1 Query و راه‌حل‌های آن در Django ORM نشان دهد. او باید به مواردی مانند استفاده از select_related و `prefetch_related`، بهینه‌سازی پرس‌وجوها با استفاده از ایندکس‌ها، و همچنین تکنیک‌های دیگر مانند کش‌کردن (caching) اشاره کند.

7. چگونه می‌توانید از مشکلات مربوط به مقیاس‌پذیری (scalability) در برنامه‌های وب جلوگیری کنید؟ راه‌حل‌های پیشنهادی شما برای بهبود مقیاس‌پذیری چیست؟

این سوال از متقاضی می‌خواهد تا دانش خود را در زمینه طراحی و پیاده‌سازی سیستم‌های مقیاس‌پذیر نشان دهد. او باید به مواردی مانند استفاده از معماری‌های چند لایه (multi-tier architecture)، پخش بار (load balancing)، افزونگی (redundancy)، کش‌کردن (caching)، شارد کردن (sharding) پایگاه داده، و همچنین تکنیک‌های دیگر مانند استفاده از سیستم‌های توزیع‌شده (distributed systems) و محاسبات ابری (cloud computing) اشاره کند.

8. چگونه می‌توانید از مشکلات مربوط به امنیت در برنامه‌های وب جلوگیری کنید؟ راه‌حل‌های پیشنهادی شما برای بهبود امنیت چیست؟

این سوال از متقاضی می‌خواهد تا دانش خود را در زمینه امنیت در برنامه‌های وب نشان دهد. او باید به مواردی مانند استفاده از رمزگذاری قوی، اعتبارسنجی ورودی‌ها، جلوگیری از حملات تزریق (injection attacks)، استفاده از پروتکل‌های امن مانند HTTPS، مدیریت دقیق دسترسی‌ها (access control)، و همچنین تکنیک‌های دیگر مانند به‌روزرسانی منظم سیستم‌ها اشاره کند.

#interview #backend

قبل مصاحبه یکاری هست که بنظرم حتما انجامش بدید!

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

اکثرا با خوشرویی بهتون جواب میدن و شمارو راهنمایی می کنن. همچنین اینکه پیگیر شرکت بودید یک پوینت مثبت به حساب میاد.

قانون امدال:

بنظرتون اگه بی نهایت core داشته باشیم، می تونیم اجرا شدن یک برنامه رو از مثلا 100 ساعت به یک ساعت برسونیم؟
قانون امدال (AMDAHL) بهمون کمک میکنه تا به جوابمون برسیم.

قبلش بصورت خلاصه بگم serial چیه:
به قسمتی از کد که اصلا توانایی این رو نداره مالتی پراسس بشه رو serial میگیم.

فرمول امدال:
speedup ≤ 1 / (S + ((1 - S) / N) )


S:
عددی بین 0 تا یک که بر اساس حالا بگیم درصد کد های serial هستش.

N:
تعداد core ها.

مثال:
خب بیاید در نظر بگیریم که بیست درصد از کد های ما serial هستش و چهار تا core داریم.
در این صورت میشه:
1 / (0.2 + ((1 - 0.2) / 4)) = 2.5

در این صورت speed up ما میشه دو و نیم برابر و کد ما دو و نیم برابر سریع تر شده.

اما حالا در نظر بگیرید ما 40 تا core داریم،‌ فکر میکنید سرعتمون چقدر افزایش پیدا می کنه؟؟
خب بیاید که حساب کنیم:
1 / (0.2 + ((1 - 0.2) / 40)) = 4.5

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

پست بعدی با نمودار یه سری توضیحات بیشترو میدم

پس قانون امدال چیه؟
قانون Amdahl یک فرموله که بهبود احتمالی عملکرد رو که با اضافه کردن پراسس های بیشتر به یک برنامه که شامل بخش‌های ترتیبی (غیرموازی) و موازی است رو میده.

#note

در زبان آلمانی بین دو جمله زیر تفاوت هست:
Shakespeare hat die Geschichte von Hamlet geschrieben.
شکسپیر، داستان هملت را نوشت.
Ein Mann namens Shakespeare schrieb die Geschichte von Hamlet.
مردی به نام شکسپیر، داستان هملت را نوشت.

میگن، شکسپیر اون شخص نیست، بلکه ی اسمه که روی اون شخص گذاشته شده.
اون شخص میتونه هر اسمی داشته باشه.

ولی در انگلیسی این ی بحث لفظی و بی معنیه و تفاوت معنایی بینشون نیست.

به متن زیر دقت کنید:
  “Suppose I say to Fat, or Kevin says to Fat, “You did not experience God. You merely experienced something with the qualities and aspects and nature and powers and wisdom and goodness of God.” This is like the joke about the German proclivity toward double abstractions; a German authority on English literature declares, “Hamlet was not written by Shakespeare; it was merely written by a man named Shakespeare.” In English the distinction is verbal and without meaning, although German as a language will express the difference (which accounts for some of the strange features of the German mind).”

Valis, p71 (Book-of-the-Month-Club Edition)

حالا ربطش به برنامه‌نویسی چیه؟
دو رویکرد بسیار شناخته شده و قابل درک برای انتقال پارامتر در زبان‌های برنامه‌نویسی مختلف، عبارتند از:
pass by reference = بر اساس مرجع
pass by value = بر اساس مقدار

بعنوان مثال، کد زیر رو در نظر بگیرید:
def reassign(lst: list) -> list:
lst = [0, 1]
return lst

def append(lst: list) -> list:
lst.append(1)
return lst

lst = [0]
print(reassign(lst))
print(append(lst))

حالا به این جمله دقت کنید:
«هملت توسط شکسپیر نوشته نشد، بلکه توسط مردی به نام شکسپیر نوشته شد.»

حالا بصورت کد:
a = []

اینجا [] ی لیست تهی و a هم متغیری که به این لیست تهی اشاره داره، ولی a ی لیست تهی نیست.
pass by reference:
در اینصورت، خود متغیر به تابع ارسال میشه و مقدار داخلش هم به تابع ارسال میشه.
مثل ی جعبه که با محتویات داخلش ارسال میشه.
اگه داخل تابع مقدارش رو تغییر بدیم، بیرون تابع هم مقدارش تغییر میکنه.

pass by value:
در اینصورت تابع ی کپی از اون متغیر رو دریافت میکنه که مقادیرش تو ی خونه دیگه حافظه رم نگهداری میشن.
مثل ی سری مدارک که داخل ی جعبه بودن، اومدیم ی کپی ازشون گرفتیم، گذاشتیم داخل ی جعبه دیگه و ارسالش کردیم.
اینجا با تغییر مقادیر داخل تابع، مقادیرش بیرون تابع تغییر نمیکنه.

pass by object reference value(Pythonic):
در اینصورت تابع ی رفرنس به اون آبجکت دریافت میکنه و میتونه به مقادیر اون آبجکت تو حافظه رم دسترسی داشته باشه، ولی خود اون جعبه‌ای که مقادیر توش هستن رو دریافت نمیکنه، بلکه تابع میاد جعبه خودش رو میسازه و ی متغیر جدید برای خودش داره که اینم به همون خونه‌ای که متغیر بیرونی اشاره میکرد اشاره میکنه.
متغیرها متفاوتن، گرچه اسمشون یکی باشه، اما رفرنس هر دو یکیه.
به تصویر بالا، shallow copy دقت کنید تا متوجه بشید چی میگم.
حالا اگه مقادیر رو داخل تابع تغییر بدیم، مقادیر بیرون تابع هم تغییر میکنن.

تو پست بعدی سعی میکنم ی جمع بندی درمورد shallow copy و deep copy صحبت کنم باز.

با تشکر از:
https://robertheaton.com/2014/02/09/pythons-pass-by-object-reference-as-explained-by-philip-k-dick/

آموزش دادن خیلی عالیه واقعا.
مثلا همین بحث مطلب قبلی تا الان بهش دقت نکرده بودم تا اینکه هنرجوی ۱۳ ساله‌ام برگشت پرسید چرا اینجوری شد نتیجه؟
یا حتی همون هنرجو پرسید آیا import هم ی تابعه تو پایتون؟
ی مورد دیگه هم که امروز برام پیش اومد این بود که داشتم به هنرجو نشون می‌دادم جای استفاده از if elif else و match case میتونه از دیکشنری هم استفاده کنه.
بعد اومدیم ی ماشین حساب نوشتیم اینجوری، مقدار پیشفرض عدد اول و دوم رو 1 گذاشته بودم، هی میخاستم ریشه دوم بگیرم از تابع لگاریتم که نوشته بودیم خطا میگرفت که تقسیم بر صفر میکنه(چون لگاریتم 1 بر مبنای 1 این مشکل رو داره)، مونده بودم این چه ربطی به اون داره آخه.
بقیه توابع همه ۲ تا عدد میگرفتن از کاربر و فقط ریشه دوم یا همون جذر فقط ی عدد میگرفت و عدد دوم پیشفرض 1 بود.
بعد برداشتن تابع لگاریتم متوجه شدم که وقتی با دیکشنری مینویسم و پرانتز تابع رو هم میذاریم، پایتون میاد تک تک توابع رو ارزیابی میکنه و نتیجه رو نگه میداره!
دو تا راه حل داره این مسئله:
۱- میشه کنترل استثنا نوشت برای توابعی که ممکنه خطا پیش بیاد.
۲- که پیشنهادم هم همینه، میشه تو دیکشنری برای توابع پرانتز نداشت و بعد دیکشنری که میخایم get کنیم اسم کلید رو بیایم پرانتز بذاریم براش.
مثلا کد زیر رو درنظر بگیرین:
import math

def calculator():
first_number = 1
second_number = 1
try:
first_number = int(input("Number: "))
except ValueError:
print("Please enter valid integer or float number")
operator = input("Operator(sqrt,+,-,/,*,log,**): ")
if operator in "+ - * ** / log".split():
try:
second_number = int(input("Number: "))
except ValueError:
print("Please enter valid integer or float number")

def add(first_number: int | float, second_number: int | float) -> int | float:
return first_number + second_number

def subtract(first_number: int | float, second_number: int | float) -> int | float:
return first_number - second_number

def square_root(first_number: int | float) -> int | float:
return first_number ** .5

def logarithm(first_number: int | float, second_number: int | float) -> int | float:
return math.log(first_number, second_number)

commands = {
"+": add(first_number, second_number),
"-": subtract(first_number, second_number),
"sqrt": square_root(first_number),
"log": logarithm(first_number, second_number),
}.get(operator, "+" )

تو این کد، دیکشنری commands میاد هر تابعی رو اجرا میکنه و نتیجه رو تو خودش نگه میداره، ما برای جلوگیری از این کار باید بیایم به روش زیر عمل کنیم:

commands = {
"+": add,
"-": subtract,
"sqrt": square_root,
"log": logarithm,
}.get(operator, "+" )(first_number, second_number)

البته باز نیاز به گذاشتن شرط هست😅 اگه جذر بود فقط ی ورودی لازم داره، مگر اینکه کد رو وصله‌دار کنیم و برای اونم ی آرگومان سوخته تعریف کنیم و داخل تابع ازش استفاده نکنیم که اینم اصولی نیست.

اگه شما هم راه حلی دارین خوشحال میشم باهام به اشتراک بذارین.😉

باهام همراه باشید...

یه سری از ورژن های خاص کتابخونه pandas با pip خیلی جور نیس. نمیدونم مشکل caching یا چیه ولی الان ۱۰ دقیقه‌اس که با سرعت ۳۵ مگ داره سعی می‌کنه pandas==2.0.3 رو با pip==24 نصب کنه!!

+ شدید منتظرم uv استیبل شه و سوییچ کنم بهش.
uv: https://github.com/astral-sh/uv

به بهانه معرفی فریمورک <جای‌خالی> با ۳ برابر سرعت در پاسخگویی نسبت به FastAPI و البته باهدف battery included بودن مثل django

وقتی صحبت از بکند توی پایتون میشه تا همین چندسال قبل تنها گزینه خوب فقط و فقط django بود و مرسی دولوپرهاش؛ تو زمانی که همه غر میزدند پایتون کند هست و نباید و ... (تو ایرانم ازین حرفا زیاد بود) قشنگ یادمه ی بنده خدایی اسم نمیبرم ولی معروفم هست توی یکی از دانشگاها پنل سخنرانی داشت.
گفت که پایتون فقط یک جو هست و خیلی زود هم تموم می‌شه؛ بعد هم ادعا کرد به همین دلیل مطالبش رو نیاورده و ترجیح میده راجب مطالب مهمتر صحبت کنه (سخنرانی به شوخی گذشت و تنها کسی که اعتراض کرد توی سالن ۳۰۰-۴۰۰ نفری من بودم) الان شنیدم همون بنده خدا داره از پایتون نون میخوره و دوره هم میذاره.

بگذریم اومد جلوتر و async معرفی شد؛ هوش مصنوعی از فقط ریسرچ بودن داشت خارج میشد و تجریه دپلوی مهم شد.
دپلوی رو django انقدر سخت و غیر بهینه بود که عملا خیلی از تیم‌هایی که پروژه‌هاشون مشتری کافی رو داشت مجبور به توسعه بکند توی زبان‌های برنامه نویسی دیگه بودند؛ خیلی از بچه ها رفتند سراغ C, C++ , Go-lang و ...
حتی جوگیری زیاد شد مدل هارو سمت وب و موبایل و ... هم بردند که صحبتی نیست.

یادی کنم از شب زنده داری‌ها و دپلوی کدها و مدل‌ها با Majid A.M (آیدی نمیزارم ولی احتمالا هرکی django کار می‌کنه میشناسه) عزیز و حجم اپتیمایز‌های بالا جزو اولین نفرات و تیم‌هایی بودیم که کل مدل هوش مصنوعی و اپتیمایز و وب و ... همه روی پایتون بود و البته دسترسی و درخواست رایگان (این برای زمانی بود که همه میرفتن سراغ C, ... برای دپلوی و کسی باورش نمیشد بشه مدل‌های سنگین رو روی سرور بیاری و اون تعداد ریکوست رو با پایتون جواب بده) اون زمان همه فکر میکردند روی سرورهای خفن و ...هستیم ولی این موضوع رو اولین بار هست دارم اعلام می‌کنم؛
۲ نسخه اول مدل‌های پردازش تصویرمون روی کلاستر رزپبری پای و نسخه آخر روی لپ‌تاپ شخصی بنده بود.

ازین دوران گذشتیم flask با ایده‌های جدید اومد و خوبیش این بود که دیگه به اندازه django سنگین نبود (برای تست‌های کوچیک خیلی جواب بود ولی بازم همون مشکلات رو داشت)
البته اضافه کنم سرویس‌هایی مثل Celery, ... خیلی از مشکلات رو توی django حل می‌کردند

بعد از این زمان FastAPI معرفی شد؛ روی همون کامیت‌های اولیه که عمومی شد چون از بچه‌ها و همکارای بکندم توی شرکت‌های سیلیکون‌ولی و ... بسیار راجبش شنیدم به خیلی از دوستان بکند دولوپرم پیشنهاد کردم که وقتش هست یاد بگیرند و بهش کد donate کنند (کاش خودم اینکارو میکردم) خیلی هم مسخره میکردند. همون Majid A.M جزوشون بود.

به لطف همه‌ی دولوپرهای پروژه‌های قبلی django - flask - fastapi حالا خیلی‌ها باور دارند پایتون می‌تونه توی پروداکشن و برای پروژه‌های بزرگ استفاده بشه؛ خیلی‌ها قبول دارند که میشه با پایتون کد زد و از پکیج‌هایی استفاده کرد که سرعت پردازش بسیار بیشتر بشه .
دولوپرهای پروژه‌های قبلی نشون دادند که توسعه پکیج‌هایی با ایده‌هایی حتی کمی بهتر بسیار ارزش داره و جامعه پایتون همیشه قدردان این زحمات خواهد بود.

تا اینجا که حالا community زبانی مثل Rust برای توسعه یک web framework با سرعت بیشتر و البته به راحتی موارد قبلی برای Python وارد شده و پروژه Robyn رو به حد خوبی رسونده بطوری که امروز توی چندین جلسه مختلف با دوستان و همکاران بسیار درمورد این پروژه شنیدم.
توی مطالبی که داشتم میخوندم و بنچمارک‌هایی که از باقی شنیدم اکثرا اشاره می‌کنند که به راحتی سرعتی ۳ برابر fastapi رو ارائه میده.
از نظر کدهم شخصا یک نگاهی انداختم به همون سادگی هست؛ خلاصه که شمارو نمی‌دونم اما شخصا فکر کردم باید قدردان زحمات تیم‌های توسعه django, flask, fastapi و برو بچه هایی که توی دوران سخنرانی ضد سرعت و ... پایتون با این زبان برنامه نویسی ادامه دادند باشم.

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

و بنده فقط طبق مهارت انگلیسی که در این چند سال کسب کردم در تلاش هستم که براتون یه فایل کامل رو خیلی به زبان رسا و قابل فهم براتون ترجمه کنم که بتونه تو یادگیری بهتر بهتون کمک کنه و شما رو یه قدم جلو تر ببره موفق باشید ریکشن یادتون نره شبتون زیبا🫡❤️💻

یکی از مشکلات کسایی که میخوان برنامه نویسی یاد بگیرن پیدا کردن منبع درست حسابیه
با وجود چنل های یوتوب خیلی خفن ممکنه بعضیا نشناسنشون و نتونن ازشون استفاده کنن برای #بحث_امشب چنل های یوتوبی که میشناسید و میدونید محتوای بدرد بخور تولید میکنن چه فارسی و چه انگلیسی تو کامنتا بفرستید

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

✔️ فرض کنیم چنین سوالی داریم

"میخوایم ببینیم، آیا حرف nام letters در کلمه nام words وجود داره یا نه"

دو راه داریم که مشخص شدن.

بدون ران کردن و تست سرعت کد، این خیلی مهمه، بگید کدوم کند‌تره؟

و برای جواب‌تون حتما دلیل بتراشید

یک نقشه راه کامل برای یادگیری ساختار داده ها و الگوریتم ها (DSA) : 👇👇

1. یادگیری مبانی برنامه نویسی : با یادگیری اصول اولیه یک زبان برنامه نویسی مانند پایتون، جاوا یا C++ شروع کنید. به مفاهیمی مانند variables, loops, functions, and arrays مسلط شوید.

2. یادگیری ساختارهای داده: ساختارهای داده اساسی مانند :
arrays, linked lists, stacks, queues, trees, graphs, and hash tables

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

3. آشنایی کامل با الگوریتم‌ها : الگوریتم‌های رایج مانند
searching, sorting, recursion, dynamic programming, greedy algorithms, and divide and conquer
را بیاموزید. نحوه کار این الگوریتم ها و پیچیدگی های زمانی آنها را درک کنید.

4. حل مسئله: حل مشکلات کدنویسی را در پلتفرم هایی مانند LeetCode، HackerRank یا Codeforces تمرین کنید. از مشکلات آسان شروع کنید و به تدریج به سمت مشکلات متوسط و سخت بروید.

5. تجزیه و تحلیل پیچیدگی : یاد بگیرید چگونه پیچیدگی زمانی و مکانی الگوریتم ها را تجزیه و تحلیل کنید. با نماد Big O و نحوه محاسبه پیچیدگی الگوریتم های مختلف آشنا شوید.

6. ساختارهای داده پیشرفته : به ساختارهای داده پیشرفته مانند
AVL trees, B-trees, tries, segment trees, and fenwick trees.
مسلط شوید. درک زمان و نحوه استفاده از این ساختارهای داده در حل مسئله.

7. الگوریتم های نمودار : الگوریتم های  Graph traversal مانند BFS و DFS را یاد بگیرید. الگوریتم هایی مانند Dijkstra's algorithm, Bellman-Ford algorithm, and Floyd-Warshall را برای حل مشکلات با کوتاه ترین مسیر مطالعه کنید.

8. برنامه نویسی پویا : بر تکنیک های برنامه نویسی پویا برای حل موثر مسائل پیچیده مسلط شوید. حل مسائل برنامه نویسی پویا را تمرین کنید و مهارت های خود را ارتقا دهید.

9. تمرین و مرور : به طور منظم مشکلات کدنویسی را تمرین کنید و راه حل های خود را مرور کنید. اشتباهات خود را تجزیه و تحلیل کنید و از آنها درس بگیرید تا مهارت های حل مسئله خود را بهبود ببخشید.

10. مصاحبه های ساختگی : با شرکت در مصاحبه های ساختگی و حل مشکلات کدگذاری به سبک مصاحبه، برای مصاحبه های فنی آماده شوید. توضیح فرآیند فکر و استدلال پشت راه حل های خود را تمرین کنید.

منابع برتر DSA برای مصاحبه کدنویسی

👉 GeekforGeeks

👉 Leetcode

👉 Hackerrank

👉 FreeCodeCamp

👉 Best DSA Resources

به به چقد دوستون دارم :(
اومدم چندتا مورد راجع به برنامه نویسی بگم نصف شبی به چالش بکشونیم خودمونو.
یسری چیزا هستن که تو هر شغلی اینا عادین مثلا یک #حسابدار ممکنه یجایی عددی رو اشتباه وارد کنه، ممکنه عددی رو اشتباه بخونه، ممکنه کالایی رو اشتباه بزنه و... یا یک فروشنده ممکنه رمز کارت شمارو به اشتباه بزنه یا مبلغ رو اشتباه بزنه اینا مواردین که ما بار ها و بارها دیدیم توی اجتماع و دلیلشم کند ذهن یا بلانسبت خنگ بودن طرف نیست این بخاطر زیاد کارکردن، درگیری زیاد، تکراری شدن اون کار بصورت روتین هستش که باعث میشه یه وقتایی مغز ارور بده :( تو برنامه نویسی یسری موارد هستن مثل:

- فراموش کردن سینتکس زبان

- نامفهوم بودن کد های قبلی یا حتی کامنت ها

- پیدا نکردن راه حل برای باگ یا تسک

- فراموش کردن فریم ورک یا کدای اون
درگیری روی یک تسک یا باگ به مدت چند روز یا ساعت

دلیل همه اینا اینه که شما ساعتها درگیر میشید و یک چیز عادی هست البته اگر همچین مواردی نباشه مطمئن باشید ادامه راه سخت میشه براتون جاهایی هنگ کردن نیازه به جواب نرسیدن نیازه تغیر رویه لازمه و الی آخر

تو کارتون مخصوصا برنامه نویسی اصلا تعصب نداشته باشید همیشه جستجو کنید، بپرسید، مطالعه کنید، بخونید و قهوه بخورید درکنار اینا :(
نا امید نشید #پایتونیزمی های عزیز❤️
#SXL
@pythonism_xl

انواع سرچ ها روی لیست:

خیلی خلاصه چند تا از انواع سرچ ها رو روی لیست باهم ببینیم:

فرض کنید یه لیست نا مرتبی از اعداد داریم به این شکل:
lst = [30, 2, 7, 14, 1, 25, 4, 15, 9]
اگه بخواهیم دنبال عدد ۱۵ بگردیم باید چیکار کنیم؟

1- Linear search(not optimized)
میتونیم از ایندکس شماره صفر شروع کنیم و تک تک تا انتها بریم جلو و اعداد رو نگاه کنیم ببینیم ۱۵ داخلشون هست یا نه. این درواقع کاری هست که پایتون انجام میده زمانی که شما از in استفاده میکنید. چون اعداد ترتیبی ندارن کار دیگه ای نمیشه کرد.
________________________________________
اگه اعداد مرتب بودن چی؟
lst = [1, 2, 4, 7, 9, 14, 15, 25, 30]

2- Linear search(optimized)
فرض کنیم میخواهیم دنبال عدد ۵ بگردیم. دوباره میتونیم شروع کنیم تک تک اعداد رو مقایسه کنیم، ولی بعد از اینکه به عدد ۷ رسیدیم، میتونیم دیگه ادامه ندیم. چون اعداد مرتب هستن، حتما توی اعداد بزرگتر از ۷ هم نخواهد بود. بهتر شد اینجا.

3- Jump search
میتونیم به جای اینکه تک تک به جلو بریم و اعداد رو، چند تا چند تا جلو بریم و بپریم اصطلاحا (jump search).
فرض کنید دنبال عدد ۲۵ میگردیم. میتونیم اعداد رو ۲ تا ۲ تا جلو بریم، یعنی اول ایندکس شماره ۰ (یا عدد ۱) و نگاه میکنیم، بعد میریم ایندکس شماره ۲ (یا عدد ۴)، بعد ایندکس شماره ۴ (یا عدد ۹) و تا آخر، هر جا که دیدیم عدد ایندکس مورد نظر بزرگتر از عدد مقصود ماست، یعنی به اون تیکه از لیست که ممکنه عدد هدف داخلش باشه رسیدیم، فقط کافیه داخل اون رو به صورت linear نگاه کنیم. برای پیدا کردن عدد ۲۵ ، فقط ۶ تا مقایسه لازم بود. (تو حالت خطی ۸ تا). حالا این jump ما چقدر باشه خوبه؟ محاسبات نشون میده که رادیکال n بهترین گام هست. ( n تعداد آیتم های داخل لیست هست)

4- Binary search
کافیه توی هر مرحله لیستمون رو به دو قسمت تقسیم کنیم، و آیتم هدف رو با آیتم وسطی مقایسه کنیم، اگه کوچیکتر بود، دیگه فقط توی اون نیمه ی سمت چپ دنبالش میگردیم، اگه بزرگتر بود توی نیمه ی سمت راست. و دوباره همینکار رو تکرار میکنیم تا به هدف برسیم.

5- Interpolation search
خیلی شبیه binary search هست با این تفاوت که اونجا نقطه ای که لیست ما رو تقسیم میکرد و دقیقا وسط لیست میگرفتیم، ولی اینجا با استفاده از این فرمول، اون نقطه رو بدست میاریم:
mid = low + ((key - arr[low]) * (high - low) / (arr[high] - arr[low]));

low = کوچکترین ایندکس
high = بزرگترین ایندکس
key = آیتم هدف

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

6 - Exponential search
توی این روش که برای لیست های خیلی بزرگ کاربرد داره، از ابتدا شروع میکنیم به گشتن، ولی گام های ما به صورت exponential هست (توان های ۲):
0, 1, 4, 9, 16, 25, ...
وقتی که آیتمی پیدا کردیم که از آیتم هدف ما بزرگتر بود، میایم اون تیکه رو دوباره فقط جست و جو میکنیم(مثل jump search) ولی دیگه این جست و جو خطی نیست بلکه روش binary search انجام میدیم.


نکته: این الگوریتم ها بسته به شرایط الگوریتم های خیلی بهتری هستن از کاری که پایتون انجام میده. به پایتون حتی اگه لیست مرتب شده هم بدید باز تک تک سرچ میکنه. ولی خب نکته اینجاست که اون با C پیاده سازی شده و احتمالا توی خیلی از پیاده سازی های pure python از الگوریتم هایی با time complexity بهتر سریعتر باشه.

در آینده سعی میکنم بیشتر درمورد time complexity ی هرکدوم از این انواع سرچ و اینکه کجا کدوم بهتره استفاده بشه صحبت کنیم.

🗃 390 پروژه رایگان پایتون

این ریپو دارای 390 پروژه متن باز عالی با مجموع 1.7 میلیون ستاره است که در 28 دسته گروه بندی شده اند. همه پروژه ها با امتیاز کیفیت پروژه رتبه بندی می شوند که بر اساس معیارهای مختلفی که به طور خودکار از GitHub و مدیران بسته های مختلف جمع آوری می شود، محاسبه می شود.
🔻🔻

https://github.com/ml-tooling/best-of-python

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

اول بذارین توضیح بدم observation یعنی چی. ما توی devops دو آپریشن داریم که شبیه همن و گاها باهم اشتباه گرفته میشن. اولیش مانتورینگه. مانیتورینگ به پروسه ای میگن که دیتا کالکت میشه از سرویسی, و یک ریپورت از سلامت سرویس بر اساس metric های مشخصی که برای سلامت سیستم رو نشون میدن و کالکت شدن ساخته میشه. یعنی چی؟ مثلا تعداد ریسپانس های 5xx در ۲۴ ساعت گذشته. یکی از شناخته شده ترین ابزار برای اینکار prometheus هست. observability به پروسه ای میگن که رویکرد تحقیقاتی داره. یعنی دنبال این نیست که بگه چقدر ریسپانس 5xx وجود داره. دنبال دلیل وجود این ریسپانس هاست. چرا الان این درخواست تو پروداکشن ارور ۵۰۰ میده؟ خوندن کل لاگ سرویس قدیمی ترین و ابتدایی ترین راهکار بود.

وقتی بک اند پیچیده تر شد, دیگه خوندن لاگ واقعا کارساز نبود. شما فکر کنید در لحظه ۱۰۰ درخواست داره میاد براتون. چطور میخواین لاگ هارو بخونید؟ تو قدم بعدی لاگ های هر درخواست رو جدا کردن. ولی بازم کار ساز نبود تو دنیای distributed system. چون مثلا یک سرویس ۱ با سرویس ۲ داشت حرف میزد. ورودی که میداد بهش درست نبود. سرویس ۱ صرفا یک exception میگرفت که سرویس ۲ استتوس ۵۰۰ داده. و این کافی نبود برای اینکه متوجه شیم چه اتفاقی میفته.

سولوشن های زیادی اومدن تو مارکت. از قبیل sentry که شاید اسمشو شنیده باشین. یا datadog و لوکی و ... . اینقدر این سولوشن ها زیاد شدن و هر کدوم ساز خودشون رو میزدن. نمیشد راحت از این سولوشن سوییچ کرد به اون یکی. نمیشد مزایا دو سولوشن رو همزمان داشت. و learning curve سختی داشت اگه میخواستین سوییچ کنید از یکی به یکی دیگه.

اینجا بود که CNCF (Cloud native compute foundation) یک پروژه جدید رو استارت زد. همون فاندیشنی که کوبر و prometheus و خیلی ابزار های تحت کلاد رو ساخته. اومد یک پروتکلی ساخت به اسم opentelemetry.
یعنی چی پروتکل؟ یعنی گفت sentry جان من برام مهم نیست شما لاگ رو چطور ذخیره میکنی یا پردازش میکنی اینترنالی. شما باید span داشته باشی. metric داشته باشی. و trace. و دقیقا تعریف کرد که اینا چین. یعنی اومد گفت اینترفیس خارجی یک سیستم observability چطور باید باشه؟ چون در نهایت همه این سیستما شبیه هم بودن. و حالا چون همشون داشتن از یک پروتکل خاصی پیروی میکردن شما میتونستی راحت از سولوشن یک سوییچ کنی به سولوشن دو. مثلا شاید مثالشو دیده باشین که تو سیستم فایل استوریج بعضی استوریجا s3 compatible هستن. اینم دقیقا شبیه همونه.

استک observation به دو قسمت تقسیم میشه. یکی میشه exporter و یکی میشه داشبورد. exporter معمولا یک لایبریه که شما نصب میکنی. و باهاش اون دیتایی که میخوای export میکنی. و میگی دیتا رو کجا بفرسته.(یک وقتام برعکسه, سرور داره دیتا رو میگیره). قسمت دوم میشه اینترنال اون استک. مثلا دیتایی که فرستاده میشه تو چه دیتابیسی ذخیره میشه؟ چطوری پردازش میشه؟ چی به شما نمایش داده میشه؟من بهش میگم داشبورد.

خوده opentelemetry داشبورد خاصی نداره. صرفا یک سری exporter تو زبون های مختلف داره که میتونید تو گیتهابش ببینید. مثلا برای fastapi و جنگو لایبری داره. ولی پیاده سازی و داشبوردی نداره برای نشون دادن این اطلاعات. چون همونطور که گفتم در نهایت فقط یک پروتکل و specification هست. از طرفی سولوشن های داشبورد زیاده.یک سرچ کنید میرسید بهش. مثلا من خودم signoz استفاده میکنم.

خب همه اینارو گفتم. حالا نقش logfire این وسط چیه؟ logfire همون لایبری های اکسپورتر opentelemetry رو اینترفیسشو بهتر کرده. و با pydantic هم اینتگریتشون کرده. و یکم utilty اضافه کرده. این قسمت exporter اش هست که اوپن سورسه.
یک قسمت داشبورد هم داره که هنوز اوپن سورس نشده. و مشخص نیست که بشه یا نه. ولی فعلا رایگانه.


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

@PyBackendHub

رویه ذخیره شده Stored Procedure ناجی برنامه های تحت فشار:
در دنیای برنامه‌نویسی(منظور ما سمت Back-End است Front-End 🥸)، بهینه‌سازی و عملکرد روان برنامه‌ها از اهمیت بالایی برخوردار است. در این میان، پایگاه‌های داده نقش حیاتی در ذخیره‌سازی و بازیابی اطلاعات ایفا می‌کنند.

رویه ذخیره‌شده یا Stored Procedure چیست ؟
به صورت خلاصه Stored Procedure یک مجموعه از دستورات SQL است که کار خاصی را انجام میدهد و ما برای آن یک نام مرتبط میگذاریم و در هر جایی که نیاز داشته باشیم آن را فراخوانی میکنیم (اگر پارامتر خاصی نیاز داشته باشد هم میتوانیم به آن پاس بدهیم )

به صورت معمول برنامه نویس ها از ORM هایی مخصوص زبان برنامه نویسی که با آن کار میکنند برای ایجاد کوئری بر روی دیتابیس استفاده میکنند ولی ORM (منظورم هر ORM است حتی اگر معجزه برنامه نویسی قرن باشد!!!) چندین ایراد مهم و اساسی دارند که در ادامه به آن ها اشاره میشود:

۱. شما باید هزینه تبدیل کد هایتان را به SQL پرداخت کنید(با کاهش قدرت برنامه) در نهایت پایگاه داده شما با SQL کار میکند نه زبان برنامه نویسی شما !!!

۲.وقتی از ORM ها استفاده میکنید اگر نیاز به کوئری پیچیده و یا خیلی خاصی داشته باشید قدرت زیادی برای مدیریت این چالش با استفاده از ORM نخواهید داشت.

۳. معمولا برای فراخوانی یک مقدار از پایگاه داده به چندین روش مختلف میتوان این کار را انجام داد که یه سری از این روش ها دارای پرفومنس خوب و بعضی از روش ها دارای پرفومنس وحشتناک هستند (این مورد مربوط به افزایش پرفومنس در SQL است که توضیح طولانی دارد که در اینجا جای نمیگیرد ولی برای آشنایی بیشتر ساده ترین مورد را اشاره میکنم :
تصور کنید جدولی به نام کارکنان و با ۱۵ ردیف داریم و میخواهید مقدار نام از جدول کارکنان خود را بخوانید با استفاده از ORM خود در نهایت به این کوئری خواهید رسید :

select * from employee;

در حالی که شما فقط به نام کارکنان در این جدول نیاز دارید و این جدول دارای ۱۵ ردیف است که فراخوانی ۱۴ ردیف دیگر بیهوده و هزینه برخواهد بود
و این کوئری نیاز شما را برطرف میکرد :

select name from employee;

که دارای پرفومنس بهتری خواهد بود
{شاید بتوانید جلوی استفاده از * بگیرید و ORM را مجبور به فرخوانی تنها name کنید ولی در موارد دیگر همچنین ساده هم نخواهد بود }

) وقتی از ORM خود استفاده میکنید شما کنترل زیادی برای اینکه از چه روشی استفاده کند نخواهید داشت و صرفا کد های ORM خود را خواهید دید

۴. گاها پیش میآید که شما برای فراخوانی مقدار در پایگاه داده با استفاده از ORM کوئری میسازید ولی ORM کوئری عجیبی تولید میکند که فشار فوق العاده ای بر روی برنامه شما وارد میکند.(برای جلوگیری این مورد اگر اصرار به استفاده از ORM دارید باید به موارد پیشرفته ORM خود مراجعه کنید که نیاز به تمرین و زمان است)

از معایب استفاده از Stored Procedure میتوان به این موارد اشاره کرد:

۱. نیاز به دانش خوبی از SQL دارد

۲. در صورت تغییر پایگاه داده نیاز به بازنویسی خواهند داشت

۳.نوشتن برنامه با سرعت خیلی پایین تری پیش خواهد رفت.

مقایسه Stored Procedure با ORM:

در واقع ORMها (Object-Relational Mapping) ابزاری برای نگاشت اشیاء برنامه به ساختارهای پایگاه داده هستند. ORMها به طور خودکار وظایف مربوط به ترجمه کوئری‌ها از زبان برنامه‌نویسی به زبان SQL را انجام می‌دهند.

در حالی که ORMها مزایایی از جمله سادگی و سهولت استفاده را ارائه می‌دهند، اما در مقایسه با Stored Procedureها، معایبی نیز دارند. ORMها می‌توانند به دلیل ترجمه‌های اضافی، باعث افت عملکرد شوند. همچنین، ORMها در مدیریت کوئری‌های پیچیده و خاص، انعطاف‌پذیری Stored Procedureها را ندارند.

در نتیجه :اگر برنامه شما دارای فشار زیادی بر روی پایگاه داده است و همین طور برنامه شما دارای بار زیادی است میتوانید برای مدیریت آن از Stored Procedure ها در پایگاه داده تان استفاده کنید
یا اینکه میتوانید استفاده نکنید و به زیبایی کد های خود با استفاده از ORM به خود افتخار کنید و بگذارید پایگاه داده تحت فشار کد های SQL عجیب شما تبدیل به نفت شود
این مورد کاملا بستگی به برنامه و نیاز شما بستگی دارد.

#Database #General
@Code_Crafters

به دنبال ساختار باشید و نه چارچوب

چند روز پیش یه مربی کودک یه حرف خیلی مهمی زد با این مفهوم: «ما اینجا برای بچه ها ساختار تعیین می کنیم نه چارچوب، چارچوب یعنی حد و مرز!»
این جمله رو باید قاب کرد و زد رو دیوار، احتمالا در ابعاد خیلی زیادی از زندگی مهم باشه. در مهندسی نرم افزار و توسعه محصول هم خیلی حرف مهمیه.
بیشتر اوقات ما دنبال چارچوب هستیم در مهندسی نرم افزار، به همین دلیل وقتی خودمون رو به یه چارچوب خاص محدود می کنیم با چالش های زیادی روبرو میشیم. در حالیکه بهتره ما برای توسعه محصول ساختار داشته باشیم و طبق اصول ساختاری کار رو پیش ببریم، اینطوری چالش مون کمتر میشه.
اجازه بدید برداشت خودم از چارچوب و ساختار رو کمی بیشتر باز کنم. ساختار میشه مجموعه از قواعد رفتاری که باید سعی کنیم در توسعه محصول بهشون پایبند باشیم، در مقابل، چارچوب میشه تعیین کردن یه سری حد و مرز مشخص به شیوه ای سختگیرانه.
مثلا اگه بخوام برای توسعه یک سرویس ساختار تعیین کنم احتمالا میگم: این سرویس باید توان پاسخگویی بالایی داشته باشه، در مقابل خطا مقاوم باشه، قابلیت مقیاس پذیری داشته باشه، یک قرارداد ساده و شفاف به کلاینت ها ارائه بده و مواردی از این دست.
اما اگه بخوام چارچوب برای سرویس تعیین کنم احتمالا میگم: ما باید از ساختار کد مبتنی بر clean code یا ddd در فلان repository که خودمون یا دیگران اونو نوشتن پیروی کنیم، باید همه ورودی هارو تو پوشه port قرار بدیم، باید همه مدل هامون تو پوشه models باشه، باید از فلان روش ci/cd استفاده کنیم.

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

خیلی از practiceهایی که معروف شدند مثل clean code و ddd و tdd و غیره هم از نظر من بیشتر به دنبال این هستند که به شما کمک کنند که برای کارتون ساختار تعیین کنید. در حالیکه اشتباهی که زیاد رخ میده اینه که ما با خوندن این مطالب احتمالا بیشتر به سمت درآوردن چارچوب میریم... همه ش به دنبال این هستیم که مثلا یه boilerplate داشته باشیم که از clean code پیروی کنه و همون رو همه جا استفاده کنیم.

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

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