Telegram Web Link
چند وقت پیش با VP یک شرکت آلمانی مصاحبهٔ behavioral داشتم. جنس این مصاحبه‌ها معمولاً این‌طوریه که از تجربیات گذشته می‌پرسن و یا چندتا سناریو مطرح می‌کنن که ممکنه تو فضای کاری پیش بیاد.
اما این یکی یکم متفاوت بود. مصاحبه حول محور core value‌های شرکت،‌ از جمله داشتن اونرشیپ (ownership) روی کارها بود. من اول فکر کردم احتمالاً باید فقط یه مثال بزنم، ولی جریان کاملاً متفاوت پیش رفت.

مصاحبه‌کننده شروع کرد به پرسیدن سؤال‌های خیلی جزئی و دقیق، مثل:
- سعی کن برای یه بچهٔ ۷ ساله اونرشیپ رو توضیح بدی.
- یه مثال از اونرشیپ توی فضای کارت بزن، و یکی هم بیرون از فضای کار و در زندگی شخصی (البته گفت اگر شخصیه و راحت نیستی، لازم نیست بگی).
- داشتن اونرشیپ چرا برای تو مهمه و چه کمکی بهت می‌کنه؟
- چرا فکر می‌کنی که اونرشیپ برای ما اهمیت داره؟

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

ولی من توی اون مصاحبه واقعاً خوشحال بودم. چون چند ماه قبلش، به بهانهٔ نوشتن در کانال [اینجا]، سعی کرده بودم جدی‌تر به این موضوع فکر کنم، بخونم، تجربیاتم رو مرور کنم و در نهایت در ذهنم یک ساختار مرتب براش بسازم و بنویسم.

عملاً هر سؤالی که مصاحبه‌کننده می‌پرسید، یا براش یه جواب ساختارمند و مرتب داشتم، یا با یک مکث کوتاه می‌تونستم بهش جواب معقولی بدم.
در نهایت هم مصاحبه خیلی خوب پیش رفت و مصاحبه‌کننده همون‌جا بازخورد مثبتی بهم داد.

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

@aminrbg
20👍14🔥1
این روزها دارم کتاب Doom Guy: Life in First Person رو می‌خونم که John Romero، سازندهٔ سری بازی‌های موفق Doom نوشته. نویسنده داستانش رو از خیلی قبل، از بچگیش شروع می‌کنه که شروع غیر قابل انتظاری هم داره. متولد و بزرگ شدن در خانواده‌ای غرق در اعتیاد، فقر، خشونت خانگی و البته اندک فرصت‌های تنفسی مثل رفتن به باشگاه بولینگ و بازی کردن با دستگاه Pinball، فونداسیون یکی از اثرگذارترین افراد صنعت بازی رو می‌سازه.

نویسنده می‌گه که من یکی از چیزهایی که از همون ابتدا فهمیدم اینه که جهان جای عادلانه‌ای نیست و کاریش هم نمی‌شه کرد. فقط می‌تونی با کارت‌هایی که داری بازی کنی و ادامه بدی.

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


بختیار علی در کتاب آخرین انار دنیا می‌نویسه:
جنگ دردهای جهان را بزرگ‌تر می‌کند. جنگ هر چند هم بر ضد خرابی‌ها باشد در آخر جور دیگری زمین را آکنده از درد می‌کند. اگر جنگ نهایت عدالت هم باشد همیشه زمین را لبریز غم می‌کند.


اما همین غم ارزش انسانیت رو بالا می‌بره. هم‌دلی رو در دل آدم‌ها روشن می‌کنه و امید، انتظار خوشبختی و انرژی مضاعف می‌سازه.

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


من هم خیلی امیدوارم. با این آدم‌هایی که داریم خیلی کارهای بزرگی می‌شه کرد. من رنج‌ها و غم‌های حاضر رو بذرهایی می‌بینم که ازشون جوانه‌هایی مثل Doom و حتی فراتر از آن هم رشد می‌کنه.

براتون آرزوی سلامتی دارم 💚
19
TechGrub - Daily Feed!

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

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

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

فکر می‌کنم کانال خیلی به‌دردبخوری شده و مدتیه خودم زیاد ازش استفاده می‌کنم و برای همین عمومیش کردم. اگه دوست داشتین، می‌تونین از اینجا عضو بشید:

