DevTwitter | توییت برنامه نویسی

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

توی این مقاله خیلی ساده flow اجرای یه کوئری رو توضیح دادم که MySQL دقیقا پشت صحنه چه فرآیندی رو انجام میده تا هم پرفورمنس رو حفظ کنه و هم نتیجه رو به کاربر برگردونه. میتونید مقاله رو توی لینک زیر بخونید:

https://farshadth.medium.com/how-mysql-works-behind-the-scenes-72746950cd65

@DevTwitter | <Farshad Tofighi/>

اگر با مدل‌های زبانی بزرگ (LLM) کار می‌کنید، حتماً با چالش‌هایی مثل هزینه‌های بالای API و تأخیر در پاسخ‌گویی (Latency) روبرو شده‌اید. این پروژه دقیقاً برای حل این مشکلات طراحی شده است.

این پروژه یک سیستم Semantic Caching است که به جای تطبیق دقیق کلمات (Exact Match)، معنای پرسش‌ها را درک می‌کند. به این ترتیب، اگر کاربری سوالی بپرسد که قبلاً مشابه آن با معنای یکسان پاسخ داده شده باشد، پاسخ مستقیماً از حافظه موقت (Cache) بازیابی می‌شود.

امکانات کلیدی:
- پشتیبانی از storage های مختلف: Redis، Elasticsearch، In-Memory
- پشتیبانی از embedding provider های متنوع: OpenAI، Azure، Ollama، ONNX (برای اجرای آفلاین)
- قابلیت multi-tenant برای جداسازی کش کاربران مختلف

https://github.com/Jamalianpour/semantic-llm-cache

@DevTwitter | <Mohammad/>

امروز این پروژه AI Prompt Optimization Platform اوپن‌سورس برای بهینه‌سازی پرامپت‌ه رو دیدم

کمک می‌کنه ورودی‌هایی که به مدل‌های هوش مصنوعی می‌دیم بهتر، دقیق‌تر و مؤثرتر باشن!

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

جذاب بنظر میرسه، وقت کنم دقیقتر بررسی کنم...

GitHub: https://github.com/AIDotNet/auto-prompt

@DevTwitter | <Amir Pournasserian/>

اگر داری AI Agent میسازی که با وب کار میکنه، این ابزار زندگیت رو راحتتر میکنه دادهها رو سریع، تمیز و کم هزینه به مدلت میرسه!

کسایی که agent هارو با دیتا وب توسعه میدن ، یک بار حداقل به به Firecrawl رسیدن ، و میدونن چه هزینه هایی داره !
حالا ابزار DeepCrawl که مخصوص توسعهدهنده های AI و builderهای AI Agentه. محتوای وبسایتها رو کراول میکنه و به شکل تمیز و بهینه استخراج میکنه: Markdown خوانا و بدون نویز درخت سلسله مراتبی لینکها و متادیتای هوشمند که LLMها راحت هضمش کنن

مزیت بزرگ نسبت به Firecrawl: کاملاً رایگان، خودت میتونی روی Cloudflare یا Vercel دیپلوی کنی (بدون وابستگی به سرویس پولی)، و استخراج لینکهاش بهتر و هوشمندتره برای agentها

این ابزار میتونه براتون
کاهش شدید هزینه توکن LLM (چون دادهها رو خلاصه و بهینه میکنه، نه خام و پرحجم)
جلوگیری از hallucination (توهم مدل) با دادن ورودیهای ساختارمند و دقیق
کارهای تکراری مثل scraping برای RAG، agentهای خودکار، یا ابزارهای تحقیقاتی

https://github.com/lumpinif/deepcrawl/

@DevTwitter | <POURYA/>

دیتابیسهای قدرتمند بساز بدون کد نوشتن! NocoDB ابزار اوپن سورس جایگزین Airtable

