MCP آشنایی با
چند وقتی هست که شرکت Anthropic سازنده Cluade AI یک استانداردی رو معرفی کرده به اسم Model Context Protocol

خیلی خلاصه بخوام بگم MCP یه راه استاندارد برای integration هست که به AI systemها مثل Cluade اجازه بده به external resourceها مثل دیتابیس، api و غیره وصل بشن برای استخراج اطلاعات.

خودشون اینطوری معرفی کردن که MCP رو چیزی شبیه پورت USB-C ببینید برای اپلیکیشن های ai.
همانطور که پورت usb-c روی دستگاه ها یه روش استاندارد وصل کردن اونا به لوازم جانبی هست، MCP هم یه راه استاندارد برای اتصال مدل های ai به منابع و ابزار متفاوت و متنوع هست.

۳ تا کامپوننت اصلی داره:
هاست یا همون ai application مثل cluade
کلاینت MCP که توسط ai model استفاده میشه تا با منابع خارجی ارتباط بگیره
سرور MCP که مسئولیت برقراری ارتباط بین کلاینت MCP و منبع خارجی رو داره

مزیت ش چیه؟
به شما اجازه میده که ایجنت ها و workflowهای پیچیده بر روی LLMها بسازید و بین LLMهای مختلف سوییچ کنید.
https://modelcontextprotocol.io/introduction



@gocasts


Ai for Software
@aicasts_ir

خب خب خب ORM چیه ؟ 🛸

امروز می‌خوام درباره‌ی یه موضوع مهم و کاربردی تو دنیای برنامه‌نویسی حرف بزنم: ORM یا همون Object-Relational Mapping.

‏🧠 ORM یعنی چی؟

‏ORM (Object-Relational Mapping) یه تکنیک تو برنامه‌نویسیه که داده‌های دیتابیس رو به شکل اشیاء (objects) تو زبون‌های شی‌گرا مثل پایتون، جاوا یا سی‌شارپ مدیریت می‌کنه. به بیان ساده، ORM یه پل ارتباطی بین دنیای شی‌گرایی (کلاس‌ها و اشیاء) و دنیای دیتابیس‌های رابطه‌ای (جداول و ستون‌ها) می‌سازه. با ORM دیگه لازم نیست مستقیم با کوئری‌های SQL کار کنی؛ در عوض، با همون زبون برنامه‌نویسی‌ات دیتابیس رو کنترل می‌کنی.

مثلاً به جای اینکه بنویسی:

SELECT * FROM users

می‌تونی تو پایتون با Django ORM اینجوری بنویسی:

users = User.objects.all()

و همون نتیجه رو بگیری

‏📚 ORM چطوری کار می‌کنه؟
فرض کن تو دیتابیست یه جدول به اسم users داری که ستون‌هاش اینان:

id، name و email

تو برنامه‌ات یه کلاس به اسم User می‌سازی که پراپرتی‌هایی مثل id، name و email داره. ORM این کلاس رو به جدول users توی دیتابیس مپ (map) می‌کنه. یعنی هر شیء از کلاس User نمایانگر یه رکورد تو جدول users می‌شه.

چند تا سناریو رو با هم ببینیم:

1⃣ ذخیره کردن داده:
یه شیء از کلاس User می‌سازی، مقادیرش رو پر می‌کنی و با یه متد مثل save() ذخیره‌اش می‌کنی. ORM این کار رو به یه دستور SQL (مثل INSERT) تبدیل می‌کنه و اجرا می‌کنه.

user = User(name='علی', email='[email protected]')
   user.save()
  

2⃣ خوندن داده:
میتونی به جای کوئری SQL، از متدهایی مثل all() یا filter() استفاده می‌کنی. ORM پشت صحنه کوئری مناسب رو می‌سازه و داده‌ها رو به شکل اشیاء برمی‌گردونه.

   # همه کاربرها
users = User.objects.all()

   # فیلتر کردن
ali_users =
User.objects.filter(name='علی')

به همین سادگی ORM تمام پیچیدگی‌های کار با دیتابیس رو از دید تو مخفی می‌کنه و یه رابط کاربری راحت بهت می‌ده.

