اگه شما هم از سنگین شدن، اکانت اجباری، لودینگ‌های رو مخ و مودی بودن ابزارهایی مثل Postman یا Insomnia خسته شدید، وقتشه سیستم تست اِی‌پی‌آی‌تون رو به Bruno مهاجرت بدید. برونو ی ابزار تست API کاملاً اوپن‌سورس و سبکه که چند ویژگی متمایزش واقعاً نجات‌دهنده‌ست:

• کاملاً آفلاین کار می‌کنه. هیچ کلاد، اکانت یا سینک اجباری نداره و تمام دیتای پروژه روی سیستم خودت می‌مونه.

• گیت‌فرندلی واقعی؛ درخواست‌ها رو به جای یه فایل جیسون بزرگ یا دیتابیس داخلی، با فرمت متنی ساده bru. ذخیره می‌کنه. این یعنی می‌تونی پوشه کالکشن رو مستقیم کنار سورس‌کد پروژه بذاری و با گیت خیلی تمیز کامیت و مرج کنی.

• افزونه‌ها و قابلیت‌های Environment کاملاً رایگان هست و بر خلاف خیلی از ابزارها، ویژگی‌های تیم‌ورک رو پشت Paywall قایم نکرده.

📦 github.com/usebruno/bruno


⌨• #DevEdu@Melfex

تو به بلندای اهدافت پرواز نمی‌کنی؛ تو به سطح هویت/سیستمت سقوط می‌کنی.

مشکل از اراده‌ نیست، مشکل از سیستم‌هاست. هر کاری که امروز انجام میدیم، ی رأی به سمت کسی هست که می‌خوایم بشیم. هر بار که ورزش می‌کنیم، داریم به خودمون ثابت می‌کنیم «من یه آدم فعال هستم».

از امروز به جای «دوست دارم کتاب بخونم» بگو «من کتابخونم». چون وقتی هویت عوض بشه، رفتارها برای همیشه قفل می‌شن.


📚• #FReading@Melfex | #عادت_های_اتمی

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

بررسی لاجیک و سینتکس پایتون هیچ ایراد و باگی رو نشون نمی‌داد و ریشه مشکل بر می‌گشت به ضعف توی درک استراکچرال پروتکل تلگرام و غفلت از ریکوئست‌های تکراری داخل وبهوک‌ها.

سناریو از این قراره که وقتی بات شما زیر ترافیک Heavy لود قرار می‌گیره، یا سرور تلگرام به هر دلیلی ( مثل نتورک تایم‌اوت یا کندی کوئری دیتابیس و.. ‌) ریسپانس 200 رو در زمان مقرر دریافت نمی‌کنه، مکانیزم Retry تلگرام فعال و همون آپدیت رو مجدد سمت سرور شما ارسال می‌کنه. اگه ساختار هندلر‌های شما Idempotent ( یعنی مقاوم در برابر ریکوئست‌های تکراری نباشه، خودمم امشب این اصطلاح رو یاد گرفتم، LOL ‌) نباشن، این ریکوئست‌های تکراری وارد بیزینس‌لاجیک می‌شه و همون فاجعه‌ی پراسس‌ مجدد رخ می‌ده.

برای فیکس کردن این کثیف کاری توسعه‌دهنده‌ی قبلی، دست بردن توی هندلر‌های اصلی بدترین انتخاب ممکن بود، درعوض، با استفاده از پترن‌های استاندارد، این چالش رو توی لایه‌ی بیس حل کردم؛ به‌جای استیت‌‌های متزلزل، از آپدیت‌ آیدی توی ردیس استفاده کردم و با ی میدلور عملیات چک کردن آپدیت آیدی رو انجام دادم که اگه آپدیت تکراری باشه، میدلور پروسه رو همون‌جا دراپ و صرفا ی ریسپانس فیک به تلگرام برگردونه تا استریم ارسال مجدد متوقف بشه.