با رابط spreadsheet-like راحت، میتونی دیتابیس هارو بسازی ، ویوهای متنوع (گرید، کانبان، گالری، فرم، تقویم)، فیلتر/سورت پیشرفته، فرمولا، لینک/لوکآپ، کنترل دسترسی دقیق و ادغام با Slack، Discord، AWS S3 و کلی ابزار دیگه!

github.com/nocodb/nocodb‎

@DevTwitter | <POURYA/>

چیت شیت bash

@DevTwitter

احتمالا بعضی وقتا پیش اومده خاسته باشید یک اپ شخصی بسازید
مثلا یک برنامه واسه کار های روزانه یک بازی ساده (مثل دوز یا منچ) و ...
این سایت بهتون کمک میکنه بدون داشتن هیچ مهارت کد نویسی صرفا با نوشتن ایدتون اون برنامه رو بسازید
این بازی مار با نوشتن یه بازی مار باحال میخام ساخته شده

dapp.codexero.xyz‎

@DevTwitter | <A3MIR/>

رقیب جدید Nano Banana Pro معرفی شد؛ Qwen-Image-2512 رایگان تصاویر باکیفیت می‌سازد

تیم Qwen از علی‌بابا با معرفی مدل متن‌باز Qwen-Image-2512 تلاش کرده جایگزینی رایگان برای Nano Banana Pro گوگل ارائه دهد. این مدل تحت لایسنس Apache 2.0 عرضه شده و از طریق Qwen Chat ،Hugging Face و ModelScope در دسترس است. Qwen-Image-2512 با تمرکز بر واقع‌گرایی چهره، وفاداری بافت‌ها و دقت در تولید متن داخل تصویر، توانسته در تست‌های AI Arena به قدرتمندترین مدل متن‌باز تصویرساز تبدیل شود.

@DevTwitter | <Digiato/>

تا حالا لیست بزرگی داخل React داشتی که اسکرولش لگ بزنه؟

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

فرض کنید یک لیست با ۵۰۰ آیتم داریم. آیا از نظر فنی می‌توانیم همه‌ی ۵۰۰ آیتم را هم‌زمان داخل DOM رندر کنیم؟ بله، امکان‌پذیر است. اما اگر از زاویه‌ی performance به موضوع نگاه کنیم، بهترین انتخاب نیست.

مسئله‌ی اصلی اینجا این نیست که React توان انجام این کار را ندارد؛ مسئله‌ی این است که:
1. DOM بیش از حد بزرگ می‌شود
2. هزینه‌ی layout و paint به‌شدت افزایش پیدا می‌کند
3. تعامل کاربر (scroll، click، input) کند و ناپایدار می‌شود

در این نقطه معمولاً راه‌حل‌هایی مثل Virtual Scroll / List Virtualization مطرح می‌شوند؛ راه‌حلی که به‌جای رندر همه‌ی آیتم‌ها، فقط المنت‌های داخل viewport را وارد DOM می‌کند. در چنین سناریوهایی، Virtual Scroll یکی از موثرترین راه‌حل‌هاست. ایده‌ی Virtual Scroll ساده است:
همه‌ی داده‌ها وجود دارند, اما همه‌ی آن‌ها هم‌زمان داخل DOM نیستند.

به‌جای رندر ۵۰۰ آیتم، فقط آیتم‌هایی که در viewport دیده می‌شوند (به‌همراه مقدار کمی قبل و بعد از آن) وارد DOM می‌شوند. با اسکرول کاربر، المنت‌های قدیمی حذف و المنت‌های جدید جایگزین می‌شوند.

اگر شما راه‌حل بهتری برای این سناریو دارید، حتماً برام بنویسید
منبع خوب برای آشنایی بیشتر با Virtual Scrolling:
https://medium.com/@sreekanthsreekanth970/virtual-scrolling-2797d722c6e2

@DevTwitter | <Mohammad Khaleghi/>

دنبال جایگزین MinIO میگردید؟ شاید SeaweedFS بهترین گزینه باشه براتون

