نظر شما در مورد این متن چیه؟
لایک یا دیسلایک هم کافیه


Free things often fail to leave a lasting impression. Why?

Behavioral economist Dan Ariely points out an intriguing aspect of human behavior: we attach greater value to things when we have invested effort or participated in a social experience - even if money never changed hands.

If your goal is to create lasting connections or memories, simply handing out freebies isn't enough. Instead, find meaningful ways for people to engage - emotionally, socially, or creatively. By creating a moment worth remembering, you increase the perceived value of the experience itself.

What are your thoughts on this approach?

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

فرض کن که یه تابع داریم که فاکتوریل یک عدد رو محاسبه می‌کنه. اگر بخوایم این تابع رو با lru_cache دکوریتور کنیم، به این صورت می‌شه:

from functools import lru_cache

@lru_cache(maxsize=None)  # maxsize می‌تونه محدودیت حافظه رو تعیین کنه
def factorial(n):
    if n == 0:
        return 1
    else:
        return n * factorial(n - 1)

print(factorial(5))  # خروجی: 120
print(factorial(5))  # اینجا دیگه محاسبه نمی‌شه و سریعاً از کش برمی‌گرده

اینجا وقتی که factorial(5) رو برای بار اول صدا می‌زنیم، تمام مراحل محاسبه انجام می‌شه و نتیجه 120 برمی‌گرده. اما وقتی دوباره همین تابع رو با همون ورودی صدا بزنیم، دیگه نیازی به محاسبه نیست و نتیجه از کش برمی‌گرده که خیلی سریع‌تره!

پس با استفاده از lru_cache می‌تونیم سرعت برنامه‌هامون رو بالا ببریم و کارایی رو بهبود بدیم.

در مورد دکوریتور lru_cache توی پایتون.
با تشکر از عمو جی پی تی

تجربه مصاحبه از کانال pyHints با یکم حذفیات از پست اصلی

سیستمی رو پیاده سازی کن که بعنوان ورودی یک استرینگ از محاسبات ریاضی بصورت infix دریافت کنه؛ بتونه خروجی رو بصورت postfix, یا prefix (هرکدوم راحت‌تری) تحویل بده یا اگر object اون کلاس صدا زده شده؛ با استفاده از postfix/prefix پیاده‌سازی شده محاسبات رو انجام بده و خروجی رو تحویل.

من اینو یادمه که با postfix حل کردم چون راحت‌تر بود (stack) :
اما چندتا چیز رو بررسی می‌کرد:
۱- چون صحبت از object شد باید. OOP می‌بود
۲- حتماً باید call رو براش پیاده‌سازی می‌کردم که callable باشه (این یعنی داندر متود‌ها رو می‌شناسم)
۳- سراغ پیاده‌سازی ساده‌تر رفتم (تصمیم گیری و شناخت مسأله، البته توضیح هم دادم چرا بنظرم ساده‌تر هست و ...)
۴- استفاده از stack که بعد خود stack رو پیاده‌سازی کردم (آشنایی با DS, حتی بحث هم کردم بین LinkedList, Array چرا و کدوم رو انتخاب می‌کنم برای ساخت stack) .

اگر خواستید پیاده‌سازی کنید این حالات رو تست کنید (تو مصاحبه از مصاحبه کننده باید پرسیده بشه)

۱- سیستم ورودی invalid داشته باشه؛ خروجی برای هر دو حالت None هست
۲- سیستم infix برای اولویت دادن به محاسبات از () ممکنه استفاده کنه
۳- سیستم فقط از ۴ عمل اصلی + پرانتز پشتیبانی خواهد کرد
۴- ورودی‌های عددی ممکنه float/int باشه
۵- ممکنه بین کاراکترها space باشه یا نباشه
"17+3.5" or "17 + 3.5"
هر دو درست هست.

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

یه ترفند کوچیک ولی مهم توی طراحی رابط کاربری که خیلی وقتا نادیده گرفته می‌شه 👇

