۲) سه مؤلفه یادگیری ماشین
اگر از مطالب نادرست و احمقانه‌ درباره‌ی هوش مصنوعی بگذریم باید گفت که تنها هدف یادگیری ماشین، پیش‌بینی نتایج بر اساس داده‌های ورودی است. تمام وظایف (tasks) یادگیری ماشین را می‌توان به همین شکل (پیش‌بینی بر مبنای داده‌ها) بیان کرد و اگر مساله‌ای را نتوان به این صورت بیان نمود احتمالا آن مساله ارتباطی به یادگیری ماشین ندارد.
هر چه تنوع نمونه‌ها (samples) بیشتر باشد، پیدا کردن الگوهای مرتبط و پیش‌بینی نتیجه آسان‌تر است. برای یادگیری ماشین به سه مولفه (component) نیاز داریم: داده‌ها (Data)، ویژگی‌ها (Features) و الگوریتم (Algorithm)

۱-۲) داده‌ها (Data)
آیا می‌خواهید هرزنامه‌ها (Spam) را از بین ایمیل‌ها شناسایی کنید؟ پس باید تعدادی هرزنامه به عنوان نمونه‌ (sample) جمع‌آوری کنید. آیا می‌خواهید قیمت سهام را پیش‌بینی کنید؟‌ پس باید تاریخچه قیمت سهام را پیدا کنید. آیا می خواهید سلیقه و پسند کاربر را کشف کنید؟ پس باید فعالیت‌های وی را در فیسبوک جمع‌آوری و سپس تجزیه و تحلیل کنید (اوه! نه مارک زاکربرگ، جمع‌آوری اطلاعات کاربران را متوقف کن! بسه دیگه!) . هر چه داده‌ها ناهمگون و دارای تنوع بیشتری باشند نتیجه‌ بهتری به دست خواهد بود. وقتی صحبت از نیاز به داده‌ها می‌شود به خاطر داشته باشید که گاهی حتی ده‌ها هزار داده و نمونه، کم‌ترین تعداد مورد نیاز در یک مساله‌ی یادگیری ماشین است.

دو روش اصلی برای آماده‌سازی داده‌ها وجود دارد: روش دستی (manual) و روش خودکار(automatic) .
در روش دستی،‌ داده‌ها خطای بسیار کم‌تری دارند اما جمع‌آوری آنها به زمان بیشتری نیاز دارد و همین امر باعث می‌شود این روش به صورت کلی پرهزینه‌تر باشد. روش خودکار نسبت به روش دستی ارزان‌تر است. شما هر داده‌ای را که پیدا می‌کنید جمع آوری می‌کنید به این امید که این داده‌ها برای حل مساله‌ی شما کافی‌اند.
برخی از شرکت‌های عقل کل‌ [کسی که تلاش می‌کند به شکل آزاردهنده‌ای باهوش‌تر از دیگران به نظر برسد؛ مترجم] مانند گوگل به صورت رایگان از مشتریان خود برای برچسب زدن (label) و آماده‌ساز داده‌ها استفاده می‌کنند. حتما به خاطر دارید که ری‌کپچای شرکت گوگل ( ReCaptcha) شما را مجبور می‌کند تا “در تصاویر زیر علائم راهنمایی را انتخاب کنید”؟ [ری‌کپچا اطمینان حاصل می‌کند که کاربر استفاده‌کننده از کامپیوتر یک انسان است نه یک ربات؛ مترجم]. این دقیقا کاری هست که آنها می‌کنند و شما را به عنوان نیروی کار رایگان به خدمت می‌گیرند! چقدر عالی! به جای کارمندان این شرکت‌ها منِ کاربر شروع می‌کنم به یاد دادن تعداد بیشتر و بیشتری از علایم راهنمایی به ری‌کپچا. اوف …!
جمع آوری مجموعه‌ای با کیفیت از داده‌ها کار بسیار دشواری است. به یاد داشته باشید که به مجموعه‌ی داده‌ها، دیتاست (dataset) گفته می‌شود. اهمیت داده‌ها به حدی است که شرکت‌ها، شاید حاضر شوند الگوریتم‌های خود را در اختیار عموم قرار دهند اما به ندرت حاضر به انتشار دیتاست‌های خود می‌شوند.
مترجم: خانم سپیده مشایخی