تغییرات اخیر در دنیای object storage — مخصوصاً فاصله گرفتن MinIO از مدل کاملاً متن‌باز — باعث شده خیلی از تیم‌ها دوباره به استراتژی ذخیره‌سازی بلندمدتشون فکر کنن.
توی این مقاله سعی کردم توضیح بدم چرا این مهاجرت برای خیلی‌ها ضروری شده، چند تا از گزینه‌های متن‌باز و سازگار با S3 رو با هم مقایسه کنم، و در نهایت یک مسیر عملی و قابل استفاده در محیط‌های production برای مهاجرت از MinIO به SeaweedFS نشون بدم. در طول مسیر هم به نقاط قوت و ضعف هر گزینه از نظر بلوغ پروژه، کارایی، پیچیدگی راه‌اندازی و مصرف منابع پرداختم و در نهایت به SeaweedFS رسیدم؛ یه گزینه متعادل، سبک و قابل اتکا برای تیم‌هایی که دنبال یه راه‌حل متن‌باز بدون دردسر و سربار اضافی هستن:
https://itnext.io/minio-alternative-seaweedfs-41fe42c3f7be?gi=446129b0e09d

@DevTwitter | <mahdi mallaki/>

یکی از کاربردهای چت باتها برای خیلی کمپانی ها مثل e-commerce ها، پشتیبانی/customer support هست. این که یک چت بات ۲۴ ساعته جواب سوالها را بده. فکر کردم یک پروژه کاربردی و آموزشی درست کنم که هم واقعا بتونید استفاده کنید و هم ایده بگیرید.
این شد که یک ورژن خوب و قابل استفاده ساختم با کمک دستیارم Claude code. اسمش را هم Chirp گذاشتم. یک سیستم چت‌بات کامل که قابلیت RAG داره، یعنی می‌تونید دیتای خودتون رو بهش بدید تا بر اساس اونا جواب بده.

- اصلاً Chirp چیه؟ یه ویجت چت هوش مصنوعی که می‌تونید تو هر وب‌سایتی امبد (Embed) کنید. مثل اینترکام یا دریفت، ولی با این تفاوت که کنترلش دست خودتونه و هزینه‌اش هم بسیار کم میشه اگه با مدلهای اپن سورس اجراش کنید. ویدیوی دمو.

- تکنولوژی‌های استفاده شده: • بک‌اِند: FastAPI • فرانت‌اِند: React + TypeScript • از Qdrant برای vector DB •و OpenAI هم که مغزش • راحت با Docker میاد بالا.

- چند تا نکته فنی:
۱. من RAG ساده پیاده کردم. ولی بسته به کاربرد میتونید (و بهتره) روش های پیشرفته تر استفاده کنید. نکته مهم: حتماً از SSE برای استریم کردن جواب‌ها استفاده کنید تا کاربر منتظر نمونه.

۲. معماری در دنیای واقعی: • استفاده از Shadow DOM برای ویجت حیاتی هست تا استایل‌های سایت مقصد روی چت‌بات اثر نذاره. • مدیریت خطا (Error Handling) مقدار قابل توجهی از کد رو تشکیل داد. توی محیط واقعی همه‌چی ممکنه خراب بشه: تایم‌اوت شبکه، محدودیت نرخ OpenAI و...

۳. جادوی داکر: با Multi-stage build حجم ایمیج نهایی رو خیلی پایین آوردم، سعی کردم زیر ۵۰۰ مگابایت نگه دارم. فقط با یک docker-compose up کل سیستم (بک‌اِند، فرانت و دیتابیس) بالا میاد.

- چرا این پروژه رو ساختم؟ هدفم فقط ساخت یک ابزار نبود، می‌خواستم نشون بدم چطور RAG رو از سطح تئوری به تولید (Production) برسونید. کدها شاید همه‌جا تمیز نباشن، ولی "واقعی" هستن.
نکته خیلی مهم: توی فولدر docs تمام جزییات پیاده سازی از plan و API و PRD همه اونجاست. و اینکه ۱۳ تا branch درست کردم که هر مرحله را کامل نشون میده. حتما ببینید.