البته هر orm با orm های دیگه فرق داره هرچی یه orm بیشتر abstraction انجام داده باشه استفاده ازش راحت تر میشه
ولی توی مقیاس بالاتر همین سادگی باعث پیچیدگی میشه.

‏🚀 ORM برای چی به وجود اومد؟

قبل از اینکه ORMها باشن، برنامه‌نویس‌ها مستقیم با SQL کار می‌کردن. (هرچند همین الانشم توی زبان های هایی که orm مناسبی براش ساخته نشده برنامه نویسان بصورت خام کد sql میزنن مثل برنامه نویسان golang)

این چند تا مشکل داشت و داره:

کدهای طولانی:
برای هر عملیات ساده، باید یه کوئری SQL می‌نوشتی که گاهی خیلی پیچیده می‌شد.

خطای زیاد:
یه اشتباه کوچیک تو کوئری (مثل یه typo) می‌تونست ساعت‌ها وقتت رو تلف کنه.

سختی نگهداری:
اگه ساختار دیتابیست عوض می‌شد (مثلاً یه ستون اضافه یا کم می‌شد)، باید همه کوئری‌ها رو دستی تغییر می‌دادی.

تفاوت پارادایم:
‏ SQL یه زبون declarative (اعلانی) هست، ولی زبون‌هایی مثل پایتون imperative (دستوری) هستن. این یعنی برنامه‌نویس باید مدام بین دو مدل فکری جابه‌جا می‌شد.

‏ORM اومد که این مشکلات رو حل کنه:

سادگی:
کار با دیتابیس مثل کار با اشیاء تو زبون خودت می‌شه.

امنیت:
‏ORMها معمولاً جلوی حملاتی مثل SQL Injection رو می‌گیرن.

انعطاف‌پذیری:
می‌تونی دیتابیس رو عوض کنی (مثلاً از MySQL بری به PostgreSQL) بدون اینکه کل کدت رو تغییر بدی.

سرعت توسعه:
چون کوئری‌نویسی کمتر می‌شه، وقت بیشتری برای منطق اصلی برنامه‌ات داری.

جمع‌بندی ✍
‏ORM یه ابزار باحال و قدرتمنده که کار با دیتابیس رو برای برنامه‌نویس‌ها راحت‌تر، سریع‌تر و امن‌تر می‌کنه. با ORM دیگه لازم نیست با SQL خام کلنجار بری و می‌تونی با همون زبون برنامه‌نویسی‌ات همه‌چیز رو مدیریت کنی.

#️⃣ #database #sql #orm

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

شاید شما هم مثل عمو فری عاشق axios باشید و دلتون نیاد هیچ‌وقت ازش جدا بشید!
همین‌طور شیفته‌ی Next.js 15 که کلی قابلیت خفن بهش اضافه شده!

دل نیست که، دریاست...

ولی یه مشکلی هست!
نکست توی داکیومنتش تاکید کرده که بهتره از fetch استفاده کنید، چون کلی API کاربردی مثل:
- مدت زمان کش (cache)
- صفحات استاتیک (Static Generation)
- به‌روزرسانی صفحات بر اساس الگوی زمانی (Revalidation)
رو داره که باعث می‌شه صفحات شما همیشه به‌روز و سریع بمونن.

اما اگر بگم یه راه هست که همه اینارو به axios هم بدیم ، اونوقت چی میگید؟

با استفاده از unstable_cache توی Next.js 15 می‌تونید axios رو مجهز به کش سرور، revalidation و static generation کنید!

برای این کار کافیه که unstable_cache رو فراخانی کنید و بپیچید دور درخواستتون
و کانفیگ مورد نظرتون رو هم بهش پاس بدید
و کار تمومه !

هر بار که این تابع رو صدا بزنید، اول کش چک میشه و اگه معتبر باشه، بدون درخواست جدید، داده‌های کش شده برمی‌گرده!
َaxios همون axios می‌مونه، ولی از مزایای کش و ISR در Next.js هم بهره می‌برید!
پس دیگه مجبور نیستید بین axios و fetch یکی رو انتخاب کنید!

توضیحات اضافه :

