Go Casts | Systems & Agents 🚀

اگه یه مهارت باشه که لازمه به خودمون اضافه کنیم تا ریسک شغلی مون کمتر بشه مهارت بررسی و investigate کردن proactive محصول برای بهبودشه. یعنی صبر نکنیم تا یکی بهمون بگه چی بسازیم و خودمون دنبال مشکل ها و فرصت های بهبود محصول بگردیم. معمولا ما که سابقه کاری مون بیشتر مهندسی نرم افزار و برنامه نویسیه این یه زمین بازی کاملا جدیده و تجربه مون توش کمه. برای اینکه یاد بگیریم چطور این کارو بکنیم خوندن این مطالب میتونه مفید باشه 1. The Product-Minded Software Engineer - Gergely Orosz https://blog.pragmaticengineer.com/the-product-minded-engineer/ 2. Product Discovery - Marty Cagan https://www.svpg.com/product-discovery/ 3. Continuous Discovery Habits - Teresa Torres https://www.producttalk.org/continuous-discovery-habits/ @gocasts

این روزها زیاد می‌پرسن «با این همه ایجنت و Claude Code، هنوز لازمه کدنویسی رو از پایه یاد بگیریم؟» جواب من آره‌ست، و به نظرم الان حتی مهم‌تر از قبله. بحث این نیست که به قول Boris Cherny کد «حل شده» یا نه. بحث اینه که ذهن ما چیزی رو یاد می‌گیره که براش زحمت کشیده باشه. وقتی خودت با یه باگ کلنجار می‌ری یا یه الگوریتم رو قدم‌به‌قدم می‌نویسی، حتی روی کاغذ، داری مهارت حل مسئله و فهم سیستمی رو می‌سازی. دانشگاه آکسفورد یه ویدیوی کوتاه داره که استاد ریاضی توش می‌گه ریاضی رو باید فعالانه یاد گرفت، یعنی با نوشتن قدم‌به‌قدم معادله‌ها. اندرو انجی هم اخیراً حرف مشابهی زد: جواب گرفتن از AI شاید همون لحظه نتیجه رو بهتر کنه، ولی یادگیری بلندمدت رو خراب می‌کنه، چون کار رو خودت انجام ندادی. https://www.instagram.com/reel/DeWpAGJoK8h ‌از طرف بازار هم قضیه روشنه: شرکت‌ها قدرت AI رو بهتر از ما می‌شناسن و پول بیشتری هم براش خرج می‌کنن. پس وقتی نیرو می‌گیرن، دنبال کسی‌ان که عمیق باشه و بتونه خروجی ایجنت رو بفهمه، نقدش کنه و مسئولیتش رو بپذیره. هیچ‌کدوم از این حرف‌ها به معنی مخالفت با AI نیست. خودم هر روز با ایجنت‌ها کار می‌کنم و معتقدم agentic development یه مهارت جدی و جدیده که همه‌مون باید بهش مسلط بشیم. فقط ترتیبش مهمه: اول پایه، بعد ابزار. آقای Lauren، که قبلاً توی تیم React Compiler بوده، می‌گه نوشته‌ها و پرامپت‌هاش رو خودش می‌نویسه، چون نوشتن یعنی فکر کردن. هر چی دانش و واژگان دامنه‌ت عمیق‌تر باشه، ایجنت رو بهتر هدایت می‌کنی. بنظرم اگه تازه شروع کردی این مسیر شغلی رو، کد بنویس، دیباگ کن، گیر کن و بذار ذهنت درگیر بشه. ایجنت‌ها وقتی خوب جواب می‌دن که خودت بدونی دقیقاً چی ازشون می‌خوای. https://x.com/poteto/status/2109885001584292091 @gocasts

سلام همراهان عزیز انسین با انسین نگران باگ امنیتی جدید PHP نباشید. داخل انسین براتون قانون WAF ای ایجاد میکنیم که جلوی اینگونه حملات رو میگیره nsin.ir @nsin_ir

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

روحت شاد آقای چاپلین. باورم نمیشه که عصر جدید داره برامون تکرار میشه! انگار خط تولید «عصر جدید» از کارخونه اومده توی سیستمهامون. متنی که نوشتم از حس شخصی خودم و تجربه چند نفر دیگه در داخل و خارج از کشوره. شاید کمی اغراق‌آمیز به نظر بیاد ولی فکر نمیکنم خیلی هم دور از ذهن باشه رخ دادنش.. چندتا ترد باز، چندتا ایجنت مشغول کار و یه آدمی که باید مدام بینشون بچرخه، خروجی بخونه، خطا بگیره، تصمیم بگیره و مدام این چرخه رو تکرار کنه! قرار بود ai بخشی از بار ما رو برداره. ولی اگه شرکت‌ها، هرچی بیشتر خرج هوش مصنوعی می‌کنن، از آدم‌ها هم انتظار بیشتری داشته باشن، اونوقت این ماییم که باید با سرعت هوش مصنوعی کار کنیم! ایجنت‌های هوش مصنوعی ابزارایی هستن که می‌تونن خیلی به ما کمک کنن، اما در عمل ممکنه ما رو مجبور کنن با سرعتشون بدویم. ایجنت‌ها خسته نمی‌شن، ولی آدمها چرا. انگار «عصر جدید ۲» داره بوجود میاد.فقط جای ماشین‌های چاپلین رو ایجنت‌ها گرفتن! @gocasts