و اما نکته اخلاقی: دیدن ویدیوهای آموزشی رو تموم کنید و شروع کنید به ساختن. پروژه بسازید، خرابش کنید و دوباره درستش کنید. این بهترین راه یادگیریه.

کد کامل پروژه رو می‌تونید اینجا ببینید، استار بدید و روش تمرین کنید:
https://github.com/mallahyari/customer-support-agent

@DevTwitter | <Mehdi Allahyari/>

كتابخانه tab رو ریلیز کردیم که خيلي كاربرديه! کاری می‌کنه توی ترمینال وقتی Tab می‌زنی، دستورها خودشون کامل شن.
اگه CLI می‌نویسی، شدیداً به کارت میاد

لینک گیت‌هابش اینجاست
https://github.com/bombshell-dev/tab

@DevTwitter | <AmirSakhravi/>

سه مفهوم SLA، SLO و SLI

تا حالا شده گیج بشید که فرق بین SLA و SLO چیه؟یا اصلا SLI کجای بازی قرار می‌گیره؟برای اینکه بتونیم یک برنامه ریزی درستی داشته باشیم و یک معیار درست برای ارزیابی وضعیت سیستممون داشته باشیم باید با این مفاهیم آشنا بشیم

معیار اول SLI (چی رو می‌سنجیم؟)

این همون دماسنج ماست ️ معیاری که نشون میده الان وضعیت واقعی سیستم چطوره. یه جورایی یعنی چند چندیم با خودمون و یک تصویری از وضعیت سیستم داشته باشیم
مثلا چند تا ارور 500 داشتیم؟ یا چقدر طول کشید صفحه لود بشه؟
دنبال معیار کمی از سیستممون باید باشیم
مهم تریناش ایناست تقریبا

(Availability/Uptime)
Latency
Error Rate
Throughput
..

معیار دوم SLO (هدفمون چیه؟):
این “خط قرمزیه” که تیم فنی برای خودش می‌کشه.
مثالا “باید ۹۹٪ ریکوئست‌ها زیر ۲۰۰ میلی‌ثانیه جواب داده بشن”. اگه از این رد بشیم، یعنی باید دست نگه داریم و سیستم رو فیکس کنیم.

معیار سوم SLA (قولی که به مشتری دادیم):
این دیگه شوخی‌بردار نیست؛ قراردادیه که بستیم.

حالا نکته ی مهم ماجرا چیه ؟

همیشه SLO (هدف داخلی تیممون ) رو سخت‌گیرانه‌تر از SLA (تعهد به مشتری) باید در نظر بگیریم
چرا؟
چون فاصله بین این دو تا میشه “حاشیه امن” . اگه تیممون هدف داخلی رو از دست داد، هنوز وقت هست قبل از اینکه کار به جریمه دادن به مشتری بکشه، قضیه رو جمع کرد!

بودجه خطا (Error Budget) چیه؟
با مثال بخوایم دربارش صحبت بکنیم .مثلا اگه SLO (هدف داخلی خودمون) درباره ی uptime سیستم ۹۹.۹٪ باشه . ما در ماه حدود ۴۳ دقیقه اجازه داریم سیستم پایین باشه
این ۴۳ دقیقه میشه بودجه ی خطای ما که میتونیم تو این تایم تغییراتی که میخوایم رو اعمال کنیم.

@DevTwitter | <Hossein Samadi/>

