از محتواهای خیلی خوبی که اخیراً بهش برخوردم کتاب رایگان Agentic Design Patterns از Antonio Gulli هستش. ایشون در حال حاضر با عنوان شغلی Sr Director, Distinguished Engineer, CTO Office در شرکت Google مشغول به کار هستن.

نویسنده در چپترهایی مجزا و با مثال‌های عملی الگوهای استفاده از Agentها رو ارائه می‌ده. من فکر می‌کنم کتاب مفیدیه چون هم به تازگی منتشر شده و اطلاعات بروزی داره و هم نگاهش به مسئله خیلی کاربردیه. خودم هم شروع به خوندنش کردم.

Agentic Design Patterns
@aminrbg

اگر عضو TechGrub بوده باشین، احتمالاً تغییر اخیر رو متوجه شدین.
قبلاً همهٔ پست‌های ۲۴ ساعت اخیر منابعی که دنبال می‌کردم یکجا ارسال می‌شد و پیدا کردن نوشته‌های به درد بخور وسط این حجم از نوشته کار سختی بود.

برای همین تصمیم گرفتم تغییرش بدم: حالا هر روز فقط یک نوشته کوتاه ارسال می‌شه: عنوان، یک چکیده مختصر ai-generated و در بعضی موارد یک تصویر.

اینجا توضیح دادم که TechGrub چیه و اگر علاقه‌مندین، می‌تونین عضو بشید:
@TechGrub

اگر خودتون نوشتهٔ فنی انگلیسی می‌نویسید و یا افرادی رو دنبال می‌کنید که نوشته‌های باکیفیتی دارن حتماً توی کامنت یا دایرکت برام بفرستین که به لیستم اضافه کنم.

در ضمن اگر عضو کامیونیتی یا صاحب کانالی هستین خوشحال می‌شم TechGrub رو معرفی کنید که به گوش افراد بیشتری برسه.

امروز ساعت ۱۸:۳۰ به وقت ایران یک ارائه رایگان از طرف Addy Osmani و انتشارات O'Reilly با عنوان Coding for the Agentic World برگزار میشه و که قراره موضوعات زیر رو پوشش بدن:

- Agentic interfaces: Moving beyond chat UX to sophisticated agent interactions
- Tool-to-tool workflows: How agents chain across environments to complete complex tasks
- Background coding agents: Asynchronous, autonomous code generation in production
- MCP and agent protocols: The infrastructure enabling the agentic web

توضیحات بیشتر و ثبت‌نام:
https://www.oreilly.com/AgenticWorld/

@aminrbg

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

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

@aminrbg

چند هفته پیش در یک هکتون شرکت کردیم و یک ایجنت پیشنهاد غذای هوشمند ساختیم.

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

ما برای ساخت این پروژه از داده‌های پلتفرم Foodpanda در کشور مالزی استفاده کردیم و در توسعه‌اش از ابزارهای اکوسیستم گوگل مثل Vertex AI، ADK و Gemini کمک گرفتیم.

برای مثال در ویدیوی دمو می‌بینید که کاربر غذایی رو در اینستاگرام دیده و نمی‌دونه از کجا می‌تونه پیداش کنه و ایجنت اون غذا رو شناسایی می‌کنه و رستوران‌هایی که اون غذا رو ارائه می‌دن پیشنهاد می‌ده.

در مراحل بعدی، این ایجنت می‌تونه به اطلاعات هویتی کاربر متصل بشه و فرآیند سفارش غذا رو به‌صورت end-to-end انجام بده. مثلاً وقتی در راه خونه هستید و دارید رانندگی می‌کنید، فقط با صحبت کردن با ایجنتتون می‌تونید غذاتون ر‌و سفارش بدید.

@aminrbg

پاول دوروف هفتهٔ گذشته توی پادکست Lex Fridman یک گفت‌وگوی چهار پنج ساعته منتشر کرد که از مفصل‌ترین مصاحبه‌هاش بود. با جزئیات زیادی دربارهٔ موضوعات مختلف حرف می‌زنه؛ از دسیپلین فیزیکی و تغذیه‌اش گرفته تا نحوهٔ ساخت و مدیریت تیم تلگرام و تصمیم‌های مهندسی و طراحی پشت این اپ.

یکی از بخش‌هایی که برام ویژه‌تر بود، مسئلهٔ درآمدزایی تلگرام بود. احتمالاً برای شما هم پیش اومده که دنبال یه ابزار ساده بگردین، ولی یا باید اشتراک بخرید، یا بنرهای تبلیغاتی کل صفحه رو گرفتن، یا کیفیت اون ابزار انقدر پایینه که عملاً قابل استفاده نیست.

