ارائه توسط: 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 باقی می‌ماند.
ادامه مطلب ...

ارائه توسط: Randy Shoup
مترجم: محمد علی بزرگ زاده 1393/12/15
در این اپیزود که در سال 2014 ضبط شده است در مورد فرهنگ حاکم بر شرکت و همینطور استخدام در صنعت نرم‌افزار صحبت می‌شود. در این اپیزود با رندی شاپ مصاحبه می‌شود. رندی برای چندین شرکت بزرگ مانند اوریکو، ای‌بِی و گوگل کار کرده است و در حال حاضر مدیر ارشد فنی شرکت کیکسای است.
سلام رندی، به SE Radio خوش آمدی. دفعه قبل که با تو مصاحبه کردیم (اپیزود 109) در مورد معماری نرم‌افزار در ای‌بِی صحبت کردی اما الان در صنعت بازی‌سازی کار می‌کنی. چطور شد؟
این جابجایی مفرحی بود. من در ای‌بِی بعنوان مدیر ارشد برای 6 سال و نیم کار کردم و همانطور که گفتی در اپیزود 109 در مورد تجربه‌هایی که در آنجا داشتم صحبت کردم. بعد از آن یک استارتاپ کوچک برای خودم راه انداختم. از درآمدش نتوانستم جزیره اختصاصی برای خودم بخرم اما در نهایت چیزهای خیلی زیادی آموختم. بعد از آن در گوگل بعنوان مدیر فنی پروژه موتور برنامه‌های گوگل (Google App Engine) کار کردم که یک پلتفرم بعنوان سرویس (Platform as a Service) بود که 3 میلیون برنامه مختلف بر روی آن پلتفرم اجرا می‌شدند اما در سال گذشته بعنوان مدیر ارشد فنی یک شرکت بازی‌سازی در سانفرانسیسکو با نام کیکسای کار کرده‌ام. این جابجایی، یک جابجایی جذاب بود. به من در گوگل و ای‌بِی خیلی خوش گذشت و چیزهای زیادی در مورد ساختن سیستم‌های خیلی بزرگ و بزرگ کردن مقیاس سازمان آموختم. یکی از کارهایی که در کیکسای در حال انجام است همین بزرگ شدن است و به همین دلیل آنها به کسی که تجربه چنین کارهایی را داشته باشد علاقه نشان می‌دهند که هم در مورد بزرگ کردن مقیاس زیرساخت‌ها برای پشتیبانی از ده‌ها بلکه صدها میلیون کاربر تجربه داشته باشد و هم بداند چطور می‌توان مقیاس سازمان را برای پشتیبانی از این حجم عظیم، بزرگ کرد. من از زمانی که در کیکسای گذرانده‌ام لذت برده‌ام. صنعت بازی‌سازی به شدت با هیجان، مفرح و دوست‌داشتنی است. آنچه من می‌توانستم (برایشان) بیاورم، زیرساخت‌های برای مقیاس‌های بالای اینترنتی و رهیافت‌های ای‌بِی و گوگل برای کارهای سمت سرور (Server Side) بود که بیشتر کارهایم در آن ارتباط بوده است و آنچه می‌آموختم نیمه دیگر بازی‌سازی بود که خیلی جذاب بود یعنی مباحث مربوط به گرافیک، بازی کردن، موتورهای بازی‌سازی، شبیه‌سازی و خیلی جنبه‌های دیگر علوم کامپیوتر که در 20 سال گذشته هیچگاه با آن تماس نداشتم. برایم خیلی مفرح بود.
خیلی خوبه. اما فکر کنم هنوز گام‌های زیادی در پیش داشته باشید.
بله، همانطور که گفتم من این فرصت را دارم که در زمینه تکنیک‌های سمت سرور مربوط به مقیاس‌های بالا که در گوگل و ای‌بِی آموخته‌‌ام به آنها کمک کنم و آنها را در حوزه کاملاً جدیدی بکار بگیریم. کیکسای هم بر روی وب و هم بر روی دستگاه‌های موبایل، بازی‌های استراتژیک بلادرنگ می‌سازد. بخش جالب مهندسی ماجرا، بلادرنگ بودن آن است. بنابراین همه چیزی که ما باید یاد بگیریم این است که سیستم‌های با مقیاس بالایی داشته باشیم که تأخیر (Latency) به شدت پایینی داشته باشد و سرعت واکنش بالا داشته باشد. اینها می‌تواند در مورد موتور برنامه‌های گوگل بعنوان پلتفرم بکارگرفته شود یا بصورت یک وبسایت تجارت الکترونیک مانند ای‌بِی باشد و یا می‌تواند در بازی‌ها مثل کیکسای باشد. بنابراین خیلی از آموخته‌هایم بلکه همه آنها مستقیماً بکار می‌آید و این برای من ارزنده بوده است.
موضوع که امروز می‌خواهیم داشته باشیم یک بحث عمومی برای همه مخاطبان است که البته شامل خود من هم می‌شود اما شما در این موضوع، صحبت کرده‌اید. چرا تصمیم گرفتید که بیایید و عقاید خود در مورد استخدام و فرهنگ و اینجور موارد را به اشتراک بگذارید.
متشکرم. سئوال خوبی است. فکر می‌کنم همانطور که گفتید این یک موضوع جهانی است. من تاکنون در مورد خیلی چیزها صحبت کرده‌ام مثلاً برای مدت طولانی در مورد معماری‌های برای مقیاس بالا صحبت کرده‌ام، در مورد تحلیل‌گری و DevOps صحبت کرده‌ام. اما درسته، همانطور که شما گفتید فرهنگ، استخدام و سبکی که افراد در مهندسی دارند، موضوعاتی هستند که کمتر از حد درباره آنها صحبت شده است و برای همه شرکت‌ها به شدت مهم هستند چه شرکت‌های مهندسی باشند و چه نباشند اما خصوصاً در شرکت‌های مهندسی ما خیلی در مورد این صحبت می‌کنیم که چطور ماشین‌ها را خوشحال نگه داریم اما شاید آن مقدار که باید برای خوشحال نگه داشتن آدم‌ها وقت صرف نمی‌کنیم.
ادامه مطلب ...