ارائه توسط: Dwigth Merriman
مترجم: محمد علی بزرگ زاده 1395/03/14
در این اپیزود که در آوریل ۲۰۱۲ منتشر شده است روبرت بلومن در حاشیه کنفرانسMongoSF با دوآیت مریمن در مورد مبحث رونوشت‌برداری (Replication) صحبت می‌کند. دوآیت مریمن مدیرعامل و از بنیانگذاران 10gen است که هم‌اکنون به شرکت سهامی MongoDB تغییر نام یافته است. این شرکت، مسئولیت پایگاه داده متن‌باز MongoDB را به عهده دارد.
دوآیت، دوباره به SE Radio خوش آمدی.
ممنون.
گفتم دوباره چون دوآیت قبلاً در اپیزود ۱۶۵ که در مورد NoSQL و MongoDB صحبت می‌کردیم مهمان ما بود. امروز با دوآیت در مورد رونوشت‌برداری پایگاه داده صحبت خواهیم کرد. دوآیت، برای شروع به ما بگو که رونوشت‌برداری پایگاه داده چیست؟
مفهوم خیلی ساده‌ای دارد. همانطور که در یک فرهنگ لغت در مورد رونوشت (Replica) آمده است، شما می‌خواهید یک نسخه از داده‌ها بر روی یک ماشین مجزا داشته باشید البته ما به این شکل از نسخه‌برداری عادت داریم که روی یک ماشین و بر روی چندین هارددرایو (یا همان RAID) باشد.
بنابراین رونوشت‌برداری در سطح پایگاه‌های داده‌ به معنای [نسخه‌برداری] روی چندین ماشین است. اینکه مجموعه‌ای از داده‌ها و بیش از یک ماشین داشته باشم و بخواهم که بصورت خودکار داده‌ها با هم همگام (Synched) بمانند.
بسیار خوب، رونوشت‌برداری چه مسأله و یا مسائلی را حل می‌کند؟
به نظر می‌رسد چند مسأله باشد. یکی ایمنی داده‌ها (Data Safety) است. اگر داده‌ها را بر روی چند ماشین داشته باشم نسبت به حالتی که یک ماشین باشد، امن‌تر است. اگر بر روی یک ماشین باشد و آب‌پاش‌های روی آنها شروع به فعالیت کنند حتی اگر بر روی آن ماشین درایوهای همانند (Mirror Drives) داشته باشید، برنامه، داده‌ها را از دست می‌دهد. بنابراین ایمنی داده‌ها بهبود می‌یابد. به علاوه، می‌توانید از آن برای ترمیم یافتن از سانحه (Disaster Recovery) استفاده کنید. از نظر ایمنی داده‌ها حتی بهتر است که یکی از رونوشت‌ها در محل جغرافیایی یا مرکز داده متفاوتی قرار گرفته باشد تا اگر سروری در آتش سوخت همچنان از داده‌ها ک‍پی داشته باشیم.
[رونوشت‌‌برداری] همچنین برای دسترس‌پذیری بالا (High Avalibility) هم خوب است که کمی متفاوت [با ایمنی] است. درصورتیکه ماشین خاموش شود و بعداً دوباره روشن شود و داده‌ها همچنان باقی باشد داده‌های من امن است با این حال در دسترس نیست. اما با داشتن چندین سرور، می‌توانیم دسترس‌پذیری داده‌ها را افزایش دهیم که اهمیت دارد.
در نهایت، فکر می‌کنم افراد از آن [رونوشت‌برداری] برای بزرگ کردن مقیاس هم استفاده می‌کنند. رونوشت‌برداری راه‌حل کاملی برای مقیاس‌پذیری نیست. به نظر من بیشتر راه‌حلی برای ایمنی و دسترس‌پذیری بالا است. اما می‌توانید با آن تا حدی، مقیاس‌پذیری برای عملیات‌‌های مربوط به خواندن را بدست آورید. در‌واقع من فکر می‌کنم تکنیک‌های دیگر از قبیل پارتیشن کردن یا چندپاره کردن (Sharding) داده‌ها راه‌حل‌های عمومی‌‌شده‌تری نسبت به رونوشت‌برداری برای مقیاس‌پذیری هستند.
آیا از رونوشت‌برداری برای این هم استفاده می‌شود که بخواهید داده‌های قرارگرفته بر روی رونوشت‌ها را به دلایلی به شکل دیگری تبدیل کنید؟
به نوعی بله. البته می‌توانید مستقیماً داده‌ها را از مبدأ خوانده، تبدیل را انجام دهید و در جای دیگری بنویسید اما فکر می‌کنم گاهی افراد رونوشتی دارند که نسبت به نسخه اصلی، کار متفاوتی بر روی آن دارند. ممکن است وظیفه‌های دسته‌ای (Batch Job) بزرگی بر روی نسخ فرعی داشته باشید بنابراین چنین الگویی مطرح می‌شود.
یعنی مشخصه‌های تأخیری متفاوتی در ارتباط با جریان کاری یکسانی دارید؟
بله، یکی از کارهایی که افراد انجام می‌دهند این است که رونوشت‌هایی در محل‌های مختلف جغرافیایی تهیه می‌کنند تا یک کپی از داده‌ها را در نزدیکی مشتری داشته باشند. این یک دلیل دیگر برای داشتن رونوشت است.
شما گفتید که رونوشت‌برداری، راه‌حل کاملی برای مقیاس‌پذیری نیست. ممکن است بیشتر توضیح دهید که منظورتان چیست؟
قطعاً. اول از همه موضوع «نوشتن‌ها» است. رونوشت‌برداری کمکی به مقیاس‌پذیری نوشتن‌ها نمی‌کند. فرض کنید که می‌خواهید سند یا رکورد جدیدی را در پایگاه داده‌ای که مثلاً n رونوشت دارد بنویسید. شما آن نوشتن را بر روی همه رونوشت‌ها انجام می‌دهید. بنابراین در واقع مقیاس‌پذیری بدست نمی‌آوریم چون داریم n بار می‌نویسیم. بنابراین بیشتر برای مقیاس‌پذیری خواندن‌ها مفید است به این ترتیب که اگر n ماشین داشته باشیم که همگی یک رونوشت از داده‌ها را داشته باشند و هرکدام ظرفیت مشخصی داشته باشند باید بتوانیم از لحاظ تعداد خواندن‌های در ثانیه، n برابر ظرفیت بدست آوریم اما میزان افزایش مقیاسی که به این روش می‌توانید داشته باشید محدود است. یکی از این محدودیت‌ها این است که باید نوشتن‌ را در همه این جاها انجام دهید. اگر ۱۰۰ رونوشت داشته باشید به نسبت ناکارآمد می‌شود که بخواهید همه نوشتن‌ها را ۱۰۰ بار انجام دهید. اگر نوشتن‌ها خیلی خیلی نادر باشد ممکن است اشکالی نداشته باشد اما اگر بازاء هر ۳ خواندن یک نوشتن داشته باشید، خیلی منطقی نیست که فقط برای اینکه خواندن‌ها مقیاس‌پذیر شود، نوشتن‌ها را ۱۰۰ مرتبه انجام دهید.
ادامه مطلب ...

ارائه توسط: Simon Brown
مترجم: محمد علی بزرگ زاده 1395/03/02
در این اپیزود که در ژوئن ۲۰۱۵ منتشر شده است، سوئن جوهان با سیمون براون مصاحبه می‌کند. سیمون براون یک مشاور و مدرس مستقل و خالق مدل معماری نرم‌افزار C4 است. او همچنین کتاب Software Architecture for Developers را نوشته است.
چطوری سیمون؟
خوبم. ممنون. و شما؟
من هم خیلی خوبم. چیزی هست که بخواهی به معرفی‌ات اضافه کنی؟
نه، همانطوری که گفتی من یک مشاور مستقل هستم. پیش‌زمینه من در مشاوره و تولید نرم‌افزار، بیشتر در لندن و بیشتر به جاوا و برای بانک‌ها است. اما طی چند سال گذشته کارم مشاوره، تدریس و کمک به تیم‌ها بوده است که فرابگیرند که معماری نرم‌افزار چیست و چگونه می‌توانند آن را با روش‌های چابک (Agile) سبک ترکیب کنند.
شما طرح کشیدن (Sketching) را به عنوان روش مؤثری برای تولید و انتقال معماری نرم‌افزار مطرح کرده‌اید. اول اینکه چرا معماری نرم‌افزار را منتقل کنیم؟
اگر به ۱۰-۲۰ سال قبل برگردید، ما مراسم خیلی پرفرآیند و پرمستنداتی برای طراحی کردن داشتیم به این ترتیب که اول همه نیازمندی‌ها را استخراج می‌کردیم، بعد همه طراحی‌ها را انجام می‌دادیم و همه آن طراحی‌های زیاد را مجبور بودیم که مستند کنیم. بعد UML آمد و همه، ابزارهای UML و مدل‌سازی را خریدند و ماه‌ها و ماه‌ها فقط برای طراحی کردن صرف کردند. حال اگر از این ۲۰ سال با سرعت رد شویم، می‌بینیم الان از آن منتها به منتهای دیگر رسیده‌ایم. الان اغلب تیم‌ها اساساً هیچ کاری نمی‌کنند. کاری که من دارم می‌کنم این است که سعی می‌کنم که زبانه را به نقطه‌ای در این بین برگردانم.
ما دوره‌ی از پیش خیلی زیاد طراحی کردن را داشته‌ایم و بعد، از پیش اصلاً طراحی نکردن را داشته‌ایم و حال شما تلاش می‌کنید که به مقدار کافی آن برسید.
بله، البته [رهیافت‌های] چابک (Agile) نمی‌گویند که طراحی نکنید اما تعبیر خیلی از افراد از آنچه رهیافت‌ها و مانیفست چابک می‌گوید، این است. بنابراین من تلاش می‌کنم که افراد دوباره به طراحی فکر کنند و سعی می‌کنم بینش و مکانیزم خوبی فراهم کنم که افراد بتوانند استفاده کنند تا ایده‌ها را به اشتراک بگذارند چون بهرحال شما ایده شگرفی برای سیستم نرم‌افزاری دارید و نیاز است که تیم آن را بفهمد، همه مقصود از طرح کشیدن در‌واقع همین است.
بنابراین ذینفعان معماری، تیم [توسعه] است.
درسته، ما توسعه‌دهنده‌های نرم‌افزار بزرگترین ذینفعان معماری نرم‌افزار هستیم. بنابراین برای مثال در مورد طرح کشیدن، این‌ها مخاطبین اصلی در صحبت‌های من هستند.
بسیار خوب، مزایای این طرح‌ها (Sketch) چیست؟
قادر می‌سازد که تصویری که از طراحی یا معماری که می‌خواهیم بسازیم را منتقل کرده و به اشتراک بگذاریم. نکته طرح‌ها این است که سبک هستند. آنچه من تلاش می‌کنم این است که از رسیدن به یک فرآیند برآمده از مدل بزرگ طراحی از پیش، اجتناب کنم که مجبور باشیم به چیزهای خیلی زیادی فکر کنیم. [طر‌ح‌ها] در اینباره است که خیلی سریع عمده ایده‌ها را به روشی که در دسترس توسعه دهندگان باشد، انجام دهیم.
بنابراین اشکالی ندارد که [برخی] چیزها بیرون بیافتند. بهتر است که کامل نباشیم اما سبک باشیم.
درسته، ما قطعاً اینجا خصوصاً در مورد انتزاع‌های سطح بالا، به دنبال ریزبینی هستیم اما آنچه نمی‌خواهم انجام دهم این است که این کار را در مورد جزئیاتِ در سطح کلاس‌ها داشته باشم. بنابراین اگر افراد برای نمودارهای کلاسی، طرح بکشند شاید باید بپرسیم که چرا اینکار را می‌کنند یا چه ارزشی ایجاد می‌کنند؟
طرح‌ها، فرموله نشده‌اند بنابراین شاید راه‌های خیلی خیلی زیادی وجود داشته باشد که بتوانم یک طرحی بکشم که ناکارا باشد. یک طرح بد یا ناکارا کدامست؟
در این مورد پاسخ‌های زیادی وجود دارد. بخشی از کارگاه من این است که از افراد می‌خواهم که راه حلی طراحی کرده و تصاویری بکشند. من هرگز هیچ راهنمایی به آن‌ها نمی‌کنم و می‌توانم بگویم شاید ۹۰٪ طرح‌ها ناکارا می‌شود. به چندین دلیل ناکارا هستند. فکر می‌کنم اولینش به خاطر نمادگذاری‌ها (Notation) باشد. افراد به استفاده از UML گرایش ندارند اما UML نمادگذاری فرموله استاندارد است. وقتی از UML استفاده نمی‌کنند به ناچار، انتزاع خود از نمادگذاری‌ها را ابداع می‌کنند و همانطور که می‌توانید تصور کنید این منجر به سردرگمی‌های زیادی می‌شود.
ادامه مطلب ...

ارائه توسط: Randy Shoup
مترجم: محمد علی بزرگ زاده 1395/02/02
در این اپیزود که در اکتبر ۲۰۱۴ منتشر شده است، توبیاز کاتز با رندی شاپ در مورد جنبه‌های اجتماعی و فرهنگی کار در صنعت نرم‌افزار صحبت می‌کنند. رندی شاپ با کار در کیکسای، گوگل و eBay به بینش عمیقی در اینباره رسیده است که چطور شرکت‌ها می‌توانند از یک فرهنگ سازمانی خوب نگهداری کنند. او می‌خواهد در این مصاحبه، نظراتش را با ما به اشتراک بگذارد.
سلام رندی، خیلی خوشحالم که دوباره با شما مصاحبه می‌کنم.
خوشحالم که دوباره پیش شما هستم.
قبل از آنکه بخواهیم به موضوع امروزمان برسیم، آیا می‌خواهید به بحث‌هایی که در مصاحبه قبلی‌مان در مورد استخدام در صنعت نرم‌افزار داشتیم، چیزی بیافزایید؟ (مصاحبه مذکور ترجمه شده و از این آدرس در دسترس است -مترجم) شاید در مورد برخی جملاتی که گفته‌اید نظرتان تغییر کرده باشد، اینجا این شانس را دارید که آن‌ها را اصلاح کنید.
نه، نظرم تغییر نکرده است. هنوز هم اعتقاد دارم که خصوصاً برای موقعیت‌های مهندسی، مهم است که مهندس‌های برتر را استخدام کنیم اما همانطور که در اپیزود قبلی به تفصیل توضیح دادیم، تعریف مشخصی از مهندس برتر وجود ندارد. به عبارت دیگر، فردی وجود ندارد که برای همه شغل‌های ممکن، بهترین باشد بلکه حتماً باید فردی را بیابید که از نظر مهارت‌ها، علائق و توانایی‌ها با فرهنگ و سازمان خاصی بهترین تطابق را داشته باشد. به نظر من یافتن چنین فردی، فوق‌العاده مهم است. همانطور که توضیح دادیم افرادی که بهترین عملکرد را دارند حدوداً ۱۰ برابر بهتر از افرادی هستند که ضعیف‌ترین عملکرد را دارند بنابراین شما به عنوان یک سازمان خیلی علاقه دارید که گروه کوچکی از افراد با عملکرد‌های برتر را داشته باشید تا اینکه گروه خیلی بزرگی از افراد با عملکردهای متوسط یا زیرِ متوسط داشته باشید.
و در نهایت، به اهمیت داشتن مهارت‌ در مقایسه با تطبیق فرهنگی، چقدر وزن می‌دهید؟
من فکر می‌کنم به هر دو نیاز دارید. اینطور نیست که یکی از دیگری مهم‌تر باشد و هر دو جنبه، حیاتی است. واضح است که اگر بخواهید به عنوان یک مهندس کار خود را بکنید باید مهارت‌ها و ابزارهای لازمش را داشته باشید اما در عین حال مشکل شناخته شده نوابغ بدقلق (Difficult Genius) را هم داریم البته برای آن اصطلاحات زیادی وجود دارد که نامودبانه‌تر است. بهرحال این کافی نیست که تنها در کارتان خیلی خوب باشید بلکه باید تعامل خوبی هم داشته باشید و به خوبی با فرهنگ تطبیق یابید. من فکر می‌کنم هر دو به یک میزان اهمیت دارند.
و در مورد [استخدام] افرادی که بیشترین تطبیق فرهنگی با تیم را داشته باشند و یا در مقابل افرادی که بتوانند جنبه‌های فرهنگی جدیدی به تیم بیاورند [چه نظری دارید]؟
این سئوال خیلی خوبی است. برای اینکه یک نفر تطابق فرهنگی داشته باشد لازم نیست که مثل دیگران باشد. من می‌خواهم به این تشبیه برگردم که شما نمی‌خواهید یک کارخانه بسازید که همه چیز یکسان باشد، بلکه می‌خواهید یک سمفونی بسازید. فکر می‌کنم دفعه قبل گروه راک را مثال زدم. شما نمی‌خواهید که همه نوازنده گیتار یا همه نوازنده ساز کوبه‌ای یا همه خواننده باشند بلکه می‌خواهید ترکیبی از همه آن‌ها را داشته باشید. در این تشبیه گروه راک، ممکن است، خواننده از پیش‌زمینه جاز آمده باشد اما با این وجود، خواننده راک خوبی هم باشد. منظورم این است که افراد مهارت‌ها، علائق و توانایی‌های مختلفی دارند و ادغام کردن این تفاوت‌ها است که تیم را خوب می‌کند. فکر می‌کنم تطابق فرهنگی اصلاً معنای یکسان بودن نمی‌دهد بلکه به مانند تکه پازلی است که تطبیق پیدا می‌کند. همه افراد شکل یکسانی ندارند اما با هم تطبیق می‌یابند و یک کلیت شگفت‌آور می‌سازند. درست می‌گم؟
قطعاً اما این به آن معناست که وقتی تصمیم می‌گیرید که آیا یک فرد با تیم‌تان مطابقت دارد یا نه، به شمّ شخصی خود و تجربیات‌تان در استخدام افراد خیلی وابسته‌اید. درسته؟
بله، قطعاً. من فکر می‌کنم آدم‌ها در اینکه بلافاصله تشخیص دهند که آیا فردی، شخصیتِ دوستانه‌ و خوش‌برخوردی دارد، خیلی خوب هستند. ما این کار را ناآگاهانه و در چند میلی‌ثانیه انجام می‌دهیم. با فرض اینکه اندازه تیم کوچک باشد و ممکن باشد من فکر می‌کنم همه افراد تیم باید در مصاحبه هر فردی شرکت کنند. فکر می‌کنم همه باید کم و بیش همه را مصاحبه کنند.
ادامه مطلب ...