ايميل:

كلمه عبور:


مرا از مطلب‌های جدید باخبر کن!
ايميل من:


فهرست مطالب


ارائه توسط: Katie Malone
مترجم: رضا بکتاش 1398/11/17
در این قسمت که در مارس ۲۰۱۷ منتشر شده است، آدیانا سالیناز با کاتلین ملون در ارتباط با یادگیری ماشین مصاحبه می‌کند. کاتلین ، یک متخصص علوم داده در دپارتمان تحقیق و توسعه شرکت Civis Analytics است. او مدرک دکترای فیزیک از دانشگاه استنفورد دارد و در زمینه فیزیک ذرات کار کرده است. او در زمینه جستجوی ذرات جدید در موسسه CERN کار کرده که کار او شامل علوم داده و یادگیری ماشین بوده است. او همچنین استاد درس آشنایی با یادگیری ماشین در سایت udacity است. او هم‌چنین مجری برنامه پادکست انحراف های خطی (Linear Digressions) است که علوم داده و یادگیری ماشین را با کاربردهای جالب و بعضا عجیب کنکاش می‌کند.
خانم کتی ملون، به رادیوی مهندسی نرم‌افزار خوش آمدی!
ممنون از دعوت شما، خوشحالم که اینجا هستم.
یادگیری ماشین امروزه به طور گسترده استفاده می‌شود. کاربردهای آن را مدت‌هاست که در موتورهای جستجو، تشخیص گفتار ماشینی و ترجمه ماشینی شاهد هستیم. اما اخیرا در فیلم‌های پیشنهادی نت‌فلیکس و ماشین‌های خودران هم کاربردهای یادگیری ماشین را می‌بینیم که هر روز بیشتر می‌شود. در ابتدا می‌خواهیم با تعریف یادگیری ماشین شروع کنیم. یادگیری ماشین چیست؟
خب بگذارید از یک گام عقب‌تر شروع کنم. سابقه من در زمینه علوم پایه است. من اعتقاد دارم که در دنیا حقایقی وجود دارد و علم یکی از راه‌های یافتن حقایق از دنیای پیرامون‌ ما است. سنجش حقیقت به طور مستقیم کار بسیار سختی است، اما به جای آن یکی از کارهایی که می توان کرد جمع کردن داده از جهان است. اگر این داده‌ها را آنالیز کنیم، گاهی می‌توانیم حقایق را از آن‌ها استخراج کنیم. مثلا علاقه من به یک فیلم یا ترجمه‌ صحیح همین جمله به فرانسوی از حقایقی هستند که می‌توانند در دنیا وجود داشته باشند.
به نظرم یادگیری ماشین مجموعه‌ای از ابزارهایی است که به ما کمک می‌کند با آنالیز آن داده‌ها نسبت به حقایق دنیای پیرامون آگاه شویم. بنابراین یادگیری ماشین معمولا شامل حجم زیادی از محاسبات می‌شود و کلمه ماشین در آن اشاره به کامپیوتر دارد. همچنین مقادیر زیادی کار آماری و معمولا زمینه‌هایی از علوم دیگر در آن کاربرد دارند. بنابراین اگر مثلا بخواهید رفتار انسان را مطالعه کنید، باید درباره مجموعه کاملی از علوم مانند روان‌شناسی رفتاری، اقتصاد و اینگونه موارد که پس‌زمینه آن است، دانش داشته باشید.
با برداشت شما، یادگیری ماشین، سنجش حقیقت به وسیله جمع‌ آوری و تحلیل داده است. اما یادگیری ماشین چه ارتباطی به هوش‌مصنوعی پیدا می‌کند؟
سوال جالبی پرسیدید. من در جایی تعریفی از هوش مصنوعی و تمایز آن با یادگیری‌ ماشین خوانده بودم؛ به نظرم تعریف دقیقی نبود، اما خلاصه‌اش این بود که یادگیری ماشین تمرکز بر استخراج حقایق پیرامون ما و مثلا پیش‌بینی وقایع دارد. اما هوش مصنوعی به یک پله بالاتر فکر می‌کند. هنگامی که پیش‌‌بینی‌ داشته باشیم و از حقایق باخبر شویم، میتوانیم بهتر تصمیم‌گیری کنیم و کارها را در آینده بهتر انجام دهیم و در واقع از دیدی که به دست آورده‌ایم بهره ببریم. پس هوش مصنوعی به یادگیری ماشین وابسته است و به نظرم یک لایه به آن اضافه می‌کند که بر اساس نتایج یادگیری ماشین، تصمیم‌گیری و شناخت بهتری داشته باشیم.
برویم سراغ یک مثال ساده از یادگیری ماشین. ابزاری که من روزانه با آن تعامل زیادی دارم سرویس ایمیل است. هر وقت که ایمیل جدیدی دریافت می‌کنم، دکمه‌ای نشان داده می‌شود که آیا ایمیل اسپم است یا نه. لطفا در مورد نحوه تشخیص اسپم با استفاده از محتوای یک ایمیل توسط یادگیری ماشین صحبت کنید.
بله حتما. تشخیص ایمیل مثال خوبی برای یک دسته از الگوریتم‌های یادگیری ماشین به نام یادگیری تحت نظارت (Supervised) است. در یادگیری ماشین، «تحت نظارت» به این معنا است که جواب درست برخی داده‌ها را داشته باشیم. در این مثال، جواب درست درباره اسپم بودن یا نبودن یک ایمیل است که خود شما به شکل دستی با برچسب زدن ایمیل‌ها مشخص می‌کنید. و اگر نگویید که اسپم است تلویحا فرض می‌شود که یک ایمیل مجاز است. این‌ها ممکن است فرضیات درستی باشند یا نباشند. اما بیایید فرض کنیم که این برچسب‌ها غالبا گویای محتوای آن ایمیل‌ها هستند. بنابراین در اینجا دسته‌بندی (Classification) به مفهوم جداسازی اشیاء به دو دسته اسپم و غیر اسپم است. پس ایده یادگیری ماشین، پیش‌بینی کردن برچسب ایمیل با استفاده از ویژگی‌های آن است. می‌توانیم بفهمیم ایمیل‌های اسپم چه الگویی دارند و این الگوها را با ایمیل‌های جدید بدون برچسب قیاس کنیم تا پیش‌بینی خوبی درباره اسپم بودن یا نبودن آن‌ها انجام دهیم.
ادامه مطلب ...

ارائه توسط: Brian Brazil
مترجم: محمد علی بزرگ زاده 1397/10/20
در این اپیزود که در اکتبر ۲۰۱۶ منتشر شده است جف میرسون با برایان برزیل در مورد ابزار مانیتورینگ Prometheus صحبت می‌کند. برایان، مؤسس Robust Perception است. این شرکت، کمک می‌کند که کاربران ابزار متن‌باز Prometheus افزایش یافته و آن‌ها را پیشتیبانی می‌کند. برایان به شدت، به پروژه Prometheus تعهد دارد. او قبل از شرکت Robust Perception در گوگل کار می‌کرد.
برایان، به SE Radio خوش آمدی.
سلام جف، خوشحالم که اینجا هستم.
بگذار با صحبت در مورد مانیتورینگ آغاز کنیم. مانیتورینگ چیست؟
طی سال گذشته با افراد زیادی صحبت کرده‌ام. افراد مختلف، درباره اینکه مانیتورینگ چیست، برداشت‌های خیلی متفاوتی دارند. برای مثال، وقتی می‌گفتم من کار مانیتورینگ را انجام می‌دهم، برخی افراد بودند که فکر می‌کردند که من به ترافیک شبکه‌شان نگاه می‌کنم تا ببینم آیا در محل کار، سراغ فیسبوک می‌روند یا خیر. روشن است که ما چنین کاری نمی‌کنیم.
من مانیتورینگ را در چهار چیز می‌بینم. یکی این است که وقتی مشکلی ایجاد شده یا احتمال مشکلی (یک مشکل کسب و کار) وجود دارد، به شما هشدار دهد. دوم، این است که اطلاعاتی که برای دیباگ آن مشکل نیاز دارید را به شما بدهد. مورد سوم، نمایش روندهای بلندمدت برای اخذ تصمیمات کسب و کار است. مثلاً اگر بدانید که نرخ موفقیت از کَش (Cache Hit Rate) فرضاً ۹۰٪ باشد و اگر تغییر شما بخواهد آن را ۹۵٪ بکند، به این معناست که می‌توانید از دست سخت‌افزارش خلاص شوید و آن را [برای کار دیگری] اضافه کنید. مورد چهارم، لوله‌‌کشی‌های کلی است. برای مثال، اگر هارد دیسک خراب شود، دست آخر، باید فردی را بفرستید که آن را تعمیر کند چون هنوز روبات‌ها برای انجام این کار به قدر کافی خوب نیستند. این‌ها، ۴ چیزی هستند که من در ارتباط با مانیتورینگ در فضای کام‍پیوترها، می‌بینم.
عالی. یک مثال از چیزهایی بزنید که وقتی در گوگل کار می‌کردید، آن را مانیتور می‌کردید.
من قبلاً در بخش Ads در گوگل کار می‌کردم. بنابراین ما چیزهایی از قبیل تعداد پرس‌وجوهای ورودی در ثانیه را مانیتور می‌کردیم. مدت زمان تأخیر (Latency) و همینطور جزییات سیستم‌ها را هم مانیتور می‌کردیم. بنابراین ما خربارها داده آماری داشتیم.
درست است. می‌خواهم بعداً از آن، جهت مثال استفاده کنم.
ما امروز در مرود Prometheus صحبت می‌کنیم. و شما ادعا کرده‌اید که Prometheus نسل بعدی سیستم‌های مانیتورینگ است. آیا می‌توانید در این مورد صحبت کنید که مانیتورینگ با Prometheus با ابزارهای نسل‌های قبلی چه تفاوتی دارد؟
اگر به نسل‌های قبل نگاه کنید فرضاً چیزی مانند Nagios را یا چیزهای دیگر منتج از آن را می‌بینیم که چند مورد هستند. Nagios براساس قاعده «بررسی کردن هر ماشین» کار می‌کند. درواقع، یک شِل‌اسکریپت را اجرا می‌کنم که خروجی درست یا غلط برمی‌گرداند و براساس آن یک هشدار به کاربر انسانی می‌فرستم. اگر ۵ ماشین داشته باشید که مراقب‌شان بوده و آن‌ها را نگهداری و تغذیه می‌کنید، این می‌تواند خوب باشد اما در نسل کنونی که افراد در مورد [معماری] بدون سرور (Serverless)، ابر و [کدهای] بومی ابر (Cloud Native) صحبت می‌کنند، ممکن است هزارها ماشین کوچک داشته باشید که دائم آشکار و پنهان می‌شوند. بنابراین، آن هشدارهای در سطح ماشین‌های منفرد آنقدرها مفید نیست.
همچنین ممکن است یک ماشین، کمی کند باشد اما این لزوماً به آن معنی نیست که آن سرویس در کل مشکلی داشته باشد. چون ممکن است همچنان SLA را برآورده کنید. به عنوان یک مثال فنی، فرض کنید که نوعی وب‌سرویس را اجرا می‌کنید. و در مورد میزان تأخیر (Latency) یک SLA دارید که می‌گوید تأخیر باید زیر یک ثانیه باشد. در این حالت خیلی دشوار است که فقط از Nagios استفاده کنید و برای تأخیر بیش از یک ثانیه هشدار داشته باشید. چون فقط می‌توانید به هرکدام از ماشین‌ها نگاه کنید و باید این داده را به نوعی فراهم کنید و نمی‌توانید دید کلی سطح سرویس را ببینید. در نهایت افراد به این می‌رسند که وقتی CPU بالا رفت، هشدار دهند. این می‌تواند حاکی از چنین مشکلی باشد مثلاً ممکن است به خاطر یک بن‌بست (Deadlock) باشد اما موارد زیادی از مثبت‌های اشتباهی (False Positive) هم می‌تواند باشد فرضاً اگر چرخش [فایل‌های] لاگ کمی بیشتر زمان برده باشد.
ادامه مطلب ...

ارائه توسط: Patrick Kua
مترجم: سید مرتضی هاشمی 1396/11/08
در این قسمت که در آگوست ۲۰۱۶ منتشر شده است یوهان سوِن با پاتریک کوآ درباره‌ی نقش رهبر فنی (Technical Lead) و چگونگی تبدیل شدنِ یک فرد، به رهبر فنی صحبت می‌کند. تعریف رهبر فنی، مسئولیت‌های این نقش و چالش‌های تبدیل شدن به یک رهبر فنی، از جمله موضوعاتی هستند که در این گفتگو مطرح می‌شود.
به یک برنامه‌ی دیگر از رادیوی مهندسی نرم‌افزار خوش آمدید. امروز با پاتریک کوا هستم. به رادیوی مهندسی نرم‌افزار خوش آمد پاتریک! خوشحالیم که با ما هستی.
ممنونم که مرا دعوت کردید، خوشحالم که با شما صحبت می‌کنم.
پاتریک کوا یک مشاور ارشد و یک رهبر فنی در ThoughtWorks است. معمولاً در لندن زندگی می‌کند، هرچند در حال حاضر در برلین کار می‌کند. او در زمینه‌ی توسعه‌ی نرم‌افزار بیش از یک دهه تجربه دارد و تمرکزش بر افراد، کسب و کار و فناوری است. ممکن است او را به واسطه‌ی کتاب The Retrospective Handbook و یا کتاب جدیدترش، Talking with Tech Leads بشناسید. پاتریک همچنین در زمینه‌ی آموزش رهبری فنی، هم به صورت داخلی در ThoughtWorks و هم در خارج از آن فعالیت داشته است. من در یکی از این آموزش‌های او بوده‌ام. موضوع این برنامه چگونگی تبدیل شدن به یک رهبر فنی است که کاملاً منطبق [با تجربیات او] است.
پاتریک آیا چیز دیگری هست که بخواهی در مورد خودت بگویی؟
نه، خیلی خوب خلاصه‌اش کردی.
برای این‌که جای ابهامی باقی نماند، هم من و هم پاتریک در ThoughtWorks کار می‌کنیم. برای همین من در یکی از آموزش‌های او شرکت کردم. اولین سؤالی که هنگام صحبت کردن در مورد رهبری فنی به ذهن می‌رسد این است که نقش رهبر فنی چیست؟ وقتی من یک رهبر فنی می‌شوم چه مسئولیت‌هایی دارم؟
این سوال خیلی خوبی است. اول از همه باید بگویم که فقط یک تعریف خوب در اینباره وجود ندارد، چون هر سازمانی این نقش را به شکلی متفاوت تلقی می‌کند. من با تعداد زیادی از مشتریان در سازمان‌های متفاوت کار کرده‌ام؛ فکر می‌کنم بتوانم آن‌چه که به نظرم ویژگی‌های مشترک مسئولیت‌های یک رهبر فنی است را بگویم.
در برخی سازمان‌ها به رهبر فنی، توسعه‌دهنده‌ی پیشرو اطلاق می‌شود؛ در سایر سازمان‌ها به آن معمار می‌گویند. به نظر من، ترکیب این دو تفکر این است که رهبر فنی، نقشِ یک معمار نیست که خارج از تیم است. در واقع یک توسعه‌دهنده است. کسی که دارای مهارت‌های توسعه است و مسئولیت رهبری تیم را بر عهده دارد. این نقش با نقش توسعه دهنده‌ی ارشد کاملاً متفاوت است، که هدایت یک حوزه در بخشی از سیستم را بر عهده دارد. رهبر فنی سعی می‌کند بر اثرگذاری کلی تیم تمرکز کند. من انتظار دارم که یک رهبر فنی تا حدی کد بنویسد و همچنین در سطوح فنی کار کند.
آنچه که به نظر من رهبر فنی نیست، چیزی است که افراد اغلب به آن مدیر فنی می‌گویند. کسی که بیشتر مسئولِ پیشرفت افراد و گزارش‌هاست اما لزوماً درگیر معماری نیست. حتی اگر پیش‌زمینه‌ی فنی داشته باشد لزوماً بر سیستم متمرکز نیست. انتظار دارم که مدیران فنی با رهبر فنی در تعامل باشند.
در بسیاری شرکت‌های دیگر استاد اسکرام (Scrum Master) نقش خیلی محبوبی است و به نظر من، این نقش خیلی متفاوت [از رهبر فنی] است، هر چند یک رهبر فنی می‌تواند استاد اسکرام هم باشد. استاد اسکرام بودن، لزوماً به صورت خودکار از شما یک رهبر فنی نمی‌سازد.
این جنبه، شاخص است که رهبر فنی همچنان یک توسعه‌دهنده است که بر اثرگذاری تیم تمرکز دارد.
درست است.
آیا در مقام مقایسه موافقید که مدیر فنی منحصراً بر تیم تمرکز دارد، معمار منحصراً بر فناوری تمرکز دارد، و توسعه‌دهنده‌ی ارشد کسی است که مالک بخش خاصی از سیستم است؟
بله، درست است. تأکید می‌کنم که این‌ها مربوط به نقش‌ها هستند، و این به آن معنی نیست که یک سازمان برای هر یک از نقش‌ها فرد مجزایی خواهد داشت. گاهی یک فرد چند تا از این نقش‌ها را بازی می‌کند. ممکن است رهبر فنی نقش مدیر فنی را هم داشته باشد که مراقب افرادِ خط تولید است، و ممکن است در عین حال ارشدترین عضو تیم هم باشد. اما در شرایط دیگر، مثلاً از نظر اندازه‌ی تیم یا نحوه‌ی ساختاردهی یک سازمان، ممکن است نقش‌های جداگانه‌ای هم باشند.
من نوعی از تقسیم [وظایف] را [در نقش رهبر فنی] می‌بینم؛ یک جنبه‌ی فنی که مربوط به معماری و مسیر سیستم است، و جنبه‌ی مدیریت افراد و پروژه که ممکن است بیشتر مربوط به مدیر فنی باشد. این یک الگوی متداول است که می‌بینم. اما تأکید می‌کنم که این یک نقش است و به این معنی است که مجموعه‌ای از مسئولیت‌ها را شامل می‌شود.
پیش از آن‌که در این موضوع عمیق‌تر شویم آیا ممکن است توضیح دهید که دقیقاً چرا به رهبر فنی نیاز داریم؟
بله، این سؤال خیلی خوبی است. وقتی در کنفرانس‌ها در مورد این‌که رهبر فنی چیست صحبت می‌کنم، یکی از سؤالاتی که عموماً پرسیده می‌شود این است که «چرا به آن نیاز داریم؟» قطعاً می‌توانم شرایطی را تصور کنم که در یک تیم کوچک کار می‌کنید و همه به خوبی با هم کنار می‌آیند و هر کس می‌داند که باید چه کاری انجام دهد؛ در چنین شرایطی شاید به یک رهبر فنی احتیاجی نباشد، چون همه کارشان را می‌دانند و به خوبی هماهنگ شده‌اند. این یک وضعیت ایده‌آل است و بسیاری تیم‌ها هستند که در وضعیت آشفته‌تری هستند و ترکیبی از مهارت‌های متفاوت دارند. عموماً ممکن است درباره‌ی نحوه‌ی پیاده‌سازی یا مسیر سیستم و معماری ابهاماتی وجود داشته باشد. خیلی خوب است که توسعه‌دهندگانی که توانایی گرفتن چنین تصمیماتی دارند، این تصمیمات را در کارهای خودشان بگیرند. اما زمانی که افراد در مقابل یکدیگر قرار می‌گیرند با یک آشفتگی مواجه می‌شوید. به نظر من یکی از وظایف یک رهبر فنی این است که کاری کند توسعه‌دهندگان به شکلی اثربخش در یک جهت فعالیت کنند.
ادامه مطلب ...