ارائه توسط: Luke Hoban
مترجم: عماد خضری 1394/11/16
در این اپیزود که در مارس ۲۰۱۱ منتشر شده است، مارکوس ولتر به مصاحبه با لوک هابان ، مدیر پروژه F# در مایکروسافت می‌پردازد.
سلام، لطفا خودت را به طور مختصر برای شنونده‌های ما معرفی کن.
حتما، اسم من Luke Hoban است و مدیر برنامه‌ی F# مایکروسافت هستم. F# در 4-5 سال گذشته به عنوان یک پروژه تحقیقاتی مایکروسافت در حال انجام بود و پارسال تصمیم گرفتیم که آن را به عنوان یک محصول تحت پشتیبانی مایکروسافت عرضه کنیم. بنابراین من در گروهی کار می‌کنم که F# را از یک پروژه تحقیقاتی به بخشی از زبان‌های برنامه‌نویسی پشتیبانی شده .Net تبدیل می‌کند.
مطمئناً بسیاری از افراد در مورد F# چیزهایی شنیده‌اند و فکر می‌کنم پسوند شارپ اشاره به .Net بودن این زبان دارد. اما اگر ممکن است به طور خلاصه برای شنوندگان توضیح بده که F# چیست؟ مثلا F# در یک جمله ...؟
البته، اگر بخواهم F# را در یک جمله توضیح دهم، درواقع F# یک زبان برنامه‌نویسی رویه‌ای (Functional) برای پلتفرم .Net است. یک زبان برنامه‌نویسی رویه‌ایی مانند بسیاری دیگر، شما حتما زبان‌های رویه‌ای مانند Scheme، Lisp، Haskell و ML را می‌شناسید. F# مستقیما از خانواده زبان‌های ML ارث برده است و به طور خاص هسته زبان Ocaml را به اشتراک می‌گذارد. با این وجود F# زبانی است که کاملا با .Net تجمیع شده است و از سیستم شی‌گرای قدرتمند .Net بهره می‌برد. همچنین F# دارای ابزارهای خوبی برای برنامه‌نویسی دستوری (Imperative Programming) و انجام برنامه‌نویسی اکتشافی (Explorative Programming) در برخی زمینه‌ها می‌باشد.
مطمئناً در بخش‌های دیگر مصاحبه به مفاهیم اصلی زبان با جزییات بیشتر خواهیم پرداخت. شما گفتید که F# یک زبان رویه‌ای است . ما پیشتر اپیزودی درباره زبان‌های رویه‌ای داشتیم و احتمالاً شنوندگان می‌دانند که تابع جنبه‌ی اصلی در اینگونه زبان‌ها می‌باشد. پس اگر ممکن است کمی بیشتر توضیح دهید که توابع چگونه در F# استفاده می‌شوند و تفاوتشان با زبان‌های دیگر مانند C و پاسکال چه است؟
ایده توابع در زبان‌هایی مانند پاسکال و C به نوعی بسیار شبیه است اما در زبان‌های رویه‌ای می‌توان قدم‌های بیشتری برداشت و می‌توان از توابع به عنوان مقادیر درجه اول (First Class Value) استفاده کرد. بنابراین می‌توان توابع را به جاهای دیگر ارسال کرد، آن‌ها را به متغیرها نسبت داد، آن‌ها را در ساختار داده‌ها قرار داد و به عنوان یک آرگومان به دیگر توابع فرستاد. با استفاده از قابلیت ارسال یک تابع به عنوان آرگومان به دیگر توابع می‌توان قسمتی از کد را به شکلی که پیشتر در زبان‌‌های پروسه‌ای امکان‌پذیر نبود، استخراج کرد. درواقع زبان‌های رویه‌ای روی این تکنیک تاکید زیادی دارند.
یکی از نکاتی که به آن اشاره کردید، قابلیت بیان الگوریتم‌ها به شکلی بسیار مختصر است، به نظر من جنبه‌ی رویه‌ای بودن توابع یکی از دلایل آن است.
بله، من فکر می‌کنم با استفاده از قابلیت استخراج قسمت‌های مشترک کد و مجردسازی آن‌ها با استفاده از چیزهایی مانند توابع درجه یک و این حقیقت که زبان‌های رویه‌ای تغییرناپذیر (Immutable) هستند، می‌توان هسته‌ی اصلی کد را بسیار خلاصه‌تر نوشت. درواقع من فکر می‌کنم این مساله یکی از تفاوت‌های اساسی برنامه‌نویسی با زبان‌های عمومی و زبان‌های رویه‌ای است.
شما در صحبت‌هایتان از کلمه تغییرناپذیر(Immutable) استفاده کردید، آیا می‌توانید توضیح دهید که چرا این قابلیت در زبان‌های رویه‌ای اهمیت دارد؟ فکر می‌کنم افراد می‌دانند که تغییرناپذیر به این معنی است که نمی‌توان ساختار داده‌ها را عوض کرد، اما چرا این مساله در زبان‌های تابعی اهمیت دارد؟
این مساله به چند دلیل برای زبان‌های رویه‌ای اهمیت دارد. ایده اصلی تغییرناپذیری این است که اگر داده‌ای را به یک متغیر نسبت دهید، نمی‌توان دیگر آن متغیر را عوض کرد. این ایده برای استخراج قسمتی از کد و استفاده مجدد از آن بسیار کارایی دارد. فرض کنیم برنامه‌ای داریم که دارای وضعیت‌های به اشتراک گذاشته شده است که در بخش‌های مختلف سیستم به کار گرفته شده است، تغییر وضعیت‌های به اشتراک گذاشته شده می‌تواند بر روی رفتار سایر مولفه‌های سیستم تاثیر بگذارد. تکنیک‌های شی‌ءگرایی سعی دارند از روش‌هایی مانند محفظه‌سازی (Encapsulation) برای مخفی‌سازی وضعیت‌ها و کنترل دسترسی به آن استفاده کنند. اما اگر یک سیستم تغییرناپذیر داشته باشیم، دیگر لازم نیست نگران باشیم که دیگران رفتار برنامه را تغییر دهند.
اما مساله‌ جالبی که فراتر از بحث‌های پایه‌ای مهندسی نرم‌افزار، رایج شده است زمینه محاسبات توزیع شده و موازی است که در بسیاری از کاربردها خیلی استفاده می‌شود. همانطور که می‌دانید، موازی‌سازی در مقیاس‌ بزرگ به عنوان بخشی از تکمیل پروسه نرم‌افزار انجام می‌شود. زمانی که شما موازی‌سازی انجام می‌دهید یکی از مشکلات بزرگی که با آن مواجه می‌شوید و عموماً حل آن‌ها دشوار است، وجود وضعیت‌های به اشتراک گذاشته شده است. اگر Threadها یا قسمت‌های مختلفی از سیستم به شکل مستقل در حال اجرا باشند و تلاش کنند تا با وضعیت به اشتراک گذاشته شده ارتباط برقرار کنند، احتمالاً دچار مشکلاتی خواهیم شد. تکنیک‌های زیادی برای حل این مشکلات معرفی شده‌اند اما در نهایت بهترین راه حل برای این مساله در زبان‌های رویه‌ای وجود دارد و آن جلوگیری از داشتن وضعیت به اشتراک گذاشته شده است، با استفاده از قابلیت تغییرناپذیری در زبان‌های رویه‌ای می‌توان جعبه ابزاری برای نوشتن برنامه‌های بدون وضعیت اشتراکی داشت.
ادامه مطلب ...

