این روزها بخشی از زمانم درگیر پروژه‌ای هستم که حدود پانزده دانشجو در آن مشغول به برنامه‌نویسی هستند. قرار است که نقش راهنما (منتور) را داشته باشم ولی این نقش را نمی‌توانم درست انجام بدهم، زیرا:
– پیش‌نیازهای زبان انگلیسی محاوره‌ای: در زبان فارسی اگر کسی عبارت “رفت تو دیوار” را در یک تیم نرم‌افزاری بگوید، ما می‌دانیم که سیستم از کار افتاده یا یک چیزی خراب شده است. 🙂 حالا اگر عبارت‌های این چنینی را در زبان انگلیسی بشنوید، بعید است که منظور گوینده را درست متوجه شوید. موضوع چالشی‌تر این است که اگر به انگلیسی بگویید “goes to wall”، احتمالا با چهره متعجب و پرسوال مخاطب رو به رو می‌شوید. 🙂

– پیش‌نیازهای زبان انگلیسی نوشتاری: فرض کنید شما مشغول بازنگری کد ارسال شده به مخزن پروژه (pull request) هستید. فرض کنید موضوعی را با نوشتن کامنت به برنامه‌نویس توضیح داده‌اید. چند خط پایین‌تر دوباره به همان موضوع برمی‌خورید و می‌خواهید بگویید “همانی که بالا گفتم”. در فارسی فقط می‌نویسم ” ایضا” “. حالا وقتی می‌خواهید انگلیسی بنویسید چه عبارتی را می‌نویسید؟ 🙂 می‌نویسید ditto . ولی این کلمه، چیزی نیست که بتوانید با جستجو در گوگل پیدا کنید، بماند که باید سریع هم این کار را انجام بدهید.

– فرهنگ و گذشته: اگر شما عبارت “من می‌دونم که ما موفق نمی‌شیم” رو بشنوید احتمالا یادتان می‌افتد که این جمله برمی‌گردد به گلام (Glum) نقش منفی در کارتون گالیور 🙂 . حالا اگر شما چنین عبارت‌هایی را به زبان انگلیسی بشنوید، متوجه نمی‌شوید که منظور گوینده چیست. اگر هم تکیه کلام گلام را به انگلیسی بگویید “I know we will not succeed” که دیگر هیچ!
حالا فرض کنید در جلسه‌ای بخواهید بگویید که محدوده پروژه را مدیریت کنید وگرنه در پایان سیستم شبیه “شتر گاو پلنگ” می‌شود. 🙂

– تکنولوژی: از دنیای کاملا ویندوزی، ورود به دنیای کاملا لینوکسی هر چند بسیار جذاب است، ولی اگر بخواهید در پاسخگویی سرعت عمل داشته باشید، تبدیل به یک چالش جدی می‌شود

– فریم‌ورک: در این پروژه از فریم‌ورک‌هایی استفاده می‌شود که تجربه‌ای در آن ندارم. با تمام تلاشم برای یادگیری، اما وقتی بخواهید راهنمای کسی باشید یا مشکلاتش را حل کنید، نداشتن پیش‌زمینه آن فریم‌ورک، تبدیل به چالش جدی می‌شود.

خلاصه، سرتان را درد نیاورم، وضعیت فعلی من “آشفتگی مطلق” است.

بس دراز است این حدیث خواجه گو تا چه شد احوال آن مرد نکو
خواجه اندر آتش و درد و حنین صد پراکنده همی‌گفت این چنین
گه تناقض گاه ناز و گه نیاز گاه سودای حقیقت گه مجاز
مرد غرقه گشته جانی می‌کند دست را در هر گیاهی می‌زند
تا کدامش دست گیرد در خطر دست و پایی می‌زند از بیم سر
دوست دارد یار این آشفتگی کوشش بیهوده به از خفتگی
آنک او شاهست او بی کار نیست ناله از وی طرفه کو بیمار نیست
بهر این فرمود رحمان ای پسر کل یوم هو فی شان ای پسر
اندرین ره می‌تراش و می‌خراش تا دم آخر دمی فارغ مباش
تا دم آخر دمی آخر بود که عنایت با تو صاحب‌سر بود
هر چه می‌کوشند اگر مرد و زنست گوش و چشم شاه جان بر روزنست

مولوی » مثنوی معنوی » دفتر اول

[et_pb_section bb_built=”1″ admin_label=”section”][et_pb_row admin_label=”row”][et_pb_column type=”4_4″][et_pb_text admin_label=”متن”]

The goal of teaching should not be to help the students learn how to memorize and spit out information under academic pressure. ?
The purpose of teaching is to inspire the desire for learning in them and make them able to think, understand, and question.

Richard Feynman

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

شنبه گذشته (بیست و سوم ماه می) اولین جلسه‌ی سخنرانی متدهای چابک در کانون برنامه‌نویسان ایرانی کانادا برگزار شد. این سخنرانی، اولین کار آموزشی من در خاک کانادا است.

به تازگی با این کانون که حدود 500 عضو دارد آشنا شده‌ام. به پیشنهاد دوست عزیزم آقای رضا رحمتی و هماهنگی آقای محمد نادی (مدیر کانون) قرار شد که یک سخنرانی کوتاه سه جلسه‌ای برای آشنایی با متدهای چابک و به‌ویژه اسکرام برگزار شود.

آگهی سخنرانی:

معرفی سخنرانی:

برای معرفی این سه جلسه تصمیم گرفتم که آن را به شکل نامتعارف و نوینی بنویسم که نتیجه‌اش برای خودم هم جالب بود:

عنوان: آشنایی با متدهای چابک از دیدگاه یک توسعه‌دهنده
شرح: به عنوان یک توسعه‌دهنده می‌خواهم بدانم چابکی در توسعه‌ی نرم افزار چیست تا بتوانم در مورد به‌کارگیری آن تصمیم بگیرم یا از آن اثربخش‌تر استفاده نمایم

معیار پذیرش:
– بدانم که توسعه‌ی چابک به چه معناست (چشم‌ها را باید شست، رهیافت، تغییر رهیافت، کانه وین، تعریف چابکی، مدل کلان متدهای چابک)
– بیاموزم که متدهای چابک برای چه پروژه‌ها یا تیم‌هایی مفیدترند (آیا همه باید چابک باشند؟ تفاوت بین چابک بودن و چابک کار کردن چیست)
– بدانم به عنوان یک توسعه‌دهنده در یک تیم اسکرام، باید به چه نکاتی دقت کنم (برآورد، رفتار جمعی، آماده‌سازی بک لاگ، تابلوی اسپرینت، اسکرام روزانه، تعریف انجام‌شده، تعریف آماده، داستان، داستان کاربر، …)
– به عنوان یک توسعه‌دهنده، به چه تکنیک‌ها و مهارت‌های فنی نیاز دارم (بدهی فنی، سرآمدی فنی، برنامه‌نویسی دو نفره، یکپارچه‌سازی پی در پی، آزمون خودکار، …)

هدف اسپرینت (جلسه) یک: چابکی از دید یک توسعه‌دهنده
هدف اسپرینت دو: همکاری یک توسعه‌دهنده در یک تیم چابک
هدف اسپرینت سه: مهارت‌های فنی مناسب برای توسعه‌دهنده در تفکر توسعه‌ی چابک

جلسه‌ی اول:

جلسه‌ی اول تجربه‌ی جالبی برای من بود. برای اولین بار بود که داشتم یک سخنرانی از راه دور انجام می‌دادم. نکته دوم هم این بود که عزیزانی از شرق تا غرب کانادا و حتی اروپا هم در جلسه حضور داشتند که تجربه‌ی جدیدی برای من بود. نکته‌ی سوم هم این بود که من برخی از مطالب را با فرض “همان طور که می‌دانید” طراحی کرده بودم که در پایان متوجه‌ی نادرستی آن شدم. نکته‌ی جالب‌تر این بود که تعدادی از شاگردهای دوره‌هایی که در ایران برگزار کرده بود نیز در این جمع حضور داشتند.

طی جلسه‌ی کوتاهی که با آقا رضا و محمد آقا داشتم، به این نتیجه رسیدیم که باید طراحی دوره را از پایه بازنگری کنیم و به شکل دیگری پیش ببریم. مهم‌ترین عامل تغییر آن هم این موضوع بود که من با فرض “سه جلسه‌ی سخنرانی” به آن نگاه کرده بودم، ولی بازخوردها ما را به این نتیجه رساند که باید آن را به صورت “یک دوره‌ی آموزشی” پیش برد.

امروز ایمیلی از دانشکده دریافت کردم که نوشته بود قرار است نام دانشکده از “مهندسی برق و کامپیوتر” به “مهندسی برق و نرم افزار” تغییر پیدا کند.

The School is considering a proposal to change the name of the Department to “Electrical and Software Engineering” to recognize the strong growth of the Software Engineering programs.

برای گام نخست، حرکت مبارکی است؛ امیدوارم به زودی نام دانشکده به “مهندسی نرم افزار و برق” تغییر داده شود. 🙂 البته ایده‌آل این است که دانشکده “مهندسی نرم‌افزار” کلا مستقل گردد. امیدوارم تا پایان تحصیلم این اتفاق مهم روی دهد. 🙂 این‌ها برای شوخی و آمدن لبخند به لبان‌تان نوشتم. خیلی مهم نیست که اسم چه باشد، مهم رسم است! اما مهم‌ترین پیام این تغییر همان عبارت “strong growth” است که در متن ایمیل آمده است.

گزیده:
اگر شاعر می‌بودم احتمالا چنین شعری برای نرم‌افزار می‌گفتم؛ با اجازه استاد محمدرضا عبدالملکیان. جاهایی از شعر که تغییر یافته، پررنگ شده است.

من از دوردست ها آمده‌ام ،
از مزارع برنج،
از باغ‌های چایی،
و از سرزمینی که آسمانش تنها دو پیراهن دارد ;
روزها آبی می پوشد ٬
و شبها پیراهنی بلند
که تاب می خورد در رقص هزار و یک ستاره ی روشن . . .
…

باورم کن که نرم‌افزار در من طغیان یگانگی است ٬
و حماسه ی دوست داشتن،
من دیگر گونه دوست می دارم ٬
….

در چشم انداز هر کجای طبیعت
تو را می بینم !
در چشمه ، در رود
در دریا ، در گل
در درخت ، در جنگل
در دره ، در دشت
در کوه . . .

با اینهمه هنوز در تو حیرانم !
که تمامی عشقی در یک وجود ٬
و تمامی آرزویی در یک لباس . . .

Lex Fridman در سخنرانی خود در MIT به تاریخ 10 ژانویه 2020، از دیدگاه خود سه کتاب مطرح در زمینه‌ی یادگیری عمیق را به شرح زیر معرفی کرد.

• Deep Learning with Python, François Chollet, 2017, manning.com
• Deep Learning, Aaron Courville, Ian Goodfellow, and Yoshua Bengio, 2016, www.deeplearningbook.org
• Grokking Deep Learning, Andrew W. Trask, 2019, manning.com

Nearly 20 years after the publication of the first Scrum book, the product owner role is still riddled with misunderstandings. It’s not uncommon for me to meet someone who refers to her- or himself as a product owner, only to discover that the person owns a feature or the product details but not the entire product. Other times, I meet people who say they are product owners but who manage a whole product portfolio. This article helps you reflect on and improve the way the product owner role is applied at your workplace. It describes six common types of “product” owners. It shows how the roles differ and relate to each other, and it explains how you can effectively apply them.

Read more on the Roman Pichler site: Six Types of Product Owners

سایت Keras.io به تازگی تغییر کرده است و حاوی مطالب جدید و هدفمندی شده است. بخش نمونه کدها (Code Example) هم بسیار جالب است.