Mahi in Tech

ما میدونیم (یا نمی دونیم) که LLM ها بدون حافظه ان. یعنی توی هر پیام جدید سیستم باید کل تاریخچه گفتگو رو از اول برای مدل بخونه تا بتونه یه کلمه جدید تولید کنه ( واسه همینه که توی چتای طولانی، کندتر عمل میکنه و به مراتب هرینه اش بالاتر میره). قبلا میومدن و برای حل این مشکل از تکنیکی به اسم Prompt Caching استفاده میکردن، یعنی محاسبات قبلی ( KV Cache) رو ذخیره میکردن تا هزینه کمتر شه. ولی خب این کش فقط روی همون مدلی کار میکرد که پیداش کرده بود! 👀 اینا رو گفتم تا برسیم به اینکه انویدیا جدیدا چه کرده- یه متد طراحی کرده که میشه KV Cache رو مستقیما به یه مدل دیگه منتقل کرد! مرحله Prefill (همونجایی که کل تاریخچه گفتگو رو از اول میخونه) رو کلا دور می زنه و حافظه قبلی رو با فرمت مختص به خودش ترجمه میکنه. ولی چطوری؟( ممنون~ شما چطوری؟) -نگاشت خطی: فهمیدن که حتی بین مدلای متفاوت لایه شباهت ساختاری وجود داره -ترکیب لایه ها: برای هر لایه در مدل مقصد، 8 لایه برتر از مدل مبدا رو ترکیب میکنن تا شباهت به 79 درصد برسه. -دستکاری RoPE: چرخش های موقعیتی توکن ها رو موقتا برمیدارن، تبدیل ریاضی رو انجام میدن و بعد چرخش مدل جدید رو روش پیاده میکنن. نتایج چطور بوده؟ • ۲.۷ تا ۲۵ برابر سریع‌تر از پردازش مجدد متن! • حفظ ۷۳ تا ۹۸ درصد از دقت مدل مقصد. این مدل فعلا روی مدل های هم خانواده تست شده ولی فعلا یه بن بست بزرگ رو شکسته توی انتقال حافظه.

کپشنی ندارم، فقط تعداد استار‌ها رو ببینید =)) چهار تا فایل‌ Markdown vs کرنل لینوکس

اگه این روزها از Coding Agent‌ها استفاده می‌کنید (که احتمالاً همه‌مون دیگه داریم می‌کنیم :) )، احتمالا اسم Graphify به گوش‌تون خورده؛ ابزاری که به ایجنت وصل می‌شه، کدبیس شما رو به یک گراف متنی تبدیل می‌کنه و با دادن دید کلی به ایجنت، باعث کاهش مصرف توکن می‌شه. با پیشنهاد یکی از دوستان، مدتی هست به جای Graphify رفتم سراغ Codebase Memory MCP، و خب حداقل از نظر من تجربه به‌مراتب بهتری بوده. علاوه‌بر این‌که پروژه رو خیلی سریع‌تر ایندکس می‌کنه، مصرف توکن‌ش حتی از Graphify هم کمتره و به لطف MCP بودنش، خیلی تمیز و بی‌دردسر با ایجنت همگام می‌شه. تازه UI گراف‌ش هم خوشگل‌تره 😅 https://github.com/DeusData/codebase-memory-mcp

سرویس جدید گوگل برای طراحی UI مبتنی‌بر AI https://stitch.withgoogle.com/ نسبت به این‌که تازه راه افتاده خروجی‌های قابل توجهی میده 👨‍💻

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

یک نمونه‌ی خیلی ساده با CSharp که به کمک ‌OpenCV یک واترمارک مشخص و محدود رو توی تصویر پیدا می‌کنه، و با یک overlay دیگه جایگزین‌ش می‌کنه. github.com/MahdiyarGHD/WatermarkSwapper

داشتم ریپوهای گیت‌هابم رو یه نگاهی می‌انداختم، که چشمم به این ریپو خورد که مال حدود ۴ ۵ سال پیشه 😄 اون زمان تازه بک‌اند و PHP کار می‌کردم و AI ای هم در کار نبود :)) اوج خلاف‌ام کپی کردن از stackoverflow بود و چقدر زود گذشت. عمرا فکر می‌کردم ۴ ۵ سال دیگه توی چنین بدبختی و وضعیتی دست و پا بزنیم. github.com/MahdiyarGHD/KnightTour این هم حدودا مربوط به یک سال بعدشه: github.com/MahdiyarGHD/ToigBot دیتابیس‌ش فایل جیسونه 😁 و چقدر هم خوب کار می‌کرد. حالا هی بیا سیستم دیزاین کن 🙂‍↔️

