گرونه

@DevTwitter

این ریپو یه نمونه‌ی کاربردی از ساخت MCP Server هست که بهتون نشون میده چطور می‌تونید MCP سرور خودتون رو بسازید

پروژه با Node.js و Hono ساخته شده تا بهتر مفهوم ارتباط بین مدل هوش مصنوعی و سرور MCP رو درک کنید.

با این ریپو می‌تونید یاد بگیرید چطور:

یه MCP Server سبک و سریع بسازید

ابزارها رو به مدل‌های هوش مصنوعی متصل کنید

داده‌های داینامیک (مثل نرخ ارز) رو در پاسخ مدل استفاده کنید

https://github.com/hshoja/Currency-Exchange-MCP-Service

@DevTwitter | <Hamid/>

معرفی ابزار فوق العاده WrenAI برای BI کارها.

به کمک WrenAI میتونید داشبوردهایی از جنس BI یا نمودارهای خیلی زیبا طراحی کنيد.
یعنی شما فقط درخواست تون رو از طریق متن می‌نویسید و توی خروجی متن به نمودار و داشبورد های خیلی زیبا و کاربردی تبدیل میکنه.
این ابزار open source و توی گیتهاب میتونید دانلود کنید یعنی یه جورایی GenBI هست که ابتدا متن رو از کاربر دریافت میکنه، متن به کوئری SQL تبدیل میشه و خروجی کوئری در قالب نمودار و چارت درمیاد.
https://github.com/Canner/WrenAI

@DevTwitter | <Ali Nazarizadeh/>

دیروز یکی از دوست‌هام ازم پرسید:

«پروتوکل HTTPS از رمزگذاری نامتقارن استفاده می‌کنه، درسته؟»

و جوابش هم آره بود، هم نه.

آره، چون در ابتدای ارتباط از رمزگذاری نامتقارن (Public/Private Key) برای تبادل امن کلید استفاده می‌شه.
نه، چون بعد از اون، خودِ داده‌ها با رمزگذاری متقارن منتقل می‌شن — سریع‌تر و سبک‌تر.

حالا بریم سراغ پشت‌صحنه‌ی اتفاقات

وقتی مرورگر و سرور تصمیم می‌گیرن “امن” حرف بزنن، چیزی به نام TLS Handshake انجام می‌شه — همون مغز اصلی HTTPS:

1- مرورگر (Client) می‌گه:
«سلام! من می‌خوام ارتباط امن برقرار کنم، اینم لیست الگوریتم‌های رمزنگاری‌ای که بلدم.»

2- سرور جواب می‌ده:
«باشه، این یکی رو انتخاب می‌کنم.» و پارامترهای امنیتی خودش رو هم مشخص می‌کنه.

3- حالا نوبت اعتمادسازی‌ست:
سرور گواهی دیجیتال (Certificate) خودش رو می‌فرسته. این گواهی شامل کلید عمومی سرور (Public Key) و اطلاعات هویتی دامنه است.
مرورگر این گواهی رو با استفاده از زنجیره‌ی اعتماد به Certificate Authority (CA) بررسی می‌کنه.
اگر معتبر بود، مرورگر حالا کلید عمومی سرور رو در اختیار داره و مطمئنه که طرف مقابل واقعی‌ست.

4- اگر الگوریتم انتخاب‌شده نیاز به تبادل پارامترهای اضافی برای تولید کلید داشته باشه (مثلاً در روش Diffie-Hellman)، سرور این اطلاعات رو در مرحله‌ی Server Key Exchange می‌فرسته.
در بعضی روش‌ها این مرحله وجود نداره، چون همون گواهی کافی‌ست.

5- سرور می‌گه: «من دیگه آماده‌ام.» (Server Hello Done)

6- مرورگر یک pre-master secret تولید می‌کنه، اون رو با کلید عمومی سرور رمز می‌کنه و می‌فرسته. فقط سرور می‌تونه با کلید خصوصی خودش اون رو باز کنه.

7- مرورگر اعلام می‌کنه از اینجا به بعد همه‌چیز رمزنگاری می‌شه (Change Cipher Spec).

8- مرورگر یک پیام تست رمزگذاری‌شده می‌فرسته (Finished) تا مطمئن بشن از کلید یکسان استفاده می‌کنن.