همون‌طور که قبلا توی سرفصل‌های دوره پیش رو اشاره کردم؛ توسعه بات صرفا کال کردن ی متد نیست، درک عمیق رفتار پروتکل‌ها و هندل کردن اصولی همین Edge کیس‌ها هست که مرز ها رو مشخص می‌کنه ( اصلا هم تبلیغی واسه دوره نیست 😆 ‌).


⌨• #DevEdu@Melfex | #TelegramBot

اگه شما هم از اون دسته توسعه‌دهندگان هستید که برای هندل کردن چندتا تسک همزمان توی لینوکس، ترمینالتون پر از تب‌های باز و درهم‌ریخته می‌شه، یا از حفظ کردن شورت‌کات‌های عجیب‌وغریب و کانفیگ‌های بی‌پایانِ تیماکس خسته شدید، وقتشه سوییچ کنید روی Zellij.


زلیج یه ترمینال مالتی‌پلکسرِ مدرنه که با زبان راست نوشته شده و اومده تا همون کاری که تیماکس می‌کرد رو بدون دردسر و کانفیگ‌های اولیه براتون انجام بده. چندتا ویژگی خفنش که باعث شد سوئیچ کنم:

• اوت-آف-د-باکس کار می‌کنه؛ برخلاف ابزارهای قدیمی که باید ساعت‌ها وقت بذارید و فایل کانفیگ براشون بنویسید تا تازه قابل استفاده بشن، زلیج از همون ثانیه اول یه UI کاربردی و منوی راهنمای کلیدها رو پایین صفحه بهتون می‌ده.

• پنل‌های شناور و تب‌های هوشمند؛ خیلی راحت می‌تونید محیط ترمینالتون رو به هر شکلی که می‌خواید تقسیم‌بندی کنید، اون هم با چیدمان کاملاً ریسپانسیو.

• پرفورمنس بالا؛ به لطف راست به شدت سبکه و حتی زیر سنگین‌ترین لودها و پروسه‌های سیستم هم کم نمیاره و کرش نمی‌کنه.

📦 github.com/zellij-org/zellij


⌨• #DevEdu@Melfex

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


• محیط کارت باید "به اندازه کافی خوب" باشه، نه بی‌نقص.

• اگه کانفیگ کردنِ یه ابزار بیشتر از ارزشی که تو طول هفته برات خلق می‌کنه زمان می‌بره، درجا رهاش کن.

• یه محیط ساده و خسته‌کننده که توش روزی هزار خط کد بزنی، شرف داره به یه سیستم به شدت شخصی‌سازی شده که فقط به دردِ اسکرین‌شات گرفتن و Neofetch می‌خوره!


از ابزارها برای خلق کردن استفاده کنید، نه این‌که خود ابزارها بشن پروژه اصلی‌تون.


👤• #FromFarshad@Melfex

اگه شما هم موقع توسعه فرانت‌اَند یا مینی‌آپ‌های تلگرام، از ستاپ کردن سرورهای فیک، نوشتن ماک‌های طولانی توی کد یا قطعی اینترنت و بالا نیومدن اِی‌پِی‌آی‌های تست خسته شدید، وقتشه با Mockoon آشنا بشید.


ماکون یک ابزار فوق‌العاده سبک، اوپن‌سورس و کاملاً آفلاین برای شبیه‌سازی اِی‌پِی‌آی‌های REST هست که پروسه توسعه و تست رو به شدت سریع می‌کنه:

• راه‌اندازی در چند ثانیه: بدون نیاز به ساخت اکانت، کلاد یا کثیف‌کاری‌های مرسوم؛ خیلی راحت می‌تونید چندتا روتِ فیک با ریسپانس‌های جیسون دلخواه بسازید و به عنوان لوکال‌هاست به فرانت یا ابزار تستون متصلش کنید.

• شبیه‌سازی محیط واقعی: می‌تونید برای روت‌ها شرط بذارید؛ مثلاً اگه فلان هدر توی ریکوئست بود ریسپانس ۲۰۰ برگرده و اگه نبود ارور ۴۰۱ یا ۴۰۳ برگردونده بشه. حتی می‌تونید روی روت‌ها دِلِی داینامیک ست کنید تا رفتار نتورک تو شرایط واقعی و اینترنت ضعیف رو تست کنید.

