ارائه توسط: Martin Thompson
مترجم: مرتضی هاشمی 1393/05/28
در این اپیزود، Robert Ford با Martin Thompson یکی از متخصصان پیشرو در تنظیم و بهبود کارایی سیستم‌های کامپیوتری است مصاحبه می‌کند. در این اپیزود، بحث می‌شود که چطور داشتن پیش‌زمینه و درک از عملکرد سخت‌افزاری و مکانیک کامپیوتر می‌تواند شما را در طراحی و توسعه مؤثرتر سیستم‌های نرم‌افزاری یاری دهد. مارتین، یک سخنران در کنفرانس‌های فناوری، بنیانگذار شرکت LMAX، یکی از بنیانگذاران پروژه متن بازِ Disruptor و صاحب بلاگی به نام درک مکانیکی (Mechanical Sympathy) است. او در حال حاضر صاحب Real Logic Ltd. است که یک شرکت مشاوره در زمینه‌ی سیستم‌های کامپیوتری در لندن است.
مارتین لطفاً کمی در مورد سوابق خود به شنوندگان ما بگویید. چطور به مبحث کارایی علاقه‌مند شدید؟
(این موضوع) خیلی حالبه، من کارهای زیادی در طول دهه‌های اخیر انجام دادم. اما همیشه به سمتی کشیده می‌شدم که کارایی کامپیوتر افزایش پیدا می‌کرد. در آنجا فرصت‌هایی ایجاد می‌شد که قبلاً وجود نداشت. فکر می‌کنم اولین کاری که در این زمینه انجام دادم به سال 92 بر می‌گردد که اطلاعات فرابورس را می‌گرفتم. در آن زمان مجبور بودیم همه چیز را روی Main Frame های IBM پردازش کنیم. این اطلاعات روی دو هارد دیسک که روی یک کامپیوتر نصب شده بودند، جا می‌شد. آن موقع اندازه‌ی هارد دیسک‌ها حدود 250 مگابایت بود. اما امروز ما نهان‌گاه‌ها (Cache) را برای نگه‌داری این اطلاعات داریم و این فرصت‌هایی را در کسب و کار ایجاد می‌کند که قبلاً امکان‌پذیر نبود.
فعالیت‌های حرفه‌ای من شامل چیزهای متفاوتی بوده است: مدل‌سازی وسایل نقلیه، کار با فهرست‌های بزرگ، کار با سیستم‌های تجاری. سیستم‌هایی که واقعاً با هم متفاوتند، اما تنظیم کارایی و دستیابی به توان عملیاتی (Throughput) بالا بخشی از اکثر این کارها بوده است.
اسم بلاگ شما درک مکانیکی است، منظورتان از آن چیست؟
درک مکانیکی اصلاح جالبی است. من از طرفداران مسابقات موتورسواری هستم؛ این اصطلاح از آن‌جا نشئت گرفت. Jackie Stewart نام موتورسواری در دهه‌های 60 و 70 است که موتورسوار فوق‌العاده موفقی بود و در زمین‌های مرطوب خیلی خوب عمل می کرد. او در مورد داشتن حس درک مکانیکی با موتوری که سوارش بود صحبت می‌کرد. زمانی که آن وسیله را درک می‌کرد، نسبت به بقیه‌ی موتور سوارها بهتر عمل می‌کرد و این در زمین‌های مرطوب به خوبی نشان داده می‌شد. در یک جمله درک مکانیکی یعنی به کارگیری قابلیت‌ها تا مرز توانایی آن و نه فراتر از آن، تا بهترین نتیجه حاصل شود. برای او درک مکانیکی به معنی هماهنگی در کار کردن با موتورش بود و برای من هم چیزی شبیه به این در سخت‌افزار و نرم‌افزار است. هر زمان که نرم‌افزار نحوه‌ی کارکرد سخت‌افزار و بستر سخت‌افزاری را درک کند، با آن هماهنگ می‌شود و بهترین نتیجه حاصل می‌شود.
امروزه تعداد زیادی از نرم‌افزارها را می‌بینیم که بر خلاف سخت‌افزار عمل می‌کنند و درک خیلی محدودی از آن دارند. در نتیجه نه تنها کارایی پایینی دارند، بلکه ممکن است دچار مشکلات دیگری هم بشوند: چون ابزارها به درستی استفاده نشده‌اند، هنگام رخ دادن شرایط مرزی مشکلات بروز می‌کنند. این به این معنی نیست که شما باید تمام جزئیات را مانند یک فرد خبره بفهمید، تنها دانستن موارد مهم کافی است. مثلاً در مسابقات موتورسواری، لازم نیست بدانم که موتور چطور ساخته شده است، فقط لازم است بدانم چطور کار می‌کند. بنابراین لازم است مفاهیم اساسی نحوه‌ی کارکرد جعبه دنده و سیستم تعلیق را بفهمم. با دانستن این موارد در سطح پایه‌ای می‌توان بهترین نتیجه را گرفت. در نرم‌افزار هم همینطور است.
ادامه مطلب ...

ارائه توسط: Michael Plöd
مترجم: محمد علی بزرگ زاده 1393/04/20
در این اپیزود، Arno با Michael Plöd در ارتباط با Object Relational Mappers یا OR Mappers مصاحبه می‌‌کند.
Michael لطفاً خود را معرفی کنید.
سلام، از اینکه به این مصاحبه SE Radio گوش می‌دهید ممنونم. نام من Michael Plöd است. من برای شرکت Senacor Technologies در نورمبرگ آلمان کار می‌کنم. نقش من توسعه‌دهنده ارشد یا معمار (هر چه اسمش را بگذارید) است. معمولاً بر روی پروژه‌های طولانی‌مدت تر کار می‌کنم. چند سال پیش کار با نگاشت‌گرهای OR را آغار کردم. بیشتر با نگاشت‌گرهای مبتنی بر جاوا از قبیل Hibernate و JDO و امروزه JPA کار کرده‌ام. خوشحال می‌شوم که سئوالات شما را بشنوم و امیدوارم بتوانم به آنها جواب دهم.
بیایید با این سئوال شروع کنیم که نگاشت‌گر OR چیست؟ درباره چیست؟
اساساً نگاشت‌گر OR چیزی است که به مسأله عدم تطابق بین اشیاء با روابط می‌پردازد. بین یک نرم‌افزار شیء‌گرا و پایگاه‌های داده یک عدم تطابق طبیعی وجود دارد. بعنوان مثال اگر به نحوه گروه کردن اشیاء یک حوزه (Domain) در مقابل نحوه تعریف کردن شِمای رابطه‌ای (Schema) نگاه کنید، بوضوح می‌بینید که از یک طرف با کلاس‌ها و خواص (Attribute) کار می‌کنید و نوع‌های داده‌ای دارید که یا مربوط به زبان برنامه‌نویسی است یا انواع داده‌ای است که خودتان داخل زبانی که با آن کار می‌کنید، تعریف می‌کنید. اما در طرف دیگر با جداول و ستون‌ها کار می‌کنید و این چیزها را داخل شِماها، گروه می‌کنید. در یک پایگاه داده رابطه‌ای نیز یک سیستم انواع داده دارید. اما در غالب پایگاه‌های داده این سیستم انواع داده خیلی استاتیک است. البته برخی از پایگاه‌های داده، گونه‌هایی از پشتیبانی انواع‌های داده تعریف شده توسط کاربر را دارند. اما اغلب این پشتیبانی خیلی پیشرفته نیست.
مطلب دیگر، جابجا شدن (Navigation) است. وقتی در گرافی از اشیاء جابجا می‌شوید، در یک نرم‌افزار شیء گرا یا کلاً در نرم‌افزار می‌دانید که چطور از یک موجودیت (Entity) مثلاً موجودیت A به سمت موجودیت B جابجا شوید. اما در طرف دیگر (در پایگاه‌های رابطه‌ای)، جابجایی، جهت ندارد. می‌توانید از جدول مشتریان به جدول صورتحساب‌ها جابجا شوید اما در همان حال می‌توانید از طریق کلید خارجی (Foreign Key) از جدول صوتحساب‌ها به جدول مشتریان هم جابجا شوید. بنابراین می‌بینید که یک مسیر جابجایی وجود ندارد.
بسیار خوب، اما برای دسترسی به داده‌ها، زبان برنامه‌نویسی SQL را دارید. چرا به نگاشت‌گر OR نیاز دارید؟ مزیت استفاده از یک نگاشت‌گر OR بر روی SQL نسبت به استفاده از تکنولوژی‌هایی که برای دسترسی مستقیم به پایگاه داده در زبان‌های برنامه‌نویسی وجود دارد، چیست؟
اساساً از یک نگاشت‌گر OR برای کپسوله کردن پایگاه داده استفاده می‌کنید. خیلی از شرکت‌ها می‌گویند که با استفاده از نگاشت‌گر OR می‌توانید بسادگی بین پایگاه‌های داده مختلف سوییچ کنید. بله، این درست است. اما من می‌گویم که در اکثر پروژه‌های شرکت‌های بزرگ، سوییچ کردن به یک پایگاه داده دیگر، چیز خیلی نادری است. فکر می‌کنم مورد کاربرد و مزیت اصلی استفاده از یک نگاشت‌گر OR این است که توسعه‌دهندگان با اشیاء کار کنند و مقدار زیادی کدهای منطق کسب و کار (Business Logic) ننویسند که اغلب مربوط به پردازش دستورات SQL باشد.
بعلاوه، کتابخانه‌هایی که تعامل با SQL را پیاده‌سازی می‌کنند، خیلی سطح پایین هستند. بعنوان مثال اگر به JDBC، دقت کنید، یک کتابخانه سطح پایین است که در آن با دستورات و ResultSet ها کار می‌کنید و می‌بایست بر روی نتایج حرکت کنید و خیلی از امور مربوط به مدیریت منابع (Resource Management) را انجام دهید. از این منظر، نگاشت‌گر OR کاملاً این چیزها را کپسوله می‌کند. (در آنجا) با فایل‌های XML، یا Annotation ها یا حتی از طریق قراردادهای نامگذاری (Code Convention)، گونه‌هایی از متادیتا را دارید که بوسیله آنها، توضیح می‌دهید که چطور کلاس‌هایتان را به جداول‌ نگاشت می‌کنید و توضیح می‌دهید که چطور ارث‌بری و روابط یا چیزهای دیگر را نگاشت می‌کنید.
ادامه مطلب ...

ارائه توسط: Rich Hickey
مترجم: جهانگیر زین‌الدین 1393/04/01
این بار ما می‌خواهیم در مورد Clojure صحبت کنیم. مهمان ما آقای Clojure، ریچ هیکی است.
لطفاً قبل از صحبت در مورد آنچه که ساخته اید، در مورد خودتان حرف بزنید.
خوب من ریچ هیکی هستم و Clojure را نوشته‌ام. این زبان، یک زبان برنامه نویسی دینامیک است که روی JVM و CLR (ماشین مجازی مایکروسافت برای اجرای کدهای دات نت) اجرا می‌شود. Clojure چهار ویژگی اصلی دارد: اول اینکه یک زبان مبتنی بر Lisp است. دیگر اینکه طوری طراحی شده که توسط یک ماشین مجازی میزبانی شود بنابراین رابطه صمیمانه‌ای با پلتفرم میزبان دارد. ویژگی دیگر این است که عمدتاً Functional (مبتنی بر توابع) است و روی تغییر ناپذیری و توابع محض و ساختمان داده‌های تغییر ناپذیر تاکید دارد. ویژگی بعدی این است که روی همزمانی متمرکز است و تمام جنبه های زبان طوری طراحی شده‌اند که در متن یک برنامه همزمان، معنای (Semantic) درستی داشته باشند.
بعداً در مورد آن بیشتر کنکاش خواهیم کرد اما قبل از آن می‌خواهم خوانندگان بدانند که ما قبلاً برنامه‌ای در مورد Lisp داشته ایم: برنامه شماره ۸۴ با گابریل. در اینجا ممکن است در مورد مقدمات Lisp به صورت مختصر صحبت کنیم، اما به خاطر ضیق وقت بنا نداریم معرفی کاملی از Lisp ارایه کنیم. اگر با Lisp، لااقل به صورت کلی آشنا نیستید می‌بایست به برنامه ۸۴ رجوع کنید. ریچ، علیرغم این به نظرم فکر خوبی است اگر Lisp را به صورت اجمالی معرفی کنید. مبانی اصلی Lisp چه هستند؟ چه تفاوتی با زبانهای برنامه نویسی دیگر دارد که به خاطر آن از نظر بسیاری افراد یک زبان خاص تلقی می‌شود؟
خوب، سوال آخر احتمالاً بهترین سوال است. بسیاری از چیزها که Lisp ابداع کرده است در زبان های دیگر نیز به صورت گسترده وجود دارد. فکر می کنم آنچه که Lisp رامنحصر به فرد می‌کند، این است که برنامه به صورت ساختمان داده به کامپایلر عرضه می‌شود، پس کامپایلر Lisp، متن را کامپایل نمی‌کند بلکه ساختمان داده‌ها را کامپایل می‌کند، و زمانی که شما با Lisp یا Clojure برنامه ای می‌نویسید در واقع با ساختمان داده‌ها و از طریق آنها برنامه می‌نویسید. اگر شما متنی را در فایلی ذخیره می‌کنید در واقع داده‌های عینی زبان، را ذخیره می‌کنید.
پس تفاوت این با زبانهایی که برنامه را ترجمه می‌کنند و از روی آن AST می سازند (که به نوعی یک ساختمان داده است که به کامپایلر عرضه می‌شود) چیست؟
این موضوع خیلی مرتبط است با اینکه آیا آن AST از چیزهایی ساخته شده که برنامه شما معمولاً با آن سر و کار دارد یا خیر. در یک برنامه Lisp و به طور خاص در Clojure، داده‌های عینی زبان، چیزهایی هستند که شما به صورت روزمره از آنها استفاده می‌کنید: vector، map و list. پس کتابخانه بزرگی برای کار با آنها وجود دارد. آنها کتابخانه های معمولی متعلق به زبان هستند و اینطور نیست که کتابخانه‌های خاصی برای کار با AST داشته باشید و لازم نیست برنامه خاص یا عجیبی برای دستکاری AST بنویسید.
پس می‌توان گفت برنامه نویسی و فرا-برنامه نویسی (Meta programming) هر دو یک چیز هستند!
دقیقاً، تفاوتی وجود ندارد، و این بسیار مهم است، اگر شما قبلاً با کتابخانه ای مربوط به AST کار کرده باشیدکه شیءگرا بوده باشد، می‌فهمید که دارید یک API خاص را می خوانید، اما زمانی که کد مربوط به یک ماکرو را در Lisp یا Clojure می‌خوانید کدهای کاملاً معمولی برای پردازش دادها هستند.
خوب شما از چه ساختمان داده‌های دیگری که پیشتر در مورد آنها صحبت کردید، استفاده کرده‌اید؟ چون Lisp به نظر فقط لیست های تو در تو است، درست است؟
این برای Lisp به صورت سنتی درست است، اما در Clojure چندین ساختمان داده دیگر وجود دارد که همگی در اولویت بالایی قرار دارند و مانند لیست درجه یک محسوب می شوند. این ساختارها، vector و map (که مشابه جداول درهم سازی (hash table) است) هستند. در نحو زبان فرم‌هایی وجود دارند که بر مبنای همین ساختمان داده‌ها ساخته شده‌اند، گاهی مبتنی بر vector ها و گاهی mapها.
شما می دانید و در برنامه ۸۴ هم آمده که Lisp زبان جدیدی نیست و یک رویکرد قدیمی است و در زمینه های خاصی با موفقیت مورد استفاده قرار گرفته است اما هیچگاه یکی از زبانهای اصلی مورد استفاده عموم نبوده است. شما چه فکری می‌کنید،‌ چرا این اتفاق نیافتاده است؟ و سوال بعدی اینکه چرا شما در سال ۲۰۰۹ یا ۲۰۱۰، Lisp خودتان را ساختید؟
(با خنده!) اینها دو سوال مجزا هستند. من مطمئن نیستم که Lisp برای استفاده عموم طراحی شده باشد، آن زمان که بوجود آمده برای کاربران ارشد طراحی شده مانند محققین و افراد بسیار باهوش که سعی می کردند مسایل بسیار سخت را حل کنند و Lisp اهرم کاملاً مناسبی برای تلاشهای آنها بود. به عنوان یک فرد شما قدرت باورنکردنی ای به واسطه Lisp داشتید.
ادامه مطلب ...