دوروف می‌گه تلاش کرده بهترین نسخه از تلگرام رو، که از نظر کارایی حتی از رقبا بهتره، رایگان ارائه بده. بعد تازه برای نسخهٔ پرمیوم فکر کردن که چه ویژگی‌هایی می‌تونن خلق کنن که بعضی کاربرها با وجود نسخهٔ رایگانِ باکیفیت، حاضر باشن براش پول بدن. نتیجه هم جالبه: بیش از ۱۵ میلیون کاربر پرمیوم!

در مورد تبلیغات هم حرف‌های قابل‌تأملی می‌زنه. می‌گه توی دنیایی زندگی می‌کنیم که تقریباً همهٔ پلتفرم‌ها از تبلیغات تارگت‌شده استفاده می‌کنن و بهره‌برداری از داده‌های کاربران تبدیل به یه چیز عادی شده (اینجا یه اشاره‌ای بهش کردم). ولی تلگرام تصمیم گرفته به اصول خودش پایبند بمونه و حریم خصوصی کاربرا رو حفظ کنه، حتی اگه به معنی از دست دادن ۸۰٪ پتانسیل درآمدی تبلیغات باشه. به‌جاش مدل متفاوتی از تبلیغات رو ارائه داده که بدون استفاده از داده‌های کاربر کار می‌کنه؛ همون تبلیغاتی که توی کانال‌های بالای هزار عضو می‌بینیم.

این نوع نگاه به درآمدزایی، هرچند سخت‌تره و انرژی بیشتری می‌خواد، به نظرم خیلی ارزشمنده و حتی از نظر بیزینسی هم پایدارتره. چون از همون اول دلیلی برای دافعهٔ کاربرها ایجاد نمی‌کنی، و وقتی به پلتفرمت جذب می‌شن و اعتماد شکل می‌گیره، راحت‌تر حاضرن توی پلتفرمت پول خرج کنن.
تلگرام برای اولین بار در سال ۲۰۲۴ سودآور شد.

🔗 لینک مصاحبه

@aminrbg

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

همونطور که در این سال‌ها دیدیم، جست‌وجو به مرور از "متن" فراتر رفت. سرچ تصویر رو با گوگل دیدیم، تشخیص صدا و موسیقی رو با محصولاتی مثل Shazam، و حالا هم با ظهور «سرچ بُرداری»، عملاً می‌تونیم هر نوع داده‌ای رو جست‌وجو کنیم.

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

من هم خوش‌شانس بودم که قبلاً مدتی عضو این تیم باشم و در شکل‌گیری جستجوی بُرداری نقش کوچیکی داشته باشم. اگر با این روش جستجو آشنا نیستید اینجا قبلاً در موردش نوشتم:
🔗 Vector Search Introduction

اگه می‌خواین بخش جست‌وجوی محصولتون رو بهبود بدین، یا فقط کنجکاوین بدونین وقتی کسی در دیوار «پراید قرمز کم‌کارکرد مدل ۹۵» رو جستجو می‌کنه پشت صحنه چه اتفاقی می‌افته، پیشنهاد می‌کنم این ویدیو رو ببینین.

🔗 داستان تکامل جست‌و‌جوی دیوار

@aminrbg

همون‌طور که احتمالاً می‌دونید، AWS یکی دو هفته پیش ریجن us-east-1 رو از دست داد و باعث شد بخش قابل‌توجهی از اینترنت در دنیا یا کند بشه یا عملاً قطع.
کلی هم خبر و محتوای جالب منتشر شد؛ از هم‌دردی شرکت‌ها با مهندس‌های AWS گرفته تا ابراز نگرانی درباره این‌که اصلاً سازوکار اینترنت نباید طوری باشه که از کار افتادن یه region، این‌همه کسب‌وکار و کاربر رو تحت تأثیر بذاره.

در این بین، بامزه‌ترین خبری که خوندم مربوط به شرکت Eight Sleep بود که تخت‌های هوشمند تولید می‌کنه. به خاطر مشکل AWS، نیمه‌شب ارتباط این تخت‌ها با سرورها قطع شده بود و دیگه نمی‌تونستن دماشون رو درست تنظیم کنن. بعضی‌هاشون زیادی داغ شده بودن و خیلی‌ها نتونستن اون شب درست بخوابن 😄
اینجا بخونید:
🔗 Owners of Luxury Smart Beds Literally Lost Sleep Due to AWS Outage

وقتی همچین اتفاقی می‌افته، بعضی شرکت‌ها بدشانس‌ترن و آسیب زیادی می‌بینن. مثلاً اون‌هایی که کل زیرساختشون روی همون region بوده. بعضی‌ها هم خوش‌شانس‌ترن و کمتر تحت تأثیر قرار می‌گیرن.
ولی بخش مثبت ماجرا اینه که همه می‌تونن ازش درس بگیرن. اگر زیرساختمون دچار کندی یا فشار بالا بشه، چطور می‌تونیم برای چنین شرایطی آماده‌تر باشیم؟

به این آمادگی می‌شه در سطوح مختلف فکر کرد. از بهبود فرآیندها و ابزارهای مدیریت incident گرفته تا بازبینی استراتژی زیرساخت، انتخاب locationهای متفاوت و تنوع پلتفرم‌ها.

اما برای من مهم‌تر اینه که از زاویه‌ی معماری و طراحی نرم‌افزار بهش نگاه کنم. یعنی ببینم چه تصمیم‌هایی می‌تونیم بگیریم تا وقتی سیستم با فشار یا کندی غیرمنتظره روبه‌رو می‌شه، بتونیم با تغییرات حداقلی سریع‌تر ریکاوری کنیم.

به نظرم این تمرین ذهنی در تصمیم‌گیری‌های فنی آینده‌امون کمک می‌کنه و در چند پست بعدی درباره‌ش خواهم نوشت. شما هم بهش فکر کنید و اگر دوست داشتید توی بخش ‌کامنت بنویسید.

@aminrbg

قبل از شروع این سری پست‌ها، یه پرانتز باز کنم.

می‌خوام طی هفته‌های آینده یه جلسه گفت‌وگوی آنلاین یک ساعته با شما داشته باشم درباره‌ی تغییرات اخیر بازار کار و layoffهای جدید تحت تأثیر AI، این‌که الان در چه وضعیتی هستیم و در شرایط جدید چه اقداماتی خوبه که انجام بدیم صحبت کنیم.

اگر به شرکت در چنین گفت‌وگویی علاقه‌مندین، چه روز و ساعتی براتون مناسب‌تره؟ (به وقت ایران)
👇

امکان سرویس‌دهی در سطوح مختلف به کمک Feature Flagها

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

همهٔ این‌ها برای کسب‌وکار مهمن، اما وقتی شرایط نرمال نباشه و فشار زیادی روی سرورها بیاد، اهمیتشون با هم برابر نیست.
مثلاً سیستم recommendation به اندازهٔ فرآیند ثبت سفارش حیاتی نیست.

بنابراین باید مکانیزمی داشته باشیم که بتونیم در مواقع ضروری بعضی قابلیت‌ها رو موقتاً غیرفعال کنیم.
یکی از راه‌حل‌ها استفاده از Feature Flagهاست؛ ابزاری که در زمان کوتاه و با تغییراتی اندک، امکان حذف بخش‌هایی از محصول رو از مسیر درخواست کاربر فراهم می‌کنه.

@aminrbg

تعریف سطوح کاهش سرویس (Degradation Levels)

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

این کار کمک می‌کنه که عملکرد بخش‌های اصلی پایدارتر بمونه چون هم محاسبات کمتری صورت می‌گیره، و هم منابعی آزاد میشه که برای scale up کردن بخش‌های مهم‌تر میشه استفاده کرد.

یه نمونهٔ فرضی برای مثال دیجیکالا می‌تونه این‌طوری باشه 👇

🟢 Level 0 — Normal
همه‌چیز فعال و در حالت عادی کار می‌کنه:
- Recommendation engine
- Reviews
- Wishlist
- Search suggestions

🟡 Level 1 — Light Pressure
فیچرهای غیرحیاتی موقتاً غیرفعال می‌شن:
- ❌ Recommendation engine
- ✅ Reviews
- ❌ Wishlist
- ✅ Search (بدون suggestion)

🟠 Level 2 — Heavy Pressure
فقط مسیر خرید و پرداخت فعال می‌مونه:
- ✅ مشاهدهٔ محصول + سبد خرید + پرداخت
- ❌ سایر قابلیت‌ها غیرفعال

🔴 Level 3 — Critical
حالت Read-only:
- ✅ فقط مشاهدهٔ محصولات
- ❌ امکان خرید جدید

با این رویکرد، می‌تونیم برنامهٔ مشخصی برای کاهش فشار روی سیستم داشته باشیم.

از طرف دیگه یه زبان مشترک بین همهٔ stakeholderها شکل می‌گیره؛ طوری که در زمان بحران هماهنگی راحت‌تر انجام می‌شه، زمان کمتری صرف ارتباط و توضیح می‌شه، و تیم می‌تونه خیلی سریع‌تر واکنش نشون بده.

@aminrbg

جلوگیری از اثر زنجیره‌ای در سرویس‌ها (Cascading Effect)