• محیط کاملاً گیت‌فرندلی: تمام محیط‌ها و روت‌هایی که می‌سازید توی یک فایل جیسون ساده ذخیره می‌شن.

📦 github.com/mockoon/mockoon


⌨• #DevEdu@Melfex

امروز سعی داشتم ی سیستم واسه دیلیت کردن مسیج‌ها با ی دیلی مشخص پیاده سازی کنم. چیزی که توی وهله اول به فکرم رسید، استفاده ترکیبی از asyncio.sleep و asyncio.create_task بود، ولی خب خیلی مشکل داشت، واسه همین با چندتا سرچ به ماژول heapq رسیدم.


پایتون ماژولی تحت عنوان heapq داره که ساختمان داده‌ی Min-Heap رو پیاده سازی می‌کنه. به زبون ساده، داخل ی آرایه‌ی Min-Heap، سیستم این تضمین رو میده که کوچیک‌ترین عنصر ( توی معماری مد نظر من، نزدیک‌ترین تایم برای حذف کردن پیام ‌)  همیشه داخل ایندکس صفر وجود داره.

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

استفاده عملی از این ماژول رو می‌تونید توی آخرین کامیت این ریپو ببینید 👀؛

📦 github.com/Melfex/telegram-msg-bridge/blob/main/util/scheduler.py


⌨• #DevEdu@Melfex | #TelegramBot

​شاید یکی از بزرگترین تله‌هایی که ما برنامه‌نویس‌ها توش می‌افتیم، سندروم « Shiny Object Syndrome » باشه.


​روال کار این‌جوریه: داری روی ی پروژه با پایتون کار می‌کنی، یهو ی مقاله می‌خونی که "Rust آینده رو تسخیر می‌کنه!". پروژه رو نصفه ول می‌کنی و می‌ری سراغ سینتکس راست. هفته بعد ی ویدیو می‌بینی درباره قابلیت‌های جدید Next.js، دوباره شیفت می‌کنی سمت فرانت‌اند. ​نتیجه؟! ده‌ها پروژه نصفه‌کاره، ی گیت‌هاب پر از ریپوهای Hello World و دانشی که مثل ی اقیانوس به عمق یک سانتی‌متره.

​تکنولوژی‌ها و ابزارهای جدید فقط "ابزار" هستن، نه هدف نهایی. ارزش واقعی تو بازار کار و مهندسی نرم‌افزار، توانایی "حل مسئله" و "تمام کردنِ" پروژه‌هاست، نه دونستن سینتکس ده تا زبان مختلف.


​پیشنهاد همون قانون ٨٠/٢٠ هست؛ ی زبان یا فریم‌ورک رو به عنوان چکش اصلیت انتخاب کن و انقدر باهاش میخ بکوب تا استادش بشی. بقیه چیزها رو فقط در حد نیاز و برای رفع کنجکاوی بخون.

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



👤• #FromFarshad@Melfex

اگه شما هم از کندی Notion، آنلاین بودن اجباریش، یا پخش و پلا شدن نوت‌هاتون تو اپ‌های مختلف خسته شدید، ابسیدین دقیقاً همون چیزیه که بهش نیاز دارید:

​• دیتای تو، روی سیستم تو؛ ابسیدین کاملاً آفلاینه. هیچ کلاد یا دیتابیس قفل‌شده‌ای در کار نیست. کل نوت‌های شما صرفاً ی سری فایل متنی ساده با فرمت md. هستن که روی هارد خودتون ذخیره می‌شن.

​• گیت‌فرندلی تا مغز استخون؛ چون فایل‌ها متنی هستن، خیلی راحت می‌تونید پوشه نوت‌هاتون رو با Git مدیریت کنید، کامیت بزنید و روی گیت‌هاب پرایوتتون پوش کنید.

​• گراف ویو؛ ابسیدین بهتون اجازه می‌ده نوت‌هاتون رو به هم لینک بدید و در نهایت ی گراف بصری خفن از ارتباط ایده‌ها و چیزهایی که یاد گرفتید بهتون میده.

​📦 obsidian.md



​⌨• #DevEdu@Melfex

امروز یکی از بچه‌ها یه چالش به‌شدت آشنا رو مطرح کرد.


از لحاظ معماری و پروتکل تلگرام دقیقا چه اتفاقی داره می‌افته؟! وقتی کاربر آفلاینه و روی باتن‌ها یا لینک‌ها پشت سر هم کلیک می‌کنه، کلاینت تلگرام معمولاً این ریکوئست‌ها رو تا زمان برقراری اتصال نگه می‌داره. به محض وصل شدن اینترنت، این ریکوئست‌‌ها به‌صورت Burst پشت سر هم ارسال می‌شن و سرور تلگرام هم اون‌ها رو با سرعت زیاد، از طریق وبهوک یا پولینگ، به سمت بات شما هدایت می‌کنه.

اگه سیستم شما هیچ شیلدی برای این سناریو نداشته باشه، بات سعی می‌کنه به همه‌ی این ریکوئست‌ها پاسخ بده و بوم! خیلی سریع به Rate Limit تلگرام برخورد می‌کنید و ارور معروف FloodWait ظاهر می‌شه. نتیجه؟! بخشی از ارسال پیام‌های بات برای مدتی متوقف یا کند می‌شن و تجربه‌ی کاربری به‌هم می‌ریزه. حالا به قولا اگه پای یه یوزربات هم وسط باشه که عمدا این سناریو رو تکرار کنه، فشار واردشده روی سرور و بیزینس‌لاجیک می‌تونه واقعا دردسرساز بشه.

برای فیکس کردن اصولی این چالش، راه‌حل توی پیاده‌سازی یه Rate Limiter توی لایه‌ی ورودی خلاصه می‌شه. ما نباید اجازه بدیم ریکوئست‌های اسپم اصلا رنگِ بیزینس‌لاجیک، دیتابیس یا APIهای پروژه رو ببینن. خیلی‌ها سریع می‌رن سراغ ردیس، ولی برای پروژه‌ها و بات‌هایی که معماری Single-Node دارن، درگیر شدن با Network I/O و ردیس همیشه انتخاب بهینه‌ای نیست و می‌تونه فقط یه Overhead اضافه باشه.

من دقیقاً برای هندل کردن همین Edge Case، توی لایه‌ی بیس پروژه‌ی Telegram-MSG-Bridge یه میدلور آنتی‌اسپم نوشتم که فعلاً برای Message پیاده‌سازی شده، اما به‌راحتی می‌شه CallbackQuery رو هم بهش اضافه کرد. این میدلور بجای ردیس از ماژول فوق‌سریع cachebox و TTLCache استفاده می‌کنه. ( با تشکر از علی بابت این ماژول محشرش 🤍 )

سناریوی این میدلور به این شکله که فرکانس پیام‌های هر کاربر رو داخل یه Window ( بازه‌ی زمانی مشخص ) مانیتور می‌کنه. اگه کاربر از Threshold ( آستانه‌ی مجاز ) عبور کنه، برای مدت مشخصی بلاک می‌شه. نکته‌ی کلفت و پرفورمنسی داستان دقیقا اینجاست؛ ریکوئست‌های رگباری و پشت‌سرهم بعدی همون‌جا داخل میدلور به‌صورت سایلنت‌دراپ حذف می‌شن ( فقط با یه "return None" ساده، توی کسری از میلی‌ثانیه ) و اصلا به هنلدرهای اصلی بات، بیزینس‌لاجیک یا دیتابیس نمی‌رسن. در نتیجه هم فشار روی سرور کم می‌شه، هم از برخورد غیرضروری با Rate Limit تلگرام تا حد زیادی جلوگیری می‌کنید.