گزیده:
درست مانند صد سال پیش که برق تقریباً همه چیز را متحول کرد، امروز هم واقعاً برایم دشوار است صنعتی را پیدا کنم که باور داشته باشم هوش مصنوعی آن را طی چند سال آینده متحول نخواهد کرد. اندرو اینگ

عامل ۵: ساخت(build)، انتشار(release)، اجرا(run)
گام‌های ساخت (‌Build) و اجرا(Run) را کاملا از هم جدا کنید.

هر پایگاه کد (codebase) طی سه مرحله به استقرار (deploy) تبدیل می‌شود:

• مرحله ساخت (build stage) : در این مرحله مخزن کد (codebase) به یک بسته قابل اجرا (executable bundle) تبدیل می‌شود. این بسته‌ی قابل اجرا با نام بسته‌ی ساخت (Build) نیز شناخته می‌شود. در این مرحله ابتدا بر اساس شماره‌ی نسخه‌ی (version) کدی که در فرایند استقرار مشخص شده، کد از مخزن کد برداشته می‌شود،‌ در گام دوم، اجزا و مولفه‌های خارجی که برنامه به آنها وابسته است (vendors dependencies) گردآوری می‌شود و در پایان، فایل‌ها و سایر اجزای برنامه کامپایل می‌شوند.
• مرحله انتشار (release stage): در این مرحله بسته ساخت (Build) که در مرحله قبلی آماده شده با پیکربندی(config) استقرار ترکیب می‌شود که نتیجه‌ی آن نسخه قابل انتشار (release) است که شامل هم بسته‌ی ساخت و هم پیکربندی است. این نسخه‌‌ی انتشار برای استفاده در محیط اجرا (execution environment) آماده است.
• مرحله اجرا (run stage): برنامه در محیط اجرا بالا می‌آید، برای هر انتشار مجموعه‌ای از فرآیندهای برنامه اجرا می‌شود. این مرحله نام “مرحله زمان اجرا” (runtime) نیز شناخته می شود.

مترجم:
بسته (bundle):‌به دو یا چند برنامه‌ی نرم‌افزاری (application) که با هم بسته‌بندی می‌شوند و به عنوان یک محصول به فروش می‌رسند) بسته یا باندل گفته می‌شود.

هر برنامه دوازده عاملی مراحل ساخت، انتشار و اجرا را کاملا از هم جدا می‌کند. و به همین دلیل برای نمونه، تغییر کد در مرحله‌ی اجرا امکان‌پذیر نیست چون هیچ راهی برای ارسال و اعمال آن تغییرات به مرحله‌ی قبلی یعنی مرحله‌ی ساخت وجود ندارد.

ابزارهای استقرار معمولاً دارای ابزارهای مدیریت انتشار نیز هستند و یکی از قابلیت‌های برجسته آنها،‌ امکان برگشت به عقب و به نسخه قبلی است (roll back). برای مثال، ابزار استقرار Capistrano نسخه‌ها را در پوشه‌ای (folder) به نام releases ذخیره می‌کند. در این ابزار به کمک یک فایل لینکی (Symlink) که به یکی از پوشه‌های داخل releases اشاره می‌کند، مشخص می‌گردد که نسخه‌ی جاری در کدام یک از پوشه‌ها قرار دارد. هم‌چنین در این ابزار، فرمان rollback به شما کمک می‌کند به راحتی و به سرعت به نسخه قبلی برگردید.

مترجم:
Symlink که symbolic link هم نامیده می‌شود نوعی فایل در لینوکس است که به فایل یا پوشه دیگری در کامپیوتر اشاره می کند. Symlink مشابه shortcut در ویندوز است.