ارائه توسط: Ben Hindman
مترجم: محمد علی بزرگ زاده 1394/11/01
در این اپیزود که درآگوست ۲۰۱۵ منتشر شده است، جف میرسون با بنجامین هایندمن مصاحبه می‌کند. بنجامین، همکار در تولید Apache Mesos بوده که یک پروژه متن باز است کهCPU، حافظه، فضای ذخیره‌سازی و دیگر منابع کامپیوتر را از ماشین انتزاع می‌کند و این امکان را فراهم می‌کند که سیستم‌‌های تحمل‌پذیر خطا و توزیع‌شده منعطف، به سادگی تولید شده و به صورت کارا اجرا شوند. بنجامین مدتی را به عنوان مهندس ارشد در توییتر گذرانده و اکنون در Mesosphere مشغول است.
بن هایندمن، به SE Radio خوش آمدی.
خیلی ممنون که دعوتم کردید.
در ارائه‌ای که داشتید صحبت خود را با این شروع کردید که به قول مارک کویج ، شما دارید یک سیستم توزیع شده می‌سازید. (اشاره به این مقاله با عنوان هیچ گریزی نیست، شما دارید یک سیستم توزیع‌شده می‌سازید -مترجم) پیش از آنکه به طور خاص در مورد Mesos عمیق شویم می‌خواهم بدانم شما چه تفکری در مورد معماری‌های مدرن سیستم‌های توزیع شده دارید؟
قطعاً. این سؤال خوبی است. فکر می‌کنم واقعاً جالب باشد زیرا همانطور که در مقاله مارک کویج که شما ارجاع دادید گفته شده است، در حال حاضر تقریباً همه دارند یک سیستم توزیع شده می‌‌سازند. اغلب افراد لزوماً متوجه نیستند که یک سیستم توزیع شده می‌سازند اما جزء ذاتی بیشتر نرم‌افزارهایی است که امروزه می‌سازیم چرا که این نرم‌افزارها یا لازم است حجم خیلی خیلی زیادی از ترافیک را رسیدگی کنند و یا اینکه مجبورید چندین عدد از آن‌ها را اجرا کنید تا خرابی‌ها را تحمل کنید. بنابراین فکر می‌کنم به نوعی همه دارند سیستم‌های توزیع‌شده می‌سازند هرچند شاید متوجهش نباشند.
مطلب واقعاً جالب در این مورد این است که سیستم‌های توزیع‌شده در بیشتر دوره‌های رسمی علوم کامپیوتر دانشگاه‌ها تدریس نمی‌شود. به خاطر دارم که وقتی در مقطع کارشناسی در دانشگاه واشنگتن درس می‌خواندم فقط یک کلاس سیستم‌های توزیع‌شده برای دانشجویان ارشد بود. شاید شروع کرده باشند که کلاسی هم برای دانشجویان کارشناسی بگذارند اما در اغلب مواقع تدریس نمی‌شود. بنابراین اغلب افراد این اطلاعات را یا از همکاران‌شان و یا در کتاب‌ها و صفحات وب و ... می‌یابند که البته مبحث پیچیده‌ای است، به نوعی پردازش موازی (Parallel Computing) است با این تفاوت که [انتظار] خرابی‌ها (Failure) هم وجود دارد بنابراین از آن هم سخت‌تر است.
در حال حاضر وقتی که از این سیستم‌ها استفاده می‌کنید باید نوعی از مدیریت حافظه را هم داشته باشید البته منظورم مدیریت حافظه به آن شکلی که در C یا C++ وجود دارد نیست؛ [منظورم این است که] وقتی می‌خواهید انتخاب کنید که کدام بخش از حافظه را می‌خواهید، سیستم‌عامل نوعی انتزاع برای‌تان فراهم می‌کند، سیستم‌عامل برای‌تان VMM (مخفف Virtual Memory Manager) فراهم می‌کند که کارها را خیلی خیلی ساده‌تر می‌کند اما وضعیت امروزی سیستم‌های توزیع‌شده این است که هر کسی مجبور است همه این کارها را دستی انجام دهد و تقریباً همه مجبورند که چرخ را دوباره اختراع کنند که باعث شده سیستم‌های توزیع‌شده تا این حد ناخوشایند‌تر و تولیدشان دشوارتر و احتمال خرابی‌شان بیشتر شود. بنابراین فکر می‌کنم امروزه شرایط سیستم‌های توزیع‌شده این چنین است و خوب هم هست چون فرصت بزرگی برای ساده‌تر کردن چشمگیر سیستم‌های توزیع‌شده مهیا شده است.
کمی بیشتر درباره قیاس آن با حافظه مجازی صحبت کنید چون حتی وقتی ما کار توسعه یک سیستم تکی را انجام می‌دهیم و مجبور نیستیم که یک سیستم توزیع‌شده را رسیدگی کنیم، ایده حافظه مجازی خیلی خوب است. در این مورد صحبت کنید و بگویید که Mesos چطور به مانند یک مدیر حافظه مجازی برای سیستم‌عامل مرکز داده‌تان عمل می‌کند.
قطعاً. فکر می‌کنم در حال حاضر مسائلی وجود داردکه هر سیستم توزیع‌شده‌ای باید آن را حل کند. به عنوان مثال اگر بخواهید به منظور توزیع‌شدگی، برنامه یا پراسسی را بر روی ماشین دیگری راه بیاندازید، بیشترِ آن را خودتان برنامه‌نویسی می‌کنید؛ یا باید کس دیگری نوعی کارگزار (Agent) برای‌تان بر روی آن ماشین قرار داده باشد یا باید خودتان روش راه انداختنش را بیابید. مثال دیگر، انتخاب پیشوا (Leader) است. در اکثر سیستم‌های توزیع‌شده مفهومی هست که مشخص می‌کند اکنون پیشوا یا هماهنگ‌کننده کیست. برای تشخیص اینکه چه کسی می‌تواند پیشوا باشد به الگوریتم‌های پیچیده‌ای نیاز دارید که در صورت [وجود احتمال] خرابی دشوارتر هم خواهد شد. ابزارهایی مانند ZooKeeper و etcd برای این منظور وجود دارند که واقعاً کمک می‌کند و مشکل را خیلی ساده‌تر می‌کند اما همچنان خیلی کارها هست که باید انجام دهید و موارد گمراه‌کننده زیادی وجود دارد که خودتان باید حلش کنید.
ادامه مطلب ...

ارائه توسط: Nati Shalom
مترجم: محمد علی بزرگ زاده 1394/09/06
در این اپیزود که در نوامبر ۲۰۱۰ منتشر شده است روبرت بلومن در حاشیه کنفرانس جاوا در سانفرانسیسکو با ناتی شالوم درباره معماری گریدهای درون حافظه‌ای (In-Memory Grid) مصاحبه می‌کند. ناتی مدیرعامل و بنیانگذار Gigaspaces و یکی از متفکران و بلاگر‌های برجسته در حوزه سیستم‌های توزیع‌شده است.
ناتی به SE Radio خوش آمدی.
خیلی ممنونم روبرت.
لطفاً‌‌ کمی در مورد خودتان به شنوندگان‌مان بگویید.
اول از همه، همانطور که شما گفتید من مدیرعامل و بنیانگذار Gigaspaces هستم. من در طول ۱۰ سال گذشته از موقعی که Gigaspaces را آغاز کردم با سیستم‌های توزیع‌شده سر و کار داشته‌ام و حتی قبل از آن، من بیشتر یک کارشناس در زمینه‌های دیگر محاسبات توزیع‌شده خاصه CORBA و J2EE و JINI بوده‌ام. من یک تکنولوژی‌گرا هستم و عاشق تکنولوژی، نرم‌افزار و اساساً آنچه انجام می‌دهم، هستم.
ما امروز می‌خواهیم در مورد معماری‌های گرید‌ درون‌حافظه‌ای صحبت کنیم. ما می‌توانیم با صحبت در مورد مقاله ای از پروفسور جان اوسترهات از دانشگاه استنفورد آغاز کنیم. من می‌دانم شما با آن مقاله آشنایی دارید. تز اوسترهات در آن مقاله را چطور خلاصه می‌کنید؟
فکر می‌کنم دو مطلب است که از این مقاله برمی‌آید و خیلی اهمیت دارند. یکی اینکه اقتصاد مربوط به حافظه RAM یا ذخیره‌سازی داده‌ها در RAM طی چند سال گذشته تغییرات شگرفی کرده است. او در این مورد یک مثال می‌زند: در گذشته این‌طور فکر می‌کردیم که در مقایسه با دیسک، هزینه یک گیگابایت RAM خیلی زیاد است اما اگر شما به غیر از ظرفیت ذخیره‌سازی، کارایی به معنای زمان دسترسی به داده‌ها را هم اندازه بگیرید، آنگاه برای یک نرخ پردازشی (Throughput) معین، حافظه می‌تواند ۱۰۰ برابر یا ۱۰۰۰ برابر ارزانتر از دیسک باشد که به نظر من می‌تواند انگیزه‌بخش باشد. مطلب دیگر این است که حافظه‌های با ظرفیت‌‌های بیشتر و قیمت‌های کمتری در دسترس قرار گرفته است. ما می‌توانیم در بازار همین روند پیشرفت را در مورد CPU هم ببینیم که ظرفیت، هر دو سال یکبار دو برابر شده و قیمت تقریباً با همین نرخ پایین می‌آید. این می‌رساند که می‌توانیم کارهایی که در گذشته قادر نبودیم را امروزه در حافظه انجام دهیم. به نظرم این مطلب اصلی مقاله است.
امروزه چه کارهایی را می‌توانیم در حافظه انجام دهیم که قبلاً نمی‌توانستیم؟
ما می‌توانیم از حافظه به عنوان جایگزینی برای دیسک استفاده کنیم. ما می‌توانیم از آن به عنوان سیستمی از رکوردها برای ذخیره‌سازی داده‌ها و انجام تراکنش استفاده کنیم. می‌توانیم از آن به عنوان پایگاه داده‌مان استفاده کنیم. می‌توانیم به قابلیت اطمینان آن اعتماد کنیم. ما می‌توانیم حافظه را حتی مطمئن‌تر از دیسک کنیم.
وقتی صحبت از این زمینه معماری می‌شود من این اصطلاح را شنیده‌ام که گفته می‌شود که «RAM، دیسک جدید و دیسک، نوار مغناطیسی جدید است.» منظورشان از این چیست؟
به این معناست که گذشته بر این، آنچه در زنجیره داده‌ها رخ می‌داد، به این شکل بود که دیسک در جلوی کار قرار می‌گرفت به این معنا که داده‌های عملیاتی را در خود ذخیره می‌کرد. بعد، انبارهای داده (Data Warehouse) بودند که داده‌های آرشیو شده را ذخیره می‌کردند. امروزه که حافظه حکم دیسک جدید یا پایگاه داده جدید را دارد، داده‌ها یک گام به عقب می‌روند. قبلاً انبارهای داده، بر روی نوارهای مغناطیسی بودند، اما الان بر روی دیسک هستند، امروزه همه آن نقش‌ها یک گام جابجا شده است.
آیا مقاله‌ای وجود دارد یا فردی را دیده‌اید که بگوید که الان برای پشته‌های نرم‌افزاری (Software Stack) متداول -که شامل یک وب سرور، سرور برنامه‌های کاربردی (App. Server) و یک پایگاه داده است که بر روی دیسک می‌نویسد- جایگزین‌هایی ایجاد شده که نهایتاً همه چیز را در دیسک نمی‌نویسد؟
بله، و به نظر من این موضوع چند جنبه دارد. یکی این است که چون داده‌ها را در حافظه ذخیره می‌کنیم -که لزوماً همان جایی است که خود برنامه هم قرار دارد- پس دیگر نیازی به داشتن آن لایه‌های برنامه نیست، دیگر مجبور نیستیم مانند آن زمان که داده‌ها از برنامه‌ مجزا بودند همه جور پیچیدگی مدیریت برنامه و چرخه زندگی [داده‌ها] و سازگاری و دسترس‌پذیری آنها را داشته باشیم و برای این منظور به لحاظ میزان تأخیر و نرخ پردازشی هزینه بدهیم. اگر داده‌ها همان جایی باشند که برنامه قرار دارد، می‌توانیم از آن بهره بگیریم و در‌ واقع برنامه را طوری معماری مجدد و طراحی کنیم که از مزیت آن بهره ببریم و این ایده‌ تنها در صورتی عملی است که داده‌ها به حافظه بیایند.
ادامه مطلب ...