| AmirHossein |

لاراگرام ۸ پکیج جدید رو در اختیار توسعه دهنده قرار میده، و این ۸ پکیج لاراگرام رو بی رقیب و از هر چیزی بی‌نیاز میکنن بریم که یکی یکی این هارو معرفی کنیم Laraproto: همونطور که قبلا توضیح داده بودم، لاراگرام توان توسعه user bot هارو خواهد داشت، و این توانایی به لطف Laraproto هست. لاراپروتو یک پیاده سازی کامل از MTProto هست که به شما اجازه ساخت یوزربات هارو میده. تنها محدودیت لاراپروتو این هست که نیازمند پکیج Surge هست تا بتونه به صورت non-block کار بکنه، و این یعنی استفاده از اون تنها روی سرورها ممکن هست، و مناسب هاست‌های اشتراکی نیست! Luna: لونا برای توسعه TMAها، با React.js یا Vue.js هست. شامل دو پکیج هست، یکی برای بک-اند و یکی برای‌فرانت-اند. لونا یک رپر از Inertia برای لاراگرام هست، و به سادگی می‌تونید فرانت خودتون رو توسعه بدید و بدون درگیر شدن با API و... اون رو به بک‌اند رباتتون وصل کنید. Citadel: سیتادل وظیفه مدیریت JWT و احرازهویت APIهارو بر عهده داره، و این مناسب زمانی هست که می‌خواید TMA توسعه بدید، یا یک API برای رباتتون داشته باشید. Sentinel: به لطف HTTP Kernel و Router که جدیدا به لاراگرام اضافه شدن، شما عملا می‌تونید یک وب‌سایت با لاراگرام بسازید. سنتینل یک پنل مانیتورینگ تحت وب هست، کاربران، کش‌ها‌، تسک‌ها، کوئری‌ها و هرچیزی که سمت ربات شما اتفاق میوفته رو مانیتور می‌کنه. Seeker: سیکر برای کار با ElasticSearch هست، و خیلی ساده مدل‌های الوکوئنت شمارو برای الاستیک‌سرچ آماده می‌کنه Armada: آرمادا هم مسئول داکرایز کردن پروژه لاراگرامی شما هست. Brain: برین برای علاقه‌مندان به وایب‌کدینگ هست، برای AI Agentها Tools و Skills فراهم می‌کنه تا کنترل و فهم بیشتری نسبت به پروژه شما داشته باشن. یک MCP Server برای خوندن لاگ‌ها‌ بررسی کوئری‌ها و ساختار دیتابیس، سرچ در داکیومنت لاراگرام و... AI: این پکیج یک SDK برای کار با مدل‌های هوش مصنوعی هست، خیلی ساده می‌تونید به یک مدل هوش‌مصنوعی مثل جمینای یا جی‌پی‌تی یا ... وصل بشید و با متدهای ساده، گفت و گو، تصویر و صدا و.. ایجاد کنید و در نهایت به پکیج Surge که یک سوپرشارژر برای LaraGram هست درایورهای FrankenPHP و RoudRunner اضافه خواهد شد مجدد خوشحال میشم به ریپوزیتوری پروژه استار بدید😁❤️ https://github.com/laraXgram/LaraGram

ورژن 4 فریم‌ورک LaraGram قرار بوداین ماه منتشر بشه، ولی خب بخاطر اتفاقات توسعه‌ش عقب افتاد، و احتمالا توی یکی دو ماه آینده منتشر میشه خیلی واسش هیجان دارم و خب می‌خوام یک توضیحاتی بدم که قراره چی داشته باشیم این ورژن بزرگترین آپدیت رو دریافت می‌کنه، و قرار نیست دیگه چنین آپدیتی داشته باشیم، بعد از منتشر شدن ورژن 4 به جرئت هیچ لایبرری یا فریم‌ورکی توی کامیونیتی تلگرام نیست که با LaraGram رقابت کنه.😁 در ادامه با این تغییرات آشنا میشیم اولین فیچری که می‌خوام بهش اشاره کنم، Router و HTTP Kernel هست. لاراگرام عملا توان توسعه صفحات وب و REST API رو خواهد داشت. این سیستم شامل روتر قدرمند مشابه لاراول، میدلورها، کنترلرها، و هر چیز دیگه برای توسعه صفحات و APIها هست میشه. با این سیستم می‌تونیم TMAها و APIهای خارجی، مثلا برای درگاه پرداخت، یا پنل‌های مدیریتی رو هندل کنیم. در ادامه لاراگرام به سیستم کانورسیشن مجهز میشه این یعنی دیگه لازم نیست درگیر ارسال سوال، مدیریت استپ‌ها، و دریافت پاسخ کاربر بشیم، کافیه سوالاتتون رو به لاراگرام بدید، و وظیفه مدیریت استپ‌ها و پرسش سوالات از کاربر و دریافت پاسخ و اعتبارسنجیش رو به عهده لاراگرام بذارید. فیچر بعدی آنتی‌فلود هوشمند هست، که به طور هوشمند و خودکار بدون هندل دستی حواسش به ربات شما هست که به محدودیت های فلود بر نخوره به لطف این سیستم آنتی فلود، سیستم برادکست فیچر بعدی لاراگرام هست، دیگه لزومی به پیاده‌سازی سرویس پیام همگانی ندارید، فقط متن پیام رو به لاراگرام بدید تا به کاربر هاتون ارسال کنه، نیازی به هیچ گونه اسلیپ یا دیلی بین ارسال‌ها نیست و خود لاراگرام درصورت نیاز این کار رو می‌کنه. قابلیت بعدی سیستم Acting هست، و با اون می‌تونید خودتون رو جای یک کاربر دیگه بذارید، به طوری که انگار دارید با هویت یک شخص دیگه به ربات پیام میدید. مورد بعدی پروکسی هست، که می‌تونیم خیلی ساده یک پروکسی برای ربات ست کنیم. قابلیت FTP، SFTP و... به Filesystem اضافه میشه، و می‌تونید فایل‌های خارج از سرور رو هم مدیریت کنید. و در نهایت قابلیت تعریف لیسنر با اتریبیوت‌های PHP به سیستم آپدیت لیسنر اضافه شده، گه تعریف آپدیت لیسنرها رو به شدت ساده میکمه، و یک کد مرتب و تمیز خواهیم داشت قابلیت‌هایی مثل استریم‌رپرها و JsonSchma هم اضافه شده، که کمتر برای استفاده مستقیم هستن و در ادامه توضیح داده میشن. این موارد صرفا مواردی بودن که مستقیما به هسته لاراگرام اضافه شدن، و فقط چند درصد از آپدیت انقلابی لاراگرام هستن سایر فیچرها تحت پکیج‌های جداگانه اضافه میشن که توی پیام بعدی معرفی میشن. تا اینجا اگر خوشتون اومد، خوشحال میشم به ریپوزیتوری پروژه استار بدید❤️ https://github.com/laraXgram/LaraGram

یکی از مشکلاتی که این آپدیت داشت، این بود که برای نصب حتما نیاز به VPN داشت تا بتونه سایت تلگرام رو اسکرپ کنه ولی توی ورژن جدید با کمک گیت‌هاب اکشنز این اسکرپ روی گیت‌هاب انجام میشه و دیتای مورد نیاز رو از گیت‌هاب می‌گیره. و تا زمانی که گیت‌هاب باز هست نصبش نیازی به VPN نداره همچنین اگر نیازی به متدها و آپدیت‌های تلگرام داشتید می‌تونید از این لینک دریافت کنید: https://raw.githubusercontent.com/laraXgram/telegram-api-data/main/telegram-api.json .

🙂‍↔️

بریم یک توضیح کامل در این مورد با جمع‌بندی نظرات دوستانی که همراهی کردند داشته باشیم. اول از همه مشکلی که اینجا داریم به Cache Stampede (هجوم همزمان درخواست‌ها به دیتابیس بعد از منقضی شدن کش) معروف هست. یعنی تا وقتی کش وجود داره همه چیز خوبه، ولی به محض اینکه TTL تموم بشه، ممکنه ۱۰۰۰ درخواست همزمان Cache Miss بخورن و به جای یک Query، هزار Query به دیتابیس ارسال بشه. این سناریو معمولا زمانی خطرناک‌تر میشه که با یک Hot Key (کلیدی که تعداد بسیار زیادی درخواست به آن ارسال می‌شود) طرف باشیم. خیلی از راهکارها برای کلیدهای معمولی جواب میدن، اما برای Hot Keyها باید بیشتر مراقب بود چون یک اشتباه کوچک می‌تونه فشار زیادی روی دیتابیس ایجاد کنه. اولین راه‌حلی که معمولا به ذهن می‌رسه استفاده از Mutex یا Distributed Lock (قفل سراسری بین چند سرور) هست. یعنی وقتی Cache Miss اتفاق افتاد فقط اولین درخواست اجازه داشته باشه از دیتابیس بخونه و کش رو مجدد پر کنه. بقیه درخواست‌ها یا منتظر بمونن یا چند لحظه بعد دوباره کش رو بررسی کنن. البته Lock به تنهایی مشکل رو کامل حل نمی‌کنه. فشار روی دیتابیس کم میشه اما ممکنه Latency کاربران افزایش پیدا کنه. همچنین در پیاده‌سازی Lock باید به Failure Scenarioها هم فکر کرد. مثلا اگر سرویسی که Lock رو گرفته قبل از آزاد کردنش Crash کنه چه اتفاقی میفته؟ به همین دلیل معمولا Lockها خودشون TTL دارن تا سیستم در وضعیت Deadlock باقی نمونه. برای همین معمولا از Request Coalescing (تجمیع درخواست‌های مشابه) هم استفاده میشه. یعنی اگر ۱۰۰۰ درخواست همزمان برای یک داده وارد بشن، فقط یک درخواست واقعا به دیتابیس بره و بقیه منتظر نتیجه همون درخواست بمونن. اگر تازگی داده خیلی حیاتی نباشه، Stale-While-Revalidate گزینه جذاب‌تریه. در این حالت وقتی TTL تموم میشه، همچنان آخرین مقدار کش به کاربر برگردونده میشه و همزمان یک فرآیند در پس‌زمینه کش رو Refresh می‌کنه. اینطوری کاربر افزایش Latency رو حس نمی‌کنه. راهکار دیگه Cache Warming یا Background Refresh هست. یعنی اصلا منتظر اولین درخواست نمی‌مونیم. قبل از اینکه TTL تموم بشه یک Job در پس‌زمینه کش رو مجدد می‌سازه و جایگزین می‌کنه. در این حالت عملا Cache Miss برای کاربران رخ نمیده. برای کاهش احتمال بروز این مشکل هم میشه از Randomized TTL یا Jitter استفاده کرد. مثلا به جای اینکه همه کلیدها دقیقا ۱۰ دقیقه عمر داشته باشن، بعضی ۹ دقیقه و بعضی ۱۱ دقیقه عمر داشته باشن. این کار باعث میشه تعداد زیادی کلید دقیقا در یک لحظه منقضی نشن. حالا یک سوال مهم اینجاست که اصلا چرا TTL داریم؟ معمولا TTL زمانی استفاده میشه که: - داده ممکنه در دیتابیس تغییر کنه و نمی‌خوایم کش برای همیشه مقدار قدیمی نگه داره. - نمی‌دونیم چه زمانی داده تغییر می‌کنه. - می‌خوایم در نهایت کش خودش به‌روز بشه حتی اگر فراموش کنیم آن را Invalidate کنیم. اما اگر کنترل کامل روی مسیر آپدیت داده داشته باشیم، شاید اصلا نیازی به TTL نباشه. مثلاً میشه از معماری Event-Driven استفاده کرد. یعنی هر زمان داده در دیتابیس تغییر کرد، یک Event منتشر بشه و همون لحظه کش هم آپدیت یا حذف بشه. در این مدل عملا کش همیشه تازه است و دیگر منتظر منقضی شدن TTL نمی‌مونیم. البته این راهکار هم هزینه خودش رو داره. اگر Event از دست بره یا آپدیت کش با خطا مواجه بشه، ممکنه دیتابیس و کش با هم ناسازگار بشن. به همین دلیل خیلی از سیستم‌ها حتی در کنار Event-Driven بودن، یک TTL بلندمدت هم قرار میدن تا اگر جایی مشکلی پیش اومد، کش نهایتا خودش اصلاح بشه. اگر حجم داده خیلی زیاد نباشه میشه یک Hybrid Cache (کش چندلایه) هم داشت. مثلا: - حافظه خود اپلیکیشن به عنوان L1 Cache - و Redis به عنوان L2 Cache در این حالت بسیاری از درخواست‌ها حتی به Redis هم نمی‌رسن و مستقیما از حافظه سرویس پاسخ می‌گیرن. البته در این مدل باید به موضوع Cache Invalidation (هماهنگ نگه داشتن چند کش مختلف) هم فکر کرد. در نهایت انتخاب راهکار تا حد زیادی به Trade-off بین Consistency (تازگی و صحت داده) و Availability (سرعت پاسخگویی و در دسترس بودن سرویس) بستگی داره. اگر داده بسیار حساس باشه شاید ترجیح بدیم درخواست منتظر Refresh شدن کش بمونه، اما اگر تجربه کاربری مهم‌تر باشه معمولا برگردوندن داده‌ای که چند ثانیه یا چند دقیقه از عمرش گذشته قابل قبوله. به همین دلیل معمولا یک راهکار واحد وجود نداره و در سیستم‌های پرترافیک از ترکیبی از همه راهکارها استفاده میشه.