هر انتشار باید یک شناسه‌ی منحصر به فرد مانند شناسه‌ی زمانی (timestamp) مانند 2011-04-06-20:32:17 یا یک شناسه‌ی عددی مانند v100 داشته باشد. فهرست انتشارها مانند لیستی است که فقط می‌توان به آن ردیف جدیدی اضافه کرد و بعد از اضافه شدن ردیف جدید، نمی‌توان آن را تغییر داد.. اعمال هر تغییر جدیدی در انتشار فقط از طریق ایجاد یک انتشار جدید و اضافه کردن آن به لیست موجود، امکان‌پذیر است.

نوشته‌های قبلی:
–قسمت پنجم: سرویس ‌های کمکی ( backing services)

مترجم: حمید آقای خاتمی

گزیده:
بخش توسعه‌ی (Devs) مریخی‌اند و بخش عملیات و اجرا (Ops) ونوسی! استیون هاینس

عامل ۴: سرویس ‌های کمکی ( backing services)
با سرویس‌‌های کمکی مانند منابع ضمیمه شده یا پیوست ( attached resources) رفتار کنید.

سرویس کمکی ( backing services) هر سرویسی است که برنامه از طریق شبکه از آن برای انجام کارهای معمول و روزمره‌اش استفاده کند. از جمله سرویس‌های کمکی می‌توان به پایگاه‌ داده مانند MySQL، سیستم‌های‌ پیام‌رسان و مدیریت صف (messaging/queueing) مانند RabbitMQ، سرویس ایمیل ( SMTP) برای ارسال و دریافت ایمیل‌هامانند Postfix و حافظه‌های ذخیره‌سازی سریع (caching) مانند Memcached اشاره کرد.

سرویس‌‌های کمکی مانند پایگاه داده از قدیم توسط راهبران سیستم (administrators) که استقرار برنامه‌ها نیز بر عهده‌ی آنهاست مدیریت می‌شوند. علاوه‌ بر سرویس‌هایی که به صورت محلی و داخلی (local) مدیریت می‌شوند، برنامه‌ها ممکن است از سرویس‌هایی استفاده کنند که توسط شرکت‌های دیگر ارائه و مدیریت می‌شوند. برای مثال می‌توان به سرویس ایمیل مانند Postmark، سرویس جمع‌آوری شاخص‌های آماری مانند New Relic یا Loggly، سرویس مدیریت دارایی‌های دیجیتالی مانند Amazon S3 و حتی سرویس‌های مبتنی بر API مانند Twitter، Google Maps یا Last.fm اشاره کرد.

کد هر برنامه دوازده عاملی هیچ تفاوتی بین سرویس‌های محلی و سرویس‌های خارجی قائل نیست. از دید برنامه، هر دو نوع سرویس، منابع پیوست (attached resources) هستند که از طریق یک آدرس (URL) یا هر مکانیزم آدرس‌دهی دیگری که در فایل پیکربندی ذخیره شده‌ قابل دسترسی‌اند. موقع استقرار ( deploy) هر برنامه دوازده عاملی باید بتوان بدون تغییر کد، یک پایگاه داده MySQL محلی را با نسخه‌ای که توسط یک شرکت خارجی مدیریت می‌شود مانند Amazon RDS تعویض کرد. هم‌چنین بدون تغییر کد باید یک سرویس‌دهنده‌ی SMTP داخلی را با یک سرویس‌دهنده‌ی خارجی مانند Postmark تعویض کرد. در هر دو مورد فقط کافی است آدرس دسترسی به منابع در پیکربندی (config) تغییر داده شود.

هر سرویس‌ کمکی یک منبع ( resource) به حساب می‌آید. برای نمونه هر پایگاه داده MySQL یک منبع است. دو پایگاه داده MySQL (که در لایه Application برای اشتراک گذاری استفاده می‌شود) دو منبع مجزا به شمار می‌آیند. برنامه دوازده عاملی با این پایگاه‌های داده مانند منابع پیوست (attached resources) برخورد می‌کند که نشان‌دهنده همبستگی کم (loose coupling) آن‌ها به استقراری است که در آن قرار دارند.
منابع را می‌توان به دلخواه به استقرارها متصل و جدا کرد. برای مثال، اگر پایگاه داده به دلیل مشکلات سخت افزاری بد کار کرد راهبر (admin) برنامه می‌تواند از روی آخرین نسخه‌ی پشتیبان، سرویس‌دهنده‌ی جدیدی برای پایگاه داده راه‌اندازی کند و برنامه را به آن متصل نماید. به عنوان نمونه‌ای دیگر، پایگاه داده عملیاتی را می‌توان جدا کرد و پایگاه داده جدیدی را به برنامه متصل کرد. تمام این‌ کارها بدون هیچ تغییری در کد انجام می‌شود.

نوشته‌های قبلی:
– قسمت چهارم: پیکربندی

مترجم: حمید آقای خاتمی

گزیده:
«زمانی که از به هدر دادنش لذت ببری. به هدر نرفته‌است.» جان لنون

چقدر سیر و صفا داره می‌ گیلان
کوه و دریا همه داره می ‌گیلان
اگر دونیا بداره چند ته خوبی
همه خوبی یجا داره می گیلان
همیشه بهاره گیلان
می دیله قراره گیلان

عکس: بی‌بالان، اردیبهشت ۱۴۰۱
با سپاس فراوان از یوسف ابر عزیز

پیش گفتار:
مدت‌هاست که دلم می‌خواهد مطالب بیشتری در زمینه یادگیری ماشین (machine learning) در وبلاگ منتشر شود. پس از بررسی به این نتیجه رسیدم که بهتر است این دسته از مطالب با یک معرفی ساده و به دور از مباحث نظری و ریاضی شروع شود. بعد از همفکری با سرکار خانم سپیده مشایخی تصمیم بر آن شد که با نوشته‌ی Machine Learning for Everyone از سایت vas3k.com شروع کنیم. ضمن تشکر و قدردانی از ایشان،‌ امیدوارم که این نوشته‌ها مورد استفاده شما عزیزان قرار گیرد.

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

۱) چرا می خواهیم ماشین ها قدرت یادگیری داشته باشند؟
اجازه دهید بیلی (Billy) را به شما معرفی کنم. بيلي قصد دارد خودرویی بخرد. او سعی دارد حساب کند که برای خرید خودرو ماهانه چقدر باید پس‌انداز کند. او ده‌ها آگهی فروش خودرو را در اینترنت بررسی کرد و فهمید قیمت خودروهای صفر و دست اول حدود ۲۰،۰۰۰ دلار است و قیمت خودروهای یک سال کار کرده‌ حدود ۱۹،۰۰۰ دلار و دو سال کارکرده حدود ۱۸،۰۰۰ دلار است و به همین ترتیب با افزایش کارکرد خودرو قیمت آن هم کاهش پیدا می‌کند.
تحلیل‌گر باهوش ما یعنی بیلی پی‌ برد که الگویی (pattern) بین این اعداد وجود دارد: قیمت خودرو به مدت کارکرد آن (سن خودرو) وابسته است. هر سال ۱۰۰۰ دلار از قیمت خودرو کاسته می‌شود ولی قیمت آن از ۱۰،۰۰۰ دلار پایین‌تر نمی‌آید.
بر اساس ادبیات حوزه‌ی یادگیری ماشین، بیلی موفق به ابداع روش رگرسیون (regression) شده است یعنی وی توانسته یک مقدار عددی (قیمت خودرو) را بر اساس داده های تاریخی (historical data) موجود پیش‌بینی کند. افراد وقتی که تلاش می‌کنند قیمت آیفون دست دوم را در سایت ebay برآورد کنند یا وقتی می‌خواهند مقدار گوشت کبابی لازم برای یک مهمانی را حساب کنند از این روش استفاده می‌کنند.
بی‌شک وجود یک فرمول ساده که بتواند همه‌ی مسائل دنیا را حل کند فوق‌العاده است به ویژه برای حل مساله‌ی مقدار گوشت کبابی لازم برای یک مهمانی. اما متاسفانه این کار امکان‌پذیر نیست.
بيایید برگرديم به مساله خرید خودرو. مشکل این است که خودروها دارای تاریخ تولید، امکانات (آپشن)، وضعیت فنی و میزان تقاضای فصلی متفاوتی هستند و معلوم نیست چه تعداد عامل ناشناخته دیگری هم در این میان وجود دارد که می‌تواند روی قیمت خودرو تاثیرگذار باشد. یک فرد عادی مثل بیلی ​​نمی‌تواند موقع محاسبه قیمت خودرو، تمام این داده‌ها را در ذهن خود نگهداری و پردازش کند. البته من هم نمی‌توانم.

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