بیشتر پروژه‌های PHP نه به خاطر سرعت،
بلکه به خاطر امنیت ضعیف نابود می‌شن
اگر PHP کار می‌کنی، این ۵ اصل امنیتی رو حتماً باید بلد باشی:
1- SQL Injection Prevention
هیچ‌وقت Query خام ننویس؛ همیشه از Prepared Statements استفاده کن.
2- XSS Protection
داده‌ای که از کاربر میاد، همیشه باید Escape بشه.
3- Password Hashing
رمز عبور = password_hash()
نه md5، نه sha1
4- CSRF Tokens
هر فرم بدون CSRF یعنی دعوت رسمی از هکرها.
5- Input Validation & Sanitization
به کاربر اعتماد نکن؛ حتی اگه خودتی!
اگه این مفاهیم رو درست پیاده‌سازی کنی،
رفتن به Laravel برات خیلی ساده‌تر می‌شه

امنیت در PHP انتخابی نیست، اجباریه.
اگه می‌خوای بک‌اند واقعی بنویسی، باید از همین حالا اصول امنیت رو جدی بگیری.
پست‌های بعدی: پیاده‌سازی عملی + مثال واقعی.

@DevTwitter | <Seyed taha Aghamir/>

این mu پلاگین تقریبا به طور دقیقی مسیر تم های وردپرس رو تغییر میده
ممنون میشم یه تست بزنید جهت فیدبک

https://github.com/HamxaBoustani/wandtech-theme-root-manager

@DevTwitter | <Hamxa/>

این ریپو خیلی خفنه، grouped-simd-hashtable یه پیاده‌سازی هش‌تیبل فوق‌سریع با استفاده از SIMD و ایده‌ی grouped probing ـه.
تمرکز اصلیش روی کاهش cache miss و بالا بردن throughput ـه، مخصوصاً برای workloadهای سنگین.
حتماً یه نگاه بندازید:
https://github.com/Cranot/grouped-simd-hashtable

@DevTwitter | <کروکس؛ روایت شخصی/>

این سایت یک نقشهٔ راهِ مختصر و مفید برایِ یادگیریِ خودآموزِ ریاضیات ارائه داده. همهٔ کتاب‌هایِ پیشنهادی رو خودش خونده. در آخر بر حسبِ شاخهٔ مورد علاقه، مسیرهایِ مختلفی برایِ یادگیری پیشنهاد داده. محتوایِ تمیزی بود. بوکمارک کنید سرِ فرصت بخونید.
https://donkuri.github.io/learn-mathematics/

@DevTwitter | <Ayub/>

استفاده از Middleware در Microsoft Agent Framework (MAF) دقیقاً همون چیزیه که ایجنت‌هات رو Production-ready می‌کنه.

توی Agent 14 نشون دادم چطور می‌شه بدون دست زدن به منطق اصلی ایجنت:
- قبل/بعد از tool call لاگ گرفت
- خروجی یک فانکشن رو override کرد (مثلاً Weather)
- چطور PII رو از ورودی و خروجی sanitize کرد
- چطور guardrail ساده برای محتوای خطرناک گذاشت
- حتی human-in-the-loop approval اضافه کرد

https://github.com/pournasserian/agent-framework-sample

خیلی شبیه middleware های دات نت هست. همون تفکر، ولی این‌بار برای AI Agentها

@DevTwitter | <Amir Pournasserian/>

هفته گذشته تصمیم گرفتم یک ابزار Code Review مبتنی بر Ollama بسازم که به‌صورت خودکار کدها را تحلیل کند.

اول با ChatGPT و سرویس‌های Cloud امتحان کردم — نتیجه رضایت‌بخش نبود.

بعد از ۵ بار طراحی مجدد با bolt.new، بالاخره به خروجی قابل قبولی رسیدم.
https://github.com/mahmoudbarzegar/code-review-ai

به نظرم:

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

ابزارها کامل نیستند، اما ما باید یاد بگیریم:
- چطور سوال درست بپرسیم.
- چطور prompt بهینه بنویسیم .
- چطور خروجی را ارزیابی و اصلاح کنیم.

نقش برنامه‌نویس حذف نشده — بلکه تخصصی‌تر و استراتژیک‌تر شده است.

@DevTwitter | <Mahmoud Barzegar/>