بیاید بیکار نباشیم، هر از گاهی یک سوال چالشی میفرستم که یکم ذهنمون درگیر بشه و یاد بگیریم. از آسون شروع کنیم😁 فرض کنید یک API داریم که داده‌هاش رو از Redis می‌خونه. داده مورد نظر هر ۱۰ دقیقه یک بار Expire میشه و بعد از Expire شدن، اولین درخواست میره دیتابیس رو می‌خونه و مجدد مقدار رو داخل Redis ذخیره می‌کنه. حالا این API حدود ۱۰۰۰ درخواست در ثانیه داره. سوال اینجاست: اگر دقیقاً در لحظه‌ای که Cache Expire شده، ۱۰۰۰ درخواست همزمان به API برسه، چه اتفاقی میفته؟ چه مشکلاتی ممکنه برای Redis، Application و Database ایجاد بشه؟ ایا ۱۰۰۰ درخواست باید به دیتابیس کوئری بزنن؟ شما برای جلوگیری از این مشکل چه راهکارهایی پیشنهاد میدید؟ در پاسخ فقط اسم بردن از راهکارها کافی نیست؛ در مورد نحوه پیاده‌سازی، مزایا، معایب و Trade-off هر راهکار هم توضیح بدید.

خوشبختانه برگشتیم سر کار، و این روزا یکم شلوغ شدم در اولین فرصت که سرم خلوت بشه LaraGram 4 رو تکمیل می‌کنم و ریلیز می‌کنم این ورژن شامل 9 پکیج جدید(تا این لحظه) هست که قراره انقلابی باشه(طبق معمول هیچکس اهمیت نمیده) تا اون موقع لطفا از سیمولا حمایت کنید، به گیت‌هابش استار بدید و به بقیه معرفی کنید خیلی خیلی خوشحالم میشم🤝 https://github.com/laraXgram/Simula .

بعد این همه بدبختی داریم بر می‌گردیم سر خونه اول

📈 Confirmed: Live metrics show a partial restoration to internet connectivity in #Iran on day 88, after 2093 hours of near-total isolation from international networks, the longest nationwide internet shutdown in modern history. It is unclear if the restoration will be sustained.

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

یکی دیگه از کارای احمقانه ای که توی نبود اینترنت انجام دادم این Lexer/Parser Generator بود که توسعه ش دادم تجربه جالبی نبود ولی خب بهتر از هیچ کار نکردن بود

در انتظار حمایت‌های بیشتر از simula هستم...

یادش بخیر یه زمانی نگران بودیم AI شغلمونو ازمون بگیره... @DevTwitter

واقعا زیباست

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