بعد از دوماه این پول ریکوست کوچک به یکی پروژه های 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

برنامه نویس عزیز
وقتی این کد رو نوشتم
فقط من و خدا میدونستیم که چطور کار میکنه
الان فقط خدا میدونه 😂🤝🏻
پس اگه به فکر بهینه سازی هستید
و شکست خوردید(احتمالا😂🤝🏻)
این شمارنده رو به عنوان هشدار
برای نفر بعدی افزایش بدید :

مجموع ساعت های تلف شده در اینجا = ۲۵۶🗿😂🤝🏻


📍تا حالا به همچین چیزی برخورد داشتی؟😂

📝 @𝕏Code_IR

🔰گزینه جدید "hugetlb_alloc_threads" در لینوکس ۶.۱۵ باعث می‌شود سیستم بهینه تر و سریع‌تر بوت شود.

🔹این گزینه تازه اضافه‌شده به شما اجازه می‌دهد تعداد رشته‌ها (threads) را که برای آماده کردن صفحات بزرگ (huge pages) استفاده می‌شوند، تنظیم کنید. با این کار، می‌توانید کارها را به‌صورت موازی انجام دهید و زمان بوت شدن سیستم را حسابی کم کنید. به‌طور پیش‌فرض، این گزینه از ۲۵٪ رشته‌های موجود در سخت‌افزار استفاده می‌کند. مهندسان شرکت Cyberus Tech گفته‌اند که در سرورهای بزرگ، این تغییر سرعت بوت را بین ۲.۷۵ تا ۴.۳ برابر بیشتر کرده است.

بهبود کار با صفحات بزرگ:
🔹با این گزینه جدید که به لینوکس اضافه شده، مدیریت صفحات بزرگ (huge pages) آسون‌تر شده.است صفحات بزرگ، تکه‌های بزرگ‌تری از حافظه هستند که سیستم ازشون استفاده می‌کنه. قبلاً یه مشکلی بود به اسم "تکه‌تکه شدن" یا همون fragmentation. یعنی حافظه به‌جای اینکه یه‌جا و منظم باشه، پخش و پراکنده می‌شد و استفاده ازش سخت‌تر بود. حالا با این گزینه، این مشکل کمتر پیش میاد و حافظه مرتب‌تر می‌مونه. یه خوبی دیگه‌ش اینه که استفاده از این روش، بار کمتری به سیستم میاره و هزینه پردازشش کمتره.

چرا این مهمه؟ چون الان حافظه‌های سیستم‌ها خیلی بزرگ شدن (مثلاً چند گیگابایت یا حتی بیشتر). وقتی حافظه زیاد باشه، صفحات کوچیک ۴ کیلوبایتی (که اندازه‌شون خیلی کمه) دیگه نمی‌تونن به‌خوبی کار کنن. این صفحات کوچیک باعث می‌شن سیستم بیشتر اذیت بشه و کارش کند بشه.

🔵 عنوان مقاله
ghw 0.15.0: A Go Hardware Discovery/Inspection Library

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

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

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

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

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

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