با یه پارادوکسی مواجه هستیم که خیلی مهمه درست درکش کنیم. وقتی در مورد کارایی که با ایجنت‌ها می‌کنم پست می‌ذارم، یه سوال رایج اینه که setup و فریمورک و trickهایی که به کار می‌بری چیه. معمولا جواب نمی‌دم چون سخته توضیح بدم که برای خیلی از کارها واقعا چیز خاصی ندارم... یا دوستان لطف دارن و می‌گن دوره و ورکشاپ برگزار کن. ولی به نظرم setup و trick اون چیزی نیست که فرق اصلی رو می‌سازه. چیزی که واقعا فرق می‌سازه یه چیز دیگه‌ست که پایین‌تر می‌گم. حالا تو توییتر dax و DHH این چند روز یه حرفی زدن که خیلی باهاش موافقم: دیگه لازم نیست برای کار با AI یه setup پیچیده و عجیب بچینی. مدل‌ها خودشون خیلی خوب شدن. تا چند ماه پیش خودم رو خیلی درگیر setupهای پیچیده می‌کردم. کلی skill، کلی MCP، فایل‌های rule چند صفحه‌ای و غیره... علت اصلیش این بود که مدل‌های اون موقع ضعیف بودن، یا بهتره بگم حواس‌پرت بودن... مثلا یادش می‌رفت چی گفتیم، یه چیزی می‌نوشتیم که یادش بمونه. یا به یه سری چیزای بدیهی دقت نمی‌کرد و باید rule سفت و سخت براش می‌نوشتی که درست کار کنه. الان مدل‌ها هنوز بی‌نقص نیستن، ولی این مشکلا رو خیلی کمتر دارن و بیشتر اون setupها دیگه لازم نیست. ولی یه چیزی هست که به نظرم همچنان مهمه، و شاید مهم‌ترین مهارتیه که تو استفاده از ایجنت‌ها باید بهش توجه کنیم. مدل هر چقدر هم باهوش باشه، پروژه شما رو نمی‌شناسه. نمی‌دونه چرا فلان کار رو تو تیمتون این‌طوری انجام می‌دید، یا اون قانون عجیب بیزینسی که شفاهیه و هیچ‌جا داکیومنت نشده از کجا اومده. این چیزا رو باید یه جا براش بنویسید. این دیگه «جبران ضعف مدل» نیست، اطلاعاتیه که هیچ‌جای دیگه پیداش نمی‌کنه. در واقع بزرگ‌ترین ضعف بیزینس‌ها الان «حجم خیلی زیاد contextهای شفاهیه» که هیچ‌جا نوشته نشده جز ناخودآگاه آدم‌ها، و تا این حل نشه ایجنت‌ها بهره‌وری کافی نخواهند داشت. برای همین مهم‌ترین کاری که معمولا می‌کنم اینه که نیازمندی رو کامل و شفاف کنم، هم از نظر بیزینسی هم فنی. نکته مهم دیگه deterministic validationهاست. یعنی تست‌هایی که سیستماتیک قوانین بیزینس رو چک می‌کنن. ایجنت الان خیلی سریع کد می‌نویسه، و دقیقا برای همین باید بتونی سریع و مطمئن چک کنی درست نوشته یا نه. هر چی ایجنت سریع‌تر بشه، تست مهم‌تر می‌شه. یه نکته مهم دیگه هم اینه که درک عمیق مسائل high level مهندسی نرم‌افزار، که اگه از ابعاد مختلف جمعشون کنی خیلی زیادن، همچنان تو کیفیت خروجی ایجنت‌ها تعیین‌کننده‌ست. ابزار ساده‌تر شده، ولی هنوز باید بدونی داری چی می‌سازی. پس از نظر من بالا بردن دانش مهندسی نرم‌افزار خیلی مهمه. چیزی که لازم نیست، micromanage کردن ایجنت‌هاست. این به معنی رها کردن کار نیست، ولی دخالت بیش از حد و وسواسی عملا سرعت ایجنت رو ازش می‌گیره. حالا پارادوکس کجاست؟ اینجا که اگه بخوایم ایجنت بهترین عملکردش رو داشته باشه، بهتره ما مثل کسی رفتار کنیم که هیچی از مهندسی نرم‌افزار نمی‌دونه. این‌طوری بدون ترس و وسواس، ماکزیمم پتانسیل ایجنت رو به کار می‌گیریم. اما برای اینکه چیزی که ایجنت می‌سازه واقعا درست باشه و اصطلاحا slop نباشه، باید خودت دید فنی و محصولی درستی داشته باشی. و وقتی دید فنی و محصولی داری، همه‌ش می‌خوای تو کار ایجنت دخالت کنی و کم‌کم می‌ری سمت وسواس و micromanage کردن. به نظرم باکیفیت‌ترین محصولات نرم‌افزاری رو الان مهندس‌هایی می‌سازن که این پارادوکس رو تو نقطه تعادلش نگه دارن. یعنی تصمیم‌های مهم مهندسی رو تو نقاط حیاتی life cycle توسعه خودشون بگیرن، و بقیه پروسه رو بسپرن به ایجنت‌ها. https://x.com/dhh/status/2107823432205484040 @gocasts