اشتباه رایج: وقتی یه کانتینر (مثلاً یه کارت یا باکس) داخل یه کانتینر بزرگ‌تر قرار می‌گیره، بعضی‌ها میان و برای هر دو یه border-radius برابر می‌ذارن. نتیجه‌اش چی می‌شه؟ گوشه‌های تیز و ناهماهنگ که حس تمیزی طراحی رو از بین می‌بره!

راه‌حل درست: شعاع گوشه‌ی بیرونی باید برابر باشه با شعاع گوشه‌ی داخلی به‌علاوه‌ی فضای خالی (padding) بین اون‌ها.

مثلاً اگه border-radius عنصر داخلی ۱۶ پیکسل باشه و فاصله بین اون و عنصر بیرونی ۸ پیکسل باشه، پس border-radius عنصر بیرونی باید ۲۴ پیکسل باشه.

اینجوری گوشه‌ها دقیقاً هم‌مرکز و تمیز درمیاد و طراحی حرفه‌ای‌تر دیده می‌شه.

نمیشه یه جاهایی ش رو بوووق بزارم
ولی نکته قابل تاملی میگه

خیلی ها پرسیدن، تو که ۲۲ سال دات نت کار کردی، چرا الان java و golang و php؟
سوال خوبیه.

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

اگر برنامه نویس دات نت یا هر زبان دیگری هستیم و نمی‌خواهیم رهاش کنیم، میشیم برنامه نویس اون زبان.

برنامه نویسی ۳۰ الی ۴۰٪ مهندسی نرم افزاره.

نظر شخصیم اینه که : اگر به زبان برنامه نویسی خاصی وابستگی زیادی دارید، احتمالا به زودی AI با هزینه خیلی کمتر از انسان اونو برامون انجام خواهد داد، ولی اگر مهندسیتون رو تقویت کنید، AI قراره ۳۰ الی ۴۰% کارتون رو که همون برنامه نویسی باشه رو راحت تر کنه.

همدلی‌در مسیر یادگیری

از اونجایی که قول داده بودم که با پلتفرم مکتبخونه پیگیر رایگان سازی دوره برای تعداد افراد بیشتری بشم. بالاخره این اتفاق افتاد و الان در طرح بزرگ همدلی مکتبخونه دو دوره جنگو مقدماتی و پیشرفته منو می تونین با ۱۰۰٪ تخفیف تهیه کنین. 😄🌷

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

جنگو مقدماتی:
https://mktb.me/tgk5/
جنگو پیشرفته:
https://mktb.me/vmxs/

۱۰۰ تا دوره محبوب مکتبخونه رایگان شدن
توی حوزه های مختلف از برنامه و نویسی و شبکه و هوش مصنوعی تا مهارت های نرم و زبان و ...

کافیه دوره ها رو توی سبد خریدتون با برداشتن تیک (دوره کامل ) و فقط خرید محتوا اضافه کنین و کد HAMDELI رو وارد کنین و در این صورت می تونین به رایگان از دوره ها استفاده کنین.

اگر می خواید AI جاتون رو نگیره سعی کنید Requirement Engineering رو یاد بگیرید و بفهمید.

یک کتاب خفن در موردش
Software Requirements Third Edition - Joy Beatty

متن بالا بخشی از یه پست کانال thisisnabi بود 😁

توضیحات chatgpt:
مهندسی نیازمندی‌ها یا Requirement Engineering بخشی از فرآیند توسعه نرم‌افزار است که به شناسایی، تحلیل، مستندسازی و مدیریت نیازمندی‌های سیستم می‌پردازد. هدف از این علم، اطمینان از این است که نرم‌افزار در نهایت به نیازها و خواسته‌های کاربران و ذینفعان پاسخ می‌دهد.

فرآیند مهندسی نیازمندی‌ها معمولاً شامل مراحل زیر است:

1. شناسایی نیازمندی‌ها**: در این مرحله، نیازمندی‌های واقعی سیستم شناسایی می‌شوند. این کار معمولاً با جمع‌آوری اطلاعات از ذینفعان، مصاحبه‌ها، کارگاه‌ها و بررسی مستندات موجود انجام می‌شود.

