فیلم “جرونیمو: افسانه آمریکایی” (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)، یک سری از متغیرها را شناسایی و به عنوان متغیر محیطی تعریف کرد

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

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

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

روز معلم را به همه‌ی معلمان و استادان عزیزم و همه‌ی بزرگوارانی که برای من معلم بودند تبریک عرض می‌کنم و صمیمانه از آنها برای تک‌تک نکاتی که به من آموختند قدردانی می‌کنم. امیدوارم که شاگرد خوبی برای آموزه‌های شما بوده باشم.

«می‌توانید اسم یک پرنده را در تمام زبانهای دنیا یادبگیرید اما وقتی این کار به پایان رسید، شما دقیقاً هیچ چیز در مورد آن نمی‌دانید… پس بیایید به پرنده نگاه کنیم و ببینیم که چه می‌کند. این مسئله است که مهم است. من خیلی زود تفاوت میان دانستن نام یک چیز و شناختن آن چیز را آموختم.» ریچارد فاینمن

منبع: ویکی گفتار

قسمت اول را اینجا و قسمت دوم را اینجا بخوانید.

به جای بهانه، گزینه‌ها و راه‌کارهای جدیدی پیشنهاد کنید. نگویید که این کار شدنی نیست؛ توضیح دهید که چه کاری می‌توان برای نجات از شرایط کنونی انجام داد. آیا بهتر است کد را حذف کنیم (delete)؟ اگر به این نتیجه رسیدید،‌ این موضوع را با آنها در میان بگذارید و اهمیت و فایده‌های بازسازی کد (refactoring) را توضیح دهید.
آیا برای انتخاب بهترین راهکار به نمونه‌سازی اولیه (prototype) نیاز دارید؟ آیا برای جلوگیری از تکرار چنین شرایطی نیاز به تعریف و پیاده‌سازی آزمون‌های بهتر یا خودکارسازی آنها دارید؟ شاید برای انجام کار به منابع بیشتری نیاز داشته باشید. یا شاید لازم باشد زمان بیشتری را با کاربران بگذرانید و روش کار آنها را از نزدیک ببینید. شاید هم نیاز باشد تکنیک یا فناوری جدیدی را عمیق‌تر و دقیق‌تر یاد بگیرید. شاید یک کتاب یا یک دوره‌ی آموزشی بتواند به شما کمک کند. از درخواست کردن یا پذیرش و اعتراف به اینکه به کمک نیاز دارید نترسید.
قبل از اینکه بهانه‌های غیرمنطقی و ناموجه را با صدای بلند جار بزنید سعی کنید آنها را از ذهن خود بیرون بریزید. اگر فکر می‌کنید باید بهانه‌‌ی ناموجهی را با صدای بلند اعلام کنید، بهتر است ابتدا آن را با گربه‌تان در میان بگذارید. خدا را چه دیدی، شاید این گربه‌ی کوچک و ملوس شما، مسئولیت اشتباهات را قبول کند.

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

وقتی فهمیدید عبارت «راستش نمی‌دونم …» را گفته‌اید، بی‌درنگ آن را با عبارت «… ولی یه راهی پیدا می‌کنم» ادامه دهید. چنین رویکردی راهی فوق‌العاده برای پذیرش چیزهایی است که نمی‌دانید، اما در عین حال مانند یک فرد حرفه‌ای مسئولیت آن را قبول می‌کنید.

منبع عکس:
gettyimages.ca

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

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

قسمت اول را اینجا بخوانید.

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

اگر با این ریسک رو به رو هستید که احتمالا فروشنده سخت‌افزار هنگام بروز مشکل مطابق میل و خواسته شما عمل نمی‌کند، باید از قبل، یک طرح اضطراری (contingency plan) داشته باشید. اگر دستگاه ذخیره انبوه (mass storage) شما که تمام کدها روی آن است خراب شده و شما نسخه‌ی پشتیبانی (backup) از آن ندارید، این تقصیر فروشنده نیست بلکه تقصیر خود شماست. این که بروید و به رییس‌تان بگویید «گربه کد من رو خورده»، مشکل شما را حل نخواهد کرد و بدیهی است که بهانه‌جویی گره‌ای از مشکل شما باز نمی‌کند.

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

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

منبع: کتاب برنامه‌نویس عملگرا (The Pragmatic Programmer)

گزیده:
بزرگترین نقطه ضعف، ترس از ضعیف به نظر رسیدن است.
جی.بی. باسوئیت

و برف می‌بارد در بهار
آن هم چه برفی

۲ اردیبهشت ۱۴۰۲
۲۲ اپریل ۲۰۲۲

یکی از پایه‌های فلسفه عمل‌گرایی این است که مسئولیت اقدامات خود را در مورد پیشرفت شغلی، یادگیری و آموزش، پروژه و کار روزانه‌ بپذیرید. برنامه‌نویسان عملگرا (Pragmatic Programmers) مسئولیت حرفه‌ای خود را می‌پذیرند و از اعتراف به ناآگاهی یا اشتباه هراسی ندارند. بی‌شک این خوشایندترین جنبه برنامه‌نویسی نیست، اما شک نداشته باشید که اتفاقی است که همواره رخ می‌دهد حتی در بهترین پروژه‌ها. با وجود آزمون‌های جامع، مستندات باکیفیت و اتوماسیون یکپارچه، اشتباهات رخ می‌دهند. تحویل سیستم با تاخیر انجام می‌شود و مشکلات فنی پیش‌بینی‌نشده پیش می‌آید. این اتفاقات می‌افتند و تلاش ما بر این است که تا جایی که می‌توانیم با آنها حرفه‌ای برخورد کنیم. یعنی برخوردی صادقانه و سرراست (بی‌شیله پیله) با این موضوعات داشته باشیم. ما می‌توانیم به توانایی‌هایمان افتخار کنیم، اما باید به کاستی‌هایمان یعنی ناآگاهی، بی‌اطلاعی و اشتباهات خود نیز اعتراف کنیم و آنها را بپذیریم.

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

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

منبع: کتاب برنامه‌نویس عملگرا (The Pragmatic Programmer)

گزیده:
بزرگترین نقطه ضعف، ترس از ضعیف به نظر رسیدن است.
جی.بی. باسوئیت