ارائه توسط: Alexander Arno
مترجم: مرتضی هاشمی 1394/02/17
در این برنامه مایکل با آرنو درباره‌ی طراحی بر اساس قراداد (Design By Contract) صحبت می‌کند.
آرنو طراحی بر اساس قرارداد چیست و از کجا آمده است؟
طراحی بر اساس قرارداد در واقع الگویی برای طراحی نرم‌افزار است؛ روشی برای فکر کردن به واسط‌ها (interface) و روشی برای جداسازی واسط‌ها از پیاده‌سازی‌ها است. اصطلاح طراحی بر اساس قرارداد در دهه‌ی 80 توسط برتراند میر مطرح شد. او نویسنده‌ی کتاب Object Oriented Software Construction و همچنین مخترع زبان Eiffel است که این مفاهیم را پیاده‌سازی می‌کند.
در نتیجه پیاده‌سازی‌هایی وجود دارد که از طراحی بر اساس قرارداد پشتیبانی می‌کنند، اما مهم، روش فکر کردن به طراحی است. ایده این است که شما [یک تعداد] انواع داده‌ای انتزاعی دارید، هر کدام از این انواع داده‌ای انتزاعی یک واسط دارند، و یک واسط، تنها امضای توابع آن نیست، بلکه شامل مشخصاتی مستقل از پیاده‌سازی است که رفتار آن تابع را تعیین می‌کند. پس به نوعی یک قرار داد ارائه می‌دهد و طبیعی است که در مورد هر چیزی به این شکل فکر کنیم. اگر واسط یک مجموعه (Collection) را در نظر بگیریم که دارای توابع add()، remove() و get() باشد، بدیهی است که انتظار داریم تابع get() در ابتدای کار هیچ چیزی برنگرداند، چون در ابتدا مجموعه خالی است. زمانی که یک عنصر را اضافه کنیم، get() آن را بر می‌گرداند. این چیزی فراتر از امضای توابع است؛ در واقع معنای پنهان شده در امضای توابع است. طراحی بر اساس قراداد روشی برای رسمی‌سازی این مفهوم است. اما حتی اگر زبان برنامه‌نویسی به صراحت از این امکان، پشتیبانی نکند، این طرز فکر مفید است.
یک قراداد دقیقاً چیست؟
قرارداد در واقع تشبیهی از زندگی روزمره است. قرارداد چیزی است که همه‌ی ما با آن آشنایی داریم. منظور این است که [زمانی که] با یک شئ تعامل می‌کنید، شما به عنوان فراخواننده، و شئ به عنوان آن‌چه فراخوانده می‌شود، روی یک قرارداد توافق می‌کنید. این شئ است که [مفاد] قراداد را تعیین می‌کند و شما یا باید آن را بپذیرید یا از آن استفاده نکنید. هر تابع از یک شئ تضمین می‌کند اگر شما به عنوان فراخواننده به بخش‌های مربوط به خود از قرداد پایبند باشید (اگر پیش‌شرط‌های (Pre-condition) مورد نیاز آن شئ را برآورده کنید) کار خود را انجام دهد. مسئله‌ی مهم این است که مانند زندگی روزمرّه، قرارداد چیزی دوطرفه است. فقط این نیست که شئ کاری را انجام دهد و من به عنوان فراخواننده وظایفم را انجام ندهم. این‌طور هم نیست که من به عنوان فراخواننده وظایفم را انجام دهم و شئ به دلخواه خود عمل کند -مثلاً اگر من یک اطاق را اجاره کنم، کلیدش را می‌گیرم و می‌توانم در آن زندگی کنم، اما به شرط اینکه اجاره‌اش را پرداخت کنم- بنابراین کاملاً دو طرفه است، فکر کردن به آن این‌گونه است.
نتیجه‌ی یک پیش‌شرط یا پس‌شرط (Post-condition) پس از ارزیابی چیست؟ آیا فقط یک مقدار بولین است یا چیزی بیشتر از این است؟
همان‌طور که می‌گویید، پیش و پس‌شرط‌ها عبارات بولین هستند. هر تابع لیستی از پیش‌شرط‌ها (لیستی از عبارات که حاصل آن یک مقدار بولین است) را دارد. حاصل این لیست پیش‌شرط‌ها هنگام فراخوانی باید مقداری درست باشد. لیست دیگری هم از پس‌شرط‌ها وجود دارد که آن هم لیستی از عبارات بولین است. شئ تضمین می‌کند اگر من پیش‌شرط‌ها را رعایت کنم، حاصل پس‌شرط‌ها هم پس از فراخوانی یک مقدار درست خواهد بود. فکر می‌کنم یک مثال در این‌جا مفید باشد. فرض کنید که یک تابع برای محاسبه‌ی ریشه‌ی دوم یک عدد اعشاری نوع Double داریم. بدیهی است که یک پیش‌شرط این است که پارامتر ورودی باید بزرگ‌تر یا مساوی صفر باشد. پس‌شرط هم این است که اگر نتیجه‌ی برگردانده‌ شده توسط تابع را در خودش ضرب کنم، همان مقدار ورودی حاصل شود. البته در واقع هیچ‌وقت دقیقاً همان عدد حاصل نخواهد شد. بنابراین اگر پس‌شرط را به صورت رسمی بیان شود باید گفت تفاوت میان نتیجه و عدد مورد نظر باید کم‌تر از یک عدد مشخص باشد. بنابراین شما دقتی برای محاسبات تابع تعیین می‌کنید. و این یکی از ارزش‌های مشخص کردن پیش و پس‌شرط‌ها به صورت رسمی را نشان می‌دهد، چون دقت عملیات را به صراحت در امضای تابع بیان می‌کند که در بسیاری از موارد مفید است.
ادامه مطلب ...

ارائه توسط: Jez Humble
مترجم: محمد علی بزرگ زاده 1394/01/11
در این اپیزود که در اواخر سال 2014 ضبط شده و در فوریه سال 2015 منتشر شده است با جز هامبل در مورد تحویل مستمر (Continuous Delivery) صحبت می‌شود. جز هامبل هم‌اکنون نائب‌رییس شرکت Chef است. او 14 سال سابقه کار IT دارد. به ‌غیر از کار توسعه و مدیریت، مشاوره هم می‌کند. نکته جالب این است که او در 11 سالگی کار برنامه‌نویسی را آغاز کرد و مجذوب ZX Spectrum شد. اما در ادامه از دانشگاه آکسفورد، لیسانس فیزیک و فلسفه گرفت. احتمالاً بیشتر افراد ایشان را از کتاب Continuous Delivery و کتاب Lean Enterprise می‌شناسند. صحبت امروز ما بیشتر در مورد کتاب تحویل مستمر و اتفاقاتی است که بعد از انتشار آن در سال 2011 افتاد.
آیا ممکن است به طور خیلی خلاصه به ما بگویید که تحویل مستمر چیست؟
قطعاً. تحویل مستمر، برآمده از تجربه‌هایی است که من و گروهی از افراد دیگر در شرکت ThoughtWorks داشتیم. ما بر روی پروژه‌های پیچیده و کاملاً بزرگی کار می‌کردیم و ریلیز کردن، همواره فرآیند رنج‌آوری داشت. در جایی، کار توسعه انجام می‌شد و بعد نرم‌افزار باید جای دیگری برای ریلیز در محیط عملیاتی می‌رفت و این کار فرآیند خیلی دشوار و رنج‌آوری داشت. ThoughtWorks در ارتباط با یکپارچه‌سازی مستمر (Continuous Integration) یکی از پیشگامان و از شرکت‌هایی بود که به محبوب شدن آن کمک کرده بود. بنابراین ما در یکپارچه‌سازی منظم کدها و اجرای منظم تست‌های خودکار خیلی خوب بودیم، اما فهمیدیم تنها این‌ها برای اینکه محصول برای عملیاتی شدن آماده شود، کافی نیست.
یکی از پروژه‌هایی که من در آن کار می‌کردم و این مسأله را برایم روشن کرد یک سیستم تأمین broadband بود که برای یک ISP نوشتیم. ما سیستم را بر روی لپ‌تاپ‌های ویندوزی توسعه می‌دادیم اما قرار بود سیستم بر روی یک کلاستر سولاریسی استقرار یابد. اولین باری که توانستیم به جایی مشابه با محیط عملیاتی آن دست پیدا کنیم، بیش از 6 ماه از پروژه گذشته بود و 2-3 هفته از ما وقت گرفت تا توانستیم آن را مستقر کنیم و وقتی آن را مستقر کردیم متوجه مشکلات معماری‌مان شدیم که به علت فرضیات بدی بود که افراد کرده بودند. مثلاً کَش کردن بر روی فایل سیستم بر روی لپ‌تاپ‌های ویندوزی خوب کار می‌کند اما بر روی کلاستر کار نمی‌کند زیرا در آنجا هر سرویسی فایل سیستم متفاوتی دارد. ما متوجه این مشکلات شدیم اما برطرف کردن آنها واقعاً پرهزینه بود. همین‌طور برای کمک در مستقر کردن سیستم یک تعداد اسکریپت‌های خودکار داشتیم که روی Ant اجرا می‌شدند اما تیم عملیات (Operation Team) علاقه‌ای به استفاده از Ant نداشت. ما از آنها پرسیدیم می‌خواهید برای عملیاتی کردن سیستم از چه استفاده کنید؟ آنها گفتند که ما فقط از Bash استفاده می‌کنیم. بنابراین مجبور شدیم برای استقرار Bash بنویسیم. در انتها یک تیم از بهترین‌های ما یک نرم‌افزار اختراع کرده و توسعه داد تا بتوانیم سیستم را بصورت منظم در محیط تست مستقر کنیم و بازخورد‌های تست را دریافت کنیم و بعد بتوانیم سیستم را بر روی محیط عملیاتی مستقر کنیم. همه‌ این تکنیک‌ها در کتاب تحویل مستمر گرد آمدند.
فکر می‌کنم آنچه باعث موفقیت آن شد این بود که افرادی که بر روی سیستم‌های تحت وب با مقیاس بزرگ کار می‌کنند، همه همزمان با هم از تکنیک‌های کاملاً مشابهی استفاده می‌کردند. وقتی ما کتاب را می‌نوشتیم، تیم فیتس درباره تحویل مستمر در شرکت IMUV (همان شرکتی که اریک ریس از بنیانگذارانش بوده) یک پست در وبلاگش گذاشت که البته آنجا، این مسأله طوفان عظیمی ایجاد کرده بود زیرا آنها هر روز چندین بار سیستم عملیاتی را مستقر می‌کردند.
ادامه مطلب ...

ارائه توسط: Leslie Lamport
مترجم: مرتضی هاشمی 1394/01/06
مصاحبه‌ای که می‌خوانید در آپریل 2014 ضبط شده است. مهمان این مصاحبه، لزلی لمپورت است. افتخارات او شامل برنده شدن جایزه‌ی Turing به خاطر کارهایش در زمینه‌ی سیستم‌های توزیع شده و همچنین ابزار نگارش و قالب‌بندی متن LaTex است. اخیراً لزلی روی TLA متمرکز شده است که مخفف Temporal Logic of Action (منطق زمانی کنش) است. TLA+ یک زبان تعیین مشخصات (Specification Language) است که برای تعیین مشخصات سطح بالای سیستم‌های همروند و توزیع‌شده مناسب است.
لزلی لمپورت از این‌که به SE-Radio آمدید متشکرم.
خوشحالم.
بردن جایزه‌ی Turing را به شما تبریک می‌گویم. این جایزه به خاطر کارهای شما در زمینه‌ی سیستم‌های همروند و توزیع شده است. شما یک سیستم توزیع شده را چطور تعریف می‌کنید؟
خوب، این چیزی نیست که من اخیراً به آن فکر کرده باشم. تعریفی که قبلاً داشتم این است: یک سیستم با چند فرآیند (Process) که در آن، زمان ارتباطات میان فرآیندی (Inter-Process Communication) در مقایسه با زمان میان رخدادها در یک سیستم تک‌پردازنده، زیاد است. به عبارت دیگر یک پردازنده زمان زیادی برای تبادل پیام با یک پردازنده‌ی دیگر صرف می‌کند، در حالی‌که دسترسی به حافظه‌ی خودش سریع‌تر است. البته همان‌طور که گفتم این تعریفی بود که من 30 یا 40 سال پیش داشتم. در حال حاضر به نظر می‌رسد که سیستم‌های توزیع شده تکامل پیدا کرده و به سیستم‌هایی تبدیل شده‌اند که در آن پردازنده‌ها با فرستادن پیام با هم ارتباط برقرار می‌کنند.
آیا این صرفاً تعریف رسمی شما را تغییر می‌دهد یا یک تعریف کاربردی جدید است؟
تعریف رسمی وابستگی به سیستم‌های توزیع شده ندارد البته بستگی دارد منظور از رسمی‌سازی چه باشد. منظور من از رسمی‌سازی چگونگی تشخیص و استدلال در مورد یک سیستم‌ توزیع شده است که با تشخیص و استدلال در مورد سایر سیستم‌های همروند متفاوت نیست.
بله منطقی است. چه موقع به فکر سیستم‌های توزیع شده افتادید؟ البته این را گفتید. چه چیزی شما را به سمت آن سوق داد؟
مطمئن نیستم. موقعی که به فکر آن افتادم، زمانی بود که یک گزارش فنی (Technical Report) نوشته‌ی Johnson و Thomas دریافت کردم. گزارشی که در مقاله‌ی Time Clocks به آن ارجاع داده‌ام. عنوان گزارش یادم نیست، اما فکر می‌کنم در مورد پایگاه داده‌های توزیع شده بود. به هر حال من آن گزارش را دریافت کردم و تا جایی که به یاد دارم این اولین باری بود که من به سیستم‌های توزیع شده فکر کردم.
به خاطر دارید که توجه شما به این موضوع متفاوت با سایر موضوعاتی باشد که پیش از آن مطالعه کرده بودید؟
نمی‌شود گفت متفاوت بود. خود مقاله موجب شد‌که مقاله‌ی Time Clocks را بنویسم. چون متوجه شدم که چیزی در کار آن‌ها اشتباه است. به طور خاص، الگوریتمی که آن‌ها استفاده کرده بودند، موجب نقض علیت می‌شد. یعنی زمانی که رخداد A به طور عِلّی رخداد B را به جریان می‌انداخت، در الگوریتم‌ آن‌ها رخداد B می‌توانست پیش از رخداد A پردازش شود. ایده‌ی اصلی مفهوم علیت، به این خاطر به ذهن من رسید که من با نسبیت خاص آشنایی داشتم. صرفاً با نگاه کردن به اتفاقات، برای من کاملاً واضح بود که این شرایط با نسبیت خاص معادل است. در نسبیت خاص علیت به این معنی است که آیا یک رخداد می‌تواند علت دیگری باشد یا خیر؛ و این وابسته به این است که آیا اطلاعات می‌تواند به صورت فیزیکی از یکی به دیگری منتقل شود یا خیر (به خاطر سرعت محدود انتقال نور). برای این‌که کمی منسجم‌تر بگویم، در نسبیت خاص، یک رخداد مقدم بر رخداد دیگری است اگر بتوان با استفاده از اشعه‌های نوری اطلاعات را از اولی به دومی ارسال کرد.
واضح بود که مفهوم معادل آن در سیستم‌های توزیع شده، به این ترتیب است که زمانی که یک رخداد مقدم بر دیگری باشد، این امکان وجود دارد که اطلاعات با استفاده از پیام‌های درون سیستم از رخداد اول به رخداد دوم انتقال یابد.
ادامه مطلب ...