سورس‌کد این میدلور و استراکچرش رو می‌تونید از ریپوی زیر بخونید 👀؛

📦 github.com/Melfex/telegram-msg-bridge/blob/main/middleware/throttling.py



⌨• #DevEdu@Melfex | #TelegramBot

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

این کتاب دقیقا دست می‌ذاره روی همون نقطه کوری که باعث می‌شه کارها رو به تعویق بندازیم؛ جایی که ترس از کامل نبودن، ما رو فلج می‌کنه.

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


📚• #FReads@Melfex | #کمال‌گرای_مضطرب
©• @soufi_learn

اگه برای توسعه‌ی بکند یا هندل کردن وبهوک‌های بات تلگرامتون از فریم‌ورک‌های مدرنی مثل FastAPI استفاده می‌کنید، احتمالاً انتخاب همیشگی‌تون برای ران کردن سرور، Uvicorn بوده. یوویکورن فوق‌العاده‌ست؛ اما اگه بهتون بگم یه سرور ASGI دیگه هست که توی خیلی از سناریوها عملکرد بهتری از خودش نشون داده، چی؟!


وقتشه با Granian آشنا بشید.

گرانیان یه سرور HTTP برای پایتونه که از ASGI، WSGI و RSGI پشتیبانی می‌کنه و کور اصلیش با زبان Rust نوشته شده.

• پرفورمنس چشمگیر؛ توی خیلی از بنچمارک‌ها، گرانیان توی هندل کردن ریکوئست‌های همزمان عملکرد بهتری نسبت به Uvicorn و Gunicorn نشون داده. بخش‌های مربوط به نتورکینگ و مدیریت کانکشن‌ها توسط Rust انجام می‌شن و همین باعث می‌شه سربار اجرای این بخش‌ها کمتر باشه.

• پشتیبانی از HTTP/2 و WebSocket؛ از HTTP/2 و WebSocket به‌صورت نیتیو پشتیبانی می‌کنه و برای استفاده از این قابلیت‌ها معمولاً به کانفیگ پیچیده یا پکیج‌های اضافه نیازی ندارید.

• مهاجرت ساده؛ اگه پروژه‌تون بر پایه‌ی ASGI باشه، معمولاً کافیه به جای کامند Uvicorn، پروژه رو با Granian اجرا کنید؛ بدون اینکه لازم باشه لاجیک برنامه‌تون رو تغییر بدید.


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


📦 github.com/emmett-framework/granian


⌨• #DevEdu@Melfex

جمله‌ای معروف وجود داره که معمولا به اینشتین نسبت داده می‌شه: «اگه نمی‌تونی یه موضوع رو برای یه بچه‌ی ۶ ساله توضیح بدی، یعنی خودت هم هنوز اون رو کامل نفهمیدی»

این دقیقا همون ایده‌ایه که پشت «تکنیک فاینمن» قرار داره؛ توی دنیای برنامه‌نویسی هم نمونه‌ی معروفش «دیباگ با اردک پلاستیکی» هست.

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

جادو از لحظه‌ای شروع می‌شه که سعی می‌کنی مشکل پروژه‌ات رو بلندبلند برای یه نفر دیگه ( یا حتی یه شیء ) توضیح بدی. وقتی مجبور می‌شی کانتکست پیچیده‌ی کدت رو به کلمات ساده و منطقی ترجمه کنی، ناخودآگاه قدم‌به‌قدم لاجیک رو دوباره می‌سازی.

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


👤• #FromFarshad@Melfex

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

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

بعضی اتفاق‌ها، مسیر زندگی رو عوض می‌کنن؛ اما قرار نیست هویت ما رو تعریف کنن. انتخاب‌های امروز، بلندتر از اتفاق‌های دیروز حرف می‌زنن.


📚• #FReading@Melfex | #عادت_های_اتمی