از دیروز چند آیتم ظاهری در GoCasts به‌روز شده 🚀 اگه دقت کرده باشید، لوگو، اسم کانال و بیو تغییر کرده: Go Casts | Systems & Agents این تصمیم یهویی نبود. حدود یک سال و نیم پیش که @aicasts_ir رو راه انداختیم، نگاهمون این بود که همه‌مون، به‌عنوان مهندس نرم‌افزار، باید به این سمت بریم. ولی کم‌کم این موضوع برای خود GoCasts هم خیلی جدی‌تر شد. خیلی وقته که محتوای کانال رنگ و بوی agentها رو گرفته و طبیعی هم هست. ولی وقتش شده بود که در هویت اصلی GoCasts هم این تغییر نشون داده بشه. لوگوی جدید هم از همین ایده اومده: سیستم‌ها و ایجنت‌ها. چند تکه‌ی جدا که در کنار هم یک چرخه‌ی کامل می‌سازن. ▫️ یعنی دیگه نرم‌افزار مهم نیست؟ نه، اصلاً. برای من، نرم‌افزار همچنان یکی از جدی‌ترین دغدغه‌هاست. هنوز practiceهای خوب نرم‌افزار، طراحی distributed system و چالش‌های مهمی مثل reliability، scalability و غیره خیلی جدی‌ان. ▫️ در آغوش گرفتن agentها در آغوش گرفتن ایجنت‌ها اجتناب‌ناپذیره. به نظرم اتفاقاً باید براش ذوق هم داشته باشیم، چون ایجنت‌ها به ما اجازه می‌دن همون نرم‌افزار خوب، باحال و scalable رو ساده‌تر، بهتر و کم‌هزینه‌تر بسازیم. خیلی وقت پیش در مورد این در آغوش گرفتنه صحبت کرده بودم. یکی از واضح‌ترین قدم‌ها هم در آغوش گرفتن تمام و کمال AI برای بهبود بهره‌وری کارمون هست: https://t.me/gocasts/743 ▫️ ایجنت‌ها خودشون هم یک «سیستم» جدیدن جدا از اینکه با ایجنت‌ها سیستم می‌سازیم، خود ایجنت‌ها هم یه دنیای مهندسی تازه‌ان: agent runtime، harness، scale کردن ایجنت‌ها و ... . موضوعی که به نظرم باید عمیق دنبالش کرد. ▫️ گولنگ خیلی خوبه! گولنگ برای من همچنان خیلی دوست‌داشتنی و مهمه، ولی agentic Go. نرم‌افزار در همه‌ی ابعادش مهمه، ولی agentic software. یعنی مباحث مهم در گولنگ و software رو باید مسلط شد، و خیلی از جزئیات کم‌اهمیت‌تر رو به ایجنت‌ها سپرد. ▫️ طراحی و معماری سیستم: مهم‌تر از قبل طراحی سیستم و معماری همیشه مهم بوده، ولی با اومدن ایجنت‌ها هم مهم‌تر شده و هم چالش‌برانگیزتر. نگاه اهمیت دادن به طراحی سیستم در GoCasts چندین ساله که وجود داره. به همین دلیله که بخش خوبی از محتوای دوره‌ی بک‌اند و گولنگ GoCasts در مورد طراحی و معماری سیستم بوده و معتقد بودیم هر فرد در این حوزه، بدون در نظر گرفتن میزان تجربه‌ش، باید از طراحی سیستم بدونه. حتی کم‌تجربه‌ترین فرد! وقتی نوشتن کد این‌قدر سریع و ارزون شده، تصمیم‌های اصلی سنگین‌تر شدن: مرزبندی سرویس‌ها، مدل داده، invariantها، trade-offها و اینکه سیستم زیر بار و در زمان خطا چه رفتاری داره. ایجنت هر چیزی رو که بهش بگیم سریع می‌سازه؛ خوبش رو سریع، اشتباهش رو هم سریع. یه تصمیم معماری غلط، با سرعت ایجنت‌ها خیلی زودتر و بزرگ‌تر خودش رو نشون می‌ده. پس هر چی کد بیشتر رو ایجنت‌ها می‌نویسن، فکر کردن به سیستم بیشتر کار ما می‌شه. ▫️ عمیق شدن سر جاشه در GoCasts تا امروز سعی کردیم نگاه نسبتاً عمیقی به مباحث ریز و درشت سیستم‌ها داشته باشیم، و این رویه همچنان پابرجاست. قرار نیست عمیق شدن رو از دست بدیم، فقط قراره هوشمندانه‌ترش کنیم: اینکه چه چیزی ارزش عمیق شدن داره و چه چیزی رو می‌شه با خیال راحت به ایجنت‌ها سپرد. پس همچنان از چالش‌های مختلف مهندسی نرم‌افزار، عمیق و دقیق، صحبت می‌کنیم. این کانال قرار نیست فقط کانال agentها باشه. agentها به لیست اضافه شدن، جای چیزی رو نگرفتن. ممنون که همراه‌مون هستید ❤️ @gocasts