ظاهرا Nvidia دسترسی به API بیش از ۷۰ مدل زبانی (مثل Mistral ،Gemma ،DeepSeek ،Kimi و Qwen) رو به‌صورت رایگان و بدون محدودیت خاصی فراهم کرده: build.nvidia.com/models

ظاهرا Nvidia دسترسی به API بیش از ۷۰ مدل زبانی (مثل Mistral ،Gemma ،DeepSeek ،Kimi و Qwen) رو به‌صورت رایگان و بدون محدودیت خاصی فراهم کرده: build.nvidia.com/models

این مطلب رو سال ها پیش گذاشته بودم در مورد این که چطور با پروژه های سنگین برنامه نویسی، خودمون رو به چالش بکشیم و چیز جدید یاد بگیریم. این مطلب قسمت دوم هم داره که لینکش رو در ادامه می‌گذارم. مورد علاقه مورد web browser متنیه. توضیحاتشو میتونید بخونید. https://austinhenley.com/blog/morechallengingprojects.html

توی سیستم‌های توزیع‌شده، هماهنگ نگه داشتن داده‌ها بین نودهای مختلف همیشه یکی از چالش‌های مهم و البته جذاب بوده. مخصوصاً وقتی چند نود به‌صورت هم‌زمان امکان Write داشته باشن و انتظار بره داده‌ها در نهایت روی همه نودها به وضعیت یکسانی برسن. یکی از رویکردهای قابل استفاده برای حل این مسئله، پیاده‌سازی Replication در لایه Application و بر بستر Event Streaming هست. در چنین معماری‌ای، تغییرات داده به‌جای اینکه مستقیماً از طریق مکانیزم‌های Replication دیتابیس منتقل بشن، به‌صورت Event منتشر و توسط سایر نودها مصرف می‌شن. برای این کار، می‌شه تغییرات دیتابیس شامل Add, Update و Soft Delete رو در لحظه Commit شناسایی کرد و از طریق الگوی Outbox برای انتشار آماده کرد. از سمت مقابل نیز Consumerهایی مسئول دریافت این رویدادها، اعمال مکانیزم‌های Idempotency و مدیریت خطاها از طریق DLQ خواهند بود تا تغییرات در مقصد به‌صورت قابل اعتماد اعمال بشن. در سناریوهای Multi-Master این‌چنینی، اولین چالش جدی معمولاً مدیریت Conflict داده‌هاست. زمانی که چند نود به‌طور مستقل روی یک رکورد تغییر ایجاد می‌کنن، باید مکانیزمی برای تعیین نسخه نهایی وجود داشته باشه. یکی از ساده‌ترین و در عین حال رایج‌ترین راهکارها، Last-Write-Wins (LWW) هست که در آن آخرین تغییر ثبت‌شده بر اساس زمان وقوع، به‌عنوان نسخه معتبر در نظر گرفته می‌شه. چالش مهم بعدی به شناسه‌های داده برمی‌گرده. در معماری‌هایی که چند نود به‌صورت مستقل داده تولید می‌کنن، استفاده از Primary Keyهای Auto-Increment معمولاً به تداخل منجر می‌شه. به همین دلیل استفاده از شناسه‌های Globally Unique اهمیت پیدا می‌کنه. GUID v7 یکی از گزینه‌های جذاب برای این سناریوهاست؛ چون علاوه بر یکتا بودن، به دلیل داشتن Timestamp داخلی، قابلیت Sort شدن داره و نسبت به GUIDهای سنتی رفتار بهتری از نظر ایندکس‌گذاری ارائه می‌کنه. ممکنه این سؤال مطرح بشه که چرا به‌جای چنین رویکردی از Replication نیتیو دیتابیس استفاده نشه؟ پاسخ اینه که در بسیاری از موارد، مسئله صرفاً انتقال داده بین چند دیتابیس مشابه نیست. گاهی نیاز داریم کانفلیکت‌ها در لایه Application مدیریت بشن، داده‌ها قبل از اعمال شدن دچار Transformation بشن یا حتی نودها از تکنولوژی‌های ذخیره‌سازی متفاوتی استفاده کنن. مزیت دیگه‌ی این رویکرد، وجود یک Log پایدار از تمام تغییرات سیستم هست. با استفاده از Kafka، رویدادها برای مدت مشخصی نگهداری می‌شن و هر Consumer می‌تونه مستقل از سایر اجزا وضعیت خودش رو بازیابی کنه. در نتیجه اگر نودی برای مدت طولانی از دسترس خارج بشه، پس از بازگشت می‌تونه از آخرین Offset پردازش‌شده ادامه بده و خودش رو با وضعیت فعلی سیستم همگام کنه. از طرفی، Eventهایی که برای Replication تولید می‌شن معمولاً کاربردشون به همینجا محدود نمی‌مونه. همون جریان رویداد می‌تونه توسط سرویس‌های دیگه برای Cache Invalidation، Analytics، Audit Logging، Search Indexing یا انواع پردازش‌های جانبی مصرف بشه. به همین دلیل، مکانیزم همگام‌سازی عملاً به بخشی از زیرساخت Event-Driven کل سیستم تبدیل می‌شه. پیاده‌سازی چنین معماری‌ای قطعاً بدون هزینه نیست و پذیرش Eventual Consistency هم چالش‌های خودش رو به همراه داره. اما در ازای این پیچیدگی، سیستمی به دست میاد که نودها می‌تونن مستقل عمل کنن، کانفلیکت‌ها به‌صورت کنترل‌شده مدیریت بشن و همگام‌سازی داده‌ها بدون وابستگی مستقیم به نوع دیتابیس یا ساختار استقرار انجام بشه.