همه‌ی ما از زخم‌هامون حرف می‌زنیم. از چیزهایی که شکستنمون، از آدم‌هایی که باعث شدن سخت‌تر اعتماد کنیم، از دردهایی که قبل از ورود بعضی آدم‌ها به زندگیمون داشتیم. و درست هم هست، هیچ‌کس نباید دردهای خودش رو تبدیل به درد آدم دیگه‌ای کنه.

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

شاید هیچ‌کس مجبور نباشه برای همیشه بمونه، شاید هیچ‌کس رو نمی‌شه با اجبار نگه داشت. اما بین «حق رفتن» و «نحوه‌ی رفتن» تفاوت بزرگی وجود داره.

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

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

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

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

نمی‌دونم اسمش دعاست یا نتیجه‌ی انتخاب‌هامون؛ اما امیدوارم هر کسی، روزی با اثری که توی زندگی دیگران گذاشته روبه‌رو بشه.

و در آخر:

این جهان کوه است و فعل ما ندا / سوی ما آید نداها را صدا.

•👤 #FromFarshad@Melfex

اگه تا حالا واسه یه API مکانیزم Retry نوشتید، احتمالا اولین چیزی که به ذهنتون رسیده این بوده که «اگه ریکوئست Fail شد، دوباره همون لحظه ارسالش کنم»

مشکل از همین‌جا شروع می‌شه. فرض کنید یه سرویس به خاطر فشار زیاد، موقتا از دسترس خارج شده. اگه هزاران کلاینت دقیقا همون لحظه دوباره Retry کنن، فشار بیشتری به همون سرویس وارد می‌کنن و عملا زمان بازیابیش طولانی‌تر می‌شه.

راه‌حل؟! مفهومی به اسم Exponential Backoff. به جای اینکه بعد از هر ارور فورا ریکوئست رو تکرار کنید، هر بار مدت بیشتری صبر می‌کنید؛ مثلا ۱ ثانیه، بعد ۲ ثانیه، بعد ۴ ثانیه، بعد ۸ ثانیه و..

اما هنوز یه مشکل باقی می‌مونه؛ اگه همه‌ی کلاینت‌ها دقیقاً با همین الگو Retry کنن، باز هم همزمان به سرور اتک می‌زنن.

اینجاست که مفهوم Jitter وارد بازی می‌شه. به هر Retry یه مقدار تأخیر رندوم اضافه می‌کنه تا ریکوئست‌‌ها بین کلاینت‌ها پخش بشن و همزمان به سرور نرسن.


⌨• #DevEdu@Melfex

اگه برای تست پروژه‌هاتون تا حالا مجبور شدید یه PostgreSQL، Redis یا RabbitMQ روی سیستم نصب کنید، احتمالا با این سناریو هم آشنا هستید: «روی سیستم من کار می‌کنه». یکی از دلایل اصلی این اتفاق، تفاوت محیط توسعه با محیطیه که تست‌ها داخلش اجرا می‌شن.

وقتشه با Testcontainers آشنا بشید. Testcontainers یه ماژول و کتابخونه اوپن‌سورسه که بهتون اجازه می‌ده موقع اجرای تست‌ها، سرویس‌های واقعی مثل PostgreSQL، Redis، RabbitMQ، Kafka و ده‌ها سرویس دیگه رو داخل داکر بالا بیارید؛ اون هم به‌صورت کاملا خودکار و موقت.

• تست روی سرویس واقعی: به جای ماک کردن دیتابیس یا Redis، تست‌هاتون مستقیما روی همون سرویسی اجرا می‌شن که قراره توی پروداکشن ازش استفاده کنید.

• ایزوله و قابل تکرار: هر بار اجرای تست، کانتینرهای جدید ساخته می‌شن و بعد از اتمام تست‌ها هم حذف می‌شن. در نتیجه هیچ دیتای باقی‌مونده یا تنظیمات قبلی روی نتیجه تست تأثیر نمی‌ذاره.

• سازگار با CI/CD: چون همه‌چیز خودکار بالا میاد، اجرای تست‌ها روی گیت‌هاب Actions یا هر سیستم CI دیگه‌ای هم دقیقا مثل سیستم توسعه‌دهنده هست.

📦 github.com/testcontainers


⌨• #DevEdu@Melfex

احتمالا اسم این کتاب رو بارها شنیدید؛ اما با توجه به چیزهایی که تا امروز درباره‌ش شنیده بودم، به نظرم چیزی که باعث شده این‌قدر ماندگار بشه، فقط محبوبیتش نیست، بلکه نگاه متفاوتش به مفهوم «زمان» و «زندگی» هست. برخلاف خیلی از کتاب‌های توسعه فردی که مدام از بهره‌وری بیشتر، مدیریت زمان و انجام دادن کارهای بیشتر حرف می‌زنن، این کتاب از یه زاویه کاملا متفاوت به موضوع نگاه می‌کنه.

طبق روال معمول، می‌تونید کوت و پاراگراف‌هایی که از نظر من ارزش بیشتری دارن رو با هشتگ #چهار_هزار_هفته دنبال کنید.

در آخر، اگه امکانش براتون فراهمه، نسخه اصلی و قانونی کتاب رو تهیه کنید. من هم نسخه قانونی کتاب رو خریدم.


📚• #FReading@Melfex | #چهار_هزار_هفته

این احساس که باید از زمان محدود خود نهایت استفاده را کنیم، ریشه در این ایده دارد که زمان چیزی است که باید از آن استفاده کنیم.

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

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

شاید مسئله، مدیریت بهتر زمان نباشه؛ بلکه پذیرفتن این واقعیته که زمان ما محدوده و دقیقا به همین خاطر، هر «آره» گفتن، یعنی به چیز دیگه‌ای «نه» گفتن.

به نظرم آرامش، از انجام دادنِ کارهای بیشتر نمیاد؛ از انتخاب کردنِ کارهای مهم‌تر میاد.


📚• #FReading@Melfex | #چهار_هزار_هفته

اگه با داکر کار می‌کنید، احتمالا با این سناریو آشنا هستین که: واسه‌ دیدن وضعیت کانتینرها، بررسی لاگ‌ها یا اجرای یه کامند ساده، مدام بین کامندها جابه‌جا می‌شین.

از طرفی ابزارهای گرافیکی مدیریت داکر همیشه برای هر سناریویی مناسب نیستن؛ مخصوصا وقتی روی سرورهای ریموت یا محیط‌های کم‌منبع کار می‌کنید و دنبال یک راه‌حل سریع و سبک هستید.


اینجاست که Lazydocker می‌تونه تجربه‌ی کار با داکر رو راحت‌تر کنه. لیزی‌داکر یه ابزار TUI هست که با گولنگ نوشته شده و محیط داکر و داکر Compose شما رو مستقیما داخل ترمینال به یه داشبورد تعاملی تبدیل می‌کنه.

• مدیریت در یک محیط واحد؛ می‌تونید وضعیت کانتینرها، ایمیج‌ها، والیوم‌ها و سرویس‌های داکر Compose رو بدون نیاز به اجرای چندین کامند مختلف مشاهده و مدیریت کنید.

• لاگ و Shell سریع؛ با چند حرکت ساده می‌تونید لاگ‌های لایو کانتینرها رو ببینید، وارد شل یک کانتینر بشید و کارتون رو انجام بدین.

• نمایش مصرف منابع؛ امکان مشاهده‌ی مصرف CPU و RAM کانتینرها به‌صورت گرافیکی داخل ترمینال وجود داره.


📦 github.com/jesseduffield/lazydocker


⌨• #DevEdu@Melfex

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

شاید بزرگ‌ترین فریب دنیای امروز این باشه که ارزش ما رو با میزان بهره‌وریمون گره زده. انگار هرچی کارهای بیشتری انجام بدیم، آدم موفق‌تر و خوشحال‌تری هستیم؛ اما واقعیت اینه که فهرست کارها هیچ‌وقت تموم نمی‌شن.

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


📚• #FReading@Melfex | #چهار_هزار_هفته