ايميل:

كلمه عبور:


مرا از مطلب‌های جدید باخبر کن!
ايميل من:


فهرست مطالب


ارائه توسط: Jonas Boner
مترجم: سید مرتضی هاشمی 1396/09/21
در این قسمت که در آگوست ۲۰۱۱ ضبط شده است مارکوس ولکر با یوناس بونر در مورد Akka صحبت می‌کند. Akka یک چارچوبِ کاری مبتنی بر اسکالا است که برای برنامه‌های هم‌روند (Concurrent) و توزیع‌شده استفاده می‌شود. Akka از اکتورها، ارتباط از راه دور، و حافظه‌ی تراکنشی پشتیبانی می‌کند. در این مصاحبه به مهم‌ترین جنبه‌های Akka و چگونگی استفاده از آن نگاهی می‌اندازیم. علاوه بر این به طور خلاصه در مورد فعالیت یوناس در شرکت Typesafe صحبت می‌کنیم.
به این قسمت از برنامه‌ی مهندسی نرم‌افزار خوش آمدید. در این قسمت باز هم در مورد چیزی مرتبط با اسکالا صحبت می‌کنیم. تا به حال دو قسمت در مورد آن داشته‌ایم: یک قسمت معرفی اسکالا و یک قسمت دیگر هم برای خبرهای جدید ، که مارتین ادرسکی مهمان آن‌ها بود. در این قسمت در مورد یک پروژه‌ی میان‌افزار (Middleware) جالب اسکالا به نام Akka صحبت می‌کنیم. احتمالاً در مورد آن شنیده‌اید. در آن سوی خط با یوناس بونر صحبت می‌کنم که توسعه‌دهنده‌ی پیشرو و مخترع Akka است. درست است؟
بله. البته امروز [انجمن] Akka بیش از من است. چند سال پیش شروع کردم و طی یک و نیم سال گذشته یک تلاش تیمی بوده است.
فکر می‌کنم ویکتور کلنگ یکی از آن‌هاست که همیشه توئیترش را می‌خوانم :-)
بله. او یکی از توسعه‌دهندگان کلیدی است؛ آدم خارق‌العاده‌ای است. توسعه‌دهندگان فوق‌العاده‌ی دیگری هم داریم و من فقط یکی از اعضای گله هستم :-)
شما قطعاً چهره‌ای هستید که بسیاری آن را به Akka نسبت می‌دهند. آیا می‌خواهید کمی خودتان را معرفی کنید تا افراد بدانند با که صحبت می‌کنیم؟
حتماً. من یوناس بونر هستم. من در سوئد زندگی می‌کنم؛ در شهر کوچکی به نام آپسالا خارج از استُکهلم. بیش از پنج سال است که با اسکالا کار می‌کنم. قبل از اسکالا با Erlang وارد برنامه‌نویسی تابعی (Functional) شدم. خلاصه این‌که از Erlang خیلی به هیجان آمدم و تلاش کردم سایر افراد -چه همکاران، و چه مشتریان- را نیز ترغیب کنم اما کار سختی بود. زبان فوق‌العاده‌ای است اما سیستم زمان اجرا و کتابخانه‌های مخصوص به خودش را دارد. اما من فکر می‌کردم چیزهای زیادی خوبی در مورد آن هست و نباید آن را در حد خوره‌های (Geek) زبان Erlang نگه داشت. می‌خواستم برخی از مفاهیم آن را به JVM منتقل کنم. بنابراین حدود دو و نیم سال پیش Akka را شروع کردم. پیش از آن در یک شرکت خوشه‌بندی JVM به نام Terracotta کار می‌کردم. در فاصله‌ی بین Terracotta و Akka در شرکت مشاوره‌ای خودم هم کار می‌کردم. قبل از Terracotta حدود چهار یا پنج سال در مجموعه BEA در تیم JRockit و تیم JVM کار می‌کردم. آن‌ها یک تیم در استُکهلم (سوئد) دارند. بنابراین من عمدتاً درگیر نوشتن محصولات میان‌افزاری در سیستم‌ها بوده‌ام. علاوه بر این در زمینه‌ی مقیاس‌پذیری همروندی کد (Code Concurrency Scalability) مشاوره می‌دهم که بیشتر مربوط به سمت سرور در پشته‌ی [تکنولوژی‌های برنامه‌نویسی] است.
با نگاه به Akka کاملاً واضح است که Erlang الهام‌بخش آن بوده است. ممکن است خلاصه‌ای از Akka به ما بگویید؟ و این‌که تأثیر‌پذیری‌های اصلی آن از Erlang چیست؟ بعداً در مورد ماژول‌های مختلف آن صحبت می‌کنیم اما فعلاً در یک توصیف اجمالی آن را خلاصه کنید.
قطعاً از Erlang تأثیر گرفته، اما از برخی زبان‌ها و ابزارهایی دیگر هم تأثیر گرفته است. من تلاش کرده‌ام برخی ابزارها و روش‌های فکری را که ممکن است به نظر یک توسعه‌دهنده‌ی عادی جاوا، بیگانه به نظر بیاید را کنار هم بیاورم. ابزارهایی که مشکلات همروندی و مقیاس‌پذیری، و تحمل‌پذیری شکست (Fault Tolerance) را به شکل زیبایی حل می‌کنند. ما مدل اکتور در همروندی (Actor Model of Concurrency) را از Erlang اقتباس کردیم که مدلی حتی بهتر از محاسبات توزیع‌شده است. سبک تحمل خطا و قابلیت اطمینان (Reliability) را هم از Erlang اتخاذ کردیم که گاهی به آن «بگذار خراب شود» (Let it Crash) یا «شکست را بپذیر» (Embrace Failure) گفته می‌شود. بعداً بیش‌تر در مورد این صحبت می‌کنیم.
ما از Akka برای مقیاس‌پذیری عمودی روی معماری‌های چند هسته‌ای استفاده می‌کنیم؛ یعنی همروندی را می‌پذیریم. همچنین از Akka برای مقیاس‌پذیری افقی روی چند JVM استفاده می‌کنیم. می‌توانید این‌کارها را انجام دهید و از همان سیستم زمان اجرا (Runtime) استفاده کنید. اساساً یک بار کد را می‌نویسید [و همه‌جا آن را اجرا می‌کنید] و به هیچ کدام از این‌ها فکر نمی‌کنید. بنابراین اگر با مدل اکتور کار کنید برنامه‌ی خود را برای مقیاس‌پذیری عمودی یا افقی و گاهی هر دو، آماده کرده‌اید. چون این سطح از واگذاری مسئولیت‌ها (Indirection) را دارید، سیستم زمان اجرا می‌تواند در زمان مقیاس‌پذیری افقی یا عمودی به جای شما این تصمیم‌ها را بگیرد.
ادامه مطلب ...

ارائه توسط: Kief Morris
مترجم: محمد علی بزرگ زاده 1396/06/24
در این اپیزود که در سپتامبر ۲۰۱۶ منتشر شده است سوئن جوهان با کیف موریس صحبت می‌کند. کیف یک متخصص پردازش ابری در ThoughtWorks و نویسنده کتاب Infrastructure as Code از انتشارات O'Reilly است. می‌خواهیم بدانیم چرا این مبحث اهمیت روزافزون یافته است. بعد از آنکه در مورد مزایای آن یعنی امنیت، قابلیت حسابرسی، قابلیت تست، مستندسازی و قابلیت ردیابی صحبت کردیم، در این مورد بحث می‌کنیم که چطور می‌توان آن را در سازمان‌ها بنا نهاد.
کیف، به مصاحبه خوش آمدی.
متشکرم.
آیا هیچ چیز مهمی درباره شما بوده که فراموش کرده باشم ذکر کنم.
فکر می‌کنم این‌ها که گفتید مهم‌ترین‌های حال حاضر است.
بسیار خوب. زیرساخت با کد (Infrastructure as Code) چیست؟
روش‌های زیادی برای پاسخ دادن به آن وجود دارد. یکی این است که بگوییم بخش خودکارسازی (Automation) از CALM است که در DevOps مطرح می‌شود. CALM مخففی است که توسط DevOps ابداع شده است و از اول کلمات فرهنگ (Culture)، خودکارسازی (Automation)، یادگیری (Learning) و اندازه‌گیری (Measurement) تشکیل شده است. و بنابراین، زیرساخت با کد، بخش خودکارسازی آن است. در مورد نحوه انجام کارها توسط DevOps ها است که مدتی است این گرایش ایجاد شده که از ابزارهایی مانند Chef و Puppet و Ansible و SaltStack و … استفاده شود. فلسفه پشت آن را می‌توانم به این شکل بیان کنم که هم‌اکنون زیرساخت بجای اینکه یک چیز فیزیکی باشد مانند داده یا نرم‌افزار شده است و لایه‌های فیزیکی انتزاع شده‌اند. بنابراین می‌توانیم از این ابزارها، به همان نحوی استفاده کنیم که از نرم‌افزارها استفاده می‌‌کنیم. در نتیجه ابزارها و رویه‌هایی که در توسعه نرم‌افزار داریم مانند پکپارچه‌سازی مستمر (Continuous Integration)، توسعه برآمده از تست (Test Driven Development)، تحویل مستمر (Continuous Delivery)، سیستم‌های کنترل نسخ (Version Control Systems) و همه این‌گونه موارد را می‌توانیم به این حوزه هم بیاوریم و آن‌ها را بکار گیریم تا زیرساخت خود را مدیریت کنیم.
بسیار خوب. آیا بین زیرساخت با کد (Infrastructure as Code)، زیرساخت قابل برنامه‌نویسی (Programmable Infrastructure) و زیرساخت تعریف‌شده با نرم‌افزار (Software Defined Infrastructure) تفاوتی هست؟
دست‌کم از نظر من، زیرساخت قابل برنامه‌نویسی و یا زیرساخت و یا شبکه‌ی تعریف‌شده با نرم‌افزار، توانمندساز هستند. این‌ها ابزار هستند. وقتی مثلاً یک پلتفرم ابری مانند AWS یا OpenStack داریم به این معنی است که ما می‌توانیم این زیرساخت‌ها را برنامه‌نویسی کنیم چون برای آن API دارند. و زیرساخت با کد، به نوعی فلسفه نحوه انجام این کار است. این ایده‌ها که نرم‌افزار را با فایل تعریف کنیم و آن‌ها را تحت ابزارهای کنترل نسخ قرار دهیم، تست‌های خودکار را در قبالشان اجرا کنیم و آن را به محیط [اجرا] پیش بفرستیم، این‌ها همگی به شدت با هم مرتبطند.
من می‌خواهم بدانم که این چه ماحصلی داشته است؟ فکر می‌کنم اولین بار اصطلاح زیرساخت قابل برنامه‌نویسی را حدود ۲ سال پیش شنیدم. چه تغییری ایجاد شده که اکنون چیز مهمی شده است؟
فکر می‌کنم این مفاهیم، مدتی است که مطرح هستند. اگر بخواهیم یکی را نام ببریم که از پیشگامان باشد احتمالاً مارک برجس باشد که ابزار CFEngine را سال‌ها پیش در اوایل دهه ۹۰ ساخت. این‌ ابزار، فایل‌هایی داشت که در آن تعریف می‌کردید که زیرساخت‌تان چه شکلی باشد و ابزار، آن را اعمال می‌کرد و آن را به آن شکل، استمرار می‌داد. فکر می‌کنم ایده‌ها از اینجا شکل گرفت. بعدها حدود سال ۲۰۰۶ بود که DevOps یک مبحث دارای عنوان شد و روش‌هایی از کار کردن را هدف قرار داد که امروزه خیلی‌ها دارند بکار می‌برند.
وقتی من کار بر روی کتابم را آغاز کردم، تصمیم گرفتم که برای عنوانش از «زیرساخت با کد» استفاده کنم اما مطمئن نبودم که مبدع این اصطلاح چه کسی است. بنابراین تلاش کردم تا او را بیابم؛ با خیلی افرادی که درگیر بودند صحبت کردم. هیچ‌کس نبود که دقیقاً بداند، همه من را به دیگری ارجاع می‌دادند تا اینکه به خانه اول برمی‌گشت. اولین موردی که من از بکار بردن این اصطلاح یافتم مربوط به جان ویلس است که توییترش با عنوان @botchagalup شناخته‌شده‌تر است. او بعد از آنکه فکر می‌کنم با اندرو کلی شفر و شاید لوک کینس از Puppet صحبتی داشت، مقاله‌ای نوشت. فکر می‌‌کنم تا جایی که ما توانسته‌ایم شناسایی کنیم این دو ممکن است مبدع‌ این اصطلاح باشند اما خیلی‌ها کارهایی برای متداول کردن آن انجام داده‌اند. فکر می‌کنم الان زمانی است که به عنوان یک موضوع، توجه خیلی‌ها را جلب کرده است.
ادامه مطلب ...

ارائه توسط: Mike Barker
مترجم: سید مرتضی هاشمی 1396/04/05
در این قسمت که در آوریل ۲۰۱۶ منتشر شده است مایکل بارکر با سوِن یوهان درباره‌ی معماری سامانه‌ی LMAX صحبت می‌کنند. بارکر یک برنامه‌نویس تحقیق و توسعه است و قبلاً در LMAX (London Multi Asset eXchange) مدیر نرم‌افزار بوده است. مایکل عضوی فعال در انجمن جاوا است و به صورت پراکنده در پروژه‌های متن‌باز از جمله GNU Class Path و Jboss و Mono شرکت می‌کند. در حال حاضر او در نیوزیلند زندگی می‌کند و به صورت دورکاری با LMAX همکاری می‌کند. LMAX یک بستر (Platform) با تأخیر (Latency) پایین و توان عملیاتی (Throughput) بالا، برای بورس است. از جمله مباحث مطرح شده در این مصاحبه می‌توان به این موارد اشاره نمود: LMAX چه می‌کند؟ منشأ LMAX کجاست؟ نیازمندی‌های شدید کارایی که LMAX با آن روبروست کدامند؟ سامانه‌ها و کاربرانی که LMAX با آن‌ها ارتباط برقرار می‌کند چه هستند؟ دو مؤلفه‌ی اصلیِ سامانه (کارگزار و بورس) چه هستند؟ چطور درک مکانیکی به عنوان یک محرکِ معماری بر LMAX تأثیر گذاشته است؟ گردش (Flow) پیام با استفاده از کتابخانه‌ی LMAX Disruptor چطور انجام می‌شود؟ الگوریتم‌های بدون قفل (Lock-free) چه هستند؟
مایک به برنامه خوش آمدی.
متشکرم سوِن.
آیا چیز مهمی را درباره‌ی شما فراموش کردم؟
در مورد چیزهای متن‌باز، تنها کاری که در حال حاضر انجام می‌دهم نگهداری LMAX Disruptor است که مطمئنم در مورد آن صحبت خواهیم کرد.
باشه. برای زمینه‌سازی [به ما بگویید] LMAX و Betfair چه هستند؟
با Betfair شروع می‌کنیم، چون بخش مهمی از تاریخ‌مان است. Betfair یک بستر شرط‌بندیِ ورزشیِ نظیر به نظیر (Peer to Peer) است؛ ورزش‌هایی از قبیل اسب‌سواری، فوتبال و ... . سال‌ها پیش قبل از آن که من با LMAX کار کنم، آن‌ها پروژه‌ای داشتند که می‌خواستند ساختن سامانه‌ای بسیار کارامد برای بورس را امتحان کنند؛ چیزی که صدها برابر از آن‌چه که در حال حاضر دارند، کارامدتر باشد. چون داد و ستدهای شرط‌بندی و داد و ستدهای مالی از لحاظ فنی کاملاً به هم شبیه‌اند. در هر دو، مفاهیم قیمت و مقدار را دارید، در سامانه شرط‌بندی تطبیق دادن (Match) افراد بر اساس شانس است و در سامانه مالی هم بر اساس قیمت است. بنابراین یک پروژه‌ی تحقیقاتی را راه‌اندازی کردند. در این زمینه به اکتشافات جالبی دست پیدا کردند که یک بورس چطور باید کار کند. آن‌ها تصمیم گرفتند برخی از این ایده‌ها را گرفته و شرکتی به نام Tradefair را راه‌اندازی کنند. بنابراین بسیاری از ایده‌های پروژه‌ی تحقیقاتی را -البته نه اصل کدها را-گرفتند و چیزی را ساختند که به تدریج به بورس LMAX تبدیل می‌شد. بعد از مدتی نام تجاری را تغییر دادند و از نام Tradefair فاصله گرفتند. از آن پس Betfair مالکیت LMAX را در اختیار داشته است. چند سال پیش سهم مدیریت توسط مدیر عامل خریده شد. بنابراین مالکیت LMAX الان کمی مستقل‌تر است. Betfair هنوز هم سهم دارد اما در حال حاضر بخش زیادی از LMAX تحت مالکیت مدیرعامل و کارمندان است.
آیا می‌توانید یک موردِ کاربرد متداول کسب و کار را برای LMAX نام ببرید؟ یک سفارش چیست؟
باشه. احتمالاً این را در توضیحات اولیه جا انداختم. LMAX چیست؟ ما به دنبال ساختن چیزی به نام (Contract For Difference) یا به اختصار CFD هستیم یعنی قراردادی برای داد و ستدهای مالی برای معامله‌ی هر جور دارایی از قبیل انتخاب‌ها (Options)، آینده‌ها (Futures)، و FX ها (Forex) و … . در‌واقع محصولاتی را درنظر بگیرید که تمام قیمت را پرداخت نمی‌کنید بلکه مشتقی از آن را می‌پردازید. در واقع به نحوی تکامل پیدا کردیم که بیشتر تمرکزمان بر فضای بورس خارجی باشد. خود LMAX در بورس FX اجرا می‌شود. ما این کار را برای بخش‌های مختلف بازار انجام می‌دهیم که به آن بورس حرفه‌ای می‌گوییم که بخش زیادی از آن کارگزاران و افراد ثروتمند هستند. بورس مؤسسات را داریم که به نوعی گران‌قیمت‌ترین داد و ستدها در آن انجام می‌شود. بورس بین بانکی را هم داریم که صراحتاً برای بانک‌هاست. برخی اصطلاحات هستند که در این صنعت کار با بورس متداول‌اند. مفاهیمی که می‌خواهیم در مورد آن صحبت کنیم، فرمان‌ها (Instructions)، سفارش‌ها (Orders) و معاملات (Trades)، و اجرا (Execution) هستند. در ابتدا کسی چیزی را در قالب یک پیام می‌بیند که می‌گوید می‌خواهم سفارش بدهم یا سفارش را لغو کنم. ما اصطلاحاً به این‌ها فرمان می‌گوییم. بنابراین پیام‌هایی که از مشتریان و فروشندگان دریافت می‌کنیم فرمان هستند. زمانی که [فرمان‌ها] به بورس می‌رسند، اجرا می‌شوند و چیزی را می‌سازند که به آن «اجرا» می‌گوییم. اجرا چیزی است که در بورس اتفاق افتاده است. در نتیجه‌ی یک اجرا می‌توانیم یک سفارش ایجاد کنیم، آن را لغو کرده یا جابجا کنیم. بنابراین یک سفارش، موجودیتی است که در بورس زندگی می‌کند و عمدتاً نوعی قیمت و مقدار دارد؛ قیمت می‌تواند اختیاری باشد. برخی سفارش‌ها مدتی در بورس می‌مانند و برخی ممکن است بلافاصله اجرا شوند. در اینجا خود سفارش‌ها هستند که جالب‌اند. اگر فرمان برای ایجاد یک سفارش با یک قیمت و مقدار مشخص بفرستید، این فرمان در جعبه‌ی سفارش‌ها قرار می‌گیرد و قیمتی خواهد داشت. بورس ما مسئول سفارش دادن این سفارش‌ها، بر اساس زمان رسیدن به بورس و قیمت تعیین‌شده است. سفارش‌های خرید، بر اساس بالاترین قیمت مرتب شده و پیشنهاد شوند. سفارش‌های فروش هم بر اساس کم‌ترین قیمت مرتب شده و پیشنهاد می‌شوند. هدف این است که همواره بهترین قیمت بازار را پیدا کنید. به محض این‌که سفارش‌هایی دریافت کنیم که قیمت‌های آن‌ها تطابق پیدا کند (سفارش خرید و سفارش فروشی که قیمت‌هایشان یکسان است یا همپوشانی دارد) داد و ستد اتفاق می‌افتد. در کاربرد ما ارز است [که داد و ستد می‌شود] اما می‌تواند پولی برای خرید کالا یا ... باشد. این مفهوم تجارت است که در آن دو طرف، چیزی را داد و ستد می‌کنند. این‌ها احتمالاً پنج مفهوم اصلی در یک بورس مالی هستند.
ادامه مطلب ...