@TechGrub
1🔥175👍3
من امروز و فردا در کنفرانس سالانهٔ WeAreDevelopers هستم. افراد جالبی قراره ارائه بدن و سعی می‌کنم خیلی کوتاه بعضی از مواردی که می‌گن رو اینجا بذارم. بیشتر موضوعات هم مطابق معمول این روزها حول محور AI می‌چرخه.
اگر احیاناً فردی از کانال هم در اینجا حضور داره خوشحال می‌شم ببینیم همو و گپی بزنیم.

#wearedevelopers2025
@aminrbg
15🔥3👍1
مدیرعامل گیتهاب، Thomas Dohmke، یه ارائه داشت که با فیچرهای جدید کوپایلوت یک بازی Snake رو با vibe coding پیاده‌سازی کنه که تا آخر هر کاری کرد کدش کار نکرد و مجبور شد ارائه‌اش رو ناتموم بذاره :))

#wearedevelopers2025
@aminrbg
🎉29👍2
توی غرفهٔ Hetzner ازشون پرسیدم که چطوری کیفیت خوب و availability بالا رو با این قیمت معقول ارائه می‌دن چون از این نظر اختلاف قابل توجهی با رقیب‌هاش داره. یکی از مسئول‌هاش گفت که دلیلش اینه که تا جای ممکن سعی می‌کنن همه چی رو خودشون بسازن و کارها رو out source نکنن. از پروسهٔ طراحی و معماری دیتاسنترها تا تولید قطعات و رک‌ها. انقدر هم دیتاسنتر دارن که این هزینه‌ها براشون سرشکن می‌شه.
واسه همین هم قیمت مصرف‌کننده تا حد خوبی پایین نگه داشته شده. حتی یه سری درپوش که توی رک‌هاشون استفاده می‌شه رو بهم نشون داد که با پرینتر سه بعدی درست می‌کردن.

#wearedevelopers2025
@aminrbg
👍15🔥61
آیندهٔ Stackoverflow با وجود LLMها به چه سمتی خواهد رفت؟

این سوالی بود که مدیرعامل شرکت،‌ Prashanth Chandrasekar سعی کرد بهش جواب بده. ارائه‌اش رو با این شروع کرد که نظرسنجی‌های سالیانه نشون می‌ده که هرچی AI داره قوی‌تر می‌شه و شرکت‌های بیشتری ازش استفاده می‌کنن، اعتماد به استفاده از خروجی‌هاش داره کمتر میشه. "اعتماد" کلیدواژه‌ای بود که به نظر مسیر جدید Stackoverflow رو قراره تعریف کنه. مثلاً دارن روی Stackoverflow.AI کار می‌کنن که جواب سوال‌های برنامه‌نویسی رو بر پایهٔ دیسکاشن‌های موجود در Stackoverflow می‌ده و بهشون هم لینک می‌ده.

البته تمرکزشون رو هم روی محصولات جانبی خیلی گسترده‌تر کردن و تصورم اینه که می‌خوان تخم‌مرغ‌هاشون رو در سبدهای بیشتری بذارن. مثل Stack Internal که محصول سوال و جواب داخلی شرکت‌هاست، یا فیچر Chat که تو رو به متخصص حوزهٔ سوالت وصل می‌کنه، پلتفرم Coding Challenge و ...

در ضمن دارن بازنمایی برندشون رو تغییر می‌دن که شما هم می‌تونید توی لینک زیر بهشون رای بدین :)
https://stackoverflow.blog/2025/07/10/vote-on-our-new-identity/

#wearedevelopers2025
@aminrbg
👍112
Compose the Future: Building Agentic Applications, Made Simple with Docker

این عنوان یک ارائهٔ خوب از تیم Docker بود که در مورد فیچرهایی که دارن روش کار می‌کردن توضیح دادن. حرفشون این بود که Docker اومد و اشتراک‌پذیری و دسترس‌پذیری برنامه‌ها رو آسون کرد. حالا اون‌ها می‌خوان همین مسیر رو با LLMها برن.

برای این کار چندتا کامند جدید مثل docker model run و docker mcp اضافه کردن که باهاشون می‌شه مدل‌ها رو روی محیط‌های دلخواه اجرا کرد و به کمک docker compose با بقیهٔ برنامه‌ها integrate کرد.

البته همینطور که می‌دونیم LLMها رو معمولاً نمی‌شه روی ماشین‌های با قدرت پردازش معمولی اجرا کرد. برای حل این چالش فیچر Offload رو اضافه کردن که به کمکش میشه وظیفهٔ پردازش رو به GPUهای ریموت سپرد.

#wearedevelopers2025
@aminrbg
5👍5
مراسم اختتامیهٔ کنفرانس با گفتگوی این دو عزیز تموم شد. دو نفری که تاثیر عمیقی روی صنعت بازی‌های ویدیویی که الان می‌شناسیم داشتن و عملاً تاریخ شفاهی این حوزه هستن.

سمت راستی آقای Warren Spector که جدا از چند ده تا بازی مهمی که ساخته، یه جورایی ایده‌پرداز ژانر Immersive sim بوده. قبل از این ایده، بازی‌ها بیشتر سیر خطی داشتن و بر پایهٔ امتیازدهی بودن. ولی با این سبک بود که آزادی عمل بازیکن در بازی بیشتر و بیشتر شد.

اما مهمتر از اون آقای سمت چپیه. خود Warren Spector موقع معرفی بهش گفت من فقط چندتا بازی ساختم ولی تو دنیا رو عوض کردی. وقتی این نوشته رو در مورد جنگ نوشتم و با نقل قول از کتاب John Romero شروع کردم، فکرش رو هم نمی‌کردم چند هفته بعد قراره که از نزدیک ببینمش، باهاش سلفی بگیرم و گپ بزنم. اتفاقاً به همین پست هم اشاره کردم و گفتم که مسیری که طی کرده چقدر برای دولوپرها و گیم‌دیزاینرهای جوون‌تر در جاهای مختلف دنیا الهام‌بخشه.

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

#wearedevelopers2025
@aminrbg
15👍1
آسیب‌پذیری IDOR

آسیب‌پذیری IDOR یا Insecure Direct Object Reference که زیرمجموعه‌ای از آسیب‌پذیری‌های کنترل دسترسیه، زمانی اتفاق می‌افته که یه API طوری طراحی شده باشه که با استفاده از شناسه‌های قابل حدس، مثل یوزرنیم یا عددهای افزایشی (مثلاً 123)، امکان دسترسی به اطلاعات رو بده.

یعنی اگر من یوزر 123 هستم و به اطلاعات خودم دسترسی دارم، بتونم با تغییر عدد به 124، اطلاعات یوزر بعدی رو هم ببینم.

حالا تصور کنید این مسئله فقط برای خوندن داده‌ها نباشه؛ یه متد update هم وجود داشته باشه که با گرفتن همون ID اطلاعات رو تغییر بده. این‌جوری مهاجم نه‌تنها می‌تونه اطلاعات بقیه رو ببینه، بلکه حتی می‌تونه تغییرشون هم بده.

با وجود این که خیلی‌هامون با این مسئله آشناییم، IDOR هنوز هم جزء آسیب‌پذیری‌های خیلی رایج محسوب می‌شه و توی پروژه‌های زیادی دیده می‌شه. [+][+]

راه‌حل چیه؟
اولین چیزی که به ذهن می‌رسه استفاده از شناسه‌های غیرقابل پیش‌بینیه؛ مثلاً UUID. این‌جوری دیگه مهاجم نمی‌تونه حدس بزنه که یوزر بعدی کیه. اما این راه‌حل کامل نیست.

درسته که دیگه نمی‌شه با یه اسکریپت ساده یا تغییر دستی آیدی‌ها به اطلاعات بقیه رسید، ولی اگه مهاجم به یه لیست از UUIDها دسترسی پیدا کنه (مثلاً از طریق ایندکس‌های دایرکتوری یا ابزارهایی مثل gau)، همچنان می‌تونه از API سوءاستفاده کنه. استفاده‌ی صرف از UUID حتی ممکنه توهم امنیت ایجاد کنه و باعث شه مشکل برای مدت طولانی کشف نشه.

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

مثلاً اگه یوزری لاگین کرده و تلاش می‌کنه اطلاعاتی شخصی رو تغییر بده، مطمئن بشیم که user_id اون رکورد مربوط به خودشه.

@aminrbg
16👏2
روز ۱۲ ژوئن ۲۰۲۵ گوگل کلاود به مدت ۳ ساعت دچار اختلال شد و کاربران با ارور ۵۰۳ مواجه بودن. گوگل در یک گزارش مفصل post mortem توضیح داده که چه اتفاقی افتاده و مهندس‌هاش چه اقداماتی برای بازگردوندن سرویس انجام دادن:
Multiple GCP products are experiencing Service issues