2. تحلیل نیازمندی‌ها**: نیازمندی‌ها تحلیل و بررسی می‌شوند تا مشخص شود که آیا آنها قابل فهم، کامل، قابل اندازه‌گیری و قابل تحقق هستند یا خیر.

3. مستندسازی نیازمندی‌ها**: نیازمندی‌ها باید به شکل مستند و مطابق با استانداردهای مشخصی ثبت شوند تا در آینده بتوان به آنها مراجعه کرد.

4. تایید نیازمندی‌ها**: پس از مستندسازی، نیازمندی‌ها باید توسط ذینفعان تأیید شوند تا از صحت و تناسب آنها اطمینان حاصل شود.

5. مدیریت نیازمندی‌ها**: نیازمندی‌ها باید به طور مداوم مدیریت شوند تا تغییرات و اصلاحات لازم در طول فرآیند توسعه نرم‌افزار اعمال شوند.

مهندسی نیازمندی‌ها به عنوان یکی از مراحل کلیدی در توسعه نرم‌افزار شناخته می‌شود و تأثیر زیادی بر کیفیت پروژه و رضایت مشتری دارد.

از کانال های مختلف دیدم پست میذارن که بله تایپینگ کد شما رو بیشتر میکنه کثیف تر میکنه اگه میخواستیم تایپ بزنیم که میرفتیم سمت C و این حرفا. اولا که C تایپ سیستم قوی نداره. تایپ سیستم بسیار ساده ای داره. پس statically typed بودن یا نبودن یک زبون رو خوب/بد بودن تایپ سیستمش تاثیری نمیذاره. پس اگه انتخابتون C هست برای اینکه تایپ سیستم قوی داشته باشین انتخاب درستی نیست!‌

ثانیا تایپینگ خودش یک داکیومنته. مثلا شما فکر کنید من یک سیستم نوشتم که ۱۰ تاسیستم مختلف رو integrate میکنه و یک API واحد میده برای هر ۱۰ تاشون. من یا میتونم ۱۰ صفحه داکیومنت بنویسم که اگه خواستیم یک سیستم جدید اضافه کنیم چه دپندسی هایی وجود داره یا اینکه میتونم یک Enum داشته باشم به اسم Service و همه جا با اون Enum بیام exhaustive check انجام بدم.

مثالش, من اینجا فقط یک سرویس Digikala دارم. و برای دیجی کالا یک رفتاری رو تعریف کردم و چک کردم سرویسی نباشه که این رفتار براش تعریف نشده باشه (`assert_never`)

def do_foo(service: Service):
    match service: 
          case Service.DIGI_KALA: ...
          case _: assert_never(service)

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

کد خواناییشو از دست میده؟ نه واقعا!‌شما اگه خوانایی کد رو به تعداد خط ملاک قرار میدین, پس کد ننویسید که خیلی خوانا و تمیز باشه. کد خوانا یعنی من کدی رو بخونم و بفهمم چیکار میکنه و constraint های اون کد چیه و تو موقع استفاده ازش اشتباه نکنم.

یک مثال دیگه بازم تو پست بعدی میزنم
@PyBackendHub

فکر نکنید پست قبلی به این جواب داده

داشتم یه مدل می‌ساختم که باید برای یه فیلدش چند مقدار مشخص تعریف می‌کردم.
طبق عادت قدیمی، رفتم یه لیست (value, label) بسازم… ولی وسط کار چشمم افتاد به models.TextChoices

گفتم خب، یه بار امتحانش کنم… و از همون لحظه فهمیدم این بهترین راهه برای تعریف choice field تو Django

مزیت‌هاش چیه؟

به جای "info" میگی Level.INFO → هم امن‌تره، هم IDE بهت autocomplete می‌ده.
مقدار دیتابیس و برچسب نمایشی رو با هم داری.
می‌تونی با obj.get_level_display() اسم قابل نمایش رو بگیری.
کد ساختاریافته تره
وقتی میشه کد تمیزتر و قابل نگهداری‌تری داشت، چرا هنوز با استرینگ خام کار کنیم؟ 😉

از لینکدین شایان حسین زاده