اینم از عمو باب که تسلیم شد! کاری ندارم که با ایشون هم نظر بودید و هستید یا نه. به دور از همه جنبه های فنی و اقتصادی ای که uncle bob داره من یه چیزی رو در ایشون خیلی بارز میدونم. تجربه نزدیک به ۶۰ سال برنامه نویسی! احتمالا هر چقدر جلوتر بریم کمتر درگیر کد خواهیم شد. نمیگم صفر میشه ولی خیلی خیلی کمتر از قبل خواهد شد. چون بیزینس‌ها انتظارشون متفاوت میشه و اعتمادشون هر روز به ایجنت‌ها بیشتر میشه. پس چه بخوایم چه نخوایم مجبور میشیم در این مسیر گام برداریم. https://x.com/unclebobmartin/status/2105647907705868659 بنده تقریبا یک سالی هست که ایده م اینه به عصر disposable code میرسیم، شاید کمی اغراق آمیز باشه، اما مسیری که در این یک سال طی شده خیلی هم اونو اغراق‌آمیز نمیکنه. اینجا در موردش نوشتم. https://t.me/gocasts/795 شاید سوال بشه که کدهای ai بعد از مدتی خیلی کثیف و غیره و غیره میشه. جواب اینه که مهم نیست چون ai خیلی راحت تر با اون کد برخورد میکنه بعلاوه اینکه راه های زیادی وجود داره ایجنت هارو تربیت کنیم که تمیز کد بزنن! https://x.com/unclebobmartin/status/2105713516359594054 چی سر مهندسی نرم افزار میاد؟ احتمال زیاد بازتعریف میشه و بخش عمده ای از مهارت هاش گره میخوره به ایجنت های هوش مصنوعی. مهندسی ایجنت ها، تربیت ایجنت ها، مدیریت ایجنت ها و هر چیز دیگه ای با ایجنت ها! کامنت uncle bob در همین زمینه مفیده https://x.com/unclebobmartin/status/2105715756746903610 نا امیدکننده ست؟ فکر نمیکنم، هنوز هم مهندس نرم افزار کلی مزیت داره نسبت به یه vibe coder صرف بودن، به شرطی که موقعیت فعلی ش گولش نزنه و غافل نباشه و agent engineering رو جدی بگیره... کار با ایجنت ها هزینه داره. اما صادقانه ناچاریم که جدی تر ببینیم این قضیه رو. چون شغل‌مونه و این هزینه رو باید جز هزینه‌های قطعی کارمون در نظر بگیریم.. @gocasts

ترکیب Sonnet 5.5 و Opus 5.5 این روزا خیلی خوب جواب میده. الگویی که برای من جواب داده اینه: کارای حجیم و تکراری (پیاده‌سازی، ریفکتور، نوشتن تست، پر کردن جزئیات) رو میدم به Sonnet 5.5. تصمیم‌های مهم رو میدم به Opus 5.5: طراحی، review، و جاهایی که اشتباه گرون تموم میشه. هزینه و سرعت متعادل میمونه و رو بخش‌های حساس هم کیفیت نمیاد پایین. چیزی که تازه حس کردم اینه که طول تسک‌های long-running از چند ساعت رسیده به چند روز. یکی دو بار پیش اومده که دو سه روز کار توسعه تو بک‌گراند جلو رفته و من اصلاً متوجه نشدم. نکته مهم‌ترش اینه که کار واقعاً پیش رفته بود. اینطوری نبود که چرت و پرت تولید کرده باشه. خروجی بی‌ربط نبود و میشد ادامه‌ش داد. این ماجرا با اکانت ۲۰ دلاری شدنیه و اگه با همون اکانت به محدودیت خوردید، اون موقع به فکر ارتقا باشید. البته هنوز باید نظارت داشته باشید در مراحل مختلف پروسه. ولی نسبت به چند ماه پیش، اعتماد به اینکه یه تسک بلند رو رها کنی خیلی بیشتر شده. یه نقش مهمی که به نظرم باید ایفا کنیم qa-engineer بودنه! https://x.com/adocomplete/status/2104638097678020992 @gocasts Ai for Software @aicasts_ir

ترکیب Sonnet 5.5 و Opus 5.5 این روزا خیلی خوب جواب میده. الگویی که برای من جواب داده اینه: کارای حجیم و تکراری (پیاده‌سازی، ریفکتور، نوشتن تست، پر کردن جزئیات) رو میدم به Sonnet 5.5. تصمیم‌های مهم رو میدم به Opus 5.5: طراحی، review، و جاهایی که اشتباه گرون تموم میشه. هزینه و سرعت متعادل میمونه و رو بخش‌های حساس هم کیفیت نمیاد پایین. چیزی که تازه حس کردم اینه که طول تسک‌های long-running از چند ساعت رسیده به چند روز. یکی دو بار پیش اومده که دو سه روز کار توسعه تو بک‌گراند جلو رفته و من اصلاً متوجه نشدم. نکته مهم‌ترش اینه که کار واقعاً پیش رفته بود. اینطوری نبود که چرت و پرت تولید کرده باشه. خروجی بی‌ربط نبود و میشد ادامه‌ش داد. این ماجرا با اکانت ۲۰ دلاری شدنیه و اگه با همون اکانت به محدودیت خوردید، اون موقع به فکر ارتقا باشید. البته هنوز باید نظارت داشته باشید در مراحل مختلف پروسه. ولی نسبت به چند ماه پیش، اعتماد به اینکه یه تسک بلند رو رها کنی خیلی بیشتر شده. یه نقش مهمی که به نظرم باید ایفا کنیم qa-engineer بودنه... @gocasts Ai for Software @aicasts_ir

از دوستان آروان اطلاع دادند مشکل ارتباطی (شبکه ای) از خارج از کشور هست و داخل ایران مسئله ای نیست.

کسی اطلاعی داره مشکل آروان چیه و کی وصل میشه؟

