من همیشه برام سوال بود چرا برای بستن پراسس ها از کلمه kill استفاده کردن، یه کلمه ملایم تر نبود؟


@Linuxor

امروز آخرین روز بستهٔ نوروزیه و چون با جمعه مصادف شده، قیمتش شده این. (قیمت تو عکس، بدون مالیاته.)
به سامانتلی‌ها اطلاع بدید. ترجیحاً مصرف ماه آینده رو بخرید تا نهایت استفاده رو ببرید.

#موقت

بعد از دوماه این پول ریکوست کوچک به یکی پروژه های cncf هم اکسپت شد
https://github.com/ContainerSSH/examples/pull/11

🔶 نسخه ۱.۶ پکیچ احزار هویت موبایلی Vordia منتشر شد.

تغییرات :

- جایگزین جدول users ورودیا به جدول users فعلی ایجاد کردیم.
- تغییرات در کنترلر MobileOTPController و حذف پوشه دیتابیس

این روش باعث می شوند که جدول users که nullable است, جایگزین جدول فعلی شود که مجبور به تغییر دستی جدول users به nullable نشوید.

گیت هاب :

https://github.com/Rayiumir/Vordia

#لاراول

@TheRaymondDev

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۹۲۰

من رنگ خزان دارم و تو رنگ بهار
تا این دو یکی نشد نیامد گل و خار
این خار و گل ارچه شد مخالف دیدار
بر چشم خلاف بین بخند ای گلزار

#مولانا | گنجور
📍@iipoem

🔵 عنوان مقاله
Why Reimplement TypeScript's Compiler in Go?

🟢 خلاصه مقاله:

پرسش‌های بسیاری درباره دلیل انتقال کامپایلر TypeScript توسط مایکروسافت به زبان برنامه‌نویسی Go به‌جای زبان‌هایی نظیر Rust یا C# مطرح شده است. آندرس هیلزبرگ، معمار اصلی TypeScript، توضیح داد که انتخاب Go به دلیل سازگاری فنی آن با نیاز‌های کامپایلر TypeScript و به عملکرد بالا و سادگی‌ای که ارائه می‌دهد، صورت گرفته است. همچنین، کتابخانه استاندارد قوی و قابلیت برخورد با فرآیندهای همزمان در Go نقش مهمی در این تصمیم داشته‌اند.

🟣لینک مقاله:
https://golangweekly.com/link/166807/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔺جزییات و نکات پیاده‌سازی تکنیک‌های Debounce و Throttle توی ری‌اکت

- این دو از تکنیک‌های پرکاربرد بهینه‌سازی و افزایش سرعت و کیفیت هر برنامه‌ای هستن و به قول معروف برای Rate Limiting به کار میرن

- تکنیک Debounce تضمین می‌کنه یک قطعه کد زمانی اجرا بشه که یک مدت زمان مشخصی از آخرین تلاش برای اجرای اون گذشته باشه. مثلاً یک تابع ده بار پشت سر هم فراخونی میشه، اما می‌خوایم اجرای واقعی اون موقعی باشه که ۵ ثانیه از آخرین فراخونی گذشته باشه.
آشنایی با این تکنیک:
ditty.ir/577

- تکنیک Throttle هم تضمین می‌کنه که کدهای ما توی یک بازه زمانی مشخص فقط یک بار اجرا بشن. مثلاً می‌خوایم یک تابع توی هر بازه زمانی ۵ ثانیه فقط یک بار اجرا بشه. پیاده‌سازی این تکنیک:
ditty.ir/573

#react

چرا نباید لاجیک پروژه رو تو سریالایزرهای DRF پیاده‌سازی کنیم؟ 🚫

یه موضوع مهم هست که چرا نباید لاجیک پروژه‌مون رو تو سریالایزرها پیاده‌سازی کنیم؟ خیلی از افرادی که میشناسم متاسفانه اینکارو میکنن (پیاده سازی لاجیک توی سریالایزر ها) اگه شماهم حزو این دسته افراد هستید این پست براتون مناسبه

اول از همه سریالایزر تو DRF چیه؟

سریالایزرها تو DRF مسئول تبدیل داده‌ها بین فرمت‌های مختلف (مثل JSON و مدل‌های Django) هستن. کارشون اینه که داده‌ها رو بگیرن، اعتبارسنجی (validation) کنن و به شکل مناسب تحویل بدن. مثلاً یه مدل User رو به JSON تبدیل می‌کنن یا برعکس. تا اینجا همه‌چیز اوکیه، ولی مشکل از جایی شروع می‌شه که بخوایم لاجیک اصلی پروژه رو تو همین سریالایزرها پیاده سازی کنیم.

🚫 چرا این کار بده؟
بعضی‌ها عادت دارن تو متدهای سریالایزر (مثل to_representation یا validate) لاجیک‌های پیچیده بنویسن، مثلاً محاسبات، فیلتر کردن داده‌ها یا حتی آپدیت دیتابیس. اما این کارا چندتا مشکل بزرگ به وجود میاره

1⃣ نقض اصل Single Responsibility:
سریالایزرها برای تبدیل و اعتبارسنجی داده‌ها طراحی شدن، نه برای مدیریت لاجیک پروژه.
وقتی لاجیک رو اونجا می‌نویسین، کدتون از یه سریالایزر ساده تبدیل میشه به سریالایزر خیلی گنده که بعداً نگهداریش سخت می‌شه.

2⃣ کاهش Readability و Testability:
اگه لاجیک تو سریالایزر باشه، پیدا کردنش تو پروژه سخت‌تره و تست کردنش هم پیچیده می‌شه. مثلاً برای تست یه محاسبه، باید کل سریالایزر رو تست کنین، نه فقط اون لاجیک خاص.

3⃣ مشکلات Scalability:
تو پروژه‌های بزرگ، وقتی لاجیک‌ها تو سریالایزرها پخش بشن، دیگه نمی‌تونین به راحتی تغییرشون بدین یا جابه‌جاشون کنین. یه تغییر کوچیک تو لاجیک ممکنه کل API رو به هم بریزه.

4⃣ وابستگی بیش از حد:
سریالایزرها به مدل‌ها و داده‌ها وابسته‌ ان. اگه لاجیک پروژه رو اونجا بذارین، هر تغییری تو مدل‌ها یا ساختار داده‌ها می‌تونه لاجیک‌تون رو خراب کنه.

5⃣ سخت شدن دیباگ:
وقتی یه باگ پیش میاد، نمی‌دونین مشکل از تبدیل داده‌ست یا از لاجیک پروژه، چون همه‌چیز قاطی شده.

سخن اخر 🗣
پیاده‌سازی لاجیک پروژه تو سریالایزرهای DRF مثل اینه که بخوای با چاقو سوپ بخوری؛ می‌شه، ولی چرا؟! سریالایزرها برای تبدیل و اعتبارسنجی داده‌ها طراحی شدن، نه برای نگه داشتن لاجیک پیچیده. با انتقال لاجیک به مدل‌ها یا سرویس‌ها، کدتون تمیزتر، قابل‌نگهداری‌تر و حرفه‌ای‌تر می‌شه. دفعه بعد که خواستین تو سریالایزر لاجیک بنویسین، یه لحظه وایسید و بگین: اینجا جای این کارا نیست 😊

#️⃣ #backend #drf #django #api

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP