<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>کانال تلگرام on امین رشیدبیگی</title><link>https://aminrb.me/fa/categories/%DA%A9%D8%A7%D9%86%D8%A7%D9%84-%D8%AA%D9%84%DA%AF%D8%B1%D8%A7%D9%85/</link><description>Recent content in کانال تلگرام on امین رشیدبیگی</description><image><title>امین رشیدبیگی</title><url>https://aminrb.me/og-cover.jpg</url><link>https://aminrb.me/og-cover.jpg</link></image><generator>Hugo -- 0.148.2</generator><language>fa</language><lastBuildDate>Wed, 28 Oct 2026 16:24:55 +0000</lastBuildDate><atom:link href="https://aminrb.me/fa/categories/%DA%A9%D8%A7%D9%86%D8%A7%D9%84-%D8%AA%D9%84%DA%AF%D8%B1%D8%A7%D9%85/index.xml" rel="self" type="application/rss+xml"/><item><title>تک‌گراب برگشت، این‌بار بدون نیاز به من</title><link>https://aminrb.me/fa/%D8%AA%DA%A9-%DA%AF%D8%B1%D8%A7%D8%A8-%D8%A8%D8%B1%DA%AF%D8%B4%D8%AA-%D8%A7%DB%8C%D9%86-%D8%A8%D8%A7%D8%B1-%D8%A8%D8%AF%D9%88%D9%86-%D9%86%DB%8C%D8%A7%D8%B2-%D8%A8%D9%87-%D9%85%D9%86/</link><pubDate>Wed, 28 Oct 2026 16:24:55 +0000</pubDate><guid>https://aminrb.me/fa/%D8%AA%DA%A9-%DA%AF%D8%B1%D8%A7%D8%A8-%D8%A8%D8%B1%DA%AF%D8%B4%D8%AA-%D8%A7%DB%8C%D9%86-%D8%A8%D8%A7%D8%B1-%D8%A8%D8%AF%D9%88%D9%86-%D9%86%DB%8C%D8%A7%D8%B2-%D8%A8%D9%87-%D9%85%D9%86/</guid><description>&lt;p>احتمالاً می‌دونید که سال پیش کانال &lt;a href="https://t.me/TechGrub" target="_blank" rel="noopener noreferrer" >@TechGrub&lt;/a> رو راه انداختم. ایده این بود که هر روز یک پست دربارهٔ مهندسی نرم‌افزار، مدیریت یا هوش مصنوعی توش منتشر بشه. ایدهٔ ابتدایی هم از اینجا شروع شده بود که من قبلاً یک لیست طولانی از وبلاگ‌های افراد فعال حوزهٔ تک و شرکت‌ها داشتم و هر روز با یک RSS Reader نوشته‌های جدیدشون رو می‌خوندم.&lt;/p>
&lt;p>بعد یک بات تلگرام نوشتم که خودش این مطالب رو برمی‌داشت، خلاصه می‌کرد و برام می‌فرستاد. در ادامه همین رو تبدیل به یک کانال کردم: هر روز بهترین مطلب رو انتخاب می‌کردم، می‌رفت توی صف انتشار و روزی یک پست ارسال می‌شد.&lt;/p></description></item><item><title>تک‌تاک: تغییرات هوش مصنوعی و آیندهٔ بازار کار مهندسی نرم‌افزار</title><link>https://aminrb.me/fa/%D8%AA%DA%A9-%D8%AA%D8%A7%DA%A9-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1%D8%A7%D8%AA-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D9%88-%D8%A2%DB%8C%D9%86%D8%AF%D9%87%D9%94-%D8%A8%D8%A7%D8%B2%D8%A7%D8%B1-%DA%A9%D8%A7%D8%B1-%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1/</link><pubDate>Sun, 16 Nov 2025 14:19:34 +0000</pubDate><guid>https://aminrb.me/fa/%D8%AA%DA%A9-%D8%AA%D8%A7%DA%A9-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1%D8%A7%D8%AA-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D9%88-%D8%A2%DB%8C%D9%86%D8%AF%D9%87%D9%94-%D8%A8%D8%A7%D8%B2%D8%A7%D8%B1-%DA%A9%D8%A7%D8%B1-%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1/</guid><description>&lt;p>پنج‌شنبهٔ این هفته قراره که به مدت یک ساعت دربارهٔ تغییرات اخیر هوش مصنوعی و تأثیری که روی شرکت‌های تکنولوژی گذاشته صحبت کنیم. همچنین نگاهی می‌کنیم به این‌که الان در چه وضعیتی قرار داریم و مهم‌تر از همه، چه کارهایی می‌تونیم انجام بدیم تا شغل و مسیر حرفه‌ای‌مون رو امن‌تر نگه داریم و از فرصت‌های موجود بیشترین استفاده رو ببریم.&lt;/p>
&lt;p>📅 پنج‌شنبه ۲۹ آبان (20 Nov)&lt;br>
🕗 ساعت ۲۰ به وقت ایران (17:30 CET)&lt;br>
&lt;strong>🔗&lt;/strong> &lt;a href="https://meet.google.com/erc-paet-bec" target="_blank" rel="noopener noreferrer" >&lt;strong>لینک گوگل میت&lt;/strong>&lt;/a>&lt;br>
&lt;strong>🗓&lt;/strong> &lt;a href="https://calendar.app.google/XjXZGYKa7gBYox2i9" target="_blank" rel="noopener noreferrer" >&lt;strong>اضافه کردن به تقویم&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>جلوگیری از اثر زنجیره‌ای در سرویس‌ها (Cascading Effect)</title><link>https://aminrb.me/fa/%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%A7%D8%AB%D8%B1-%D8%B2%D9%86%D8%AC%DB%8C%D8%B1%D9%87-%D8%A7%DB%8C-%D8%AF%D8%B1-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-cascading-effect/</link><pubDate>Fri, 14 Nov 2025 09:01:29 +0000</pubDate><guid>https://aminrb.me/fa/%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%A7%D8%AB%D8%B1-%D8%B2%D9%86%D8%AC%DB%8C%D8%B1%D9%87-%D8%A7%DB%8C-%D8%AF%D8%B1-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-cascading-effect/</guid><description>&lt;p>هر محصول از چندین برنامهٔ قابل‌اجرا تشکیل شده که با رشد تیم و وسعت محصول، تعدادشون کم‌کم به ده‌ها یا حتی صدها برنامه می‌رسه.&lt;br>
سازمان‌ها معمولاً سرویس‌ها رو بر اساس اهمیت به چند سطح تقسیم می‌کنن: tier1، tier2، &amp;hellip; تا برای هر سطح SLA، آن‌کال، و ظرفیت منابع متفاوتی تعریف کنن.&lt;br>
به عنوان نمونه در مثال دیجیکالا، اپلیکیشن ثبت سفارش می‌تونه tier1 باشه چون مستقیم روی درآمد و تجربه‌ی کاربر اثر می‌ذاره، اما بخش لایو اینفلونسرها tier کم‌اولویت‌تری داره و اگر چند دقیقه هم از دسترس خارج بشه، اثرات خیلی کمتری داره.&lt;/p></description></item><item><title>شرکت‌های Bootstrap پایه‌گذاری شده توسط برنامه‌نویس‌ها</title><link>https://aminrb.me/fa/%D8%B4%D8%B1%DA%A9%D8%AA-%D9%87%D8%A7%DB%8C-bootstrap-%D9%BE%D8%A7%DB%8C%D9%87-%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%D8%B4%D8%AF%D9%87-%D8%AA%D9%88%D8%B3%D8%B7-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3-%D9%87%D8%A7/</link><pubDate>Tue, 07 Jan 2025 07:06:42 +0000</pubDate><guid>https://aminrb.me/fa/%D8%B4%D8%B1%DA%A9%D8%AA-%D9%87%D8%A7%DB%8C-bootstrap-%D9%BE%D8%A7%DB%8C%D9%87-%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%D8%B4%D8%AF%D9%87-%D8%AA%D9%88%D8%B3%D8%B7-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3-%D9%87%D8%A7/</guid><description>&lt;p>ما توی خبرها معمولاً از شرکت‌های بزرگ با فاند‌ها و سرمایه‌گذاری‌های میلیون‌دلاری خبر دار می‌شیم. اما لابه‌لای این این سازمان‌های عظیم، شرکت‌‌های کوچکتری هم هستن که با هزینهٔ شخصی سازندگانش و عموماً در تیم‌های کوچک رشد پیدا کردن. جذابیت این مدل شرکت‌ها در اینه که به صورت مستقل مسیرشون رو تعیین می‌کنن، سریع و به دور از کندی‌های رایج سازمان‌های بزرگ حرکت می‌کنن و برای رسیدن به اهداف مالی پاسخگوی عوامل بیرونی نیستن.&lt;/p></description></item><item><title>سال ۲۰۲۴ برای من سال پذیرش چالش‌ها و…</title><link>https://aminrb.me/fa/telegram-57/</link><pubDate>Thu, 26 Dec 2024 11:41:27 +0000</pubDate><guid>https://aminrb.me/fa/telegram-57/</guid><description>&lt;p>سال ۲۰۲۴ برای من سال پذیرش چالش‌ها و مسئولیت‌های جدید بود. توی این پست خلاصه‌ای از سالی که گذشت رو نوشتم.&lt;/p>
&lt;p>&lt;a href="https://aminrb.me/2024-in-review/" >&lt;strong>2024 in Review&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>شاپیفای آماری از Black Friday امسال منتشر کرده…</title><link>https://aminrb.me/fa/telegram-56/</link><pubDate>Wed, 18 Dec 2024 16:43:29 +0000</pubDate><guid>https://aminrb.me/fa/telegram-56/</guid><description>&lt;p>شاپیفای &lt;a href="https://x.com/ShopifyEng/status/1863953414742257740" target="_blank" rel="noopener noreferrer" >آماری&lt;/a> از Black Friday امسال منتشر کرده که اعدادش حیرت آوره 🤯&lt;/p>
&lt;ul>
&lt;li>پردازش 7TB خط لاگ در دقیقه&lt;/li>
&lt;li>پاسخ دادن به ۱۷۰ میلیون درخواست در دقیقه (2M rps)&lt;/li>
&lt;li>استفاده از ۲.۴ میلیون CPU Core بر روی کوبرنتیز&lt;/li>
&lt;li>پاسخ دادن به ۴۵ میلیون کوئری بر ثانیه با MySQL (!)&lt;/li>
&lt;li>پردازش ۶۶ میلیون پیام کافکا در ثانیه&lt;/li>
&lt;/ul></description></item><item><title>چه کاری رو می‌تونستیم متفاوت انجام بدیم تا…</title><link>https://aminrb.me/fa/telegram-55/</link><pubDate>Tue, 17 Dec 2024 16:09:03 +0000</pubDate><guid>https://aminrb.me/fa/telegram-55/</guid><description>&lt;p>چه کاری رو می‌تونستیم متفاوت انجام بدیم تا جلوی این اتفاق رو بگیریم؟&lt;/p>
&lt;p>این سوالیه که بعد از رخ دادن یک باگ، یک دیپلوی اشتباه، پاک شدن اشتباهی داده‌ها یا حتی شکست خوردن یک پروژه از خودمون و از تیم می‌پرسیم. معمولاً خروجی این سوال تبدیل به تعدادی تسک و یا داکیومنت‌هایی مثلpost mortem می‌شه.&lt;/p>
&lt;p>دیروز &lt;a href="https://x.com/norootcause/status/1868127337407209875" target="_blank" rel="noopener noreferrer" >این توییت&lt;/a> رو از Lorin Hochstein خوندم که معتقد بود که این سوال، سوال خوبی نیست و ممکنه ریشهٔ اصلی مشکل رو نشون نده و از آماده شدن برای رخ دادن مجدد مشکل جلوگیری کنه. پیشنهاد داده‌ بود که به جاش سعی کنیم که لحظهٔ به وجود اومدن مشکل رو از زاویه دید افراد درگیر در اون بازهٔ زمانی ببینیم. ای پرسش رو مطرح کنیم که اون‌ها در اون زمان چی می‌دیدن و چه داده‌هایی در دست داشتن که به تصمیم‌گیری اشتباه منتج شده. با جواب دادن به این سوال‌ها شاید دقیق‌تر متوجه ریشهٔ تصمیم‌های اشتباه بشیم.&lt;/p></description></item><item><title>پیش‌نیازهای تیمی با اونرشیپ بالا</title><link>https://aminrb.me/fa/%D9%BE%DB%8C%D8%B4-%D9%86%DB%8C%D8%A7%D8%B2%D9%87%D8%A7%DB%8C-%D8%AA%DB%8C%D9%85%DB%8C-%D8%A8%D8%A7-%D8%A7%D9%88%D9%86%D8%B1%D8%B4%DB%8C%D9%BE-%D8%A8%D8%A7%D9%84%D8%A7/</link><pubDate>Sun, 15 Dec 2024 15:29:44 +0000</pubDate><guid>https://aminrb.me/fa/%D9%BE%DB%8C%D8%B4-%D9%86%DB%8C%D8%A7%D8%B2%D9%87%D8%A7%DB%8C-%D8%AA%DB%8C%D9%85%DB%8C-%D8%A8%D8%A7-%D8%A7%D9%88%D9%86%D8%B1%D8%B4%DB%8C%D9%BE-%D8%A8%D8%A7%D9%84%D8%A7/</guid><description>&lt;p>در انتهای &lt;a href="https://t.me/aminrbg/53" target="_blank" rel="noopener noreferrer" >&lt;u>این پست&lt;/u>&lt;/a> پرسیدم که چه فضاهایی در تیم باید وجود داشته باشه که افراد تمایل بیشتری برای گرفتن مسئولیت کارها در خارج از وظایف عادیشون داشته باشن؟ طبق توضیح دوستان و البته تجربهٔ شخصی من، افرادی که علاقه‌مند به رشد و یادگیری در حیطه‌هایی خارج از وظایفشون هستن، در شرایط مختلف، رفتارهای متفاونی از خودشون نشون می‌دن. این افراد با کار کردن در یک تیم می‌تونن اونرشیپ خیلی بالایی از خودشون نشون بدن و در تیم دیگری نه.&lt;br>
حالا چه ويژگی‌هایی باعث میشه تیم تبدیل به بستری برای ایجاد اونرشیپ بالا در اعضاش بشه؟&lt;/p></description></item><item><title>اونرشیپ به چه معناست؟</title><link>https://aminrb.me/fa/%D8%A7%D9%88%D9%86%D8%B1%D8%B4%DB%8C%D9%BE-%D8%A8%D9%87-%DA%86%D9%87-%D9%85%D8%B9%D9%86%D8%A7%D8%B3%D8%AA/</link><pubDate>Thu, 12 Dec 2024 10:26:00 +0000</pubDate><guid>https://aminrb.me/fa/%D8%A7%D9%88%D9%86%D8%B1%D8%B4%DB%8C%D9%BE-%D8%A8%D9%87-%DA%86%D9%87-%D9%85%D8%B9%D9%86%D8%A7%D8%B3%D8%AA/</guid><description>&lt;p>توی &lt;a href="https://t.me/aminrbg/52" target="_blank" rel="noopener noreferrer" >این پست&lt;/a> نوشتم که همهٔ مدیرها دوست دارن اعضای تیمشون ownership بالایی نسبت به محصول داشته باشن. اما خیلی وقت‌ها این اتفاق نمی‌افته.&lt;br>
طبق تجربهٔ من، اعضای تیم هم معمولاً کم‌ و بیش علاقه‌مندن که نسبت به کارها ownership داشته باشن. پس وقتی که دو طرف یک خواستهٔ مشترک دارن، چرا همیشه این اتفاق نمیفته؟&lt;/p>
&lt;p>قبل از جواب دادن به این سوال خوبه که ابتدا به درک مشترکی از سه مفهوم Ownership، Responsibility و Accountability برسیم. توی فارسی تفکیک این سه مورد یکم سخته و بعضاً به جای هم به کار می‌رن. من تعریف این سه واژه روی از &lt;a href="https://www.signalkey.com/articles/2022/10/4/responsibility-accountability-ownership-definitions-distinctions-and-how-they-add-up-to-a-healthy-team" target="_blank" rel="noopener noreferrer" >این نوشته&lt;/a> برداشتم که به نظرم توضیح واقعی‌تری برای این مفاهیم ارائه داده.&lt;/p></description></item><item><title>تصور کنید مدیر تیمی هستید و این جملات…</title><link>https://aminrb.me/fa/telegram-52/</link><pubDate>Mon, 09 Dec 2024 15:54:13 +0000</pubDate><guid>https://aminrb.me/fa/telegram-52/</guid><description>&lt;p>تصور کنید مدیر تیمی هستید و این جملات زیر رو از یکی از اعضای تیمتون می‌شنوید:&lt;/p>
&lt;ul>
&lt;li>توی code baseامون تعدادی &lt;a href="https://aminrb.me/fa/%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%A8%D8%AF%D9%87%DB%8C-%D9%87%D8%A7%DB%8C-%D9%81%D9%86%DB%8C/" >بدهی فنی&lt;/a> مهم داریم که روند توسعهٔ فیچرهامون رو کند کرده. من اون‌ها رو با نوشتن میزان اهمیت و پیچیدگی حلشون لیست کردم.&lt;/li>
&lt;li>هفتهٔ بعد که مرخصی هستی من دیلی‌ها رو برگزار می‌کنم.&lt;/li>
&lt;li>دیروز یک مشکلی توی منطق کد پیدا کردم و درستش کردم. این هم گزارش خسارت‌های احتمالیه که به وجود آورده.&lt;/li>
&lt;li>من علاقه‌مندم که کل هماهنگی‌های فیچر جدیدمون رو خودم پیش ببرم. صرفاً می‌خوام که بر روی کارم نظارت داشته باشی تا مسیر رو اشتباه نرم.&lt;/li>
&lt;/ul>
&lt;p>از جملات بالا چه حسی پیدا می‌کنید؟&lt;/p></description></item><item><title>تصور کنید که خیلی متمرکز بر روی محصولی…</title><link>https://aminrb.me/fa/telegram-50/</link><pubDate>Fri, 15 Nov 2024 11:10:52 +0000</pubDate><guid>https://aminrb.me/fa/telegram-50/</guid><description>&lt;p>تصور کنید که خیلی متمرکز بر روی محصولی کار می‌کنید، که مدیریتون به یک باره اعلام می‌کنه که: «پروژه رو همینجا متوقف می‌کنیم و از این پس این مسیر جدید رو دنبال می‌کنیم.»&lt;/p>
&lt;p>اگر این تغییر برای شما منطقی نباشه، احتمالاً در مرحلهٔ اول مقاومت می‌کنید. اما احتمالاً به زودی متوجه می‌شید که تغییر دادن تصمیمی که گرفته شده خیلی آسون نیست. پس چه کار باید کرد؟&lt;/p>
&lt;p>برخی افراد، از جمله خودِ قبلیِ من، ممکنه به تلاش برای ارائهٔ دلایل منطقی برای ادامهٔ مسیر پافشاری کنن؛ که در نهایت باعث بشه انگیزه‌اشون از دست بره و پروژه و یا شرکت رو ترک کنن. امّا این می‌تونه تنها انتخاب موجود نباشه.&lt;/p></description></item><item><title>از صفحاتی جالبی که امروز به چشمم خورد…</title><link>https://aminrb.me/fa/telegram-49/</link><pubDate>Sun, 10 Nov 2024 19:37:46 +0000</pubDate><guid>https://aminrb.me/fa/telegram-49/</guid><description>&lt;p>از صفحاتی جالبی که امروز به چشمم خورد &lt;a href="https://www.jmeiners.com/lc3-vm/" target="_blank" rel="noopener noreferrer" >Write your Own Virtual Machine&lt;/a> بود.&lt;/p>
&lt;p>این صفحه به صورت خیلی ساده و قدم به قدم ساختن یک VM رو توضیح می‌ده و با خوندنش گذاری به معماری کامپیوتر، مدیریت حافظه و اسمبلی می‌زنید.&lt;/p></description></item><item><title>Tech Radar volume 31</title><link>https://aminrb.me/fa/tech-radar-volume-31/</link><pubDate>Fri, 01 Nov 2024 17:12:48 +0000</pubDate><guid>https://aminrb.me/fa/tech-radar-volume-31/</guid><description>&lt;p>گزارش تک رادار ۳۱ منتشر شد. این گزارش هر شش ماه یک بار توسط Thoughtworks و به قلم تعدادی از لیدرهای شرکت‌های مهندسی منتشر میشه. در هر نسخهٔ گزارش، تغییرات دنیای نرم‌افزار در چهار زمینهٔ Techniques, Tools, Platforms, and Languages &amp;amp; Frameworks بررسی میشه.&lt;/p>
&lt;p>محورهای اصلی گزارش این نسخه به این صورته:&lt;br>
— Coding assistance antipatterns&lt;br>
— Rust is anything but rusty&lt;br>
— The gradual rise of WASM (Web Assembly)&lt;br>
— The Cambrian explosion of generative AI tools&lt;/p></description></item><item><title>در دورهٔ کنونی LLMها، میگن که تنها محدودیتی…</title><link>https://aminrb.me/fa/telegram-46/</link><pubDate>Sat, 26 Oct 2024 13:56:04 +0000</pubDate><guid>https://aminrb.me/fa/telegram-46/</guid><description>&lt;p>در دورهٔ کنونی LLMها، میگن که تنها محدودیتی که داریم خلاقیتمونه. الان ما می‌تونیم خیلی سریع‌تر و با وابستگی خیلی کمتر به افراد متخصص، ایده‌هامون رو پیاده‌سازی، تست و ارزیابی کنیم.&lt;br>
در حال حاضر اکثر LLMها برای استفاده‌های عمومی به صورت رایگان در دسترس هستن؛ اما برای بکارگیری قدرتشون در محصول‌هایی که توسعه می‌دیم به APIهاشون نیاز داریم که عموماً رایگان نیست و برای بعضی از کاربردها می‌تونن خیلی هم گرون باشن.&lt;/p></description></item><item><title>گوگل اخیراً ابزاری رو منتشر کرده که من…</title><link>https://aminrb.me/fa/telegram-45/</link><pubDate>Fri, 18 Oct 2024 14:35:59 +0000</pubDate><guid>https://aminrb.me/fa/telegram-45/</guid><description>&lt;p>گوگل اخیراً ابزاری رو منتشر کرده که من رو به وجد آورده. &lt;a href="https://notebooklm.google/" target="_blank" rel="noopener noreferrer" >&lt;strong>&lt;u>NotebookLM&lt;/u>&lt;/strong>&lt;/a> لینک وبسایت، لینک یوتیوب، فایل و یا متن خام ازتون می‌گیره و با سرعت زیادی داده‌های مورد نظرتون رو با فرمت دلخواه استخراج می‌کنه.&lt;br>
برای مثال می‌تونید ازش بخواید که یک ویدیو یوتیوب رو براتون خلاصه کنه.&lt;/p>
&lt;p>تفاوتی که این ابزار با ابزارهای مشابه داره، یکی اینه که می‌تونید به تعداد دلخواه منابع مختلفی بهش بدید و ازش خروجی بخواید، دو این که می‌تونه به فرمت‌های غیرمتنی خروجی مطلوبتون رو تولید کنه.&lt;/p></description></item><item><title>The Senior Shortcut</title><link>https://aminrb.me/fa/the-senior-shortcut/</link><pubDate>Sun, 13 Oct 2024 15:20:26 +0000</pubDate><guid>https://aminrb.me/fa/the-senior-shortcut/</guid><description>&lt;p>بعد از شروع موج layoffهای یکی دو سال گذشته و همچنین ظهور AI به عنوان یک یار کمکی برای افزایش سرعت توسعهٔ نرم‌افزارها، شرکت‌ها موقعیت‌های شغلی جونیور رو کمتر و کمتر کردن و دیگه خیلی از شرکت‌ها فقط سینیور استخدام می‌کنن.&lt;/p>
&lt;p>در این نوشته، Camille Fournier که نویسندهٔ کتاب معروف The Manager&amp;rsquo;s Path هستش، نقدی به این رویکرد شرکت‌ها داره و از نظر ایشون این کار در بلندمدت نتیجهٔ عکس خواهد داشت.&lt;br>
همچنین از نظر ایشون تقسیم‌بندی مهندس‌ها به junior و senior به خصوص در دورهٔ کنونی خیلی درست نیست و بهتره افراد رو به early career و افراد باتجربه تقسیم کنیم.&lt;/p></description></item><item><title>Secret Rotation</title><link>https://aminrb.me/fa/secret-rotation/</link><pubDate>Fri, 11 Oct 2024 15:16:03 +0000</pubDate><guid>https://aminrb.me/fa/secret-rotation/</guid><description>&lt;p>سکرت روتیشن به این صورت تعریف می‌شه که در بازه‌های معینی، یکی از سکرت‌ها و یا همهٔ سکرت‌های سیستمتون رو عوض کنید. این سکرت می‌تونه پسورد‌ها، کلید APIها و یا هر دادهٔ حساس دیگری باشه.&lt;br>
هدف این کار کاهش بازهٔ زمانی معتبر بودن این سکرت‌ها و کاهش خسارت بعد از لیک شدن داده‌ها است.&lt;/p>
&lt;p>بذارین چندتا حالت فرضی رو مثال بزنم.&lt;/p>
&lt;ul>
&lt;li>فرض کنید کلید مهمی در بین افراد و پروژه‌های مختلف به اشتراک گذاشته شده. افراد از شرکت می‌رن ولی کماکان این کلید رو در اختیار دارن.&lt;/li>
&lt;li>دولوپری پسورد سرویسی رو به اشتباه کامیت می‌کنه.&lt;/li>
&lt;li>دولوپرها در لاگ کردن خطاها دقت کافی نداشتن و سکرت مهمی به اشتباه لاگ شده (چه در سرویس‌های داخلی، چه در پروایدرهای خارجی مثل Sentry).&lt;/li>
&lt;/ul>
&lt;p>اگر به هر کدوم از این موارد آگاه باشید احتمالاً سکرت رو عوض خواهید کرد. اما ممکنه به این مسئله آگاه نباشید و برای جلوگیری از لیک شدن داده‌ها تلاشی نکنید. سکرت روتیشن کمک می‌کنه که این تغییرات رو به یک پروسه تبدیل کنید و به اطلاع‌رسانی افراد وابسته نباشید.&lt;/p></description></item><item><title>دیروز برام ایمیل اومد که دامنهٔ expedition-diaries داره…</title><link>https://aminrb.me/fa/telegram-41/</link><pubDate>Mon, 23 Sep 2024 17:40:45 +0000</pubDate><guid>https://aminrb.me/fa/telegram-41/</guid><description>&lt;p>دیروز برام ایمیل اومد که دامنهٔ expedition-diaries داره منقضی میشه.&lt;/p>
&lt;p>چند سال پیش چالشی برای خودم تعریف کردم که پروژه‌ای رو شروع کنم و همهٔ بخش‌های مختلفش مثل بکند و فرانت‌اند و زیرساخت رو خودم پیش ببرم. قبلاً در هر کدوم از این بخش‌ها تجربه‌های مستقلی داشتم اما هرگز فرصت توسعهٔ همهٔ این بخش‌ها در کنار هم و با هم رو نداشتم. از طرفی هم برای هر کدوم از این بخش‌ها اهداف متفاوتی داشتم:&lt;/p></description></item><item><title>چند وقت پیش فایل‌های Protocol Buffer پروژه‌ای رو…</title><link>https://aminrb.me/fa/telegram-40/</link><pubDate>Mon, 19 Aug 2024 19:33:13 +0000</pubDate><guid>https://aminrb.me/fa/telegram-40/</guid><description>&lt;p>چند وقت پیش فایل‌های Protocol Buffer پروژه‌ای رو مرتب‌ می‌کردم که دیدم این دو فیلد در بین چندین message پروژه تکرار شده:&lt;/p>
&lt;pre tabindex="0">&lt;code>message A {
    ...
    int64 seconds = n;
    int64 nano_seconds = m;
    ...
}
&lt;/code>&lt;/pre>&lt;p>با توجه به این که این دو خط عیناً تکرار شده بود، یک message تعریف کردم و به جای اون دوتا فیلد از message جدید استفاده کردم:&lt;/p>
&lt;pre tabindex="0">&lt;code>message Timestamp {
    int64 seconds = 1;
    int64 nano_seconds = 2;
}
message A {
    ...
    Timestamp timestamp_utc = p;
    ...
}
&lt;/code>&lt;/pre>&lt;p>بعداً متوجه شدم که &lt;code>Timestamp&lt;/code> هم یکی از تایپ‌هاییه که به صورت استاندارد تعریف شده و نیازی نیست خودمون تعریف کنیم. به همین خاطر message‌ها رو به دوباره بازنویسی کردم:&lt;/p></description></item><item><title>"معذرت می‌خوام". آیا همین کافی است؟</title><link>https://aminrb.me/fa/%D9%85%D8%B9%D8%B0%D8%B1%D8%AA-%D9%85%DB%8C-%D8%AE%D9%88%D8%A7%D9%85-%D8%A2%DB%8C%D8%A7-%D9%87%D9%85%DB%8C%D9%86-%DA%A9%D8%A7%D9%81%DB%8C-%D8%A7%D8%B3%D8%AA/</link><pubDate>Sat, 10 Aug 2024 13:03:38 +0000</pubDate><guid>https://aminrb.me/fa/%D9%85%D8%B9%D8%B0%D8%B1%D8%AA-%D9%85%DB%8C-%D8%AE%D9%88%D8%A7%D9%85-%D8%A2%DB%8C%D8%A7-%D9%87%D9%85%DB%8C%D9%86-%DA%A9%D8%A7%D9%81%DB%8C-%D8%A7%D8%B3%D8%AA/</guid><description>&lt;p>یادداشتی در مورد اشتباه کردن.&lt;/p>
&lt;p>در گذشته کار کردن معنای متفاوتی با الان داشت. کمتر نیاز بود که افراد هر روزه تصمیم‌های متعددی بگیرن. هرچی جلوتر می‌ریم، فضایی که توش کار می‌کنیم و ابزارهایی که باهاشون کار می‌کنیم پیچیده‌تر و متنوع‌تر می‌شن. توی این شرایط، ابهام و عدم قطعیت هم بالاتر میره.&lt;/p>
&lt;p>کار خیلی ماها اینه که توی این عدم قطعیت تصمیم‌های هر روزه بگیریم. معمولاً شرکت‌ها هم بیشترین حقوق و مزایا رو به افرادی می‌دن که تصمیم‌های بزرگ‌تر، مهم‌تر و پرریسک‌تر می‌گیرن. از طرفی هم دانش و آگاهی ما به مسائل محدوده و همیشه همهٔ داده‌های لازم رو در اختیار نداریم. اساساً اگر میشد همه این داده‌ها رو در اختیار داشت، احتمالاً شرکت‌ها هم نیازی به استخدام این همه نیروی متخصص و با این هزینه گزاف نداشتن.&lt;/p></description></item><item><title>How to create software quality.</title><link>https://aminrb.me/fa/how-to-create-software-quality/</link><pubDate>Thu, 27 Jun 2024 18:04:16 +0000</pubDate><guid>https://aminrb.me/fa/how-to-create-software-quality/</guid><description>&lt;p>کیفیت نرم‌افزار چیه دقیقاً؟ اگر برای توسعهٔ یک محصولی Automated Test خیلی خوبی توسعه بدیم می‌تونیم بگیم که کیفیت بهتر شده؟ یا این که اگر برای دیپلوی‌ها Automated Rollouts داشته باشیم می‌تونیم بگیم حتماً کیفیت رو بهبود دادیم؟&lt;/p>
&lt;p>توی این نوشته Will Larson سعی کرده مشاهدات و تجربیاتش در مورد کیفیت نرم‌افزار رو جمع‌آوری کنه و خلاصه کنه.&lt;/p>
&lt;p>در ابتدا سعی می‌کنه یک تعریف کلی از کیفیت ارائه بده. بعد این مسئله رو به پیچیدگی محصولی که داریم روش کار می‌کنیم ارتباط می‌ده. در ادامه هم به برخی موضوعات دیگر پیرامون همین موضوع می‌پردازه.&lt;/p></description></item><item><title>My Thoughts on The Clean Coder Book</title><link>https://aminrb.me/fa/my-thoughts-on-the-clean-coder-book/</link><pubDate>Mon, 24 Jun 2024 18:39:23 +0000</pubDate><guid>https://aminrb.me/fa/my-thoughts-on-the-clean-coder-book/</guid><description>&lt;p>مدتی پیش کتاب The Clean Coder از Uncle Bob رو خوندم.&lt;br>
کتاب عموماً موضوعات سطح بالای مهندسی نرم‌افزار مثل اهمیت تست کردن کد، نحوهٔ مدیریت ددلاین‌ها، تمرین زبان‌های جدید برنامه‌نویسی و &amp;hellip; رو مطرح کرده بود.&lt;/p>
&lt;p>بعضی از بخش‌های کتاب برام تازگی داشت و یا موضوعاتی که از قبل بهشون آشنا بودم رو مجدداً بهم یادآوری کرد. توی این پست نظرم رو دربارهٔ بعضی از این موارد نوشتم.&lt;/p>
&lt;p>🔗 &lt;a href="https://aminrb.me/the-clean-coder/" >&lt;strong>لینک نوشته&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>Ten Years and Counting: My Affair with Microservices</title><link>https://aminrb.me/fa/ten-years-and-counting-my-affair-with-microservices/</link><pubDate>Sat, 15 Jun 2024 15:04:51 +0000</pubDate><guid>https://aminrb.me/fa/ten-years-and-counting-my-affair-with-microservices/</guid><description>&lt;p>چند هفته پیش همایون توی لینکداین این پست رو به اشتراک گذاشته بود و امروز فرصت کردم که بخونمش. یکی از مهندس‌های شرکت allegro که ده سال اخیر رو توی این شرکت بوده و تغییر و تکامل قسمت‌های مختلف فنی شرکت رو دیده این پست رو نوشته. نویسنده با لحن خیلی ساده و از نظر من فروتنانه‌ای از تغییرات معماری، زبان برنامه‌نویسی، دیتابیس‌ها، فرهنگ شرکت و &amp;hellip; نوشته.&lt;/p>
&lt;p>من این یک خط از متن پست رو خیلی دوست داشتم:&lt;/p></description></item><item><title>استک‌اورفلو هر سال گزارش کاملی از دنیای برنامه‌نویسی…</title><link>https://aminrb.me/fa/telegram-33/</link><pubDate>Wed, 12 Jun 2024 11:12:33 +0000</pubDate><guid>https://aminrb.me/fa/telegram-33/</guid><description>&lt;p>استک‌اورفلو هر سال گزارش کاملی از دنیای برنامه‌نویسی و بر اساس نظرسنجی از برنامه‌نویس‌ها ارائه می‌ده. اخیراً هم برای ۲۰۲۴ هم این نظرسنجی رو شروع کرده.&lt;br>
اگر علاقه‌مند بودید پیشنهاد می‌کنم شرکت کنید تا بتونن آمار دقیق‌تری (به طور خاص در مورد ایران) ارائه بدن. حدوداً ۲۰ دقیقه طول می‌کشه تا به سوالاتش جواب بدید.&lt;/p>
&lt;p>🔗 &lt;a href="https://stackoverflow.az1.qualtrics.com/jfe/form/SV_6rJVT6XXsfTo1JI?utm_medium=referral&amp;amp;utm_source=metaexchange-community&amp;amp;utm_campaign=dev-survey-2024&amp;amp;utm_content=meta-post" target="_blank" rel="noopener noreferrer" >&lt;strong>لینک نظرسنجی&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>What is DDD - Eric Evans - DDD Europe 2019</title><link>https://aminrb.me/fa/what-is-ddd-eric-evans-ddd-europe-2019/</link><pubDate>Sat, 25 May 2024 14:03:19 +0000</pubDate><guid>https://aminrb.me/fa/what-is-ddd-eric-evans-ddd-europe-2019/</guid><description>&lt;p>آقای Eric Evans که پدیدآورندهٔ نگاه Domain-Driven Design هستش، توی این ویدیو سعی می‌کنه که خیلی سطح بالا اهمیت Domain و Model و تفاوت‌هاشون رو در طراحی‌های نرم‌افزاری توضح بدن.&lt;br>
برای این کار هم از چندین مثال واقعی استفاده می‌کنه تا تفاوت شیوه‌های مختلف Model کردن یک مسئله در دنیای واقعی به طراحی نرم‌افزاری رو نشون بده.&lt;/p>
&lt;p>🔗 &lt;a href="https://www.youtube.com/watch?v=pMuiVlnGqjk" target="_blank" rel="noopener noreferrer" >&lt;strong>لینک ویدیو&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>Scaling to Count Billions - Canva Engineering Blog</title><link>https://aminrb.me/fa/scaling-to-count-billions-canva-engineering-blog/</link><pubDate>Fri, 17 May 2024 14:19:46 +0000</pubDate><guid>https://aminrb.me/fa/scaling-to-count-billions-canva-engineering-blog/</guid><description>&lt;p>تولیدکننده‌های محتواهای هنری مثل لوگو، تمپلیت عکس و &amp;hellip; می‌تونن محصولاتشون رو برای فروش توی Canva بذارن تا کاربرها بتونن این محصولات رو بخرن و توی طراحی‌هاشون استفاده کنن. توی این نوشته از بلاگ فنی Canva، به چالش پرداخت سهم این تولیدکننده‌ها پرداختن.&lt;/p>
&lt;p>نویسنده‌ از اینجا شروع کرده که در ابتدا طراحی رو خیلی ساده و ابتدایی پیش بردن و به مرور مقیاس بزرگ شده و باعث شده که کدها خیلی پیچیده بشن و دیباگ‌هم سخت‌تر شده. بعد نحوهٔ بازطراحی سیستم‌ها و تغییر تکنولوژی‌ها رو توضیح دادن. دوتا تغییر کلی که دادن به این شکل بوده:&lt;/p></description></item><item><title>Vector Search: An Introduction</title><link>https://aminrb.me/fa/vector-search-an-introduction/</link><pubDate>Tue, 16 Apr 2024 07:35:28 +0000</pubDate><guid>https://aminrb.me/fa/vector-search-an-introduction/</guid><description>&lt;p>من در بازهٔ اخیر زمان قابل توجهی بر روی مسئلهٔ‌ جستجوی برداری یا vector search گذاشتم. این شیوهٔ جستجو که چند سالیه که بیشتر باب شده و در شرکت‌های بزرگی مثل Netflix و Pinterest به کار گرفته میشه، این امکان رو میده که بر روی مدیاهای غیر متنی مثل صوت، تصویر و ویدیو هم جستجو کنیم. جدا از این مدیاهای غیرمتنی، می‌تونه کمک کنه که جستجوی متنی بهتری رو هم داشته باشیم و به کمکش بر روی اطلاعات استنباط شده از متن جستجو کنیم.&lt;/p></description></item><item><title>Popular git config options - Julia Evans</title><link>https://aminrb.me/fa/popular-git-config-options-julia-evans/</link><pubDate>Thu, 28 Mar 2024 16:41:49 +0000</pubDate><guid>https://aminrb.me/fa/popular-git-config-options-julia-evans/</guid><description>&lt;p>تنظیمات و کانفیگ‌های git در یک فایل به آدرس &lt;code>~/.gitconfig&lt;/code> ذخیره شده. شما می‌تونین تنظیمات دیفالت گیت رو با تغییر این فایل و یا داخل پروژه و به صورت locally تغییر بدین. Julia Evans توی این پست از git configهایی نوشته که احتمالاً شما هم مثل من از خیلی‌هاشون خبر نداشتین که اتفاقاً می‌تونن خیلی هم کاربردی باشن.&lt;/p>
&lt;p>چند تا از configهایی که خودم بعد از خوندن این نوشته اعمال کردم:&lt;/p></description></item><item><title>How Netflix builds a culture of excellence | Elizabeth Stone (CTO)</title><link>https://aminrb.me/fa/how-netflix-builds-a-culture-of-excellence-elizabeth-stone-cto/</link><pubDate>Fri, 22 Mar 2024 09:26:39 +0000</pubDate><guid>https://aminrb.me/fa/how-netflix-builds-a-culture-of-excellence-elizabeth-stone-cto/</guid><description>&lt;p>این روزهای تعطیلی اول سال نشستم به خوندن کتاب و دیدن ویدیوهای افراد خوش‌ذهنی مثل Elizabeth Stone. ایشون با وجود این که تحصیلات دانشگاهی اقتصاد دارن، الان CTO شرکت high techای مثل نتفلیکس هستن.&lt;br>
در این مصاحبهٔ Lenny&amp;rsquo;s Podcast در مورد فرهنگ نتفلیکس، پیشرفت شغلی، انتظارات بالای شرکت نتفلیکس و &amp;hellip; صحبت میشه.&lt;/p>
&lt;p>چندتا فکت جالب هم در مورد نتفلیکس فهمیدم:&lt;/p>
&lt;ul>
&lt;li>نتفلیکس مرخصی تعطیلات نامحدود داره!&lt;/li>
&lt;li>قبلاً به این معروف بود که نردبان شغلی و کلا مفهومی به اسم ارتقای شغلی نداره و همه senior و در یک سطح هستن. به همین دلیل performance review هم ندارن. ولی اخیراً یک سطح برای نیروهای fresh و کم‌تجربه‌تر ایجاد کردن.&lt;/li>
&lt;li>مدتیه که به دلیل جلوگیری از آسیب زدن به تجربهٔ کاربرهاشون از روش chaos monkey که خودشون مبدعش بودن استفاده نمی‌کنن و برای اطمینان از مقاومت اجزای سیستم از روش‌های دیگری استفاده می‌کنن.&lt;/li>
&lt;/ul>
&lt;p>🔗 &lt;a href="https://youtu.be/2XgU6T4DalY?si=8_tWaVsFhES-9rND" target="_blank" rel="noopener noreferrer" >&lt;strong>لینک پادکست (یوتیوب)&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>دوستی می‌گفت اگر روزی یک موجود فضایی به…</title><link>https://aminrb.me/fa/telegram-26/</link><pubDate>Fri, 08 Mar 2024 15:39:18 +0000</pubDate><guid>https://aminrb.me/fa/telegram-26/</guid><description>&lt;p>دوستی می‌گفت اگر روزی یک موجود فضایی به کرهٔ زمین سفر کنه و ما بخوایم فقط با نشون دادن یک چیز انسان رو بهش معرفی کنیم، Video Games بهترین گزینه است؛ چون هم بر پایهٔ مهندسی، ریاضی و منطق و فیزیک بنا شده و هم هنرهای مختلفی مثل موسیقی، تصویرگری، بازیگری و داستان‌نویسی بهش رنگ و لعاب داده که در نهایت باعث میشه که عواطف انسانی هم درش متجلی بشه.&lt;/p></description></item><item><title>در قسمت نظرهای پست قبلی مهدی خوشنودی موضوع…</title><link>https://aminrb.me/fa/telegram-25/</link><pubDate>Tue, 05 Mar 2024 18:25:43 +0000</pubDate><guid>https://aminrb.me/fa/telegram-25/</guid><description>&lt;p>در قسمت نظرهای پست قبلی مهدی خوشنودی موضوع «تخمین زدن» رو از زاویه‌ای بررسی کرد که از نظرم جالب و ارزشمندی بود و گفتم اینجا هم به اشتراک بذارم.&lt;br>
فقط متن طولانی بود و نمی‌شد از قابلیت نقل قول تلگرام استفاده کرد و من متن رو کپی می‌کنم.&lt;/p>
&lt;p>مهدی:&lt;br>
&lt;em>&amp;ldquo;زوایه‌ای از موضوع که خیلی برای من جالبه و همیشه بهش فکر می‌کنم خود ایدهٔ «تخمین زدن» هست.&lt;/em>&lt;br>
&lt;em>در اولین پاراگراف هم از این پیش‌فرض این که تخمین زدن یه مهارته مهم و تاثیرگذاره صحبت می‌کنی و به نظرم این کمی جای تأمل داره. من یه درگیری ذهنی سر این با خودم دارم که تلاش می‌کنم همیشه خودم رو سر اینکه خود «تخمین زدن» چقدر ارزش داره به چالش بکشم. به نظرم خیلی ساده‌تره که چارچوب ملموسی برای کار تعریف کنیم و بگیم کار X در مدت زمان Y انجام میشه و همه خیالشون راحته که ذهنشون لازم نیست با پیچدگی و گنگی اینکه مشخص نیست یک کار چقدر طول خواهد کشید دست و پنجه نرم کنن ولی واقعیت دنیا اینه که این‌ها بیشتر حدس و گمانن و در نهایت باید این گنگی رو بپذیریم.&lt;/em>&lt;/p></description></item><item><title>وقتی یک تسکی قراره بیشتر از تخمین اولیه طول بکشه چه کنیم؟</title><link>https://aminrb.me/fa/%D9%88%D9%82%D8%AA%DB%8C-%DB%8C%DA%A9-%D8%AA%D8%B3%DA%A9%DB%8C-%D9%82%D8%B1%D8%A7%D8%B1%D9%87-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-%D8%A7%D8%B2-%D8%AA%D8%AE%D9%85%DB%8C%D9%86-%D8%A7%D9%88%D9%84%DB%8C%D9%87-%D8%B7%D9%88%D9%84-%D8%A8%DA%A9%D8%B4%D9%87-%DA%86%D9%87-%DA%A9%D9%86%DB%8C%D9%85/</link><pubDate>Fri, 01 Mar 2024 18:10:44 +0000</pubDate><guid>https://aminrb.me/fa/%D9%88%D9%82%D8%AA%DB%8C-%DB%8C%DA%A9-%D8%AA%D8%B3%DA%A9%DB%8C-%D9%82%D8%B1%D8%A7%D8%B1%D9%87-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-%D8%A7%D8%B2-%D8%AA%D8%AE%D9%85%DB%8C%D9%86-%D8%A7%D9%88%D9%84%DB%8C%D9%87-%D8%B7%D9%88%D9%84-%D8%A8%DA%A9%D8%B4%D9%87-%DA%86%D9%87-%DA%A9%D9%86%DB%8C%D9%85/</guid><description>&lt;p>یکی از مهارت‌هایی که با بیشتر شدن تجربه و کار کردن در یک تیم و یا یک شرکت بهبود پیدا می‌کنه، مهارت تخمین زدنه. با وجود این که این مهارت رو میشه به مرور بهتر کرد (در فرصتی بیشتر در موردش می‌نویسم)، هر چقدر هم به جوانب کار فکر کرده باشیم، باز هم ممکنه زوایایی رو ندیده باشیم و یا این که اتفاق‌هایی در طی انجام تسک پیش بیاد ما رو از رسوندن به ددلاین تعیین شده عقب بندازه.&lt;/p></description></item><item><title>Go v1.22</title><link>https://aminrb.me/fa/go-v1-22/</link><pubDate>Thu, 15 Feb 2024 17:48:38 +0000</pubDate><guid>https://aminrb.me/fa/go-v1-22/</guid><description>&lt;p>در روزهای اخیر Go v1.22 عرضه شد. از مهمترین تغییرات این نسخه، اضافه شدن امکان loop زدن بر روی یک integer هستش. مثل کد زیر:&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" class="chroma">&lt;code class="language-go" data-lang="go">&lt;span class="line">&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="kn">package&lt;/span> &lt;span class="nx">main&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="kn">import&lt;/span> &lt;span class="s">&amp;#34;fmt&amp;#34;&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="kd">func&lt;/span> &lt;span class="nf">main&lt;/span>&lt;span class="p">()&lt;/span> &lt;span class="p">{&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="k">for&lt;/span> &lt;span class="nx">i&lt;/span> &lt;span class="o">:=&lt;/span> &lt;span class="k">range&lt;/span> &lt;span class="mi">10&lt;/span> &lt;span class="p">{&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="nx">fmt&lt;/span>&lt;span class="p">.&lt;/span>&lt;span class="nf">Println&lt;/span>&lt;span class="p">(&lt;/span>&lt;span class="mi">10&lt;/span> &lt;span class="o">-&lt;/span> &lt;span class="nx">i&lt;/span>&lt;span class="p">)&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl"> &lt;span class="p">}&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="p">}&lt;/span>
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>یک بهبود مهم دیگری که توی این نسخه دادن اینه که تغییراتی روی Garbage Collector صورت گرفته که باعث می‌شه که ۱ تا ۳ درصد در مصرف CPU و حدود ۱ درصد در مصرف مموری صرفه‌جویی بشه.&lt;/p></description></item><item><title>Error categories and category errors</title><link>https://aminrb.me/fa/error-categories-and-category-errors/</link><pubDate>Fri, 09 Feb 2024 13:29:21 +0000</pubDate><guid>https://aminrb.me/fa/error-categories-and-category-errors/</guid><description>&lt;p>خطاها عضو جداناشدنی نرم‌افزارها هستن. تصور این که کدی داشته باشیم که هرگز هیچ خطایی براش پیش نیاد غیرواقعی و آرمانی به نظر می‌رسه.&lt;br>
اما خطاها می‌تونن گسترهٔ تبعات خیلی وسیعی داشته باشن. یک ارور شاید باعث بشه که کاربرها فقط چند دقیقه بیشتر منتظر ثبت سفارششون بمونن، یا این که ممکنه باعث خطا در لانچ یک ماهواره و شکست خوردن پروژه و میلیون‌ها دلار ضرر و زیان بشه.&lt;/p>
&lt;p>نویسنده ارورها رو به چند دسته تقسیم می‌کنه و در مورد هر کدومشون توضیح می‌ده:&lt;br>
&lt;strong>- ارورهایی که قابل پیشبینی هستن و ما می‌تونیم هندلشون کنیم.&lt;/strong>&lt;br>
&lt;strong>- ارورهایی که قابل پیشبینی هستن و ما نمی‌تونیم (یا نمی‌خوایم) هندلشون کنیم.&lt;/strong>&lt;br>
&lt;strong>- ارورهایی که نمی‌تونیم پیشبینی کنیم (همون باگ‌ها).&lt;/strong>&lt;/p></description></item><item><title>Useful tradeoffs are multi-dimensional.</title><link>https://aminrb.me/fa/useful-tradeoffs-are-multi-dimensional/</link><pubDate>Fri, 02 Feb 2024 13:11:42 +0000</pubDate><guid>https://aminrb.me/fa/useful-tradeoffs-are-multi-dimensional/</guid><description>&lt;p>اخیراً می‌خواستیم فیچر بزرگی رو به محصولمون اضافه کنیم. فیچر جدید ابعاد زیادی داشت که بعد از چندین اکسپریمنت و لود تست هنوز بخش‌های گنگی داشت. سوال‌هایی از قبیل اینکه می‌تونه همهٔ ریکوست‌های کاربران رو در ساعات مختلف روز جواب بده؟ اینکه owner سرویس‌های درگیر با این تغییرات عمده موافق هستن؟ این که کاربرها می‌تونن از این فیچر استفاده کنن؟ و &amp;hellip;&lt;br>
برای ریلیز کردن این فیچر دو راه کلی پیش رومون داشتیم. یکی این که سریع‌ ریلیز کنیم و فیدبک بگیریم (ریسک زیاد، گرفتن فیدبک سریع) یا این که بیایم قبل از ریلیز همهٔ پیشفرض‌هامون رو تست کنیم (ریسک پایین، گرفتن فیدبک کند). اما اومدیم یک راه میانی رو انتخاب کردیم که مزایای هردوی این روش‌ها رو به ارث برده باشه. به این شکل که با تعیین feature flag و ترشولدهای خیلی سخت‌گیرانه محصول رو «&lt;strong>دیپلوی&lt;/strong>» کردیم، اما همزمان فرضیاتمون رو تحلیل می‌کردیم و بعد از مدتی محصول نهاییمون رو «&lt;strong>ریلیز&lt;/strong>» کردیم.&lt;br>
با این کار، عملاً بُعد دیگری به ترید‌آف‌هامون اضافه کردیم؛ همزمان که دیپلوی سریعی داشتیم، ریلیز کم‌ریسکی هم داشتیم.&lt;/p></description></item><item><title>Twitch Tech Blog - Go memory ballast: How I learnt to stop worrying and love the heap</title><link>https://aminrb.me/fa/twitch-tech-blog-go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/</link><pubDate>Fri, 26 Jan 2024 16:22:59 +0000</pubDate><guid>https://aminrb.me/fa/twitch-tech-blog-go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/</guid><description>&lt;p>این نوشته از بلاگ فنی Twitch می‌گه که در بازه‌هایی از زمان ممکنه تعداد ریکوست‌های کاربرها به ۲۰ برابر حالت عادی برسه! مثلاً کانکشن اینترنت یک استریمر پربیننده‌ به مشکل می‌خوره و همهٔ بیننده‌هاش شروع می‌کنن به رفرش کردن. مثل اینه که هر روز باید برای هندل کردن load یک black friday آماده باشن 🙂&lt;/p>
&lt;p>در این مواقع، سرویسی که این APIهارو هندل می‌کنه که با Go نوشته شده به مشکل می‌خوره و کند می‌شه. یک راه اینه که به صورت همیشگی اسکیل کنن که خب خیلی پرهزینه و غیربهینه است. حالا اومدن توی این نوشته توضیح دادن که فقط با اضافه کردن یک خط کد به تابع main برنامه، 30% مصرف CPU و 45% لیتنسی رو کاهش دادن! من در ادامه یکم توضیح می‌دم.&lt;/p></description></item><item><title>Show Your Work!</title><link>https://aminrb.me/fa/show-your-work/</link><pubDate>Fri, 05 Jan 2024 09:51:33 +0000</pubDate><guid>https://aminrb.me/fa/show-your-work/</guid><description>&lt;p>در هفتهٔ گذشته کتاب Show Your Work از Austin Kleon رو خوندم. نویسنده در این کتاب به اهمیت «دیده شدن» کارها می‌پردازه‌. کتاب ۱۰ فصله و زوایای مختلف انتشار کارها رو مطرح می‌کنه. مثل این که خیلی وقت‌ها فکر می‌کنیم حتما باید یک کاری پرفکت شده باشه که انتشارش بدیم در صورتی که اتفاقاً کارهای آماتوری جذابیت‌های خاص خودشون رو دارن. یا مثلاً اگر پروسهٔ تولید و یادگیری رو قبل از محصول نهایی منتشر کنی، احتمالاً&lt;br>
مخاطب‌هات رو بیشتر engage نگه می‌داری.&lt;/p></description></item><item><title>Go Test Doubles by Example</title><link>https://aminrb.me/fa/go-test-doubles-by-example/</link><pubDate>Wed, 03 Jan 2024 07:11:43 +0000</pubDate><guid>https://aminrb.me/fa/go-test-doubles-by-example/</guid><description>&lt;p>چند هفته پیش در مورد روش‌های مختلف تست کردن dependency در کد با استفاده از test-doubleها (mock، stub، و fake) نوشتم. غیر از این سه مورد، test-doubleهای دیگری مثل spy و dummy هم هستن که کاربردهای خاص خودشون رو دارن.&lt;/p>
&lt;p>در همین راستا، این مفاهیم رو در یک پست به طور دقیق‌تر توضیح دادم. همچنین با استفاده از زبان Go، یک مثال از دنیای واقعی رو پیاده‌سازی کردم.&lt;/p>
&lt;p>پیشنهاد می‌کنم اگر کدی دارید که به یک dependency وابسته است و براش تست می‌نویسید، این نوشته رو بخونید؛ به خصوص اگر با زبان Go کد می‌زنید.&lt;br>
&lt;a href="https://aminrb.me/blog/go-test-double/" >https://aminrb.me/blog/go-test-double/&lt;/a>&lt;/p></description></item><item><title>نوشته‌های مربوط به مرورِ سالِ افرادی که دنبال…</title><link>https://aminrb.me/fa/telegram-17/</link><pubDate>Mon, 01 Jan 2024 20:42:44 +0000</pubDate><guid>https://aminrb.me/fa/telegram-17/</guid><description>&lt;p>نوشته‌های مربوط به مرورِ سالِ افرادی که دنبال می‌کنم همیشه برام جالب بوده.&lt;/p>
&lt;p>مثل این پست‌ها که مفصل‌تر نوشتن:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://eugeneyan.com//writing/2023-review/" target="_blank" rel="noopener noreferrer" >eugeneyan - 2023 Year in Review&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://lethain.com/2023-in-review/" target="_blank" rel="noopener noreferrer" >Will Larson - 2023 in review.&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://jvns.ca/blog/2023/12/31/2023--year-in-review/" target="_blank" rel="noopener noreferrer" >Julia Evans - 2023: Year in review&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>یا این توییت‌ها که مختصرتر نوشتن:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://twitter.com/abhi9u/status/1741419175468532183?s=20" target="_blank" rel="noopener noreferrer" >Abhinav Upadhyay&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://twitter.com/hnasr/status/1741487768088568274?s=20" target="_blank" rel="noopener noreferrer" >Hussein Nasser&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>و پند و اندرز‌ها:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://addyo.substack.com/p/23-lessons-in-2023" target="_blank" rel="noopener noreferrer" >Addy Osmani - 23 lessons in 2023&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>و البته لیست‌های سالیانه!:&lt;/p></description></item><item><title>End of Year Pay Report 2023</title><link>https://aminrb.me/fa/end-of-year-pay-report-2023/</link><pubDate>Sun, 24 Dec 2023 14:54:09 +0000</pubDate><guid>https://aminrb.me/fa/end-of-year-pay-report-2023/</guid><description>&lt;p>وبسایت levels.fy مثل هر سال وضعیت حقوق در شرکت‌های تکنولوژی‌محور رو گزارش کرده.&lt;/p>
&lt;p>نکاتی که برای من جالب‌تر بود:&lt;/p>
&lt;ul>
&lt;li>در سال ۲۰۲۳ درآمد مهندس‌های نرم‌افزار و دیتاساینتیست‌ها نسبت به ۲۰۲۲ کمتر شده. اما برای پروداکت‌منیجر‌ها و طراحان محصول بهبود پیدا کرده&lt;/li>
&lt;li>کشور سویس با اختلاف زیادی بالاترین حقوق‌های اروپا رو داره.&lt;/li>
&lt;li>در کشور لوکزامبورگ شرکت‌ها پرداختی‌های بالایی دارن. طوری که از آلمان و هلند هم بالاتره.&lt;/li>
&lt;/ul>
&lt;p>&lt;strong>🔗&lt;/strong> &lt;a href="https://www.levels.fyi/2023/?level=Engineer" target="_blank" rel="noopener noreferrer" >&lt;strong>لینک گزارش&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>در هنگام نوشتن Automation Test برای یک نرم‌افزار…</title><link>https://aminrb.me/fa/telegram-15/</link><pubDate>Tue, 19 Dec 2023 08:00:25 +0000</pubDate><guid>https://aminrb.me/fa/telegram-15/</guid><description>&lt;p>در هنگام نوشتن Automation Test برای یک نرم‌افزار، با دیپندنسی‌ها و APIهایی مواجه می‌شیم که ترجیح می‌دیم در هر بار اجرای تست‌ها اون‌ها رو فراخوانی نکنیم. در چنین مواقعی، از Test Doubleها استفاده می‌کنیم که انواع متفاوتی دارند و اغلب به اشتباه به همه‌ٔ اون‌ها Mock می‌گیم. اینجا سه نوع رایج Test Double و تفاوت‌هاشون رو توضیح می‌دم.&lt;/p>
&lt;p>📌 &lt;strong>Fake&lt;/strong>&lt;br>
این نوع Test Double به عنوان یک جایگزین ساده‌تر، کم‌هزینه‌تر و قابل آزمایش‌تر برای دیپندنسی مورد نظر استفاده می‌شه. Fakeها از همون interfaceهای دیپندنسی اصلی استفاده می‌کنه و اون‌ها رو پیاده‌سازی می‌کنه. مثلاً، فرض کنید می‌خوایم یک شیء رو در دیتابیس بنویسیم و بخونیم. به جای راه‌اندازی یک دیتابیس واقعی برای اجرای هربارهٔ تست‌ها، از یک دیکشنری in memory استفاده می‌کنیم تا وظیفه خوندن و نوشتن داده‌ها رو برامون انجام بده. توی این حالت این دیکشنری وظیفهٔ Fake کردن دیتابیس اصلی رو بر عهده داره.&lt;/p></description></item><item><title>Tech predictions for 2024 and beyond</title><link>https://aminrb.me/fa/tech-predictions-for-2024-and-beyond/</link><pubDate>Fri, 15 Dec 2023 09:39:22 +0000</pubDate><guid>https://aminrb.me/fa/tech-predictions-for-2024-and-beyond/</guid><description>&lt;p>در یک سال اخیر فضای تکنولوژی و سرمایه‌گذاری بر روی شرکت‌های تک، تغییرات زیادی کرد و خیلی‌ها منتظر نشستن تا ببینن مسیر به چه سمتی می‌ره. در این نوشته، Werner Vogels پیشبینی کرده که دنیا در سال ۲۰۲۴ و بعدش به چه سمت‌وسویی خواهد رفت.&lt;/p>
&lt;p>📌 Generative AI becomes culturally aware&lt;br>
توی سال گذشته همگانی شدن استفاده از Generative AI از این تحولات انقلابی دنیای تک بود که هنوز هم با سرعت زیادی داری همه چیز رو تغییر میده. اما به طور واضحی هنوز در جای ایده‌آلی قرار نداره و به بهبودهایی نیاز داره. یکی از موضوعاتی که خیلی بهش خرده می‌گیرن بایاس‌های فرهنگی این مدل‌هاست. این مدل‌ها بیشتر با داده‌های زبان انگلیسی آموزش داده شدن که باعث شده که به سمت فرهنگ کشورهای انگلیسی زبان بایاس داشته باشن. نویسنده معتقده که مدل‌ها باید این بایاس‌ها رو کاهش بدن و بر اساس کانتکست اون زبان و کشور خروجی تولید کنن.&lt;/p></description></item><item><title>Enhancing the security of WhatsApp calls</title><link>https://aminrb.me/fa/enhancing-the-security-of-whatsapp-calls/</link><pubDate>Wed, 13 Dec 2023 08:00:55 +0000</pubDate><guid>https://aminrb.me/fa/enhancing-the-security-of-whatsapp-calls/</guid><description>&lt;p>تیم فنی واتس‌اپ توی این بلاگ پست توضیح داده که برای افزایش امنیت تماس‌های صوتی چه تغییراتی در طراحی‌هاشون دادن.&lt;/p>
&lt;p>برای این کار دوتا امکان به اپلیکیشن اضافه کردن. یکی Silence Unknown Callers است که جلوی مزاحمت و البته حمله‌های مختلف رو به گیرنده می‌گیره. همچنین Protect IP Address in Calls رو اضافه کرده که باعث می‌شه به جای برقراری ارتباط به صورت P2P، سرورهای واتس‌اپ واسط تماس صوتی باشن و طرفین از IP همدیگه اطلاع نداشته باشن تا مواردی از جنس privacy کاربر مثل موقعیت جغرافیایی و پرودایدر اینترنت پنهان بمونه.&lt;/p></description></item><item><title>Upgrading GitHub.com to MySQL 8.0</title><link>https://aminrb.me/fa/upgrading-github-com-to-mysql-8-0/</link><pubDate>Fri, 08 Dec 2023 19:20:29 +0000</pubDate><guid>https://aminrb.me/fa/upgrading-github-com-to-mysql-8-0/</guid><description>&lt;p>بروزرسانی نسخهٔ دیتابیس در خیلی از پروژه‌ها و شرکت‌ها کار پیچیده‌ای نیست و شاید چند ساعت بیشتر زمان نیاز نداشته باشه. اما برای شرکتی مثل Github که +۳۰۰ ترابایت داده رو بر روی بیشتر از ۵۰ کلاستر دیتابیس نگهداری می‌کنه و +۵ میلیون کوئری بر ثانیه رو تحمل می‌کنه، پروژه‌ای بزرگ و پر هزینه است.&lt;/p>
&lt;p>در گیتهاب چندین تیم بیشتر از یک سال برای ارتقای mysql 5.7 به 8 بر روی برنامه‌ریزی، تست و اجرای این فرآیند زمان گذاشتن تا بتونن بدون داون‌تایم خاصی، این ارتقا رو صورت بدن.&lt;/p></description></item><item><title>چرا به منتور نیاز داریم؟</title><link>https://aminrb.me/fa/%DA%86%D8%B1%D8%A7-%D8%A8%D9%87-%D9%85%D9%86%D8%AA%D9%88%D8%B1-%D9%86%DB%8C%D8%A7%D8%B2-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-10/</link><pubDate>Sun, 03 Dec 2023 06:34:19 +0000</pubDate><guid>https://aminrb.me/fa/%DA%86%D8%B1%D8%A7-%D8%A8%D9%87-%D9%85%D9%86%D8%AA%D9%88%D8%B1-%D9%86%DB%8C%D8%A7%D8%B2-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-10/</guid><description>&lt;p>احتمالاً تا به حال در مقاطعی از مسیر شغلیمون احساس کردیم که برای تصمیم‌گیری در مورد یک انتخاب، یک دوراهی و یا حل کردن یک چالش به کمک نیاز داریم. راهنمایی گرفتن از منتور یکی از راه‌حل‌هاست. اما به چه کسی می‌گیم منتور؟ داشتن یک منتور کجاها می‌تونه به ما کمک کنه؟ توی این نوشته سعی شده به این سوال‌ها جواب داده بشه.&lt;/p>
&lt;p>در ابتدا یک تجربهٔ شخصی رو بازگو کردم؛ از چالش‌هایی که در ابتدای مسیر کاری‌ام به عنوان برنامه‌نویس بک‌اند جونیور تجربه داشتم گفتم، و این که چطوری حضور یک برنامه‌نویس باتجربه‌تر باعث شد بتونم راه‌حل مناسبی برای چالش‌هایی که داشتم پیدا کنم. در ادامهٔ نوشته به تعریف منتور و همچنین اهمیت داشتن منتور پرداختم.&lt;/p></description></item><item><title>How Meta built Threads in 5 months</title><link>https://aminrb.me/fa/how-meta-built-threads-in-5-months/</link><pubDate>Thu, 30 Nov 2023 19:14:25 +0000</pubDate><guid>https://aminrb.me/fa/how-meta-built-threads-in-5-months/</guid><description>&lt;p>سال پیش شرکت متا محصول Threads رو عرضه کرد. این محصول جدا از سر و صدایی که به خاطر رقابت با توییتر درست کرد، یک شاهکار مهندسی در دنیای نرم‌افزار بود. پیاده‌سازی یک محصول کامل در ۵ ماه، رسیدن به ۱۰۰ میلیون یوزر در یک هفته و بدون هیچ داون‌تایم خاصی!&lt;/p>
&lt;p>من خیلی کنجکاو بودم ببینم چطوری محصولی با این کیفیت رو در این مدت زمان کوتاه پیاده‌سازی و عرضه کردن. توی این قسمت از پادکست مهندسی متا، با سه نفر از مهندس‌های Threads در مورد همین موضوع صحبت کردن. یک Android Engineer، یک iOS Engineer و یک Product Backend Engineer.&lt;/p></description></item><item><title>Code Rush (2000, Documentary)</title><link>https://aminrb.me/fa/code-rush-2000-documentary/</link><pubDate>Fri, 24 Nov 2023 19:21:57 +0000</pubDate><guid>https://aminrb.me/fa/code-rush-2000-documentary/</guid><description>&lt;p>این مستند یک ساعته، تلاش‌های تیم مهندسی شرکت NetScape رو برای جلوگیری از ورشکسته شده این شرکت میلیارد ‌دلاری در سال‌ ۱۹۹۸ رو نشون میده.&lt;/p>
&lt;p>شرکت NetScape یکی از مهمترین شرکت‌های تکنولوژی سال‌های قبل از ۲۰۰۰ بود یکی از مهم‌ترین محصول‌های این شرکت، مرورگر اینترنت بود که ۹۰ درصد سهم بازار مرورگرهای اون دوران رو به خودشون اختصاص داده بودن. اما در اون سال‌ها بیل‌گیتس با مایکروسافت شروع به گرفتن سهم بازار این شرکت کرد که به &lt;a href="https://en.wikipedia.org/wiki/Browser_wars#:~:text=The%20%22first%20browser%20war%2C%22,Safari%2C%20Microsoft%20Edge%20and%20Opera" target="_blank" rel="noopener noreferrer" >First Browser War&lt;/a> معروف شد. موقعی که شرکت در سرازیری از دست دادن یوزرهاش بود، تصمیم به اوپن سورس کردن Mozilla گرفت تا برنامه‌نویس‌های سراسر دنیا در توسعهٔ این مرورگر بهشون کمک کنن.&lt;/p></description></item><item><title>Remaining Relevant Over Four Decades</title><link>https://aminrb.me/fa/remaining-relevant-over-four-decades/</link><pubDate>Tue, 21 Nov 2023 07:51:46 +0000</pubDate><guid>https://aminrb.me/fa/remaining-relevant-over-four-decades/</guid><description>&lt;p>آقای Andrew Wulf برنامه‌نویسی رو از ۱۹۸۱ شروع کرده بود و در ۲۰۲۱ بازنشسته شد. توی این نوشته توضیح می‌ده که در این ۴۰ سال چطوری تونسته پابه‌پای تغییرات تکنولوژی پیش بره و توی این حوزه باقی بمونه.&lt;/p>
&lt;p>به صورت خلاصه توصیه می‌کنه که:&lt;/p>
&lt;ul>
&lt;li>ترندها رو دنبال کن&lt;/li>
&lt;li>دنبال یادگیری چیزهایی باش که بلد نیستی&lt;/li>
&lt;li>جاهایی کار کن که بتونی تغییری ایجاد کنی&lt;/li>
&lt;li>همیشه تلاش کن چیزی برای بهبود دادن پیدا کنی تا اوضاع تیم/پروژه بهتر از قبل بشه&lt;/li>
&lt;li>هرگز در یک کار بی‌ارزش باقی نمون و در اون صورت جایی که کار می‌کنی رو عوض کن&lt;/li>
&lt;/ul>
&lt;p>&lt;strong>🔗&lt;/strong> &lt;a href="https://thecodist.com/how-i-stayed-relevant-over-four-decades/" target="_blank" rel="noopener noreferrer" >&lt;strong>لینک نوشته&lt;/strong>&lt;/a>&lt;/p></description></item><item><title>TechnicalDebtQuadrant</title><link>https://aminrb.me/fa/technicaldebtquadrant/</link><pubDate>Tue, 07 Nov 2023 08:32:23 +0000</pubDate><guid>https://aminrb.me/fa/technicaldebtquadrant/</guid><description>&lt;p>بدهی‌های فنی عضو جدا ناپذیر توسعهٔ یک محصول هستن. با وجود این که عموماً بار معنایی منفی دارن، اما به وجود آوردنش لزوماً تصمیم معیوبی نیست؛ بلکه همونطور که از اسمش پیداست، یک چیزی رو قرض می‌گیریم که در آینده و در فرصت بهتری بهاش رو پرداخت کنیم.&lt;/p>
&lt;p>مارتین فالر بدهی‌های فنی رو به چند دسته تقسیم می‌کنه. بدهی‌های فنی می‌تونن بی‌ملاحظه (reckless) باشن و یا محتاطانه (prudent) به وجود اومده باشن. این که بیایم دیزاین یک قسمتی از کد رو به خاطر چند روز از برنامه جلو افتادن بد پیش ببریم، بیشتر ساختن یک بدهی بی‌ملاحظه است تا محتاطانه. یا این یک بدهی تولید کنیم و برنامه‌ای بهبودش در آینده نداشته باشیم بی ملاحظه است.&lt;/p></description></item><item><title>Experimentation at Spotify: Three Lessons for Maximizing Impact in Innovation</title><link>https://aminrb.me/fa/experimentation-at-spotify-three-lessons-for-maximizing-impact-in-innovation/</link><pubDate>Thu, 02 Nov 2023 08:56:32 +0000</pubDate><guid>https://aminrb.me/fa/experimentation-at-spotify-three-lessons-for-maximizing-impact-in-innovation/</guid><description>&lt;p>در محصول‌های بالغ، اکسپریمنت کردن روش خوبی برای تغییر و بهبوده؛ ولی خیلی مهمه که بدونیم به کمک یک اکسپریمنت خاص به چه نتیجه‌ای می‌خوایم برسیم، چه یوزرهایی رو درگیر می‌کنیم و چه نیازهایی برای این&lt;br>
اکسپریمنت داریم.&lt;/p>
&lt;p>به طور دقیق‌تر، وقتی می‌خوایم یک تغییری رو آزمایش کنیم، خوبه که قبلش برای این دو سوال جواب داشته باشیم:&lt;/p>
&lt;ul>
&lt;li>با این آزمایش به چه تصمیمی می‌خوایم برسیم؟&lt;/li>
&lt;li>چرا این تصمیم رو با اطلاعات فعلی نمی‌تونیم بگیریم؟&lt;br>
جواب دادن به این سوال‌ها کمک می‌کنه که اکسپریمنت‌هایی رو طراحی کنیم که با حداقل منابع، بیشترین کمک رو به تصمیمی که می‌خوایم بگیریم بکنه.&lt;/li>
&lt;/ul>
&lt;p>یک نکته دیگری که مقاله میگه اینه که بدونیم برای چه کاربری داریم آزمایش رو اجرا می‌کنیم و تا جای ممکن کاربرها رو به صورت محلی انتخاب کنیم. این که بیایم تغییری رو برای همهٔ کاربرهامون آزمایش کنیم، احتمالاً به اون نتیجه‌ای که می‌خوایم بگیریم همگرا نمی‌شیم. مثلاً یک تغییری ممکنه برای یک دسته از کاربرهامون خیلی مفید باشه اما دستهٔ عمده‌تری بهبودی حس نکنن. توی این حالت متریک‌هامون به اندازه کافی جابجا نمی‌شه و ممکنه&lt;br>
به نتیجه برسیم که تغییر، تغییر خوبی نیست؛ در صورتی که می‌تونستیم این تغییر رو فقط برای اون دستهٔ محدودتر کاربرهامون انجام بدیم.&lt;/p></description></item><item><title>You Cannot Have Exactly-Once Delivery</title><link>https://aminrb.me/fa/you-cannot-have-exactly-once-delivery/</link><pubDate>Mon, 30 Oct 2023 22:27:41 +0000</pubDate><guid>https://aminrb.me/fa/you-cannot-have-exactly-once-delivery/</guid><description>&lt;p>نویسنده می‌گه که توی دنیای سیستم‌های توزیع‌شده، این که تضمین کنیم یک پیام دقیقاً یک بار به دست گیرنده برسه افسانه‌ای بیش نیست. چون از طرفی برای این که مطمئن باشیم پیام به دست گیرنده رسیده، باید acknowledge بگیریم. حالا اگر ack نگیریم احتمالاً باید فرض کنیم که پیام نرسیده و پس میایم retry می‌کنیم. از طرف دیگه ممکنه واقعا رسیده باشه و ack به دست ما نرسیده باشه. در این حالت با retry کردن پیام چند بار به دست گیرنده می‌رسه.&lt;/p></description></item></channel></rss>