هر محصول از چندین برنامهٔ قابل‌اجرا تشکیل شده که با رشد تیم و وسعت محصول، تعدادشون کم‌کم به ده‌ها یا حتی صدها برنامه می‌رسه.
سازمان‌ها معمولاً سرویس‌ها رو بر اساس اهمیت به چند سطح تقسیم می‌کنن: tier1، tier2، ... تا برای هر سطح SLA، آن‌کال، و ظرفیت منابع متفاوتی تعریف کنن.
به عنوان نمونه در مثال دیجیکالا، اپلیکیشن ثبت سفارش می‌تونه tier1 باشه چون مستقیم روی درآمد و تجربه‌ی کاربر اثر می‌ذاره، اما بخش لایو اینفلونسرها tier کم‌اولویت‌تری داره و اگر چند دقیقه هم از دسترس خارج بشه، اثرات خیلی کمتری داره.

در حالت ایده‌آل، از کار افتادن یک سرویس با اولویت پایین نباید روی سرویس‌های حیاتی اثر جدی بذاره. اما همیشه این‌طور نیست؛ گاهی ارتباط سرویس‌ها طوری چیده شده که از کار افتادن یک سرویس tier4، عملاً سرویس tier1 رو هم با خودش پایین می‌کشه.

یکی از مهم‌ترین راه‌ها برای جلوگیری از این اثر زنجیره‌ای، طراحی asynchronous بین سرویس‌هاست. یعنی برنامه‌ها به‌جای وابستگی‌های synchronous و اجرای خطی، از صف‌ها، eventها یا callbackهای غیرهمزمان استفاده کنن.
خوبه هنگام طراحی ارتباط بین سرویس‌ها به این موضوع دقت کنیم و در trade-offها گزینهٔ async رو جدی‌تر بررسی کنیم.

مورد مهم دیگه انتخاب timeout مناسب و استفاده از retry + backoff و circuit breakerهاست؛ به‌طوری که اگر یکی از وابستگی‌ها قطع شد، سرویس بتونه خودش رو سرپا نگه داره و کامل از مدار خارج نشه.

رعایت این موارد کمک می‌کنه که در زمان بحران، راحت‌تر و با ریسک کمتری تصمیم به خاموش کردن موارد کم‌اولویت‌تر بگیریم و بار رو از روی دوش کل سیستم کاهش بدیم.

@aminrbg

توی این سه تا پست از چند شیوه برای آماده شدن در برابر مشکلات پیش‌بینی‌نشده‌ی زیرساخت یا لودهای ناگهانی نوشتم:

⛳ ارائه سرویس در سطوح مختلف با کمک Feature Flagها
⬇️ تعریف سطوح کاهش سرویس (Degradation Levels)
🔗 جلوگیری از اثر زنجیره‌ای در سرویس‌ها (Cascading Effect)

این اقدامات فقط مختص به شرایط بحرانیِ غیرمنتظره نیستن و در زمان‌های فشار پیش‌بینی‌پذیر هم کاملاً کاربرد دارن.
مثلاً همین چند هفتهٔ دیگه بلک‌فرایدی رو پیش داریم و اپلیکیشن‌هایی که انتظار لود بالا دارن، با استفاده از همین روش‌ها می‌تونن احتمال داون شدن کامل سرویسشون رو کم کنن.

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

@aminrbg

🎙 تک‌تاک: تغییرات هوش مصنوعی و آیندهٔ بازار کار مهندسی نرم‌افزار

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

📅 پنج‌شنبه ۲۹ آبان (20 Nov)
🕗 ساعت ۲۰ به وقت ایران (17:30 CET)
🔗 لینک گوگل میت
🗓 اضافه کردن به تقویم

@aminrbg

جهت یادآوری، اگر هنوز به کلندرتون اضافه نکردین، این ارائه فرداشب برگزار می‌شه.

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

می‌بینمتون.

ده دقیقهٔ دیگه شروع می‌کنیم 🙂

https://meet.google.com/erc-paet-bec

پنج‌شنبهٔ هفتهٔ پیش دربارهٔ تغییرات اخیر در هوش مصنوعی، تأثیراتش روی آیندهٔ کار، و کارهایی که ما می‌تونیم برای بهره گرفتن از شرایط موجود انجام بدیم صحبت کردیم.

اینجا می‌تونید محتوای متنی ارائه رو ببینید:
AI Changes and Their Impact on Software Engineering

این چندتا نوشته و پادکست هم در ارائه بهش اشاره شد که اینجا می‌ذارم:

- The 70% problem: Hard truths about AI-assisted coding
- How Block is becoming the most AI-native enterprise in the world | Dhanji R. Prasanna
- The State of the AI Industry is Freaking Me Out
- Let's Talk About the AI Bubble
- Beyond Vibe Coding with Addy Osmani

@aminrbg

سال ۲۰۲۵ برای من پر بود از تغییر و جابجایی. توی این پست می‌تونین خلاصه‌ای ازش رو بخونین.

2025 in Review

@aminrbg