ارائه توسط: 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 پردازش شود. ایده‌ی اصلی مفهوم علیت، به این خاطر به ذهن من رسید که من با نسبیت خاص آشنایی داشتم. صرفاً با نگاه کردن به اتفاقات، برای من کاملاً واضح بود که این شرایط با نسبیت خاص معادل است. در نسبیت خاص علیت به این معنی است که آیا یک رخداد می‌تواند علت دیگری باشد یا خیر؛ و این وابسته به این است که آیا اطلاعات می‌تواند به صورت فیزیکی از یکی به دیگری منتقل شود یا خیر (به خاطر سرعت محدود انتقال نور). برای این‌که کمی منسجم‌تر بگویم، در نسبیت خاص، یک رخداد مقدم بر رخداد دیگری است اگر بتوان با استفاده از اشعه‌های نوری اطلاعات را از اولی به دومی ارسال کرد.
واضح بود که مفهوم معادل آن در سیستم‌های توزیع شده، به این ترتیب است که زمانی که یک رخداد مقدم بر دیگری باشد، این امکان وجود دارد که اطلاعات با استفاده از پیام‌های درون سیستم از رخداد اول به رخداد دوم انتقال یابد.
ادامه مطلب ...

ارائه توسط: Eberhard Wolff, Markus Volter
مترجم: محمد علی بزرگ زاده 1394/01/03
این اولین اپیزود از چندین اپیزودی است که SE Radio در مورد معماری سرویس‌گرا داشته است و در سال 2006ضبط شده است. در این اپیزود مارکوس و ابرهارد در مورد مبانی و خواستگاه‌های تاریخی معماری سرویس‌گرا صحبت می‌کنند و در مورد جنبه‌های فنی‌تر آن در اپیزودهای بعدی صحبت خواهند کرد.
انگیزه و خواستگاه SOA چیست؟ برچه اساس و فلسفه‌ای شکل گرفت؟ فکر می‌کنم شما یک مطالعه موردی در این مورد آماده کرد‌ه‌اید که می‌توانیم از آن شروع کنیم؟ درسته؟
بله، یک مطالعه موردی فرضی است. کاری که می‌خواهیم انجام دهیم این است که یک شرکت فرضی را در نظر بگیریم و ببینیم چطور آن شرکت، نرم‌افزارها و زیرساخت‌های IT خود را از طریق چندین تکنولوژی مختلف توسعه داده است. می‌خواهیم ببینیم چطور سفارش‌هایی که برایشان می‌آید را رسیدگی کردند زیرا این چیزی است که هر شرکتی آن را دارد و با تمامی فرآیندهای دیگری که در شرکت وجود دارد در تعامل است. آغاز مطالعه ما دهه 70 است. در دهه 70 شرکت ما امور IT را آغاز می‌کند و در آنجا مانند معمول ابتدا کار با Main Frame شروع می‌شود. برای اینکه به نوعی مقایسه داشته باشید، در سال 1972 بود که شرکت آلمانی SAP، تأسیس شد که در آن زمان‌ها (در آلمان) نرم‌افزارهایی که استفاده می‌شدند بیشتر در آنجا تولید و رسیدگی می‌شد. آنها برنامه‌ها‌‌ Main Frame یکپارچه‌ای (Monolithic) بهمراه تعدادی ترمینال‌ توسعه می‌دادند که یک سیستم پردازش دسته‌ای (Batch Oriented) بود به این ترتیب که کلیه سفارش‌های روزانه، در قالب یک دسته در انتهای روز پردازش می‌شد. این اولین گام بروز IT در سازمان بود.
در دهه 80 تکنولوژی بعدی که تکامل یافت کامپیوترهای شخصی (PC) بودند که به واسطه برنامه‌های صفحه گسترده (Spreadsheet) و برنامه‌های اداری مطرح شد؛ همینطور در PC برای دسترسی به Main Frame، تقلید کار ترمینال‌ها هم انجام می‌شد. در این موقع بود که سرورهایی در بخش‌های مختلف شرکت، ظاهر شدند. در دهه 90 بود که واسط کاربری گرافیکی به PC ها افزوده شد. در اینجا این سئوال مطرح شد که آیا PC باید برای برنامه‌های سازمان هم استفاده شود و تنها برای برنامه‌های صفحه گسترده‌ای استفاده نشود که از برخی شرکت‌ها خریداری شده است.
شما می‌گویید که برنامه‌های معظم (Enterprise) سازمان همچنان مبتنی بر سرورها یا Main Frame بودند و ترمینال‌ها و واسط‌های گرافیکی روی کلاینت‌ها تنها برای آن برنامه‌های Excel و برنامه‌هایی بودند که به وقت نیاز برای محاسبات صفحه گسترده‌ها استفاده می‌شدند.
برای محاسبات ساده استفاده می‌شدند. بعد از آن بود که واسط کاربری گرافیکی با بعنوان مثال برنامه Excel آمد. در اینجا این سئوال پیش آمد که آیا می‌توانیم کارهای پیشرفته‌تری هم با آن برنامه‌ها انجام دهیم؟
احتمالاً اینجا بود که پردازش‌های کلاینت سروری آمدند.
و همینطور تا اندازه‌ای شیء‌گرایی. به اعتقاد من شیء‌گرایی تا حدی با واسط کاربری گرافیکی پیوند خورده است زیرا تولید واسط کاربری گرافیکی با سیستم‌های شیءگرا کاملاً ساده و زیبا می‌شود. مثلاً می‌توانید ببنید که بعنوان مثال SmallTalk یا MFC با واسط کاربری گرافیکی، پیوند نزدیکی دارند. یا اگر به کتاب مرجع الگوهای طراحی نگاه کنید می‌بینید که خیلی از الگوها، در ارتباط با واسط‌های کاربری گرافیکی هستند و مثال‌های این کتاب در مورد واسط‌های کاربری گرافیکی است.
بله، یک فریم‌ورک بود که اریک گاما بر روی آن کار می‌کرد، اسمش را به خاطر نمی‌آورم اما خیلی از مثال‌های کتاب GOF از آن فریم‌ورک بود.
دقیقاً. اما چرا از شیء‌گرایی استفاده شد؟ همانطور که گفتیم به علت واسط کاربری بود و بعلاوه امروزه اهمیت بیشتری یافته است که از مدل توسعه‌ای استفاده کنید که بوسیله آن ابزارهایی برای تحلیل کسب و کار چه در طراحی و چه در برنامه‌نویسی داشته باشید. با این روش اموری از قبیل قابلیت نگهداریِ بالاتر و قابلیت استفاده مجدد بهتر، تضمین شده است.
اما همانطور که همه می‌دانیم اینها تنها تا حدی جامه عمل پوشید.
دقیقاً. اگر به ساختار سیستم‌های IT که در این سازمان داریم نگاه کنید، ما این برنامه یکپارچه را در Main Frame داریم و اگر بخواهید پردازش‌های با واسط کاربری گرافیکی دیگری را انجام دهید، مشکل اینجاست که برنامه Main Frame همچنان آنجاست و همچنان مجبورید که با آن سر و کار داشته باشید. بنابراین آنچه معمولاً رخ می‌دهد این است که برنامه‌های نسبتاً سبکی با زبان‌های شیء‌گرا بعنوان مثال C++ می‌نویسید اما همچنان منطق اصلی کسب و کار در Main Frame باقی می‌ماند.
ادامه مطلب ...