الان رو فستلی خیلی از سایتها رو باز کردن، سایفون از فستلی هم میتونه برای اتصال استفاده کنه، کافیه تو اپ شیرو خورشید برای اندروید یا se7en pro برای ویندوز (یا کانفیگهای mitm+psiphon)یک دامنه سفید پشت فستلی قرار بدید: github.githubassets.com docs.github.com…

الان رو فستلی خیلی از سایتها رو باز کردن، سایفون از فستلی هم میتونه برای اتصال استفاده کنه، کافیه تو اپ شیرو خورشید برای اندروید یا se7en pro برای ویندوز (یا کانفیگهای mitm+psiphon)یک دامنه سفید پشت فستلی قرار بدید: github.githubassets.com docs.github.com www.fastly.com pypi.org repo.almalinux.org ... برای ip هم هر دامنه ای که قرار دادید ازش ping بگیرید و ip که بهتون دادو قرار بدید، دقت کنید ip و sni باید مچ هم باشن یعنی هر sni که قرار دادید ip همونو باید وارد کنید. هم به دلیل محدودیت های سایفون و هم به دلیل تعداد بالای کاربران سرعت متوسطی بهتون میده این روش.

ویندسکرایب روی TCP 443 متصل می‌شه ظاهرا، امتحان کنید اگر نشد پروتکل‌/لوکیشن‌های دیگه رو تست کنید

thefeed-android-v0.14.9-arm64-v8a.apk

من که کارم رو دارم انجام میدم دیگه، کی گفت برم دانشگاه توی این خراب‌شده :/ سوال استاد برای ثبت حضور و در نتیجه حذف نشدن: «دست‌آوردهای جمهوری اسلامی رو در ۴۷ سال اخیر لیست کنید.» 🤣🤣

🛡مهم: اگر این نسخه رو نصب کنید دیگه دردسر ستاپ کردن MITM و... ندارید! این نسخه حدودا یک ساعت پیش توسط برنامه‌نویس شیر و خورشید آپدیت شد و به راحتی می‌تونید طبق این آموزش بهش وصل بشید: 1- وارد اپلیکیشن شیر و خورشید(آخرین نسخه که امروز منتشر شده) می‌شید 2- وارد بخش Options میشید از نوار بالا 3- روی More Options کلیک میکنید 4- گزینه‌ی Connection Protocol رو قرار میدید روی CDN Fronting 5- میرید و عادی کانکت میشید و به راحتی وصل میشه!