9- سرور هم به حالت رمزنگاری سوئیچ می‌کنه.

سرور پیام تست خودش رو می‌فرسته. حالا دیگه ارتباط کاملاً امنه — همه‌چیز با رمزگذاری متقارن ادامه پیدا می‌کنه.


@DevTwitter | <Abolfazl Bakhtiari/>

#کدبوک

راهنمایی جامع برای مدیریت و تأمین امنیت سیستم‌های لینوکسی:
- آموزش اصول مدیریت کاربران، دسترسی‌ها و پیکربندی سیستم
- پیاده‌سازی سیاست‌های امنیتی، فایروال و مانیتورینگ
- آشنایی با ابزارهای امنیتی پیشرفته در لینوکس
- مناسب برای مدیران سیستم و توسعه‌دهنده‌هایی که به امنیت سرور اهمیت می‌دن


* فایل PDF این کتاب رو میتونید از کانال DevBooks که لینکش توی بیو هست دانلود کنید.

@DevTwitter

یه مقاله‌ی خوب در مورد بهینه‌سازی PHP برای پروداکشن

جزئیات خوبی رو توش گفته که با رعایت کردنش می‌تونید سرعت بیشتری رو با PHP تجربه کنید

https://mateusguimaraes.com/posts/optimizing-php-applications-for-performance

@DevTwitter | <Milad Niroee/>

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

https://www.youtube.com/watch?v=hwhCmbSBeQQ

@DevTwitter | <Navid Kashani/>

زباله‌ای به نام وردپرس

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

ولی سؤال مهم‌تر اینه:
آیا “درست‌ترین راه فنی”، همیشه “درست‌ترین تصمیم محصول” هم هست؟

وردپرس واقعاً برای معماری تمیز ساخته نشده
در مقیاس بالا دردسر درست می‌کنه
و اکوسیستم پلاگین‌هاش مثل یه لگوی نصفه‌کاره‌ست که هرلحظه ممکنه فروبپاشه
اما اگه از دید محصول نگاه کنی، ماجرا فرق می‌کنه
تصمیم‌گیری در محصول یعنی درک محدودیت‌ها، انتخاب بهینه، و تحویل دادن چیزی که کار می‌کنه
نه صرفاً چیزی که شیک توسعه پیدا کرده
وردپرس شاید از نظر فنی زباله باشه
ولی برای خیلی از بیزینس‌ها، همون زباله تبدیل به ماشین درآمدزایی شده
چون سریع لانچ می‌شه
با سئو آشناست
برای تیم کوچک قابل استفاده‌ست
و محتوامحور طراحی شده
یعنی برای خیلی از MVPها، انتخاب بدی نیست
اتفاقاً خیلی وقتا، انتخاب به‌شدت مناسبیه
نه چون بهترینه
بلکه چون متناسب با منابع و نیاز و فاز رشده
مشکل جایی شروع میشه که وردپرس رو ابزار نهایی فرض می‌کنن
یا برعکس
از اول دنبال ساختن یه سیستم کاملن سفارشی می‌رن، در حالی‌که هنوز هیچ‌کس نمی‌دونه محصولشون جواب می‌ده یا نه
تناقض جالب اینجاست
سازمان‌ها برای ERP و CRM، قالب آماده می‌خرن
اما برای یه سایت معرفی ساده، می‌رن سراغ تیم توسعه و ده‌ها جلسه‌ی فنی
وردپرس زباله نیست
ابزاریه که اگه درست استفاده نشه، به زباله تبدیل میشه
و اگه درست استفاده بشه، می‌تونه راه رو برای یه بیزینس واقعی باز کنه
نه برای دمو دادن به تیم فنی
انتخاب ابزار، نشونه‌ی فهم ما از مرحله‌ایه که توش هستیم
نه نشونه‌ی میزان تسلط‌مون روی syntax

@DevTwitter | <Reza Mehrniya/>

تیم Hugging Face یه قابلیت خیلی خوب معرفی کرده به اسم Streaming Datasets. یعنی دیگه لازم نیست کل دیتاست‌هاتون رو دانلود کنید تا آموزش مدل‌هاتون شروع بشه! فقط با یه خط کد فعالش می‌کنید:

dataset = load_dataset("HuggingFaceM4/FineVisionMax", split="train", streaming=True)

چند تا نکته‌ی جذابش که احتمالاً خوشتون میاد:

- دیگه خبری از «هارد پر شد»، «دانلود بی‌پایان» یا خطای ۴۲۹ نیست.

- سرعت شروع کار خیلی بالا رفته: تا ۱۰ برابر سریع‌تر در resolve فایل‌ها، ۲ برابر نمونه در ثانیه، و حداقل خطا حتی با ۲۵۶ workers همزمان.

- زیرساختشون کلی بهینه شده: cache اشتراکی برای فایل‌ها، pre-fetch برای Parquet، و بافر قابل تنظیم برای بهینه‌سازی I/O
- حتی از SSD لوکال هم تو بعضی تست‌ها سریع‌تر بوده!

اگه دارید روی مدل‌های بزرگ یا دیتاست‌های چندترابایتی کار می‌کنید، حتماً این قابلیت رو تست کنید. احتمالاً کلی تو زمان و هزینه‌ی زیرساختتون صرفه‌جویی می‌کنه.
Link:
https://huggingface.co/blog/streaming-datasets

@DevTwitter | <Mehdi Allahyari/>

پس این eSIM ما چی شد؟

کسایی که ثبت‌نام کردن همینجوری تو لیست موندن

@DevTwitter

️ Cache Components in Next.js 16:

این مکانیزم باعث میشه تا data fetching از فرآیند prerendering کنار گذاشته بشه و fetch شدن data بصورت dynamic انجام بشه و همیشه data ی تازه fetch بشه به جای اینکه از data ی cache شده استفاده بشه. البته به علت وجود مکانیزم PPR یا همون Partial Prerendering، قسمت های static کامپوننت ها همواره prerender میشن.
برای فعال سازی این flag باید cacheComponents رو در فایل config بصورت true قرار بدید و برای غیر فعال کردن موردی این مکانیزم هم میتونید از یه directive به نام "use cache" در بالای کامپوننت ها استفاده کنید.

@DevTwitter | <Amir Hossein Saberi/>

به به Fedora Linux 43 رسماً منتشر شد!
نسخه‌ی جدید فدورا با کلی فناوری تازه و به‌روز حالا برای دانلود آماده است

https://fedoramagazine.org/announcing-fedora-linux-43

@DevTwitter | <MehrdadLinux/>

یک پروژه جالب آموزشی (شامل backend و frontend) برای کسایی که دوست دارند یک سیستم multi agent با استفاده از Google ADK بسازند که از طریق پروتکل A2A به یک ایجنت دیگه مثل ایجنت بانک وصل میشه. این پروژه توی یک چلنجی که گوگل برگزار کرده بود، برنده شد (که باید تو ۴ ساعت یک اپ درست میکردند).

Github: https://github.com/bhancockio/ai_agent_bake_off_ep_2

ویدیوی یوتیوبش را هم که کامل این پروژه را توضیح میده میتونید اینجا کامل ببینید:
https://youtube.com/watch?v=g8s6HZZLQsk

و ویدیوی خود چلنج گوگل هم که چندین تیم شرکت کردند و جالبه را اینجا ببینید:
https://youtube.com/watch?v=0CQxF56MKWo

@DevTwitter | <Mehdi Allahyari/>

معادل دستور du در لینوکس که با راست نوشته شده: dust

توضیحات کامل در گیت هاب:
http://github.com/bootandy/dust


@DevTwitter | <Mohammad/>

الان ۸ ساله با کمک ۴۰ نفر دیگه لیستی از APIهای ساخت ایران رو نگهداری می‌کنم. دنبال اینم که لیستی بسازم از MCP Server مربوط به سرویس‌های داخلی.
https://github.com/Hameds/APIs-made-in-Iran

@DevTwitter | <Hamed/>

#لاس

کامپیوتر بهانه است؛
خط به خط به دنبال تو می‌گردم.

@DevTwitter | <Masih/>

اون اوایل که زیاد می گفتن ویندوزت لینوکسه؟

توی این سال‌ها هم که لینوکس با میزکار Gnome شناخته شده، با توجه به اینکه از KDE استفاده می کنم بارها بهم گفتن اینکه ویندوز هست!

قیافه KDE قبل از ویندوز همین شکلی بوده!
حتی فراتر از این عکس‌ها Customize میشه کرد.
https://hackernoon.com/18-awesome-linux-themes-for-your-inspiration

@DevTwitter | <VAHID NAMENI/>

آنچه خوبان همه دارند، تو تنها داری: معرفی OpenObserve

بیش از یک دهه پیش، مسیر من در دنیای مشاهده‌پذیری زیرساخت‌ها (Observability) با پشته‌ی کلاسیک ELK (Elasticsearch, Logstash, Kibana) آغاز شد.
در سال‌های اخیر، ابزارهایی چون VictoriaMetrics و Signoz را نیز تجربه کردم، هر یک با ویژگی‌هایی ارزشمند در حوزه‌ی متریک‌ها، لاگ‌ها و تریس‌ها.

اما در این مسیر، اخیراً با پلتفرمی مواجه شدم که به نظرم می‌رسد حرف تازه‌ای برای گفتن دارد:
OpenObserve (O2)
openobserve.ai
OpenObserve

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

معماری مدرن و الهام‌گرفته از نسل جدید سیستم‌های داده

پروژه OpenObserve از Apache Parquet به‌عنوان فرمت ذخیره‌سازی ستونی و از DataFusion Query Engine برای اجرای مستقیم کوئری‌ها استفاده می‌کند. (دیتافیوژن مشابه با duckdb است که با زبان rust توسعه یافته و متعلق به بنیاد آپاچی است)
این طراحی نشان‌دهنده‌ی حرکت آگاهانه به سمت همان معماری‌ای است که در نسل جدید سیستم‌های داده دیده می‌شود:
> جداسازی کامل لایه‌ی ذخیره‌سازی (Storage Layer) از لایه‌ی محاسبات (Compute Layer)
و تعامل از طریق فرمت‌های باز، ستونی و بهینه مثل Parquet.

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

️ آنچه در بررسی اولیه توجه من را جلب کرد

امکان Full-Stack Observability برای Logs، Metrics و Traces در یک بستر واحد

پشتیبانی از Session Replay و Real User Monitoring (RUM) برای تحلیل تجربه‌ی واقعی کاربران

معماری Stateless با مقیاس‌پذیری افقی آسان

قابلیت High Compression (~40×) و هزینه‌ی ذخیره‌سازی تا ۱۴۰× کمتر از Elasticsearch

پشتیبانی از ذخیره‌سازی در S3، MinIO، GCS و Azure Blob

کوئری با SQL، PromQL و VRL

سیستم Observability Pipelines برای پردازش، پالایش و غنی‌سازی داده‌ها در لحظه

طراحی High Availability و Clustering برای نیازهای سازمانی بزرگ

عملکرد و مقیاس

در بنچمارک داخلی، OpenObserve توانسته است ۱ پتابایت داده را در کمتر از ۲ ثانیه کوئری بگیرد، عددی که حتی برای سیستم‌های تحلیلی مدرن نیز قابل توجه است.
معماری Stateless Node آن امکان گسترش افقی بدون پیچیدگی Replication یا وابستگی داده را فراهم می‌کند.

جامعه و مسیر رشد

این پروژه‌ی متن‌باز اکنون بیش از ۱۶٬۰۰۰ ستاره در GitHub دارد و توسط جامعه‌ای فعال از متخصصان DevOps، SRE و مهندسان داده توسعه می‌یابد.
مستندات رسمی و نمونه‌های کاربردی در openobserve.ai/docs در دسترس است.

دعوت از تیم‌های DevOps و SRE

اگر در زمینه‌ی DevOps، SRE، Data Platform یا Observability فعالیت می‌کنید، پیشنهاد می‌کنم OpenObserve را از نزدیک بررسی کنید.
ترکیب زبان Rust، طراحی چندلایه‌ی مبتنی بر Parquet و DataFusion، و مجموعه‌ی کامل قابلیت‌ها از Session Replay تا Alerting و Metrics Analysis
آن را به یکی از جامع‌ترین و آینده‌نگرترین پلتفرم‌های مشاهده‌پذیری حال حاضر تبدیل کرده است.

@DevTwitter | <Mojtaba Banaie/>