بعضی وقتا درخواست‌ها سمت کلاینت هستن و بعضی وقتا سمت سرور.
برای درخواست‌های کلاینتی، من از همین ترکیب + TanStack query استفاده می‌کنم تا مدیریت درخواست‌ها راحت‌تر بشه.
البته اگه اصل Single Responsibility رو رعایت کنید، می‌تونید:
- درخواست unstable_cache رو جدا بسازید
- هوک استفاده از اون در TanStack Query رو هم جدا نگه دارید
و بعد، بسته به نیازتون، هرکدوم رو که لازم داشتید فراخوانی کنی

@DevTwitter | <Fariborz Shalghooni/>

استخدام دواپس (جونیور یا میدلول) - سازیتو - بصورت هیبرید

Sazito DevOps Engineer
اگر در موقعیت شغلی DevOps Engineer (جونیور یا میدلول) سابقه فعالیت دارید، لطفا رزومه خود را ارسال کنید.
نوع همکاری تمام وقت و هیبرید است.

لطفا این فرم رو پر کنید.
https://survey.porsline.ir/s/xXuaagrl


@gocasts

امروز وقتی وارد لینکدین شدم کلی پست راجب پیشنهاد خوندن کتاب fluent python دیدم.

خیلی خوشحالم که این کتاب داره دیده می‌شه؛ یک زمانی بود آدما زبان برنامه‌نویسی رو درست نمی‌شناختند ولی بخاطر جوی که راه افتاده بود
Clean coder, clean code , ....

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

https://t.iss.one/pyHints/s/3

#موقت

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

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

توی دسکتاپ KDE با Alt + Space ران می‌شه

@Linuxor

چون زیاد سوال شد :

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

استفاده کنید هم باحاله هم کاربردی
داستانش چیه :

KIMI
یه مدل زبانی جدید چینیه که می‌تونه همزمان تا 50 فایل رو بررسی کنه و متن تا 200,000 توکن رو پردازش کنه. حتی ظاهرشم هم خیلی شبیه دیپ‌سیک هستش

لینک:
https://kimi.ai

@DevTwitter | <Mr.programmer/>

Skill issue

#fun
@CleverDevs - @CleverDevsGp

۲۶ اسفند۱۳۷۶ اتوبوس حامل نخبگان ریاضی شرکت‌کننده در مسابقات ریاضی در راه بازگشت به تهران در جاده انديمشک-پل‌دختر به دره سقوط ‌كرد.

در این سانحه ۲ راننده و ۷ نفر از دانشجویان نخبه رياضی دانشگاه‌های شريف و تهران كشته شدند.

مریم میرزاخانی یکی از بازماندگان این فاجعه بود.

روحشان شاد🙏

🔵 عنوان مقاله
Keep Postgres Maintenance from Slowing Down Your Go App

🟢 خلاصه مقاله:
جای خود را برای یادگیری روش‌های پیشگیرانه نگهداری تضمین کنید که خطرات پنهان کارایی پایگاه داده،

مانند

پرس و جوهای کند (slow queries)،

رفتار نقطه بازرسی (checkpoint behavior)،

و مسائل اتصال (connection issues)،

را پیش از آنکه تشدید شوند، آشکار می‌سازند.

🟣لینک مقاله:
https://golangweekly.com/link/166476/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

خب حالا که خیلی زیاد حرف از بیکار شدن برنامه نویس ها توسط AI هست پینک اورکا ی عزیز زحمت کشیدن یک ویدیوی کوتاه آموزشی تهیه کرده در این باره، امیدوارم که به دردتون بخوره

#fun

@PhiloLearn

تبیین عمیق تر #معماری و #معمار - تو مو بینی و مجنون پیچش مو ( شعری از وحشی بافقی » فرهاد و شیرین)

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

قطعا الگوی Retry را تابحال شنیده اید، الگویی که در ذات بدلیل فهم ناقض و بدتر از آن بدلیل فقدان #تفکر_سیستمی به شدت می تواند #تجربه_کاربر را دچار خدشه کند. به طور مثال اگر و صرفا اگر قرار به پیاده سازی این الگو باشد، عموما این الگو توسط فرآیندهای سیلو شده در تیم های بک اند انجام میپذیرد! دلیل این انتخاب هم عموما وقتی نیازمندی مطرح می شود، به دلیل عدم نگاه سیستمی و وجود مرزهای بوجود آمده (فرانت/بک) فرآیند به شکل صحیح قابلیت ترسیم حتی برای خود توسعه دهندگان ندارد. به دلیل همین فقدان ها یعنی نبود دانش موثر در تصمیم گیری ها، حتی شاید از پیاده سازی این الگو بدلیل پیچیدگی ها زیاد آن صرفنظر می شود و براحتی فراخوانی مجدد فرآیند را به شکل ناشیانه ای به کاربر منتقل می کنند. کاربر کلافه از فرآیندهای ناقض و خسته کننده، اگر با بازار رقابتی روبرو باشد قطعا به عنوان یک کاربر ناراضی سازمان را رها می کند و در اکثر اوقات حتی بدون داده مناسب برای سازمان و حتی خود فرد در خصوص چرایی این اتفاق، سازمان صرفا تماشاگر از دست دادن سهم بازار خواهد بود. هر چند متاسفانه در سازمان های وابسته به حکومت کشورها، این موضوع مهم بدلیل ذات انحصارگرایانه ارائه خدمت عملا منجر به ترک سازمان نمی شود ولی منجر به مشکلات اجتماعی مثل بالا رفتن سطح خشونت در جامعه خواهد شد. اتفاقی که متاسفانه در خیلی از اوقات صرفا با سرکوب معلول (خشم، ...)، بدون حل علت، به دنبال پنهان کردن آنها هستند. وقتی حرف از حل ریشه ای مشکلات می کنیم، نگاه خطی به هیچ عنوان موثر نمی باشد و قطعا نیاز به #تفکر_سیستمی خواهیم داشت.

بگذارید یک مثال واقعی هم که قبلا بهش برخورد کردم را اینجا مطرح کنیم. در نرم افزار ازکی (azki.com) وقتی قصد ثبت یک پلاک جدید دارید و سرویس مورد نظر به هر دلیلی در دسترس نباشد، به شکل عجیبی اول درخواست با استفاده از پروتکل HTTP با کد وضعیت 200 پاسخ داده می شود ولی در عملا در بدنه خطایی ارسال می شود با مضمون به زبان فارسی "در حال حاضر امکان ثبت پلاک وجود ندارد."! متاسفانه بدلیل error handleing ضعیف این نرم افزار، اولا کاربر اصلا متوجه نمی شود که خطایی رخ داده، چون خطایی نمایش داده نمی شود! مشخصا سرویس در سمت سرور قصد برقراری ارتباطی با سرورهای بیمه مرکزی یا پلیس راهور را دارد و بدلیل عدم پاسخگویی آنها، امکان ثبت مهیا نمی باشد. هر چند مشخص نیست. بدلیل ذات طولانی بودن مدت درخواست (16 ثانیه) می شود حدس زد که در سمت سرور حداقل چندبار تلاش (الگوی نام برده شده) اتفاق افتاده است! ولی آیا کاربر عادی 16 ثانیه صبر میدهد بدون اینکه بداند فرآیند در بدون چه وضعیتی می باشد؟ قطعا اگر داده مناسب جمع آوری شود براحتی می توان ادعا کرد بالای 50% از کاربرها به عنوان وجود مشکل به مرورگر دستور بارگزاری مجدد صفحه را می دهند!
قصد نیست در چند خط کوتاه پاسخ قطعی به موضوع بدهیم، ولی از دید شما بهتر نیست فرآیند به شکل عمومی تر دیده بشه و در سمت نرم افزار کاربر، در هر حال فرآیند اخذ اطلاعات و نمایش به عنوان پلاک جدید با یک وضعیت مثلا در حال بررسی نمایش داده شود و در فرآیندهای مستقل تر موضوع تایید پلاک انجام پذیرد؟ و موضوع الگوی تکرار بدون نیاز به دخالت کاربر در زمان مناسب تر انجام پذیرد؟ عموما وقتی در حال ایجاد یک خطا هستید به این فکر کنید که مخاطب خطا کیست؟ آیا اصولا نیاز به وجود این خطا می باشد یا نیاز به اصلاح یا ایجاد فرآیند درست دیگر در جهت حل مشکل در فرآیند. در کامنت های همین پست عکس های مرتبط با ازکی را قرار میدهم که ملموس تر باشد موضوع.