ارائه توسط: Jon Gifford
مترجم: محمد علی بزرگ زاده 1394/04/22
در این مصاحبه که در فوریه 2015 منتشر شده است، رابرت بلومن با جان گیفارد در ساختمان اداری زیبای شرکت Loggly واقع در مرکز شهر سانفرانسیسکو صحبت می‌کند. جان در رشته کامپیوتر از دانشگاه کانتربری، فارغ‌التحصیل شده است. او بیش از 25 سال است که در زمینه مهندسی نرم‌افزار مشغول است. تمرکز او بر روی سیستم‌های Back End بزرگ مقیاس با کارایی بالا و اخیراً برنامه‌های جستجو با تأخیر پایین بوده است. او بنیانگذار و کارمند ارشد در مباحث جستجو در Loggly است. این شرکت، زیرساخت‌های لاگ‌های میزبانی‌شده را فراهم می‌کند.
جان، به SE Radio خوش آمدید.
خیلی ممنون. خوشحالم که اینجا هستم.
من امروز در مورد لاگ‌ کردن و زیرساخت‌های لاگ کردن صحبت می‌کنم. ما جلسات زیادی در مورد نحوه طراحی نرم‌افزار، تست آن، تولید آن، فرآیندهای خوب داخل تیم و ... داشته‌ایم. اما جایی می‌رسد که باید آن را اجرا کنید...
بله، و اینجاست که موضوع لاگ کردن پیش می‌آید. وقتی زمان زیادی را برای نوشتن نرم‌افزار صرف کرده‌اید، لاگ کردن هم یکی از آن چیزهایی است که به زعم خیلی از افراد تا حدی مانند مستندسازی است. از این جهت که ایده خیلی خوبی است اما همیشه چیزی است که از قلم می‌افتد؛ به نوعی مثل یک فرزند ناتنی برای مهندسی نرم‌افزار است.
لاگ کردن یعنی چه؟
فکر می‌کنم موارد زیادی از چیزهای مختلف است. در ساده‌ترین سطح آن، تنها برخی پیام‌های استاتیک است که از کرنل و درایورهای کرنل می‌گیرید؛ خیلی مختصر و مبهم هستند و به نوع خاصی از رمزگشایی نیاز دارید تا بفهمید چه می‌گویند. از چنین چیزهایی تا ماتریس‌های خیلی ساخت‌یافته داده‌های مربوط به کارایی می‌تواند باشد و حتی -همان‌طور که خیلی از این نوع لاگ‌ها را می‌بینیم- می‌تواند تنها یک رشته باشد که تفکرات برنامه‌نویس باشد. جالب است که به لاگ‌ها سر بزنیم و ناسزاهایی که در آن هست را جستجو کنیم، هرگاه ناسزایی را در لاگ‌ها ببینید می‌فهمید که در جای جالبی از سیستم قرار گرفته‌اید. چیزهای زیاد متفاوتی هست.
ما نمی‌خواهیم که نمره‌ی خوبمان در iTune در زمینه مناسب برای خانواده‌ها! را از دست بدهیم، بنابراین از شما نمی‌خواهم که مثال بزنید! :-)
مطمئنم که مهندس‌ها چیزهای زیادی دارند که در موردش جستجو کنند :-)
هرچند این، عموماً روش خوبی در یک مصاحبه نیست اما از آنجاییکه این 4 سئوال به نظرم خیلی به هم مرتبط هستند می‌خواهم همه این 4 سئوال را یکجا از شما بپرسم: محتوای لاگ‌ها چیست؟ کدام بخش‌های سیستم لاگ‌ها را تولید می‌کنند؟ مصرف‌کننده لاگ کیست؟ و به چه منظوری لا‌گ‌ها تولید می‌شوند؟
بله، این‌ها پیوند تنگاتنگی با هم دارند. وقتی در مورد لاگ‌های رایج فکر می‌کنیم، لاگ‌های سیستمی و لاگ‌های برنامه‌، به ذهن می‌رسند. در اینجا منظور از برنامه، برنامه‌هایی که شما می‌نویسید یا برنامه‌های‌ شخص ثالث (Third Party) متن‌باز یا تجاری دیگر است. همه این گونه لاگ‌ها در همه سطوح مختلف را شامل می‌شود. این حقیقت که لاگ‌ زدن یک تاریخچه طولانی دارد به این معناست که کاربردهای مختلفی برایش داریم. اگر جاوا کار کرده باشید -من مدت طولانی به آن مشغول بوده‌ام- در آنجا فریم‌ورک‌هایی برای تولید لاگ وجود دارد که هدف اصلی طراحی آن خوانایی برای انسان بوده است. وقتی تکه کد جاوایی بنویسید و چیز جالب توجهی بیابید احتمالاً آن را با سطح info لاگ می‌زنید. اگر چیز جالب توجهی بیابید که بد باشد، آن را با سطح warn لاگ می‌زنید و اگر خیلی بد باشد احتمالاً آن را بعنوان error لاگ می‌زنید.
شاید یک رویه برتر در نوشتن لاگ این باشد که سعی شود لاگ‌ها هدایتتان کنند که چه کاری انجام دهید. وقتی لاگ می‌زنید حتماً باید به مخاطبین خود فکر کنید. برای بیشتر توسعه‌دهنده‌ها، مصرف‌کنندهای لاگ، خودشان هستند. همانند مثال ناسزاگویی که گفتیم، توسعه‌دهنده‌ها هستند که سیستم را می‌شناسند و می‌دانند که تست کردن، سخت یا حتی غیرممکن است با این وجود حتماً می‌خواهند بدانند که چه اتفاقی می‌افتد. آنها برای خودشان لاگ می‌زنند و تمام اطلاعاتی که دارند را انباشت می‌کنند تا بفهمند که چه رخ می‌دهد. بنابراین محتوای لاگ‌ها می‌تواند هرچیزی باشد که کمک کند که کسی که سیستم را اجرا می‌کند بفهمد چه رخ می‌دهد. یکی از راه‌هایی که من به آن فکر می‌کنم این است که در دنیای ایده‌آل، شما می‌توانید هر چیزی که در محیط عملیاتی در حال اجرا است را با gdb یا پروفایلر یا یک ابزار پوشش (Coverage) زیرنظر بگیرید اما اکثر مردم آن قدر پول ندارند. بنابراین لاگ‌ها روشی برای فهمیدن آن چه رخ می‌دهد بدون داشتن دسترسی کامل به آن است. یک روش آن، از طریق صدای برنامه‌تان است که تلاش می‌کند که به شما کمک کند که بفهمید چه کار دارد می‌کند. من فکر می‌کنم هدف اصلی بیشتر لاگ‌ها همین است که تلاش می‌کنند به شما بفهمانند که چه دارد رخ می‌دهد. این توضیحات می‌تواند به همین سادگی باشد که مثلاً من یک درخواست دریافت کردم و آن را برآورده کردم.
ادامه مطلب ...

ارائه توسط: Alexander Arno
مترجم: مرتضی هاشمی 1394/02/17
در این برنامه مایکل با آرنو درباره‌ی طراحی بر اساس قراداد (Design By Contract) صحبت می‌کند.
آرنو طراحی بر اساس قرارداد چیست و از کجا آمده است؟
طراحی بر اساس قرارداد در واقع الگویی برای طراحی نرم‌افزار است؛ روشی برای فکر کردن به واسط‌ها (interface) و روشی برای جداسازی واسط‌ها از پیاده‌سازی‌ها است. اصطلاح طراحی بر اساس قرارداد در دهه‌ی 80 توسط برتراند میر مطرح شد. او نویسنده‌ی کتاب Object Oriented Software Construction و همچنین مخترع زبان Eiffel است که این مفاهیم را پیاده‌سازی می‌کند.
در نتیجه پیاده‌سازی‌هایی وجود دارد که از طراحی بر اساس قرارداد پشتیبانی می‌کنند، اما مهم، روش فکر کردن به طراحی است. ایده این است که شما [یک تعداد] انواع داده‌ای انتزاعی دارید، هر کدام از این انواع داده‌ای انتزاعی یک واسط دارند، و یک واسط، تنها امضای توابع آن نیست، بلکه شامل مشخصاتی مستقل از پیاده‌سازی است که رفتار آن تابع را تعیین می‌کند. پس به نوعی یک قرار داد ارائه می‌دهد و طبیعی است که در مورد هر چیزی به این شکل فکر کنیم. اگر واسط یک مجموعه (Collection) را در نظر بگیریم که دارای توابع add()، remove() و get() باشد، بدیهی است که انتظار داریم تابع get() در ابتدای کار هیچ چیزی برنگرداند، چون در ابتدا مجموعه خالی است. زمانی که یک عنصر را اضافه کنیم، get() آن را بر می‌گرداند. این چیزی فراتر از امضای توابع است؛ در واقع معنای پنهان شده در امضای توابع است. طراحی بر اساس قراداد روشی برای رسمی‌سازی این مفهوم است. اما حتی اگر زبان برنامه‌نویسی به صراحت از این امکان، پشتیبانی نکند، این طرز فکر مفید است.
یک قراداد دقیقاً چیست؟
قرارداد در واقع تشبیهی از زندگی روزمره است. قرارداد چیزی است که همه‌ی ما با آن آشنایی داریم. منظور این است که [زمانی که] با یک شئ تعامل می‌کنید، شما به عنوان فراخواننده، و شئ به عنوان آن‌چه فراخوانده می‌شود، روی یک قرارداد توافق می‌کنید. این شئ است که [مفاد] قراداد را تعیین می‌کند و شما یا باید آن را بپذیرید یا از آن استفاده نکنید. هر تابع از یک شئ تضمین می‌کند اگر شما به عنوان فراخواننده به بخش‌های مربوط به خود از قرداد پایبند باشید (اگر پیش‌شرط‌های (Pre-condition) مورد نیاز آن شئ را برآورده کنید) کار خود را انجام دهد. مسئله‌ی مهم این است که مانند زندگی روزمرّه، قرارداد چیزی دوطرفه است. فقط این نیست که شئ کاری را انجام دهد و من به عنوان فراخواننده وظایفم را انجام ندهم. این‌طور هم نیست که من به عنوان فراخواننده وظایفم را انجام دهم و شئ به دلخواه خود عمل کند -مثلاً اگر من یک اطاق را اجاره کنم، کلیدش را می‌گیرم و می‌توانم در آن زندگی کنم، اما به شرط اینکه اجاره‌اش را پرداخت کنم- بنابراین کاملاً دو طرفه است، فکر کردن به آن این‌گونه است.
نتیجه‌ی یک پیش‌شرط یا پس‌شرط (Post-condition) پس از ارزیابی چیست؟ آیا فقط یک مقدار بولین است یا چیزی بیشتر از این است؟
همان‌طور که می‌گویید، پیش و پس‌شرط‌ها عبارات بولین هستند. هر تابع لیستی از پیش‌شرط‌ها (لیستی از عبارات که حاصل آن یک مقدار بولین است) را دارد. حاصل این لیست پیش‌شرط‌ها هنگام فراخوانی باید مقداری درست باشد. لیست دیگری هم از پس‌شرط‌ها وجود دارد که آن هم لیستی از عبارات بولین است. شئ تضمین می‌کند اگر من پیش‌شرط‌ها را رعایت کنم، حاصل پس‌شرط‌ها هم پس از فراخوانی یک مقدار درست خواهد بود. فکر می‌کنم یک مثال در این‌جا مفید باشد. فرض کنید که یک تابع برای محاسبه‌ی ریشه‌ی دوم یک عدد اعشاری نوع Double داریم. بدیهی است که یک پیش‌شرط این است که پارامتر ورودی باید بزرگ‌تر یا مساوی صفر باشد. پس‌شرط هم این است که اگر نتیجه‌ی برگردانده‌ شده توسط تابع را در خودش ضرب کنم، همان مقدار ورودی حاصل شود. البته در واقع هیچ‌وقت دقیقاً همان عدد حاصل نخواهد شد. بنابراین اگر پس‌شرط را به صورت رسمی بیان شود باید گفت تفاوت میان نتیجه و عدد مورد نظر باید کم‌تر از یک عدد مشخص باشد. بنابراین شما دقتی برای محاسبات تابع تعیین می‌کنید. و این یکی از ارزش‌های مشخص کردن پیش و پس‌شرط‌ها به صورت رسمی را نشان می‌دهد، چون دقت عملیات را به صراحت در امضای تابع بیان می‌کند که در بسیاری از موارد مفید است.
ادامه مطلب ...

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