ارائه توسط: 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) را هم داریم البته برای آن اصطلاحات زیادی وجود دارد که نامودبانه‌تر است. بهرحال این کافی نیست که تنها در کارتان خیلی خوب باشید بلکه باید تعامل خوبی هم داشته باشید و به خوبی با فرهنگ تطبیق یابید. من فکر می‌کنم هر دو به یک میزان اهمیت دارند.
و در مورد [استخدام] افرادی که بیشترین تطبیق فرهنگی با تیم را داشته باشند و یا در مقابل افرادی که بتوانند جنبه‌های فرهنگی جدیدی به تیم بیاورند [چه نظری دارید]؟
این سئوال خیلی خوبی است. برای اینکه یک نفر تطابق فرهنگی داشته باشد لازم نیست که مثل دیگران باشد. من می‌خواهم به این تشبیه برگردم که شما نمی‌خواهید یک کارخانه بسازید که همه چیز یکسان باشد، بلکه می‌خواهید یک سمفونی بسازید. فکر می‌کنم دفعه قبل گروه راک را مثال زدم. شما نمی‌خواهید که همه نوازنده گیتار یا همه نوازنده ساز کوبه‌ای یا همه خواننده باشند بلکه می‌خواهید ترکیبی از همه آن‌ها را داشته باشید. در این تشبیه گروه راک، ممکن است، خواننده از پیش‌زمینه جاز آمده باشد اما با این وجود، خواننده راک خوبی هم باشد. منظورم این است که افراد مهارت‌ها، علائق و توانایی‌های مختلفی دارند و ادغام کردن این تفاوت‌ها است که تیم را خوب می‌کند. فکر می‌کنم تطابق فرهنگی اصلاً معنای یکسان بودن نمی‌دهد بلکه به مانند تکه پازلی است که تطبیق پیدا می‌کند. همه افراد شکل یکسانی ندارند اما با هم تطبیق می‌یابند و یک کلیت شگفت‌آور می‌سازند. درست می‌گم؟
قطعاً اما این به آن معناست که وقتی تصمیم می‌گیرید که آیا یک فرد با تیم‌تان مطابقت دارد یا نه، به شمّ شخصی خود و تجربیات‌تان در استخدام افراد خیلی وابسته‌اید. درسته؟
بله، قطعاً. من فکر می‌کنم آدم‌ها در اینکه بلافاصله تشخیص دهند که آیا فردی، شخصیتِ دوستانه‌ و خوش‌برخوردی دارد، خیلی خوب هستند. ما این کار را ناآگاهانه و در چند میلی‌ثانیه انجام می‌دهیم. با فرض اینکه اندازه تیم کوچک باشد و ممکن باشد من فکر می‌کنم همه افراد تیم باید در مصاحبه هر فردی شرکت کنند. فکر می‌کنم همه باید کم و بیش همه را مصاحبه کنند.
ادامه مطلب ...

ارائه توسط: Jun Rao
مترجم: محمد علی بزرگ زاده 1395/01/22
در این اپیزود که در فوریه ۲۰۱۵ منتشر شده است، جف میرسون با جون راو در ارتباط با Apache Kafka مصاحبه می‌کند. جون راو پیش از این در LinkedIn مشغول بوده است و سپس به افتتاح شرکتی مبادرت کرده که کارش به شکل گسترده‌ای مبتنی بر Kafka است. او یک محقق و توسعه‌دهنده نرم‌افزار است و بیشتر زمانش را به تحقیق در حوزه‌های MapReduce، پایگاه‌های مقیاس‌پذیر، پردازش پرس‌وجوها و جنبه‌های دیگر انباره‌های داده (Datawarehouse) صرف کرده است. او طی چند سال گذشته از تثبیت‌کننده‌های کد (Commiter) در پروژه Kafka بوده است.
جون راو، به SE Radio خوش آمدی!
ممنونم جف که من را دعوت کردید.
بیا شروع کنیم و در مورد چند تا از تعاریف صحبت کنیم. شما جریان‌پردازی (Streaming) را چطور تعریف می‌کنید؟ و پیام‌رسانی (Messaging) را چطور؟
سئوال خوبی است. بر اساس دیدی که من دارم جریان‌پردازی، تاریخچه‌اش بیشتر برمی‌گردد به سیستم‌ها یا فریم‌ورک‌هایی که قابلیت پردازش یک یا چند دنباله از رخدادهای نامتناهی را فراهم می‌کنند. این سیستم‌ها برای پردازش این رخدادها، عموماً امکاناتی از قبیل جازدنِ (Plugin) منطق‌های شخصی‌شده (Customized Logic) فراهم می‌کنند، می‌توانید کارهایی از قبیل فیلتر کردن، تجمیع‌سازی‌ مبتنی بر پنجره‌های زمانی و یا الحاق‌ کردن جریان‌ها را انجام دهید. برخی فریم‌ورک‌هایی هم وجود دارند که کارهایی مانند موازی‌سازی را برایتان انجام می‌دهند و دیگر نیاز نیست که خیلی نگران موازی‌سازی‌ها باشید. این فریم‌ورک‌ها اغلب امکانات تحمل‌پذیری خطا هم فراهم می‌کنند و لازم نیست نگران از کار افتادن یکی از واحدهای پردازشی باشید زیرا فریم‌ورک می‌تواند بر روی یک ماشین دیگر دوباره یک پراسس برایتان اجرا کند. از دیدگاه من، این‌ها چیزهایی است که یک سیستم جریان‌پردازی به آن ارجاع دارد. براساس این تعریف، چیزهایی از قبیل Apache Storm و Apache Spark در این دسته قرار می‌گیرند، همینطور Apache Samza هم هست که در این دسته قرار می‌گیرد. این‌ها سیستم‌هایی هستند که فریم‌ورکی برای پردازش دنباله‌های نامتناهی از رخدادها فراهم می‌کنند.
حال، یکی از چیزهایی که این سیستم‌ها باید نگرانش باشند این است که داده‌ها را از کجا بیاورند؟ اینجاست که سیستم‌های پیام‌رسانی وارد می‌شوند. بنابراین یکی از راه‌های اصلی که این سیستم‌های جریان‌پردازی برای گرفتن داده‌ها دارند از سیستم‌های پیام‌رسانی یا سیستم‌های انتشار/عضویت (Publish/Subscribe) است. مثلاً در Apache Storm متداول‌ترین راه گرفتن داده‌ها از طریق Apache Kafka است که یک سیستم پیام‌رسانی است. در سیستم‌های جریان‌پردازی دیگر مانند Spark و Samza هم یکپارچه‌سازی‌ باKafka وجود دارد. این دید من در مورد ارتباط‌های مختلف بین سیستم‌های جریان‌پردازی و پیام‌رسانی است.
قیاس دیگری که وجود دارد مقایسه آن با دنیای Hadoop است. Hadoop دو بخش دارد. یکی بخش MapReduce است که فریم‌ورک پردازشی داده‌های برون‌خط (Offline) است و بخش دیگر، HDFS است که مکانیزم ذخیره‌سازی و تحویل‌دهی این داده‌ها است و این دو سیستم با روش غیرسفت و سختی به هم همبسته شده‌اند تا یک فریم‌ورک محاسباتی برون‌خط را فراهم کنند. شما می‌توانید سیستم‌های جریان‌پردازی را به مثابه MapReduce و سیستم‌های پیام‌رسانی مانند Kafka را معادل بخش HDFS آن ببینید اما با این تفاوت که این‌ها برای دنیای بلادرنگ هستند.
جالب است که می‌توانید اینطور توضیحش دهید که Kafka و Storm به نوعی دسته‌های از هم باز شده چیزهایی هستند که در حوزه‌های دیگر عموماً با هم هستند. بیا کمی در این مورد صحبت کنیم که Kafka چه چیزی است؟ جمع‌بندی که من پیدا کردم این است که یک سیستم پیام‌رسانی انتشار/عضویت است که به عنوان یک Commit Log توزیع‌شده بازنگری شده است. نظر شما در مورد این تعریف چیست؟ چرا شباهت برقرار کردن بین پیام‌رسانی و Commit Log توزیع‌شده مفید است؟
درست است که در تعریف سطح بالایش Kafka یک سیستم پیام‌رسانی انتشار/عضویت است اما امروزه مرز بین سیستم‌های پیام‌رسانی و انتشار/عضویت محو شده است. سابقاً سیستم‌های پیام‌رسانی بیشتر به سیستم‌هایی اطلاق می‌شد که نوعی توزیع پیام نقطه به نقطه داشتند، پیام در محلی انتشار می‌یافت و تحویل محل دیگری می‌شد اما در دنیای انتشار/عضویت این تفاوت وجود دارد که پیام‌ها می‌توانند چندین بار و بالقوه توسط مصرف‌کننده‌های مختلف، مصرف شوند. اما امروزه این مرزها محو شده است چرا که خیلی از سیستم‌ها می‌توانند هر دو ویژگی را پشتیبانی کنند.
ادامه مطلب ...