این بهترین تجربه‌ای بود که تا حالا با یه agent داشتم. دیشب با تاخیر چند ساعته ایمیل هاستینگ رو خوندم که نوشته بود «فردا ۸ صبح سرورتون رو با اسنپ‌شات می‌بریم روی زیرساخت جدید، IP عوض می‌شه، از دیتاتون بکاپ بگیرید، مسئولیتش با خودتونه.» سرور، تنها سرور پروداکشن یه سازمانه که تو پنج سال گذشته هر چیزی که لازم بوده روش نصب شده: چند تا استک داکر (Nuxt، دو تا Laravel، MySQL های جدا)، وردپرس روی php-fpm و MariaDB خود هاست، یه رجیستری خصوصی داکر، ۱۹ تا دیتابیس که نصفشون legacy‌ان، بیش از ۱۵ گیگ فایل و مدارک مهم سازمان، درگاه‌های بانکی که IP سرور رو whitelist کردن، و CentOS 7 که دو ساله EOL شده. دیسک ۹۹٪ پر بود و روش قدیمی بکاپ (tar بگیر، با HTTP دانلود کن) عملاً غیرممکن. کار ما عملاً ۱۲ شب شروع شد، یعنی ۸ ساعت تا مهاجرت. ابزار Claude Code با مدل Fable رو باز کردم و اول نقشه‌ی سرور رو کشید: کدوم سرویس کجاست، دیتا کجاست، چی به IP وابسته‌ست. بعد فهمید پهنای باند سرور به لپ‌تاپ من ۱۵۰ کیلوبایت بر ثانیه‌ست و ۱۵ گیگ عمراً تا صبح نمی‌رسه؛ رفت سراغ object storage داخلی که کلیدش از قبل روی سرور بود، rclone رو بدون sudo نصب کرد، آپلود رو تو tmux راه انداخت و با ۶ مگابایت بر ثانیه تو ۴۰ دقیقه تموم شد. dump دیتابیس‌ها رو گرفت و قبل از اینکه بگه «بکاپ داریم» روی لپ‌تاپ من restore کرد و ردیف‌ها رو شمرد. docker save ایمیج‌هایی که هیچ‌جای دیگه وجود نداشتن، کانفیگ‌ها، docker inspect همه‌ی کانتینرها، همه رفت. هم‌زمان یه runbook زنده نوشت: وضعیت، ریسک‌ها، پلن بکاپ با وضعیت هر آیتم، چک‌لیست تغییر IP، تست‌های بعد از انتقال، و دستور بازسازی از صفر اگه اسنپ‌شات خراب می‌شد. تو همین مسیر چند تا چیز پیدا کرد که خودم نمی‌دونستم: یه فایل nginx که روی IP قدیم listen می‌کرد و روی سرور جدید کل nginx رو زمین می‌زد (قبل از مهاجرت درستش کردیم)، اینکه کل زون DNS پشت CDN بود و TTL اصلاً مهم نبود، و گواهی‌های TLS مبدأ که شش هفته بود منقضی شده بودن و CDN قایمشون کرده بود. چیزی که این تجربه رو با هر ابزار دیگه‌ای فرق داد، همیشه‌آنلاین بودنش بود. من ساعت ۳ رفتم خوابیدم؛ Fable بیدار موند. هر ۵ دقیقه پیشرفت آپلود و تعداد خطاها رو چک می‌کرد، بعد از هر مرحله rclone check می‌زد و فایل‌ها رو با دیسک مقایسه می‌کرد، بعد که تصمیم گرفتم به‌خاطر تعویق احتمالی مهاجرت هیچ سرویسی رو stop نکنم، یه dump تکرارشونده‌ی ۵ دقیقه‌ای گذاشت که تا لحظه‌ی قطع سرور کار کرد و هر دور رو همون لحظه به storage می‌فرستاد. صبح که مهاجرت شروع شد، مانیتورش هر دقیقه IP قدیم و جدید رو می‌زد؛ لحظه‌ی قطع رو ثبت کرد، لحظه‌ی بالا اومدن سرور جدید رو گرفت، همون دقیقه SSH زد، شبکه و ۱۵ کانتینر و crash recovery هر دو MySQL و تعداد ردیف پرداخت‌ها و تعداد فایل‌ها رو با شب قبل مقایسه کرد، بعد یه مانیتور روی CDN گذاشت که تک‌تک دامنه‌ها کی ۲۰۰ برمی‌گردن، و بعد از اون هم تا یه ساعت، هر ۱۰ دقیقه پرداخت‌های موفق رو با همون ساعت دیروز و هفته‌ی قبل مقایسه کرد و نتیجه رو تو runbook نوشت تا مطمئن بشیم درآمد سازمان واقعاً برگشته. من صبح فقط ریویو می‌کردم، sudo می‌زدم و تصمیم می‌گرفتم؛ بقیه‌ش چشم و دست اون بود. نتیجه: حدود ۴۰ دقیقه downtime، که ۳۰ دقیقه‌ش زمان خود اسنپ‌شات و بوت سرور جدید توسط هاستینگ بود و ۱۰ دقیقه‌ی بعدش عوض کردن origin تو CDN به دست خودم. صفر داده از دست رفت؛ آخرین پرداخت قبل از قطع و اولین پرداخت بعدش با شمارش ردیف تأیید شد. بعدش هم یه hotfix فرانت داد که فقط درگاهی که IP جدید رو تأیید کرده بود فعال بمونه (با env، بدون rebuild برای برگردوندن بقیه) و تو همون مسیر یه باگ چندساله پیدا شد: هر فرم پرداختی که کاربر دست به رادیوباتن‌ها نمی‌زد به یه درگاه هاردکد می‌رفت. اغراق نمی‌کنم: اشتباه هم داشت (اولین نسخه‌ی fix ای که برای flush کش نوشت یه باگ quoting داشت و خودش تو دور بعد درستش کرد). واقعا لذت بردم از همراهی‌ش به عنوان یه همکار on-call که خسته نمی‌شه، همه چیز رو مستند می‌کنه و قبل از ادعا تست می‌کنه. آخراش روم نمیشد ازش کار بخوام میخواستم پرامپت بنویسم ناخودآگاه جلمه رو با «بیزحمت» شروع میکردم 😅. بدون اغراق احتمالا این بهترین تجربه‌ای بود که تا حالا با یه agent داشتم. @gocasts

بچه ها اگه تجربه software factory جدی داشتید توی شرکت و سازمان و محصول تون، بهم فیدبک بدید از چه ایجنت و ابزارهای open-source و غیره ای استفاده کردید و اگه خودتون توسعه دادید تجربه تون چی بوده، فرآیندهای توسعه و حتی فرآیندهای غیرفنی رو بهبود داده یا خیر. چالش ها و مشکلاتش چیه. @gocasts

در مورد پست دیشب که در لینکدین منتشر شد لازمه این نکته رو اضافه کنم که   https://lnkd.in/p/eGm7-M_B درسته که هیچ اشکالی نداره رزومه با هوش مصنوعی نوشته بشه، خودم هم این کارو میکنم، اما رزومه باید بازتابی از شخصیت و تجربیات شما باشه، وقتی با کلمات کلیشه ای پر بشه از نظر من عملا بی فایده میشه، درسته که شرکت ها در پروسه بازبینی اولیه از هوش مصنوعی برای ارزیابی استفاده میکنن، اما در نهایت گزینه های نهایی رو عامل انسانی بررسی میکنه، و اونجاست که مهم میشه رزومه شما بازتاب دهنده شماست، یا صرفا از کلماتی پر شده که ایجنت استخدام رو هک کنه... @gocasts

