ارائه توسط: Monica Beckwith
مترجم: سید مرتضی هاشمی 1395/12/12
در این قسمت که در آوریل ۲۰۱۶ منتشر شده است، رابرت بلومن با مانیکا بِک‌ویث درباره‌ی زباله‌روبی (Garbage Collection) در جاوا صحبت می‌کند. مانیکا یک مشاور مستقل است که در زمینه‌ی بهینه‌سازی ماشین مجازی جاوا و زباله‌روبی در برنامه‌‌های معظم (Enterprise) تخصص دارد. او یک سخنگوی متداول در کنفرانس‌هاست و مقالاتی در موضوعاتی از قبیل زباله‌روبی، مدل حافظه‌ی جاوا و ... منتشر کرده است. مانیکا در زباله‌روب G1 رهبر کارایی (Performance) بود و در سال ۲۰۱۳ عنوان فوق ستاره JavaOne را دریافت کرد.
از جمله موضوعات مطرح شده در این مصاحبه می‌توان به این موارد اشاره کرد: زباله‌روبی و الگوریتم‌های آن، تاریخچه‌ی زباله‌روی در زبان جاوا، قطعه قطعه کردن (Fragmentation) و فشرده‌سازی (Compaction)، راهبردهای نسل‌بندی، علت‌های درنگ (Pause)، تأثیر درنگ بر برنامه‌های کاربردی، تنظیم‌کاری (Tuning) زباله‌روب، زباله‌روب‌ها در پردازنده‌های چندهسته‌ای و ماشین‌های دارای حافظه‌های بزرگ، اینکه آیا سرورهای عملیاتی (Production Servers) باید در زبان‌های بدون زباله‌روب پیاده‌سازی شوند؟ اینکه چطور می‌توان از حافظه‌ی خارج از Heap و سایر فنون برنامه‌نویسی استفاده کرد تا از ایجاد زباله اجتناب شود؟ و آینده‌ی زباله‌روبی در جاوا.
مانیکا به رادیوی مهندسی نرم‌افزار خوش آمدی.
متشکرم.
آیا چیز دیگری هست که بخواهید شنوندگان در مورد شما بدانند.
نه. فکر می‌کنم خیلی خوب خلاصه کردید. بیش از یک دهه است که من به عنوان یک مهندس کارایی در جاوا فعالیت می‌کنم. قبلاً در AMD کار می‌کردم و به نوعی این علت ورود من به حوزه‌ی ماشین مجازی جاوا، زباله‌روبی و کامپایلر زمان اجرا (JIT Compiler) بود. اصل کار من روی HotSpot بود که زباله‌روب OpenJDK است. اما با jRockit و IBM J9 هم کار کرده‌ام. کارم را با استفاده از دستورالعمل‌های صحیح و بهینه‌سازی کد تولید شده شروع کردم. به تدریج به سطح پایین‌تر وارد شدم و تلاش کردم کامپایلر زمان اجرا را بهینه‌سازی کنم. در نهایت به سطح پایین‌تر زباله‌روبی رفتم و در آن‌جا ماندم. بیشتر، زباله‌روبی در سمت سرور؛ مثل زباله‌روب توان‌مند (Throughput Collector) و کار با CMS وبیشتر با علامت‌گذاری و جاروب کردن همروند (Concurrent Mark Sweep) [سر و کار داشته‌ام]. و نهایتاً زباله‌روب G1 که الان مدتی است روی آن کار می‌کنم.
موضوع برنامه‌ ما زباله‌روبی است. دوست دارم با برخی مفاهیم پایه شروع کنم. با این سوال شروع می‌کنم: زباله چیست؟
به زبان ساده زباله آن چیزی است که دیگر به آن نیاز ندارید؛ دیگر مورد ارجاع نیست. مثلاً در جاوا اشیاء در Heap قرار می‌گیرند. اغلب می‌توانید آن را به مانند یک لیست پیوندی در نظر بگیرید. مجموعه‌ای از ریشه‌ها دارید و هر چیزی که از ریشه‌ها ارجاع داشته باشد، زنده است و باید آن را علامت‌گذاری کنید. اما آنچه که مورد ارجاع نیست و هنوز در Heap فضا اشغال کرده است باید جمع‌آوری یا جاروب شود. این شئ که توسط هیچ چیزی در Heap مورد ارجاع نیست و به طور مستقیم یا غیر مستقیم به مجموعه‌ی ریشه‌ها متصل نیست، می‌تواند بازپس گرفته شود و به آن زباله می‌گوییم.
می‌توانید یک الگوریتم زباله‌روبی ساده را توضیح دهید که میان همه‌ی زبان‌هایی که زباله‌روبی دارند مشترک باشد؟
حتماً. اجازه بدهید در این مورد صحبت کنیم که زباله‌روبی به چه معناست؛ فقط جاروب کردن نیست، تخصیص دادن (Allocation) هم هست. برای مثال در جاوا زمانی که برنامه‌ی شما یک شئ را ایجاد می‌کند این زباله‌روب است که به تخصیص حافظه رسیدگی می‌کند. معمولاً یک تخصیص سریع وجود دارد که طوری بهینه سازی شده تا سربار همگام‌سازی نداشته باشیم. سپس به جمع‌آوری می‌رسیم. زمانی که اشیاء قابل دسترسی نیستند باید جاروب/جمع‌آوری شوند؛ Heap مقداری محدود از حافظه است. مثلاً اگر در مورد Heap چندنسلی (Generational) صحبت کنیم، زمانی که نسل جوان یا نسل پیر پر شود و نتوانید حافظه‌ی بیشتر تخصیص دهید یا شئ‌ای را ارتقاء دهید؛ آن‌گاه زباله‌روب وارد کار می‌شود. برای این‌که زباله‌روب [بتواند] شروع به کار کند و گراف/درخت اشیاء را تشکیل دهد، درخت‌های اشیاء باید یک یا چند شئ ریشه داشته باشند. چیزهایی مثل متغیرهای محلی یا نخ‌ها (Thread) و ناحیه‌های جاوا و ... ریشه‌های زباله‌روب هستند. ارجاعات JNI و متغیرهای ایستا هم هستند. از این مجموعه شروع می‌کنید و هر درختی از اشیاء از مجموعه‌ی ریشه‌ها قابل دستیابی باشد، زنده در نظر گرفته می‌شود؛ به این کار علامت‌گذاری می‌گویند؛ اشیاء زنده را علامت‌گذاری می‌کنید. وقتی همه‌ی اشیاء زنده علامت‌گذاری شدند آن‌چه که باقی می‌ماند اشیاء غیرقابل دسترسی هستند و به نظر نمی‌رسد که در گراف اشیاء جایی داشته باشند و بنابراین زباله در نظر گرفته می‌شوند. الگوریتم‌های متفاوتی برای رسیدگی به زباله‌ها وجود دارد که با عنوان جاروب‌گر شناخته می‌شود. جاروب کردن هم بهینه شده است و لازم نیست تمام Heap را پیمایش کنید تا زباله‌ها را جمع‌آوری کنید. مثلاً CMS لیستی [از اشیای] آزاد دارد و زمانی که کار جاروب را انجام می‌دهد زباله‌ها در این لیست آزاد نگه‌داری می‌شوند تا لازم نباشد تمام Heap را جستجو کند. الگوریتم‌های متفاوتی برای علامت‌گذاری و پاک‌سازی وجود دارد. یکی از الگوریتم‌های متداول «علامت‌گذاری-جاروب، علامت‌گذاری-فشرده‌سازی» است که شامل دو نسل است: «نسل جوان» که به صورت یک زباله‌روب در حال کپی و فشرده‌سازی (Copying Compacting Collector) است و «نسل پیر» که در برابر خرابی ایمن است. الگوریتم CMS هم هست که فشرده‌سازی ندارد و G1 که فشرده‌سازی افزایشی دارد.
ادامه مطلب ...

ارائه توسط: Michael Nygard
مترجم: محمد علی بزرگ زاده 1395/11/15
در این اپیزود که در ماه مِی ۲۰۰۹ منتشر شده است درباره یک کتاب بسیار محبوب در حوزه مهندسی نرم‌افزار با عنوان Release It صحبت می‌شود. مهمان این برنامه، نویسنده این کتاب مایکل ناگارد است.
سلام مایکل.
سلام. خیلی خوشحالم که اینجا هستم.
ما خوشحالیم که توانستیم با شما جلسه داشته باشیم. خوب، اولین سئوال روشنی که وجود دارد این است که لطفاً در مورد خودتان صحبت کنید تا مخاطبان‌مان شما را بشناسند.
حتماً. من تا الان نزدیک به ۲۰ سال است که یک معمار و توسعه‌دهنده برنامه‌های نرم‌افزاری هستم. من در حوزه‌های خیلی زیادی شامل نظامی، علمی، مهندسی، صنعتی، آموزشی و مالی فعال بوده‌ام و در ۱۰ سال گذشته کارهای زیادی در حوزه خرده‌فروشی داشته‌ام. ۵ سال قبل، طی یک شرایط عجیبی که پیش آمد در نهایت به گروهی پیوستم که کار عملیات را برای نرم‌افزاری می‌کردند که ما ننوشته بودیم. بنابراین من که همیشه نرم‌‌افزار خودم را عملیاتی می‌کردم حال باید مسئولیت نرم‌افزاری که دیگر افراد توسعه داده بودند را هم می‌پذیرفتم.
بنابراین دردش را چشیدید!
دقیقاً.
:) این خودش کمی مقدمه‌ای شد که در واقع چه شد که کتاب را نوشتید. لطفاً یک نمای کلی مثلاً از ارتفاع ۳۰۰۰ کیلومتری، از کتاب به ما بدهید. خیلی‌ها احتمالاً آن را می‌شناسند. در‌واقع به طور خاص از ما درخواست شده بود که شما را دعوت کنیم، حداقل آن افراد کتاب را می‌شناسند. لطفاً از منظر خیلی کلی‌اش بگویید که کتاب شامل چه چیزهایی است و چه شد که آن را نوشتید.
آنچه که از تحویل گرفتن نرم‌افزارها تا عملیاتی کردن آن‌ها -و اینکه فردی باشم که وقتی‌که نرم‌افزارها کار نمی‌کردند ساعت ۳ صبح صدا زده می‌شدم- آموختم این است که نوع نرم‌افزار‌هایی که ما می‌سازیم برای زندگی در دنیای واقعی آنقدرها مناسب نیستند. آنچه در نهایت اهمیت دارد، دنیای واقعی عملیاتی است. و من به این نتیجه رسیدم که همه کارهایی که در زمان معماری و طراحی می‌کنیم همگی به هدف پذیرفته شدن در QA است. همگی به این هدف است که نیازمندی‌های عمل‌کردی (Functional) را برآورده کنند اما به هدف زنده ماندن در محیط عملیاتی نیستند. برای من مانند این است که دنیا آمدن بچه را هدف بگیریم اما هیچ آمادگی برای زندگی آن بچه بعد از تولدش به عنوان یک انسان، نداشته باشیم.
بله. بنابراین کتاب در این مورد است که چطور نرم‌افزار را به روشی بنویسیم که افراد عملیات از آن خوشحال شوند. این اولین فرض است که کمی بیش از حد کم‌دامنه است.
این قطعاً یک طریقه خواندن این کتاب است. اما البته تنها بحث افراد عملیات نیست. حامیان مالی و افرادی که برای نرم‌افزار ما پول می‌دهند واقعاً به این موضوع خیلی بیشتر علاقه‌مندند که نرم‌افزار در محیط عملیاتی چگونه کار می‌کند تا اینکه چطور از QA پذیرفته شده است. می‌توانید QA و اولین تست رگرسیون را قهرمانانه موفق شوید اما اگر در محیط عملیاتی اجرا نشود در نهایت، کسی اهمیت نمی‌دهد.
بسیار خوب. حال اگر بخواهیم از ارتفاع ۳۰۰۰ کیلومتری مثلاً تا ۲۰۰۰ کیلومتر پایین بیاییم، اگر ساختار کتاب و از این رو ساختار این موضوع در فضای کلی مسأله را در نظر بگیریم [چگونه بیانش می‌کنید] مثلاً در چند بخش که بخواهید در ادامه بحث توضیح‌شان دهید به آن ساختار بدهید.
من [مطالب] کتاب را بر اساس درجه اهمیت، ترتیب دادم و سعی کردم اول به بدترین مشکلات بپردازم. به همین خاطر اولین بخش کتاب در مورد پایداری (Stability) است چون اگر نرم‌افزارتان در محیط عملیاتی، پایدار نباشد اهمیتی ندارد که چه کاری می‌کند یا در آینده قرار است چه تغییری کند. بنابراین بخش اول کتاب در مورد پایداری است. و در هر بخش از کتاب، من یک مطالعه موردی را آورده‌ام. به من گفته شده که آن‌ها مانند داستان‌های کارآگاهی خوانده می‌شوند که به نوعی همان چیزی است که مدنظر من بوده است که باید یک بیان اول شخص از یک مثال دنیای واقعی ازچیزهایی باشد که در شرکت‌های واقعی رخ می‌دهد هرچند به دلایلی که واضح است همه نام‌ها، بدلی هستند.
برای اینکه نمایی از ادامه این اپیزود فراهم کنیم، بعد از پایداری چه چیزی را داریم؟
بعد از پایداری، یک فصل در مورد ظرفیت (Capacity) داریم چون بعد از آنکه سیستم‌تان را پایدار کردید، بزرگترین شکایت بعدی که دیده‌ام این بوده است که «به مقدار کافی کارا نیست چون نمی‌تواند کاربران همزمان را رسیدگی کند». اینجا هم یک مطالعه موردی آورده‌ام و تعدادی ضدالگو (Anti-Pattern) دارم. مورد متداولی که دیده‌ام افراد انجام می‌دهند این است که ظرفیت‌شان را آسیب می‌رسانند. من الگوهایی را [معرفی کرده‌ام] که می‌توانید حتی روی همان زیرساختی که به شما داده شده است، برای بهبود ظرفیت بکار ببرید. بنابراین من بطور خاص مقیاس‌پذیری (Scalability) را اشاره نمی‌کنم که به معنای قابلیت اضافه کردن منابع بیشتر است بلکه به بیشینه کردن ارزش منابعی که دارید اشاره می‌کنم.
ادامه مطلب ...

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