یک راهنمایی بزرگ:‌لاجیک کد مشکل نداره.
خروجی کنسول اینه:

Ma: Hirad
Hir: Hirad

در صورتی که باید Ma: Mani و Hir: Hirad باشه. چرا؟

@PyBackendHub

برای اینکه بفهمین چطور کار می‌کنه، اول یه مثال ساده‌تر رو در نظر بگیرین:

adders = []
for x in [1, 2, 3]:
    adders.append(lambda number: number + x)

for adder in adders:
    print(adder(3))

قاعدتاً باید خروجی‌ها ۴، ۵ و ۶ باشن، درسته؟ چون یه لیست از تابع‌های lambda داره که هر کدوم یه عدد می‌گیرن و x رو بهش اضافه می‌کنن.
ولی در واقع خروجی‌ها ۶، ۶ و ۶ هستن! چرا این اتفاق می‌افته؟
چون این lambdaها تو این مثال closure هستن. تو پایتون، توابع closure زمانی اجرا می‌شن که صدا زده بشن، نه وقتی که تعریف می‌شن! و به متغیرهایی که تو scopeشون هست رفرنس می‌زنن.

def foo():
    adders = []
    for x in [1, 2, 3]:
        adders.append(lambda number: number + x)
    return adders


def main():
    adders = foo()
    x = 5
    for adder in adders:
        print(adder(3))

تو این مثال، x یه بار تو foo تعریف شده و یه بار تو main. وقتی تو main اون closureها رو صدا می‌زنه که تو foo تعریف شده بودن، xی که استفاده می‌کنن همونیه که تو foo بوده، نه اون x تو main.یعنی الان تو این مثال x داخل lambda عدد ۳ میشه نه ۵.
چرا؟ چون داخلش توابع ‍closure یک cell هست که arguement رو ذخیره کرده. و تو همون اسکوپی که تعریف شده اون مدام آپدیت میشه اگه تغییر کنه. بنابراین اینجا چون scope تابع main دیگه با closureمون یکی نیست پس دیگه تغییر نمیکنه.


یک مقاله برای درک بهتر این موضوع تو medium
یک بلاگ راجب اشتباهات رایج تو پایتون این شکلی

@PyBackendHub

‏وقتی scala و Ruby یاد بگیرم باسن همه دولوپرای دورو برم میذارم!

<Rust/>

@DevTwitter

t.iss.one/tamozi_karaj

طموزی کرج:

#معرفی #موقت

ما طموزی هستیم، طرفداران محیط زیست
برای ایران 🇮🇷 برای زمین 🌏
محیط‌زیست سالم، حقّ اوّلیهٔ همهٔ موجودات

tamozi.ir
instagram.com/tamozi.ir
@tamozi
t.iss.one/+eujf7n6TFldkMjVk

#معرفی #موقت

لینک جدید دورهمی به علت محدودیت های پیش آمده


https://engage.shatel.com/b/soh-kwv-w45-csq

خسروپناه، دبیر شورای عالی انقلاب فرهنگی:
باید یه هوش‌مصنوعی مخصوص بسازیم و باهاش مملکتو اداره کنیم


اگر این خبر تأیید شد، از طرف خمینی بهش بگید:

خیلی خررررری

اگه به عنوان یه برنامه نویس چالش پروژه گرفتن دارید پست جدیدمون رو از دست ندید 😉

https://www.instagram.com/p/DAL0HKZos8Q/?utm_source=ig_web_copy_link&igsh=MzRlODBiNWFlZA==

نوشتن manifestهای کوبرنتیز میتونه چالش برانگیز باشه مخصوصا اگه تعداد microserviceها زیاد باشه

این مقاله یه سری best practice رو میگه که بهتر و منسجم تر بتونید manifestهارو بنویسید.


Best Practices for Writing Kubernetes YAML Manifests
https://mogenius.com/blog-posts/best-practices-for-writing-kubernetes-yaml-manifests


@gocasts

#devops
#kubernetes

اگه کلاینت#2 تصمیم بگیره داده قبلی رو به‌روزرسانی کنه، می‌تونه دوباره درخواست رو با هدر If-Match بفرسته. ولی اگه مقدار ETag توی هدر با مقدار فعلی منبع مطابقت نداشته باشه، API باید با کد 412 ("Precondition Failed") پاسخ بده. اما اگه شرط هدر مطابقت داشته باشه، API باید وضعیت منبع رو به‌روزرسانی کنه و با کد 200 ("OK") یا 204 ("No Content") پاسخ بده.
اگه API یه نمای جدید از وضعیت منبع رو برگردونه، باید هدرهای Last-Modified و ETag رو با مقادیر به‌روزرسانی شده توی پاسخ بذاره.


⭕️ استفاده از Location برای مشخص کردن URI منبع جدید
مقدار هدر Location یه URI هست که منبع جدیدی رو که ممکنه برای کلاینت مهم باشه، شناسایی می‌کنه. وقتی که API یه منبع جدید رو توی یه مجموعه یا فروشگاه ایجاد می‌کنه، باید هدر Location رو توی پاسخ قرار بده تا URI منبع جدید رو مشخص کنه.
توی پاسخ 202 ("Accepted")، این هدر می‌تونه کلاینت رو به وضعیت عملیاتی یه منبع کنترل غیرهمزمان (asynchronous controller) هدایت کنه.

⭕️ از هدرهای Cache-Control، Expires و Date برای کش کردن استفاده بشه
کش کردن یکی از قابلیت‌های مفید HTTP هست که می‌تونه به کاهش تأخیرهای تجربه‌شده توسط کلاینت، افزایش اطمینان‌پذیری، و کاهش بار روی سرورهای API کمک کنه. کش‌ها می‌تونن هر جایی باشن؛ توی شبکه‌ی سرور API، شبکه‌های تحویل محتوا (CDN)، یا حتی شبکه‌ی کلاینت.
وقتی که یه نمایشی از داده رو ارسال می‌کنی، باید هدر Cache-Control رو با مقدار max-age (به ثانیه) قرار بدی تا طول عمر تازگی داده رو مشخص کنی. به عنوان مثال:

Cache-Control: max-age=60, must-revalidate

برای پشتیبانی از کش‌های قدیمی HTTP 1.0، API باید هدر Expires رو با یه تاریخ و زمان انقضا قرار بده. این مقدار برابر با زمانی هست که API داده رو تولید کرده به اضافه‌ی طول عمر تازگی داده. همچنین API باید هدر Date رو با تاریخ و زمانی که پاسخ رو برگردونده، بذاره. این هدر کمک می‌کنه کلاینت‌ها طول عمر تازگی داده رو به‌عنوان اختلاف بین مقادیر Expires و Date محاسبه کنن. به عنوان مثال:

Date: Tue, 15 Nov 1994 08:12:31 GMT
Expires: Thu, 01 Dec 1994 16:00:00 GMT

⭕️ از هدرهای Cache-Control، Expires و Pragma میشه برای جلوگیری از کش استفاده کرد
اگه پاسخ API نباید کش بشه، باید هدر Cache-Control با مقادیر no-cache و no-store قرار بگیره. برای سازگاری با کش‌های قدیمی HTTP 1.0، هدرهای Pragma: no-cache و Expires: 0 هم باید اضافه بشن.


⭕️ کش کردن باید تشویق بشه
استفاده از no-cache باعث میشه هیچ کشی نتونه پاسخ‌های کش شده رو ارائه بده. APIهای REST نباید از این دستور استفاده کنن، مگر اینکه واقعاً ضروری باشه. به‌جای استفاده از `no-cache`، بهتره مقدار کمی برای max-age تنظیم بشه تا کلاینت‌ها بتونن حداقل برای یه مدت کوتاه از نسخه‌های کش شده استفاده کنن، بدون اینکه تازگی داده‌ها به طور قابل توجهی تحت تاثیر قرار بگیره.


⭕️ هدرهای کش‌کردن باید با پاسخ‌های 200 (“OK”) استفاده بشن
تو پاسخ‌های موفقیت‌آمیز GET و HEAD باید هدرهای کش‌کردن انقضا قرار داده بشن. هرچند روش POST هم قابل کش شدنه، اکثر کش‌ها اون رو به عنوان غیرقابل کش در نظر می‌گیرن. نیازی نیست این هدرها رو برای متدهای دیگه تنظیم کنی.

⭕️ هدرهای کش‌کردن می‌تونن به‌صورت اختیاری با پاسخ‌های 3xx و 4xx استفاده بشن
علاوه بر پاسخ‌های موفقیت‌آمیز 200 (“OK”)، می‌تونی تو پاسخ‌های 3xx و 4xx هم هدرهای کش‌کردن اضافه کنی. این کار که بهش کش‌کردن منفی میگن، کمک می‌کنه تا بار ریدایرکت‌ها و خطاها روی API کاهش پیدا کنه.

⭕️ از هدرهای HTTP سفارشی نباید برای تغییر رفتار متدهای HTTP استفاده بشه
هدرهای سفارشی رو میشه فقط برای اطلاع‌رسانی استفاده کرد. کلاینت‌ها و سرورها باید به شکلی پیاده‌سازی بشن که وقتی هدرهای سفارشی مورد انتظار رو پیدا نمی‌کنن، دچار خطا نشن.
اگه اطلاعاتی که توی هدر سفارشی قرار میدی برای تفسیر درست درخواست یا پاسخ ضروریه، بهتره اون اطلاعات رو توی بدنه درخواست یا پاسخ، یا توی URI استفاده کنی. از هدرهای سفارشی برای این کاربردها اجتناب کن.

@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل چهارم: Metadata Design

📍پارت: اول

#کتاب

‏💎 HTTP Headers 💎
توی درخواست و پاسخ‌های HTTP، یه سری اطلاعات متا (Metadata) از طریق هدرهای مختلف منتقل می‌شن. HTTP یه سری هدر استاندارد داره که بعضیاشون درباره منابع درخواست شده اطلاعات میدن. یه سری دیگه نشون میدن که چه نوع دیتایی توی پیام وجود داره. یه تعداد دیگه هم برای کنترل کش (Cache) استفاده میشن.

توی این متن کوتاه چندتا قانون مهم برای استفاده از هدرهای استاندارد HTTP توی طراحی REST API ها پیشنهاد شده.

⭕️ استفاده از Content-Type اجباریه
هدر Content-Type نوع داده‌ای که توی body درخواست یا پاسخ هست رو مشخص می‌کنه. مقدار این هدر یه رشته متنی با فرمت خاصه که بهش "Media Type" گفته میشه. سرور و کلاینت با استفاده از مقدار این هدر متوجه میشن چطوری باید بایت‌های موجود توی بدنه پیام رو پردازش کنن.

⭕️ استفاده از Content-Length توصیه میشه
هدر Content-Length اندازه بدنه پیام (entity-body) رو بر حسب بایت مشخص می‌کنه. این هدر توی پاسخ‌ها مهمه چون دو تا کار رو راحت می‌کنه:
اول اینکه کلاینت متوجه میشه که آیا تعداد بایت‌های درست رو خونده یا نه. دوم اینکه می‌تونه با یه درخواست HEAD بفهمه که اندازه بدنه پیام چقدره بدون اینکه نیاز باشه کل پیام رو دانلود کنه.

⭕️ استفاده از Last-Modified توی پاسخ‌ها توصیه میشه
هدر Last-Modified فقط توی پیام‌های پاسخ استفاده میشه. مقدار این هدر یه timestamp (زمان دقیق) هست که نشون میده آخرین باری که چیزی توی منابع تغییر کرده کی بوده. کلاینت و کش‌های میانی (Cache Intermediaries) می‌تونن از این هدر استفاده کنن تا بفهمن نسخه محلی‌شون از منبع به‌روز هست یا نه. این هدر باید همیشه توی پاسخ به درخواست‌های GET باشه.

