عامل ۲: وابستگی ها (Dependencies)
وابستگی ها را به صورت شفاف و صریح بیان کنید و آن ها را ایزوله کنید (Explicitly declare and isolate dependencies)

اکثر زبان‌های برنامه‌نویسی دارای سیستم بسته‌بندی (packaging system) یا مدیریت بسته‌ها (package manager) برای توزیع و پخش کتابخانه‌ها هستند، مانند npm برای جاوا اسکریپت، pip برای پایتون و NuGet برای دات‌نت. کتابخانه‌هایی که با ابزار مدیریت بسته‌ها نصب می‌شوند می‌توانند در سطح کل سیستم (system-wide) نصب ‌شوند که با نام site packages نیز معروف‌ هستند یا می‌توانند فقط محدود به یک دایرکتوری شوند که برنامه در آن قرار دارد که با نام vendoring یا bundling نیز معروف هستند.

یک برنامه دوازده عاملی هیچ گاه اعتماد نمی‌کند که بسته‌ها از قبل در سیستم نصب شده‌اند و به صورت پیش‌فرض وجود دارند. این گونه برنامه‌ها همه‌ وابستگی‌ها را به صورت کامل و دقیق و به کمک یک «بیانیه اعلان وابستگی‌» (dependency declaration manifest) اعلام می‌کنند. به علاوه از یک «ابزار ایزوله‌سازی وابستگی» (dependency isolation tool) در طول اجرای برنامه استفاده می‌کنند تا مطمئن شوند که هیچ‌گونه وابستگی بیان‌نشده‌ای از محیط اطراف به داخل سیستم “نشت نمی‌کند” (leak in). وابستگی‌ها به صورت کامل و صریح و به شکل یکسان هم برای محیط عملیاتی و هم برای محیط توسعه اعمال می‌شوند.

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

یکی از مزایای اعلان صریح وابستگی‌ها (explicit dependency declaration) این است که راه اندازی (setup) را برای توسعه‌دهندگان تازه‌وارد ساده می‌کند. توسعه‌دهنده جدید کافی است نسخه‌ای ازکد (codebase) برنامه را روی دستگاه خود داشته باشد و آن وقت برای اجرا تنها به ابزارهای خود زبان (مانند پایتون) و ابزار مدیر وابستگی (مانند pip) ‌نیاز خواهد داشت. پس از این مراحل، آنها می‌توانند به کمک یک سری دستورات ساخت (build command) معین کارهای لازم برای اجرای برنامه را انجام دهند.

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

نوشته‌های قبلی:
– قسمت دوم: پایگاه کد (۲)

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

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

عامل ۱:‌ پایگاه کد (code base)

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

یک برنامه‌ی دوازده عاملی همیشه به کمک سیستم‌های کنترل نسخه (version control) مانند Git، Mercurial یا Subversion کنترل و ردیابی (track) می‌شود. به یک کپی از پایگاه داده‌ای که حاوی اطلاعات نسخه‌ها است مخزن کد (code repository) گفته می‌شود که معمولا به صورت مختصر به نام مخرن، code repo یا repo خوانده می‌شود.

معمولا ارتباط یک به یکی بین پایگاه کد و برنامه وجود دارد:

• وجود چندین پایگاه کد برای یک برنامه نشان می‌دهد که آن برنامه تنها یک برنامه جدا نیست، بلکه احتمالا یک سیستم توزیع‌شده است. هر مؤلفه (component) از این سیستم توزیع‌شده، خود یک برنامه‌ی جداست و هر یک از این برنامه‌ها به تنهایی می‌تواند عوامل دوازده‌گانه را رعایت کنند.
• اگر چند برنامه دارای یک کد یکسان و مشترک باشند، عوامل دوازده‌گانه را نقض کرده‌اند. راه حل این است که کد مشترک بین آنها جدا شود و در کتابخانه‌هایی قرار گیرد که بتوان به کمک مدیر وابستگی(dependency manager) در جاهای مختلف استفاده شوند.

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

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

نوشته‌های قبلی:
– قسمت اول: برنامه ۱۲ عاملی (۱)

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

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

مهم‌ترین تصمیم زندگی از دید ریک راس نویسنده کتاب A Perfect Day for Boss Up:

How you choose to spend your time is your most important decision in life.

گزیده:
ندارد.

پیش‌گفتار:
چندی پیش به صورت اتفاقی با مفهومی آشنا شدم با نام The Twelve-Factor App یا برنامه ۱۲ عاملی. برای من جالب آمد و بعد از گفتگو و بررسی آن در جلسات هفتگی با چند تن از دوستانم، تصمیم گرفتم که روزی آن را ترجمه نمایم. در این بین موضوع را با دوست خوبم حمید آقای خاتمی مطرح کردم و ایشان استقبال کردند تا آن را ترجمه نمایند. قرار بر آن شد که ایشان مطالب را ترجمه نمایند و بازنگری نهایی نیز بر عهده‌ من باشد. ضمن تشکر صمیمانه از ایشان،‌ امیدوارم آموختن این موضوع برای شما هم مفید باشد.

گفتار:

۱- معرفی

در دنیای مدرن، نرم افزارها معمولا به صورت خدمت (سرویس) ارائه می‌شوند و با نام‌های برنامه‌ی تحت وب (web apps) یا «نرم‌افزار‌ در قالب خدمت» (software-as-a-service) شناخته می‌شوند.

برنامه‌ دوازه عاملی (twelve-factor app) روشی برای ساخت برنامه‌های «نرم‌افزار در قالب خدمت» است که دارای ویژگی‌های زیر هستند:

• از شکل تشریحی (declarative) برای تعریف و راه‌اندازی خودکارسازی‌ها (automation setup) استفاده می‌کنند تا زمان و هزینه برای توسعه‌دهندگان تازه‌ وارد به پروژه به حداقل برسد.

• قرارداد مشخص و شفافی (clean contract) با سیستم عاملی که نرم‌افزار روی آن مستقر می‌شود دارند تا حداکثر امکان جابه‌جایی (portability) بین محیط‌های اجرا فراهم گردد.

• برای استقرار(deployment) روی سکوهای (platform) ابری مدرن مناسبند و نیازی به خدمت‌گذارها (server) و مدیریت سیستم‌ ندارند.

• تفاوت و دوگانگی بین محیط توسعه (development) و محیط عملیاتی (production) را به حداقل می‌رسانند و امکان استقرار پیوسته (continuous deployment) با هدف حداکثرسازی چابکی را فراهم می‌کنند.

• و بدون تغییرات قابل توجهی در ابزار، معماری یا شیوه‌‌های توسعه می‌توانند مقیاس و اندازه خود را افزایش دهند (scale up).

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

گزیده:
ارزش یک محصول به تعداد مشکلاتی است که می‌تواند حل کند تقسیم بر میزان پیچیدگی که کاربر برای استفاده از آن باید در ذهن خود نگه دارد. آیفون را با کنترل تلویزیون استاندارد مقایسه کنید: صفحه نمایش آیفون را می‌توان برای کارهای متفاوتِ بی‌شماری استفاده کرد، اما برای کار با آن اطلاعات کمی را باید به خاطر سپرد. برای کار با کنترل تلویزیون باید یادتان بماند که هر دکمه چه کاری انجام می‌دهد. هر چقدر بخواهید از کنترل تلویزیون برای کارهای بیشتری استفاده کنید، باید دکمه‌های بیشتری را به خاطر بسپارید. ما می‌خواهیم آیفون بسازیم، نه کنترل تلویزیون.
– آدام ویگینز: ارزش‌های شرکت Heroku (شرکت خدمات ابری)

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

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

گزیده:
خودت را در رویاهای داشتن چیزهایی که نداری، غرق نکن، اما موهبت‌هایی که دارا هستی را بشمار، و شکرگزارانه به خاطر داشته باش که چطور رؤیای داشتن شان را در سرت می‌پروراندی اگر آنها را نداشتی‌. مارکوس آئورلیوس

منبع:‌ویکی پدیا

یکی از نقش‌های دوست‌داشتنی مجموعه کلاه‌قرمزی، فامیل دور است. او از اهالی دور است و ارادت ویژه‌ای هم به درب دارد. حالا با اقتباس از فامیل دور،‌ برنامه‌نویسی که از راه دور کار می‌کند (دور کار هستند) را برنامه‌نویس دور می‌نامم. در این نوشته چند نکته‌ای درباره‌ی برنامه‌نویسان دور را که از دوستان و اخبار یادگرفته‌ام، بازگو می‌کنم.

در گزارشی از مجله‌ی Communications of the ACM خواندم که «کمبود توسعه‌دهندگان نرم‌افزار» در راه هست و شرکت‌های بزرگ فناوری اطلاعات با این چالش بزرگ باید دست و پنجه نرم کنند. مقاله را می‌توانید اینجا بخوانید.

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

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

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

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

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

متاسفانه امروز با خبر شدم خانم مهندس آزاده داننده از بین ما رفت.
برای او که «آزاده» زیست و در کار خود، «داننده» بود، آرامش ابدی و برای بازماندگان و همکارانش به ویژه سرکار خانم مهندس افسانه عمادافشار صبر و سلامتی آرزومندم.