مارتین فاولر یه مطلب نوشته به اسم «I don't like LLMs». فاولر قبول داره که این ابزارها کار می‌کنن. حتی از Jessica Kerr نقل می‌کنه که استفاده نکردن ازشون غیرمسئولانه‌ست. مشکلش با کارایی‌شون نیست، با رفتارشونه. می‌گه ادای آدم رو درمیارن، و تازه ادای آدمی رو که اگه واقعی بود باهاش رفیق نمی‌شد. وقتی یه چیزی رو نمی‌دونن با همون اطمینانی که جواب درست می‌دن سرهمش می‌کنن، و اشتباهشون رو که بگی یه عذرخواهی سرسری می‌کنن و می‌رن سراغ جواب بعدی. لینک مطلبش رو گذاشتم، تمایل داشتید بخونید: https://martinfowler.com/articles/2026-dont-like-llms.html @gocasts

سلام به همه دوستان یکی از دوستان به همراه تیم‌ش سرویس CDN رو از صفر نوشتن — نه روی استک‌های آمادهٔ معمول. با مؤسسش جلسه داشتم؛ چیزی که دیدم این بود که تو مدت کوتاهی رشد خوبی داشتن. به گفتهٔ خودشون بالای ۷۰ مشتری دارن و در اوج قطعی‌های اینترنت، سرویس‌شون بالا مونده و از بیرون هم در دسترس بوده. دو تا ویژگی‌اش برام واقعاً جالب بود: ۱) لاگ کامل درخواست‌ها. یعنی می‌تونی ببینی دقیقاً چی از CDN رد شده، نه فقط چند تا نمودار کلی. برای دیباگ و تحلیل ترافیک ارزشش رو داره. ۲) سرویس Gateway. این یکی به درد خیلی‌هامون می‌خوره. از سرور ایران که می‌خوای به پروایدرهای خارجی ریکوئست بزنی، معمولاً به خاطر تحریم به ۴۰۳ می‌خوری. اینجا یه base URL روی دامنهٔ خودت می‌گیری و به جای آدرس اصلی توی کدت می‌ذاری: https://openrouter.ai/api/v1/chat/completions ↓ https://openrouter.yourdomain.com/api/v1/chat/completions برای OpenRouter، سرویس‌های گوگل، docker pull، رجیستری npm و مشابهش. به گفتهٔ خودشون حتی موقع قطعی اینترنت هم فعال می‌مونه. صادقانه: من خودم هنوز روی پروداکشن تستش نکردم، و این پست تبلیغ نیست. CDN خوب تو ایران کم داریم و ترجیح می‌دم تیمی که داره جدی روش کار می‌کنه دیده بشه. اگر امتحانش کردید حتماً بهم فیدبک بدید. 🔗 CDN: https://nsin.ir/products/cdn/ 🔗 Gateway: https://nsin.ir/products/gateways/ ثبت‌نام با ۱۰٪ تخفیف گوکست 🔗 https://panel.nsin.ir/auth/jwt/sign-up?ref=gocasts این فیچر ai crawlerها رو هم اینجا تو کانالشون میتونید بخونید در موردش https://t.me/nsin_ir/24 حمایته، نه تبلیغ ❤️ @gocasts

همکاران سیستم برگزار می‌کند: بوت‌کمپ برنامه‌نویسی Go ℹ️ آغاز دوره از ۲ مهرماه | ۴ جلسه ۴.۵ ساعته | ساعت ۸:۳۰ تا ۱۳ ‼️ در طی ۴ جلسه مباحث اصلی برنامه‌نویسی با زبان Go رو یاد میگیری و با انجام پروژه‌های کوچک به حل چالش‌ها و مسائل واقعی دنیای برنامه‌نویسی می‌پردازی. 🔺هزینه دوره: رایگان 📧 برای شرکت در این دوره کافیه رزومه‌ت رو برای ما ارسال کنی: Hr-Dev@systemgroup.net 🔷 سرفصل‌های بوت‌کمپ - Think in Go Familiarity with Go Program Structure, Data Types, Types, and Functions - Build with Go Methods، Interfaces، Abstraction, Packages - Go Beyond One Thread Goroutine، Channel، Shared State, Concurrency - Engineer with Confidence Development Tools, Testing, Project structure, and principles of writing reliable software ⌛ مهلت ارسال رزومه: سه‌شنبه ۳۱ شهریورماه ۱۴۰۵ 📍این دوره آموزشی به صورت حضوری در محل شرکت همکاران سیستم در شهر تهران برگزار می‌شه. لینکدین | اینستاگرام

یه نکته‌ی جذاب در مقاله‌ی جدید مهندسی Uber اینه که برای نصف‌کردن latency جست‌وجوی Uber Eats، فقط سراغ بهینه‌سازی مدل یا زیرساخت نرفتن؛ کل مسیر «تایپ‌کردن تا دیدن اولین نتایج» رو اندازه گرفتن. مثلاً hydration رو به دو بخش شکستن: داده‌هایی که ranking واقعاً لازم داره وارد critical path می‌شن و اطلاعات نمایشی مثل قیمت و تخفیف، هم‌زمان و جداگانه دریافت می‌شن. چند retrieval کم‌بازده رو هم حذف کردن، زنجیره‌ها رو زودتر deduplicate کردن و با گروه‌بندی آیتم‌های مشابه، تعداد lookupها رو بیشتر از ۱۰۰ برابر کاهش دادن. حتی در سرویس‌های Go، جای pointer و value type رو بازنگری کردن؛ چون در بعضی سرویس‌ها GC بیش از ۴۰٪ CPU رو مصرف می‌کرد. نمونه‌ی خوبی از این‌که performance معمولاً با یک ترفند عجیب بهتر نمی‌شه؛ بلکه باید کار اضافه، dependency اشتباه و allocationهای ریز روی hot path رو پیدا کرد! اما برای من، جذاب‌ترین بخش ماجرا agent loop اوبر بود. به یک coding agent هدف مشخص کاهش latency و ابزارهایی برای خواندن traceهای واقعی production، پیدا‌کردن spanهای کند، نوشتن fix، بازکردن PR و اجرای benchmark داده بودن. بعد agent در یک حلقه‌ی «اندازه‌گیری ← تشخیص ← اصلاح ← اعتبارسنجی» جلو می‌رفت تا یا به هدف برسه یا بازده تغییر بعدی از یک حد کمتر بشه. نکته‌ی مهم اینه که اینجا agent صرفاً کد تولید نمی‌کنه؛ به observability و verification وصل شده و هر تغییر باید اثر قابل‌اندازه‌گیری داشته باشه. برای اینکه افزایش سرعت کیفیت نتایج جست‌وجو رو خراب نکنه هم یک سیستم ارزیابی مبتنی بر LLM ساخته بودن تا feedback loop سریع‌تر بشه. به نظرم این دقیقاً یکی از کاربردهای جدی AI agentها در مهندسی نرم‌افزاره: سپردن بهینه‌سازی‌های کوچیک، کم‌هیجان ولی پرتعداد یا allocation نامناسب به سیستمی که پروداکشن رو مشاهده می‌کنه، تغییر می‌ده و نتیجه رو دوباره اندازه می‌گیره. https://www.uber.com/gb/en/blog/uber-eats-search-pipeline @gocasts

برخی از دوستان به درستی در کامنت ها اشاره کردن که ai باعث شده دیگه مثل قدیم از برنامه نویسی لذت نبرن. پاسخ بنده اینه که از یه جنبه هایی این حرف درسته. ولی از یه جنبه هایی هم آدم هیجان زده میتونه باشه. به شخصه تکنولوژی های فوق العاده متنوعی در یک دهه گذشته برای خودم لیست کرده بودم که یه روزی سعی کنم عمیق تر یادشون بگیرم و باهاشون یه محصولی رو توسعه بدم و لذت‌ش رو ببرم. لیست این ابزار و تکنولوژی و زبان ها اینقدر طولانی شده که هیچ وقت حتی نمیتونم ۱ درصدشون رو عملی کنم. اومدن ai یه هیجان و انرژی جدیدی رو به آدم میده. چون بهش اجازه میده که با صرف کردن زمان کمتری از تکنولوژی مد نظرش کمک بگیره و محصول تولید کنه و اون لذت نهایی که توسعه و ساختن با استفاده از تکنولوژی و ابزار محبوبش هست رو بهش برسه. درسته که در نهایت عمق دانشی که کسب میکنه به اندازه حالت بدون ai نمیشه. اما خب واقع بین اگه باشیم بدون ai احتمالا حتی ۱ درصد اون ابزار و تکنولوژی هارو نمیتونستیم تجربه کنیم. اما ai این اجازه رو میده که بصورت هوشمندانه و selective مفاهیم مهم تر هر تکنولوژی رو یاد بگیریم و باهاشون محصول توسعه بدیم و ازش لذت ببریم. از یاد نبریم که یکی از عوامل اصلی ای که ما نمیتونیم یادگیری یه چیز سخت رو ادامه بدیم اینه که خیلی زمان میبره که به یه خروجی ملموس برسیم. واسه همینه شاید همیشه یادگیری یه چیزی که خروجی ملموس داره مثل تکنولوژی های front-end برای خیلی ها ساده تره. چون در مراحل ابتدایی یادگیری به خروجی ملموس میرسی... با اومدن ai این قضیه میتونه برای سخت ترین تکنولوژی ها هم رخ بده و در خیلی از موارد بتونی از اول مسیر یادگیری خروجی ملموس داشته باشی که بهت انگیزه مضاعف بده برای طی کردن ادامه مسیر یادگیری این لینک کامنت ها https://t.me/c/1525472919/7803 https://t.me/c/1525472919/7810 که پاسخ کوتاهی در این کامنت نوشته م https://t.me/c/1525472919/7811 @gocasts