⭕️ استفاده از ETag توی ریسپانس ها توصیه میشه
مقدار ETag یه رشته متنی غیرشفافه (opaque) که یه "نسخه" خاص از منبع (Resource) توی body ریسپانس رو شناسایی می‌کنه. body پیام HTTP شامل هدرها و body اصلی پیام میشه. مقدار ETag می‌تونه هر رشته‌ای باشه، به شرطی که وقتی نمایشی از منبع تغییر می‌کنه، مقدارش هم تغییر کنه. این هدر باید همیشه توی پاسخ به درخواست‌های GET ارسال بشه.

کلاینت‌ها می‌تونن مقدار هدر ETag رو ذخیره کنن تا توی درخواست‌های GET بعدی، ازش استفاده کنن؛ به عنوان مقدار هدر شرطی If-None-Match. اگه API تشخیص بده که ETag تغییر نکرده، می‌تونه از ارسال دوباره‌ی بدنه پیام صرف‌نظر کنه و در نتیجه توی زمان و پهنای باند صرفه‌جویی بشه.


@ninja_learn_ir

‏⭕️ store ها باید از درخواست‌های شرطی PUT پشتیبانی کنن
وقتی برای ذخیره یه منبع از متد PUT استفاده می‌کنه (چه برای ایجاد و چه به‌روزرسانی)، ممکنه برای API مشخص نباشه که درخواست کلاینت برای درج داده جدیده یا به‌روزرسانی. اینجاست که HTTP از طریق هدرها ابزار لازم رو در اختیار API میذاره تا این ابهام رو برطرف کنه. برای این کار، API باید به هدرهای شرطی کلاینت مثل If-Unmodified-Since یا If-Match متکی باشه تا منظور دقیق کلاینت رو بفهمه.

هدر If-Unmodified-Since از API می‌خواد که فقط در صورتی عملیات رو انجام بده که از زمانی که توی این هدر مشخص شده، وضعیت منبع تغییری نکرده باشه.

هدر If-Match یه مقدار ETag رو از کلاینت می‌گیره، که از پاسخ قبلی API ذخیره شده. اگه این مقدار ETag با وضعیت فعلی منبع مطابقت داشته باشه، API درخواست PUT رو انجام میده؛ وگرنه درخواست رو رد می‌کنه.

✅ مثال برای درخواست‌های شرطی PUT

فرض کنیم دو کلاینت (کلاینت#1 و کلاینت#2) از یه منبع ذخیره‌ی API با آدرس /objects برای اشتراک‌گذاری اطلاعات استفاده می‌کنن.

کلاینت#1 یه درخواست PUT می‌فرسته تا یه داده جدید توی مسیر /objects/2113 ذخیره کنه. این مسیر قبلاً توی API وجود نداشته، پس API این درخواست رو به‌عنوان "ایجاد" (Insert) تفسیر می‌کنه، منبع جدید رو می‌سازه و با کد 201 ("Created") پاسخ میده.

چند وقت بعد، کلاینت#2 درخواست PUT برای همون مسیر (/objects/2113) می‌فرسته. حالا API این مسیر رو به یه منبع موجود متصل می‌کنه. اما چون اطلاعات کافی نداره که بفهمه آیا کلاینت#2 می‌خواد داده‌ی قبلی رو به‌روزرسانی کنه یا نه، درخواست رو با کد 409 ("Conflict") رد می‌کنه و باید توی بدنه پاسخ هم یه توضیح از خطا بده.

@ninja_learn_ir

به پاس روز آزادی نرم افزار و همینطور رخ دادن حاشیه‌های اخیر در فضای مجازی، ما برگذار کنندگان دورهمی پارچ و ارائه‌دهندگان بیانیه‌ای را مرتبط با حریم خصوصی آماده کردیم.

https://meetup.parchlinux.com/statements/statement.html


@ParchLinux

اندرمن changed their name to Disabled