ارائه توسط: 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 یک سیستم پیام‌رسانی انتشار/عضویت است اما امروزه مرز بین سیستم‌های پیام‌رسانی و انتشار/عضویت محو شده است. سابقاً سیستم‌های پیام‌رسانی بیشتر به سیستم‌هایی اطلاق می‌شد که نوعی توزیع پیام نقطه به نقطه داشتند، پیام در محلی انتشار می‌یافت و تحویل محل دیگری می‌شد اما در دنیای انتشار/عضویت این تفاوت وجود دارد که پیام‌ها می‌توانند چندین بار و بالقوه توسط مصرف‌کننده‌های مختلف، مصرف شوند. اما امروزه این مرزها محو شده است چرا که خیلی از سیستم‌ها می‌توانند هر دو ویژگی را پشتیبانی کنند.
ادامه مطلب ...

ارائه توسط: Luke Hoban
مترجم: عماد خضری 1394/11/16
در این اپیزود که در مارس ۲۰۱۱ منتشر شده است، مارکوس ولتر به مصاحبه با لوک هابان ، مدیر پروژه F# در مایکروسافت می‌پردازد.
سلام، لطفا خودت را به طور مختصر برای شنونده‌های ما معرفی کن.
حتما، اسم من Luke Hoban است و مدیر برنامه‌ی F# مایکروسافت هستم. F# در 4-5 سال گذشته به عنوان یک پروژه تحقیقاتی مایکروسافت در حال انجام بود و پارسال تصمیم گرفتیم که آن را به عنوان یک محصول تحت پشتیبانی مایکروسافت عرضه کنیم. بنابراین من در گروهی کار می‌کنم که F# را از یک پروژه تحقیقاتی به بخشی از زبان‌های برنامه‌نویسی پشتیبانی شده .Net تبدیل می‌کند.
مطمئناً بسیاری از افراد در مورد F# چیزهایی شنیده‌اند و فکر می‌کنم پسوند شارپ اشاره به .Net بودن این زبان دارد. اما اگر ممکن است به طور خلاصه برای شنوندگان توضیح بده که F# چیست؟ مثلا F# در یک جمله ...؟
البته، اگر بخواهم F# را در یک جمله توضیح دهم، درواقع F# یک زبان برنامه‌نویسی رویه‌ای (Functional) برای پلتفرم .Net است. یک زبان برنامه‌نویسی رویه‌ایی مانند بسیاری دیگر، شما حتما زبان‌های رویه‌ای مانند Scheme، Lisp، Haskell و ML را می‌شناسید. F# مستقیما از خانواده زبان‌های ML ارث برده است و به طور خاص هسته زبان Ocaml را به اشتراک می‌گذارد. با این وجود F# زبانی است که کاملا با .Net تجمیع شده است و از سیستم شی‌گرای قدرتمند .Net بهره می‌برد. همچنین F# دارای ابزارهای خوبی برای برنامه‌نویسی دستوری (Imperative Programming) و انجام برنامه‌نویسی اکتشافی (Explorative Programming) در برخی زمینه‌ها می‌باشد.
مطمئناً در بخش‌های دیگر مصاحبه به مفاهیم اصلی زبان با جزییات بیشتر خواهیم پرداخت. شما گفتید که F# یک زبان رویه‌ای است . ما پیشتر اپیزودی درباره زبان‌های رویه‌ای داشتیم و احتمالاً شنوندگان می‌دانند که تابع جنبه‌ی اصلی در اینگونه زبان‌ها می‌باشد. پس اگر ممکن است کمی بیشتر توضیح دهید که توابع چگونه در F# استفاده می‌شوند و تفاوتشان با زبان‌های دیگر مانند C و پاسکال چه است؟
ایده توابع در زبان‌هایی مانند پاسکال و C به نوعی بسیار شبیه است اما در زبان‌های رویه‌ای می‌توان قدم‌های بیشتری برداشت و می‌توان از توابع به عنوان مقادیر درجه اول (First Class Value) استفاده کرد. بنابراین می‌توان توابع را به جاهای دیگر ارسال کرد، آن‌ها را به متغیرها نسبت داد، آن‌ها را در ساختار داده‌ها قرار داد و به عنوان یک آرگومان به دیگر توابع فرستاد. با استفاده از قابلیت ارسال یک تابع به عنوان آرگومان به دیگر توابع می‌توان قسمتی از کد را به شکلی که پیشتر در زبان‌‌های پروسه‌ای امکان‌پذیر نبود، استخراج کرد. درواقع زبان‌های رویه‌ای روی این تکنیک تاکید زیادی دارند.
یکی از نکاتی که به آن اشاره کردید، قابلیت بیان الگوریتم‌ها به شکلی بسیار مختصر است، به نظر من جنبه‌ی رویه‌ای بودن توابع یکی از دلایل آن است.
بله، من فکر می‌کنم با استفاده از قابلیت استخراج قسمت‌های مشترک کد و مجردسازی آن‌ها با استفاده از چیزهایی مانند توابع درجه یک و این حقیقت که زبان‌های رویه‌ای تغییرناپذیر (Immutable) هستند، می‌توان هسته‌ی اصلی کد را بسیار خلاصه‌تر نوشت. درواقع من فکر می‌کنم این مساله یکی از تفاوت‌های اساسی برنامه‌نویسی با زبان‌های عمومی و زبان‌های رویه‌ای است.
شما در صحبت‌هایتان از کلمه تغییرناپذیر(Immutable) استفاده کردید، آیا می‌توانید توضیح دهید که چرا این قابلیت در زبان‌های رویه‌ای اهمیت دارد؟ فکر می‌کنم افراد می‌دانند که تغییرناپذیر به این معنی است که نمی‌توان ساختار داده‌ها را عوض کرد، اما چرا این مساله در زبان‌های تابعی اهمیت دارد؟
این مساله به چند دلیل برای زبان‌های رویه‌ای اهمیت دارد. ایده اصلی تغییرناپذیری این است که اگر داده‌ای را به یک متغیر نسبت دهید، نمی‌توان دیگر آن متغیر را عوض کرد. این ایده برای استخراج قسمتی از کد و استفاده مجدد از آن بسیار کارایی دارد. فرض کنیم برنامه‌ای داریم که دارای وضعیت‌های به اشتراک گذاشته شده است که در بخش‌های مختلف سیستم به کار گرفته شده است، تغییر وضعیت‌های به اشتراک گذاشته شده می‌تواند بر روی رفتار سایر مولفه‌های سیستم تاثیر بگذارد. تکنیک‌های شی‌ءگرایی سعی دارند از روش‌هایی مانند محفظه‌سازی (Encapsulation) برای مخفی‌سازی وضعیت‌ها و کنترل دسترسی به آن استفاده کنند. اما اگر یک سیستم تغییرناپذیر داشته باشیم، دیگر لازم نیست نگران باشیم که دیگران رفتار برنامه را تغییر دهند.
اما مساله‌ جالبی که فراتر از بحث‌های پایه‌ای مهندسی نرم‌افزار، رایج شده است زمینه محاسبات توزیع شده و موازی است که در بسیاری از کاربردها خیلی استفاده می‌شود. همانطور که می‌دانید، موازی‌سازی در مقیاس‌ بزرگ به عنوان بخشی از تکمیل پروسه نرم‌افزار انجام می‌شود. زمانی که شما موازی‌سازی انجام می‌دهید یکی از مشکلات بزرگی که با آن مواجه می‌شوید و عموماً حل آن‌ها دشوار است، وجود وضعیت‌های به اشتراک گذاشته شده است. اگر Threadها یا قسمت‌های مختلفی از سیستم به شکل مستقل در حال اجرا باشند و تلاش کنند تا با وضعیت به اشتراک گذاشته شده ارتباط برقرار کنند، احتمالاً دچار مشکلاتی خواهیم شد. تکنیک‌های زیادی برای حل این مشکلات معرفی شده‌اند اما در نهایت بهترین راه حل برای این مساله در زبان‌های رویه‌ای وجود دارد و آن جلوگیری از داشتن وضعیت به اشتراک گذاشته شده است، با استفاده از قابلیت تغییرناپذیری در زبان‌های رویه‌ای می‌توان جعبه ابزاری برای نوشتن برنامه‌های بدون وضعیت اشتراکی داشت.
ادامه مطلب ...