ارائه توسط: Martin Fowler and Pramod Sadalage
مترجم: محمد علی بزرگ زاده 1395/10/17
میهمانان این برنامه پرامود سدالگه و مارتین فاولر هستند. در این اپیزود، در مورد تکامل پایگاه داده (Database Evolution) و توسعه چابک پایگاه داده صحبت می‌شود. همچنین در مورد چالش‌های اصلی در کار با پایگاه‌های داده در یک فرهنگ توسعه چابک صحبت می‌شود و اینکه طراحی پایگاه داده و مهم‌تر از همه، تکامل آن را چطور می‌توان در چرخه‌های اغلب کوتاهی جای داد که در روش‌های پیشرفته توسعه نرم‌افزار وجود دارد. همینطور در مورد یکپارچه‌سازی مستمر تغییرات کد مرتبط با پایگاه داده با استفاده از اسکریپت‌های تغییر شِمای پایگاه داده، استفاده از چندین شِما برای غلبه بر استقرار متمرکز تیم‌های توسعه، چگونگی مهاجرت دادن داده‌ها در گام‌های افزایشی و ابزارهایی که می‌توانند در این محیط‌های چابک استفاده شوند صحبت می‌شود.
لطفاً خودتان را معرفی کنید.
مارتین: من مارتین فاولر هستم. یک نویسنده و سخنران پُرسر و صدا در مهندسی نرم‌افزار هستم.
پرامود: من پرامود سدالگه هستم. همانطور که مارتین گفت من خیلی به مهندسی نرم‌افزار علاقه‌مندم. من خاصه مبحث داده‌ها در هر نوع برنامه‌ای را دوست دارم و شِمای پایگاه داده (Schema) مانند NoSQL و چیزهای از این قبیل را علاقه‌مندم. فکر می‌کنم امروزه، امر داده‌ها نقش مهمی در چرخه توسعه نرم‌افزار دارد.
بسیار خوب. اجازه دهید در مورد بحث امروزمان یعنی تکامل پایگاه داده صحبت کنیم. شما از تکامل پایگاه داده دقیقاً منظورتان چیست؟
پرامود: همچنانکه نرم‌افزار تکامل می‌یابد [داده‌ها هم تکامل می‌یابند] و البته نرم‌افزار به این جهت تکامل می‌یابد که کسب و کار تکامل پیدا می‌کند. کسب و کار در‌واقع تلاش می‌کند که به اجبارهای بازار واکنش دهد یا تلاش می‌کند که راه جدیدی برای کارش بیابد. این شاید مربوط به فرآیند باشد، شاید مربوط به محصولات جدیدتر باشد و یا شاید مربوط به راه‌های جدید‌تری برای انجام کارها باشد. اما همانطور که روش‌های جدیدتری برای انجام کارها مطرح می‌شود، نرم‌افزار باید تکامل یابد. این بدان معناست که پایگاه داده‌ای که نرم‌افزار از آن استفاده می‌کند هم باید تکامل یابد. مثلاً می‌تواند مانند این باشد که قبلاً کتاب می‌فروخته‌ام و الان می‌خواهم ریش‌تراش یا چیز دیگری بفروشم. بهرحال نرم‌افزار تغییر می‌کند و وقتی نرم‌افزار تغییر می‌کند آنچه در پایگاه داده ذخیره می‌کند و آنچه از پایگاه داده بازیابی می‌کند و هرچیز دیگری که از پایگاه داده بخواهید هم تغییر می‌کند. یعنی ساختار پایگاه داده و طراحی پایگاه داده باید تغییر کند. این می‌تواند بر چند چیز دلالت داشته باشد. مثلاً قبل از این ۵۰ کاربر را پشتیبانی می‌کرده‌ام و الان نیاز دارم که ۵ میلیون کاربر را پشتیبانی کنم. این می‌تواند امور مربوط به پایگاه داده را تغییر دهد یا می‌تواند علاوه بر آن فرآیندهای کسب و کار متفاوتی را هم منجر شود. بنابراین همه این‌ها ایده تکامل پایگاه داده را در برمی‌گیرد. همانطور که گفتم از آنجاییکه نیازمندی‌ها تغییر می‌کند، بنابراین تکامل پایگاه داده هم رخ می‌دهد.
نکته خوب این است که ما در مورد تکامل خود سیستم‌های پایگاه‌های داده صحبت نمی‌کنیم مثلاً اینکه MySQL چطور در طی زمان تکامل یافته است. ما در مورد تکامل نرم‌افزاری که از یک پایگاه داده استفاده می‌کند صحبت می‌کنیم و اینکه پایگاه داده و یا شِمای (Schema) آن تغییر می‌کند. بیشتر شِمای آن و یا داده‌های آن در طی زمان تغییر می‌کند.
مارتین: بله. و من آن را خیلی مرتبط با تغییر نحوه‌ی تفکرمان به توسعه نرم‌افزار می‌بینم. از این جهت که ما این دیدگاه را داشتیم که تنها راه معقولانه ساختن نرم‌افزار این است که قبل ازکار ساختمان آن، طراحی‌اش را درآوریم و بعد، آن ساختمان را به طراحی نگاشت دهیم. اما آنچه افرادی مانند من و کلاً جنبش چابک (Agile Movement) از آن حمایت می‌کند این است که باید فرآیند مستمرتری داشته باشیم و نیاز داریم که بتوانیم تغییرات را هم رسیدگی کنیم. وقتی ما رویه چابک را در روزهای اولیه آن آغاز کردیم که به حدود سال ۲۰۰۰ برمی‌گردد یکی از مباحثه‌ها این بود که: آیا واقعاً می‌توانیم آن را بر روی یک سیستم پایگاه داده‌ی رابطه‌ای اجرا کنیم؟ در این زمینه، پرامود نقش بارزی داشته است، نه تنها از این نظر که نشان دهد که این کار را می‌شود کرد بلکه در‌واقع آن را در یک پروژه بزرگ‌مقیاس، انجام داده است. و این یک گام خیلی قابل توجهی است چون خیلی از پروژه‌ها مبتنی بر رسیدگی به حجم زیادی از داده‌های ذخیره‌شده در پایگاه‌های رابطه‌ای هستند. بنابراین مجبورید که بفهمید چطور آن پایگاه داده را تکامل دهید. و این از تکامل کد، پیچیده‌تر است چون نه تنها باید تغییرات ساختاری در پایگاه داده بدهید بلکه باید در این مورد هم تصمیم بگیرید که با داده‌ها چه کنید. چون نمی‌توانید مانند کاری که در مورد طراحی کدها می‌کنید، داده‌ها را دور بریزید و آن‌ها را دوباره بسازید. در‌واقع باید به این هم فکر کنید که چطور داده‌ها را مهاجرت دهید.
فکر می‌کنید در رسیدگی به داده‌ها به یک روش چابک و تکاملی، مهمترین مطلب چیست؟
پرامود: چیزهای زیادی هست مثلاً چیزهای کوچکی از قبیل یکپارچه‌سازی مستمر (Continuous Integration) وجود دارد که چطور جنبه پایگاه داده‌اش را فراهم می‌کنید. مورد دیگر، انشعاب دادن (Branching) است؛ اینکه در انشعاب چه رخ می‌دهد و چطور کدها را مهاجرت می‌دهید، نه فقط کدهای برنامه بلکه کدهای پایگاه داده را چطور مهاجرت می‌دهید. اینکه کدام نسخه درست است و بهرحال نسخه‌بندی یک مشکل بزرگ است. جنبه دیگر این است که آیا می‌توانید به افراد، یک Sandbox بدهید؟ آیا می‌توانید خودکارسازی کنید؟ چون در توسعه نرم‌افزار افراد نمونه‌های دیگری از برنامه را بر روی ماشین خودشان بالا می‌آورند. آیا می‌توانید این کار را با پایگاه داده بکنید؟ چطور می‌توانید این کار را خیلی ساده بکنید؟ خصوصاً برای توسعه‌دهنده‌ها، آیا می‌توانید تنظیماتی داشته باشید که افراد بتوانند نمونه‌های خود را سریع اجرا کنند. مخصوصاً در یک سناریوی تست واحد (Unit Test) آیا می‌توانید بدون هزینه خیلی زیاد، برای خودتان آغاز کنید و تست واحدتان را انجام داده و همه چیزهای [تولیدشده در جریان تست] را دور بریزید و دوباره از نو آغاز کنید؟ و چطور همه این‌ها را داخل یک چرخه یکپارچه‌سازی مستمر قرار می‌دهید؟
این‌ها اغلب مربوط به جنبه توسعه‌ آن می‌شود اما اگر در زنجیره پیش‌تر بروید [مشکلات دیگری هم مطرح می‌شود مثلاً می‌دانیم] نیازمندی‌ها و ویژگی‌های جدید به شکل مدام، مستقر می‌شود. حال چطور محیط QA را در حالت خوبی نگه داریم که تنها ویژگی‌های جدید و تغییرات جدید در پایگاه داده به آن‌ها داده شود اما با [اعمال] آن‌ها، تست‌های موجود بهم نریزد؟ بهمین ترتیب، چطور می‌خواهید آن را به محیط عملیاتی ببرید؟ وقتی رشته مدامی از تغییرات دارید، چطور بدون اینکه دسترس‌پذیری سیستم را تحت تأثیر قرار دهید، آن را مستقر می‌کنید؟ چطور این کار را می‌کنید بدون اینکه داده‌های واقعی موجود در پایگاه داده را تحت تأثیر قرار دهید از این جهت که با کارهای اشتباه آن را خراب نکنید؟ وقتی رشته مدامی از تغییرات دارید همه این چیزها مطرح می‌شود.
ادامه مطلب ...

ارائه توسط: Steve McConnel
مترجم: سید مرتضی هاشمی 1395/10/02
در این برنامه که در نوامبر ۲۰۱۶ منتشر شده است، سوِن یوهان با استیو مک‌کانل درباره‌ی برآورد نرم‌افزار (Software Estimation) صحبت می‌کند. از جمله مباحثی که مطرح می‌شود می‌توانیم به این موارد اشاره کنیم: چرا و چه وقت کسب‌وکارها به برآورد نیاز دارند یا چه وقت ندارند؟ تبدیل برآورد‌ها به طرح‌ریزی و سنجش پیشرفت بر اساس این طرح‌ریزی به چه نحوی است؟ چرا برآورد‌های نرم‌افزار همواره مملو از عدم قطعیت است؟ این عدم قطعیت‌ها چه هستند و چه‌طور با آن‌ها روبرو شویم؟
من سوِن یوهان هستم و امروز استیو مک‌کانل مهمان من است. استیو مدیر ارشد اجرایی و مهندس ارشد نرم‌افزار در شرکت نرم‌افزاری Construx است؛ او مؤلف Code Complete ، Rapid Development و بسیاری کتاب‌های دیگر است. او در سال ۲۰۰۶ کتابی در مورد برآورد نرم‌افزار منتشر کرد. همچنین به عنوان سردبیر مجله مهندسی نرم‌افزار IEEE فعالیت کرده است. من امروز با استیو درباره‌ی برآورد هزینه‌ی نرم‌افزار صحبت می‌کنم. استیو به برنامه خوش آمدی!
متشکرم که مرا دعوت کردید.
آیا چیز مهمی را در معرفی شما فراموش کردم؟
نه فکر می‌کنم، تقریباً به طور کامل توضیح دادید.
خوب. یک برآورد چیست؟
فکر می‌کنم وقتی سوال می‌کنیم که برآورد چیست، باید میان نحوه‌ی استفاده‌ی عمومی افراد -که در بسیاری از موارد ناسالم و غیرسازنده است- و آنچه‌که یک برآورد واقعاً هست، تمایز قائل شویم؛ هم از لحاظ تعریف کتابی و هم از لحاظ نحوه‌ی درست صحبت کردن در مورد برآورد. فکر کنم اگر به تعریف برآورد در واژه‌نامه نگاه کنید، برآورد یک پیش‌بینی آماری از مدت زمان انجام یک کار، یا هزینه‌ی آن، و یا این‌ که چه تعداد ویژگی را می‌توان در یک زمان مشخص تحویل داد است. بنابراین مفهوم مورد نظر در اینجا پیش‌بینی است. تعریف واژه‌نامه‌ای معمولاً مفهومی از تقریبی، تجربی و مقدماتی بودن یا چیزی شبیه به آن را نیز مطرح می‌کند. بنابراین در واقع ما درباره‌ی یک تصویر مقدماتی یا پیش‌گویی تجربی یا همچنین چیزی صحبت می‌کنیم. فکر می‌کنم این درست باشد. این بهترین و سازنده‌ترین روش فکر کردن به آن در نرم‌افزار است.
در عمل آن‌چه فهمیدیم این است که افراد در هر دو سوی تصمیمات فنی و کسب‌وکار، قطعاً گرایش دارند که از کلمه‌ی برآورد به معنی پیش‌گویی آماری استفاده کنند؛ اما از آن به معنی تعهد هم استفاده می‌کنند. یعنی افراد کسب‌وکار می‌پرسند به برآورد شما این کار چقدر طول می‌کشد؟ افراد فنی هم می‌گویند فکر می‌کنیم تا فلان تاریخ طول بکشد. در این لحظه تاریخ مورد نظر تبدیل به تعهدی به کسب‌وکار می‌شود؛ این کمی فراتر از برآورد می‌رود. فکر می‌کنم استفاده از این کلمه علاوه بر اشاره برآورد و تعهد، برای اشاره به اهداف هم استفاده می‌شود. مثلاً طرف کسب‌وکار ممکن است بگوید ما واقعاً دوست داریم که این کار تا فلان تاریخ تمام شود و در حین گفتگو ما به نحوی کلمات برآورد و تعهد را تلفیق می‌کنیم. این منجر به انواع مشکلات می‌شود که می‌توانیم در صورت نیاز در مورد آن‌ها صحبت کنیم؛ اما فکر می‌کنم برای کوتاه کردن سخن اگر بتوانیم در گفتگوهایمان و یا حداقل در ذهن‌مان میان برآورد‌ها، تعهدات و اهداف تمایز قائل شویم -حداقل در جنبه‌ی فنی معادله- خودمان را برای داشتن گفتگوهای بسیار سازنده‌تری درباره‌ی برآورد آماده کرده‌ایم. ما ارزش بسیاری در صِرفِ روشن کردن این مفهوم دیده‌ایم. چون روشن کردن مفهوم، منجر به روشن شدن فعالیت هم می‌شود. بنابراین می‌دانیم کِی برآورد می‌کنیم، کِی درباره‌ی یک هدف صحبت می‌کنیم، و کِی تعهد می‌دهیم. روشن کردن این کلمات در حقیقت به ما کمک می‌کند تا از دادن تعهد درحالی که فکر می‌کنیم صرفاً برآورد می‌کنیم، دوری کنیم.
تعهد، هدف و برآورد. رئیس من از من یک برآورد خواست اما در واقع می‌خواست به هدفی برسد و از ما تعهدی برای رسیدن به هدف بگیرد. آیا این بازگویی از زبان من درست است؟ :-)
فکر می‌کنم درست باشد. فکر می‌کنم روش سازنده‌ای برای فکر کردن به آن است. یعنی [تشریح] کامل آن این است که کسب‌وکار چیزی در ذهن دارد که فکر می‌کند به درد کسب‌وکار می‌خورد. این هدف است. معمولاً کسب‌وکار می‌پرسد چه برآوردی از این کار دارید؟ فکر می‌کنید چه تعداد ویژگی می‌توانید تا فلان تاریخ تحویل دهید؟ بنابراین آن‌چه که کسب‌وکار طبیعتاً فکر می‌کند این است که آن‌چه که امیدوار بودیم به آن دست پیدا کنیم، صد درصدِ آن‌چیزی است که در ذهنمان بود. عموماً این‌طور است که افراد خوش‌بین هستند. افراد فنی می‌روند و کار واقعیِ برآورد کردن را انجام می‌دهند که من در واقع به آن برآورد می‌گویم. و عموماً برمی‌گردند و همان‌طور که از نام خوش‌بینی پیداست متوجه می‌شوند در واقع هدف کسب‌وکار [در زمان] مورد نظر قابل دست‌یابی نیست؛ [هدف] خیلی خوش‌بینانه بود. توانایی حقیقی سازمان برای تحویل آن کافی نیست. اتفاقی که در اینجا رخ می‌دهد این است که ما از برآورد استفاده می‌کنیم تا بفهمیم توانایی ما در رسیدن به یک هدف و این‌که به آن متعهد شویم مقعول است یا خیر. برآورد در واقع به ما کمک می‌کند تعیین کنیم که این تعهدی است که «احتمالاً» به آن دست می‌یابیم یا این تعهدی است که «احتمالاً» نمی‌توانیم زیر بار آن برویم. اما مفهومی از بی‌ثباتی و احتمال در هر برآورد واقع‌بینانه وجود دارد. بنابراین در هر برآورد واقع‌بینانه درجه‌ای از انعطاف‌پذیری وجود دارد. وقتی می‌گوییم برآورد، حاکی از احتمال برآورده شدن تعهد است، برآورد آن را تضمین نمی‌کند. در عوض می‌گوید که فرصت خیلی خوبی برای برآوردن تعهد داریم یا این‌که امکان تلاش کردن برای آن را داریم یا این‌که هیچ شانسی برای عمل به تعهد نداریم و در نتیجه احتمالاً از همان ابتدا نباید زیر بار آن برویم.
ادامه مطلب ...

ارائه توسط: John Wilkes
مترجم: محمد علی بزرگ زاده 1395/09/19
در این اپیزود، که در ژانویه ۲۰۱۶ منتشر شده است، چارلز اندرسون با جان ویلکس در ارتباط با سیستم Borg گوگل صحبت می‌کند. جان از سال ۲۰۰۸ در گوگل بوده است و بر روی مدیریت خوشه‌ها و سرویس‌های زیرساختی کار می‌کرده است. قبل از آن، مدت زیادی را در آزمایشگاه‌های HP بوده است و در سال ۲۰۰۲ از برگزیده‌های ACM شده است. او به جنبه‌های زیادی از سیستم‌های توزیع‌شده علاقه‌مند است اما کار فعلی او در ارتباط با تکنولوژی‌هایی است که به سیستم‌ها اجازه می‌دهد خود را مدیریت کنند.
جان، آیا چیزی هست که بخواهی به معرفی‌ات اضافه کنی؟
نه، خوب بود. من به زودی سالگرد هفتمین سالم در گوگل را دارم.
بسیار عالی. از منظر خیلی سطح بالا، Borg چیست و در گوگل چه کاری انجام می‌دهد؟
Borg سیستمی است که ما برای مدیریت خوشه‌های ماشین‌هایمان (Cluster) استفاده می‌کردیم. هدف اصلی آن، این بود که به کاربران داخلی خودمان خدمت بدهد. کسانی که چیزهایی از قبیل Gmail و Google Docs را می‌نویسند تا دسترسی به منابعی را فراهم کند که برای انجام کارشان به آن نیاز داشتند یعنی چیزهایی که نیاز داشتند تا امور ما در دنیای خارجی را پشتیبانی کنند. بنابراین Borg، اساساً یک سیستم زمانبندی (Scheduling) است که کارها را به آن می‌دهید و او تصمیم می‌گیرد که کدام ماشین بر روی آن کار کند، و وقتی یکی از آن ماشین‌ها فرضاً برای بروزرسانی سیستم‌عامل خارج می‌شود و یا وقتی مشخص می‌شود کاری که در ابتدا فکر می‌کردیم مناسب بوده، در واقع مناسب آن ماشین نبوده، عمل انتخاب [ماشین جدید] را انجام می‌دهد.
بسیار خوب، کمی بعد در مورد زمانبندی صحبت خواهیم کرد. بدون استفاده از تصویر و تخته سفید، آیا ممکن است در مورد بازیگران فضای کلی Borg برایمان بگویید.
قطعاً. بگذار از جنبه فیزیکی‌اش آغاز کنیم. اینطور تصور کنیم که ناوگانی از ماشین‌های گسترده شده در کل زمین را داریم و این ماشین‌ها بر روی مراکز داده‌ای قرار دارند و هر مرکز داده عموماً شامل یک یا چند ساختمان است و هر ساختمان متشکل از یک یا چند خوشه (Cluster) است. و هر خوشه مجموعه‌ای از ماشین‌ها با یک شبکه پرسرعت بین آن‌ها است. بزرگی یک خوشه با سایز متوسط را در حد ده‌ هزار ماشین در نظر بگیرید. و همانطور که شما از روش استاندارد نحوه ساخت مراکز داده بزرگ انتظار دارید، ماشین‌ها داخل قفسه‌هایی (Rack) قرار می‌گیرند.
از جنبه نرم‌افزاری، کاری که می‌کنیم این است که هر خوشه را به یک یا چند سلول تقسیم می‌کنیم. سلول گروهی از ماشین‌ها است که به عنوان یک واحد تحت یک نمونه [سرور] Borg مدیریت می‌شود. بنابراین عموماً هر خوشه، از یک سلول بزرگ تشکیل شده است و گاهی برخی سلول‌های اضافی هم برای مقاصد تست وجود دارد و گاهی پیش می‌آيد که یک خوشه را تقسیم کنید اما عموماً بخش عمده خوشه، یک سلول بزرگ است. سلول بوسیله Borg مدیریت می‌شود که خود از چندین مؤلفه مختلف تشکیل شده است. یکی از آن‌ها Borgmaster است که مؤلفه مرکزی است که مراقب وضعیت کل سلول است. و البته بر روی هر ماشینی بر روی این سلول، ما عاملی (Agent) را اجرا می‌کنیم که Borglet می‌نامیم که مسئول وظیفه‌ها (Task)، محفظه‌ها (Container) و پردازش‌های مختلفی است که بصورت محلی [بر روی آن سیستم] اجرا می‌شوند. من از اصطلاح «وظیفه» استفاده کردم. در اینجا منظور از وظیفه، یک محفظه لینوکسی است که یک برنامه کاربردی را اجرا می‌کند و ما آن‌ها را تحت چیزی که به آن کار (Job) می‌گوییم، گروه‌بندی می‌کنیم. کار، دسته‌ای از وظیفه‌های اساساً یکسان است. در‌ واقع وقتی می‌خواهید کاری را با Borg راه بیاندازید، مثلاً می‌گویید که: «فلان کار است که شامل ۴۰۰ کپی از فلان وظیفه است؛ لطفاً آن را زمانبندی کرده، راه‌اندازی کنید و آن‌ها را بالا نگه دارید.»
ادامه مطلب ...