و با این یافته‌ی جدید، یادگیری ماشین متولد شد.

مترجم: خانم سپیده مشایخی

گزیده:
اگر کامپیوتری بتواند انسان را فریب دهد تا انسان بودنش را باور کند، سزاوار این است که هوشمند نامیده شود. آلن تورینگ

فیلم “جرونیمو: افسانه آمریکایی” (Geronimo: An American Legend) داستان سرخ‌پوستان و بومیان آمریکا در مبارزه با ارتش سفیدپوستان آمریکاست. قهرمان اصلی داستان،‌ جرونیمو یکی از رهبران سرخ‌پوستان آمریکاست. داستان فیلم بسیار غم‌انگیز است.
سفیدپوستان زمین‌های بومیان را از آنها می‌گیرند و آنها را با زور اسلحه مجبور می‌کنند در منطقه‌ی محدودی زندگی کنند و البته حق خروج از آن منطقه را هم ندارند. سرآخر هم به این بسنده نمی‌کنند و مانع از انجام آیین سرخپوستان آپاچی می‌شوند و خودشان آتش‌بس را زیر پا می‌گذارند، سرخپوستان را تحریک می‌کنند و کشت و کشتار را شروع می‌کنند.

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

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

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

عامل ۳: پیکربندی
پیکربندی (config) را در محیط استقرار (environment) ذخیره کنید

پیکربندی هر برنامه احتمالاً برای استقرارهای مختلف (محیط عملیاتی یا production، محیط داخلی یا stage، محیط‌ توسعه‌دهندگان و غیره) یکسان نیست. این تفاوت می‌تواند به دلایل متفاوتی از جمله موارد زیر باشد:
– منابع دسترسی به پایگاه داده، حافظه‌های ذخیره‌سازی سریع (Memcached) و سایر خدمات پشتیبان (backing services) سرویس‌دهنده‌
– اعتبارنامه (Credentials) برای خدمات خارجی مانند Amazon S3 یا Twitter
– مقادیری مانند نام مستعار میزبان (canonical hostname یا cname) برای هر استقرار

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

دقت کنید که تعریف ما از “پیکربندی” شامل پیکربندی داخلی برنامه [مثلا پیکربندی ارتباط بین ماژول‌ها و مولفه‌های برنامه] نمی‌شود. این نوع پیکربندی در استقرار‌ها متفاوت نیست در نتیجه بهتر است در خود کد نگهداری و مدیریت شود.

رویکرد دیگر مدیریت پیکربندی، استفاده از فایل‌های پیکربندی (config files) است که در مخزن کد (repo) قرار نمی‌گیرند. چنین رویکردی در مقایسه با نوشتن پیکربندی در کد به کمک تعریف مقادیر ثابت، پیشرفت بزرگی محسوب می‌شود، هر چند این روش نیز ایراداتی دارد. احتمال اشتباه و قراردادن فایل پیکربندی در مخزن کد بسیار بالا است. احتمال پراکنده شدن فایل‌های پیکربندی در جاهای مختلف و با قالب‌های (format) متفاوت زیاد است. چنین اتفاقی مدیریت فایل‌های پیکربندی‌ و یکسان‌سازی آنها را دشوار می‌کند. معمولا قالب‌(formats) هر یک از این فایل‌های پیکربندی مختص زبان یا چارچوب متفاوتی است که مدیریت آنها را دشوارتر می‌کند.

هر برنامه دوازده عاملی پیکربندی را در متغیرهای محیط (environment variables) ذخیره می‌کند (به صورت اختصار env vars یا env نامیده می‌شوند). متغیرهای محیطی (env vars) را بدون آن که نیازی به تغییر کد باشد، به راحتی می‌توان برای هر استقرار تغییر داد. در مقایسه با فایل‌های پیکربندی، احتمال قرار گرفتن اشتباهی آنها در مخزن کد نیز کمتر است. و برخلاف فایل‌های پیکربندی خاص‌منظوره یا مکانیزم‌های پیکربندی خاص هر زبان‌ برنامه‌نویسی، این متغیرها مستقل از استاندارد زبان و سیستم عامل تعریف می‌شوند.

گروه‌بندی یکی دیگر از موضوعات مدیریت پیکربندی (config) است. گاهی‌ افراد متغیرهای پیکربندی را در قالب گروه‌هایی دسته‌بندی می‌کنند که نام آنها ترکیبی است از انواع استقرار (development, test, ,production) و کلمه‌ی environments . چنین روشی مقیاس‌پذیر نیست زیرا با اضافه شدن انواعی جدیدی از استقرار مانند staging یا qa به نام‌های جدیدی برای محیط‌ها نیاز خواهیم داشت. حتی احتمالا با رشد پروژه و ورود توسعه‌دهندگان جدید، هر فردی محیط‌ دلخواه و مورد نیازش را به فهرست محیط‌های قبلی اضافه خواهد کرد (مانند smith-qa یا smith-development). چنین اتفاقی باعث رشد نمایی و انفجار تعداد پیکربندی‌ها (config) می‌شود و عملا مدیریت استقرار را پراشتباه و فلج می‌نماید.

در هر برنامه دوازده عاملی، هر متغیر محیطی (environment variables یا env vars) مانند یک واحد کنترل‌کننده کوچک است که هیچ ارتباط یا وابستگی به بقیه متغیرهای محیطی ندارد. هرگز نباید تعدادی از آنها را تحت عنوان یک محیط جدید (environment) با هم دسته‌بندی کنید. بلکه باید تک‌تک آنها را هر نسخه از استقرار مقدار دهی و مدیریت کنید. با رشد طبیعی برنامه و افزایش نسخه‌های استقراریافته‌ی آن، این مدل نیز می‌تواند پا به پای آن رشد کند و به بالندگی برسد.

پانوشت:
استقلال یا orthogonal بودن دو متغیر محیطی (env var) به چه معناست؟
orthogonal به این معناست که دو متغیر محیطی می‌توانند مستقل از همدیگر تغییر کنند و تغییر یکی لزوما منجر به تغییر دیگری نمی‌شود. در نتیجه هنگام انتخاب متغیرهای محیطی باید بدون در نظر گرفتن محیط‌های استقرار (مانند development, test, and production)، یک سری از متغیرها را شناسایی و به عنوان متغیر محیطی تعریف کرد

نوشته‌های قبلی:
– قسمت سوم: وابستگی‌ها (۳)

مترجم: حمید آقای خاتمی

گزیده:
بگذارید تعریف کاملاً متفاوتی از موفقیت به شما ارائه دهم، تعریفی که دست کم دو هزار سال قدمت دارد. موفقیت، براساس تعریف خود، نه به میزان منزلت و اعتباری که جامعه به فرد می‌دهد وابسته است و نه به قرار گرفتن در فهرست‌های مبتذل. تعریفش این است؛ موفقیت حقیقی، موفقیت درونی است. همین!» رولف دوبلی
مرجع:‌ ویکی گفتار