بلاگ Surfing Complexity که دربارهٔ موضوعات پایداری سیستم‌ها می‌نویسه، در یکی از نوشته‌هاش (که چند ماه پیش اینجا در @techgrub هم بازنشر شده بود) میگه که در این گزارش، به خوبی و با جزئیات قابل قبولی به اقداماتی که در راستای پایداری مجدد سیستم صورت گرفته اشاره کردن.

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

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

نوشتهٔ کامل رو اینجا می‌تونید بخونید:
“What went well” is more than just a pat on the back

@aminrbg
🔥9👍52
برای شما هم پیش اومده که از میانهٔ راه یک پروژه نسبتاً بزرگ بهش اضافه شده باشین و کلی علامت سوال براتون پیش اومده باشه؟ این که چرا از فلان تکنولوژی استفاده شده؟ چرا معماری پروژه به این شیوه طراحی شده؟ چرا از ابزار X اینجا استفاده نکردن؟

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

در این حالت تنها راهی که باقی می‌مونه پرسیدن این سوال‌ها از اعضای فعلی تیمه. اما خب ممکنه خود اون‌ها هم همهٔ جزئیات رو به یاد نداشته باشن و یا مثل شما، از میانهٔ راه به تیم اضافه شده باشن.

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

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

اگر این مسئله ذهنتون رو قلقلک می‌ده پیشنهاد می‌کنم این نوشتهٔ کوتاه رو بخونید:
Documenting Architecture Decisions

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

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

Agentic Design Patterns
@aminrbg
1👍16🔥2
اگر عضو TechGrub بوده باشین، احتمالاً تغییر اخیر رو متوجه شدین.
قبلاً همهٔ پست‌های ۲۴ ساعت اخیر منابعی که دنبال می‌کردم یکجا ارسال می‌شد و پیدا کردن نوشته‌های به درد بخور وسط این حجم از نوشته کار سختی بود.

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

اینجا توضیح دادم که TechGrub چیه و اگر علاقه‌مندین، می‌تونین عضو بشید:
@TechGrub
1🔥5👍1
امین رشیدبیگی | مهندسی نرم‌افزار
اگر عضو TechGrub بوده باشین، احتمالاً تغییر اخیر رو متوجه شدین. قبلاً همهٔ پست‌های ۲۴ ساعت اخیر منابعی که دنبال می‌کردم یکجا ارسال می‌شد و پیدا کردن نوشته‌های به درد بخور وسط این حجم از نوشته کار سختی بود. برای همین تصمیم گرفتم تغییرش بدم: حالا هر روز فقط…
اگر خودتون نوشتهٔ فنی انگلیسی می‌نویسید و یا افرادی رو دنبال می‌کنید که نوشته‌های باکیفیتی دارن حتماً توی کامنت یا دایرکت برام بفرستین که به لیستم اضافه کنم.

در ضمن اگر عضو کامیونیتی یا صاحب کانالی هستین خوشحال می‌شم TechGrub رو معرفی کنید که به گوش افراد بیشتری برسه.
1👍4
امروز ساعت ۱۸:۳۰ به وقت ایران یک ارائه رایگان از طرف 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
1👍74
وقتی می‌خواین یک دادهٔ حساس مثل گذرواژه یا یک سیکرتی رو برای همکارتون بفرستین، معمولاً سریع‌ترین راه فرستادنش توی ایمیل یا ابزارهای پیام‌رسان مثل اسلک و تلگرامه. اما همون‌طور که می‌دونید این‌ها امن نیستن و بهتره پس از استفاده حذف بشن. با این حال خیلی وقت‌ها این اتفاق نمی‌افته. یا فراموش می‌کنیم، یا بدتر اینکه از همون پیام به‌عنوان پسوردمنیجر استفاده می‌کنیم!

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

@aminrbg
1👍8👎32🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
چند هفته پیش در یک هکتون شرکت کردیم و یک ایجنت پیشنهاد غذای هوشمند ساختیم.

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

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

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

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

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

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

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

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

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

🔗 لینک مصاحبه

@aminrbg
1🔥15👍1
2025/10/27 05:07:58
Back to Top
HTML Embed Code: