سلام دوستان
موضوعاتی که فعلا پیشنهاد شده که میتونه یک یا چند تا از این ها باشه بسته به مدت زمان بحث، این ها هستند:
- ویژگی های cloud-native application و چرا گولنگ زبان مناسبیه
- تطبیق ویژگی های oop از زبان های قدیمی با گولنگ برای افرادی که از این زبان ها مهاجرت می کنند و مشکلات مرتبط
- بحث جنریک و نگرانی ها بابت generic pollution
- چه مباحثی مهم هستند برای اینکه تبدیل به یه go engineer بهتر بشیم
- ویژگی های یک microservice حرفه ای (چیزی که در دوره های آموزشی تبلیغ میشه توسط ایشون)

اگه در مورد این موضوعات نکته ای مد نظرتون هست حتما تو کامنت ها در موردش بحث کنیم

@gocasts

سلام وقت بخیر خدمت همه دوستان عزیز
ببخشید که یک هفته ای میشه مطلب فنی تو کانال نذاشتم، درگیر کارهای مرتبط با meetupمون با Bill Kennedy هستم، خیلی تلاش میکنم که همه چیز خوب پیش بره و ان شاءالله با کمک شما ها جلسه خیلی خوبی بشه که بتونیم این روند رو ادامه هم بدیم با افراد فعال و مطرح خارجی دیگه این حوزه
این نوید رو هم بدم که کلی مطلب خوب و باحال در مورد مباحث تکنیکال، از ادامه خلاصه کتاب ها گرفته، تا آموزش های ویدیویی فارسی گولنگی و خلاصه های صوتی فارسی فنی در مورد موضوعات مختلف برنامه نویسی مخصوصا مباحث دیتابیس و cloud native تو برنامه هست که ان شاءالله بعد از جلسه با بیل کندی خدمتتون ارائه میدم، امیدوارم که نوشته های این حقیر براتون مفید واقع بشه، بودنتنون انرژی خیلی مضاعفی بهم میده برای تولید کردن محتوای درجه یک و با کیفیت که خدمتتون ارائه بدم. دم همتون گرم ❤️

@gocasts

سلام دوستان، وقت بخیر، فردا، چهارشنبه ۱۲ آبان، ساعت ۱۸ و ۳۰ به وقت تهران منتظر شما هستیم 😍

https://www.twitch.tv/tehrantechtime

@gocasts

خب خب، جلسه نیم ساعت دیگه برگزار میشه، حین برگزاری جلسه، هر نکته و سوالی از بیل داشتید داخل کامنت همین پست یا در توییتر با این هشتگ مارو باخبر کنید که از بیل بپرسیم.
#TehranTechTimeQA

@gocasts

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

بقول دوستم over engineering کردیم، فکر کردیم ممکنه تعداد خیلی زیاد بشه تصمیم گرفتیم گوگل میت رو استریم کنیم در حالیکه باید همه رو دعوت میکردیم به گوگل میت، ازین بابت خیلی عذرخواهی میکنم و شرمنده ام😞😞
من ویدیو رو به زودی منتشر میکنم، ولی گویا اونم کیفیت خوبی نداره 🤦‍♂🤦‍♂
من به صورت تاپیک به تاپیک سعی میکنم اکثر صحبت هاشو به صورت متنی یا صوتی تو کانال بذارم که از محتوای جلسه با خبر باشید کامل

خب این از اولین جلسه tehrantechtime، میدونم که کم و کاست زیاد داشت، به بزرگواری خودتون ببخشید، ان شاءالله حتما سعی میکنیم در جلسات بعدی اگه ادامه داشت جبران کنیم.

برای اینکه از کیفیت تصویر کم نشه فرمت ویدیو HEVC/H.265 انتخاب شده، ممکنه با هر playerی باز نشه.
متاسفانه کیفیت صدا در فیلم ضبط شده هم خوب نیست، اما فکر میکنم بهتر از چیزی هست که داخل لایو بود، و احتمال زیاد بتونید گوش بدید.
اما به هرحال من قول میدم حتما حتما، تاپیک به تاپیک، سوال به سوال همه قسمت های جلسه رو به صورت voice داخل کانال منتشر کنم که در جریان همه صحبت های آقای بیل کندی قرار بگیرید.
ممنون از صبوری و همراهی تون
🌹
#tehrantechtime
#bill_kennedy

@gocasts

بحث با بیل رو از اینجا شروع کردم که گولنگ یه زبان بسیار جدیده، و حتی در ایران این زبان جدیدتر هم هست و به همین دلیل در ایران برنامه نویسان کمی هستند که به اندازه کافی تجربه کار با گولنگ را داشته باشند. همچنین به علت مهاجرت برنامه نویسان ایرانی به اروپا، این مشکل شدید تر بوده و برنامه نویسان junior فرصت کمتری برای کسب دانش از باتجربه ها دارن
سوال اولم این بود که تفاوت بین golang developer و golang engineer چیه؟

#bill_kennedy

@gocasts

بیل پاسخ داد که این یه موضوع خیلی گسترده است. بحث رو ازینجا شروع کرد که ما تعداد خیلی زیادی برنامه نویس در زبان هایی مثل java و c# و c++ داریم که خیلی از این ها میتونن بالقوه برنامه نویس گولنگ بشن و این کار رو برای متقاضیان junior که به دنبال کار هستند سخت میکنه و شما در ایران مشقت مضاعف دارید چون که دولت های ما تصمیم گرفتند با هم خوب نباشند و به علت تحریم ها، برنامه نویسان ایرانی با چالش های بیشتری برای پیدا کردن فرصت شغلی مناسب روبرو هستند.

در ادامه گفتن که اکثر فرصت های شغلی رو که نگاه کنید همه شرکت ها به دنبال «senior developer» هستند و من با تاکید این رو داخل qoute میذارم چون که خود من هم (bill) نمیتونم مصاحبه هاشونو پاس کنم!

بعدش گفت که من معتقدم که هر تیمی باید یک lead یا mentor داشته باشه و نقش این فرد نباید انجام دادن تسک های روزانه باشه و بیشتر درگیر code review و مسائل software design باید باشه.

نکته بعدی که بیل بهش اشاره کرد این بود که شما باید همیشه دو تا کلاه داشته باشید یه کلاه programming و یه کلاه engineering. کلاه programming یعنی اینکه شما بتونی کد بنویسی در حدی که کد کار بکنه و کار انجام بشه، در این مرحله احتیاجی نیست شما تمیز کد بنویسی یا idiom های گولنگ رو رعایت کنی، فقط کدی باید بنویسی که کار کنه، همین! من در استخدام آدمایی که لازم دارم فقط به این موضوع دقت میکنم که بتونن کد بزنن. در قدم بعدی این من هستم که بهشون engineering رو آموزش میدم. این نقشی هست که باید leader یا mentor داشته باشه، یعنی یک guideline و فلسفه مشخصی داشته باشه و بر اساس اون به تیم کمک کنه که مهندسی کنن. نکته دیگه ای که وجود داره اینه که حتما باید مساله و چالشی وجود داشته باشه که برای حل کردن اون چالش لازم به مهندسی باشه و از این طریقه که یه developer میتونه اصول مهندسی رو یاد بگیره. صرفا با خوندن material های متفاوت شما نمیتونی انتظار داشته باشی که شخص مهندس بشه، حتما باید چالش وجود داشته باشه. که خب یک راه حلی که پیشنهاد میشه اینه که حتما open source مشارکت کنید و سعی کنید چالش های پروژه های مربوط به شرکت های بزرگ رو حل کنید چون وقتی که برای این پروژه ها PR میفرستید، اونا کد شمارو review میکنن و کلی نکته باید و نبایدی در مورد کد به شما میگن که خیلی برای یادگیری اصول مهندسی به شما کمک میکنه.

#bill_kennedy

@gocasts

یه مثالی هم زد از اینکه تعریف کردن مسائل چالشی و حل اونها میتونه کلی نکات مهندسی به شما آموزش بده، مثلا میگفت برای یادگیری concurrency و کلی موضوع دیگه میشه یه سرویس چتی بنویسید که از پروتکل شخصی خودتون برای communication استفاده کنه نه http و نه grpc. اگه این کار رو بتونید انجام بدید خودش به اندازه کافی کلی چالش مهندسی داره و همینطور میشه چالش رو پیچیده تر کرد که نکات بیشتری رو یاد گرفت. مثلا من معتقدم اگه شما Message Bus احتیاج دارید و در محیط پروداکشن از Nats استفاده نمیکنید، احتمال زیاد دارید over engineering میکنید. اما برای یادگیری به شما میگم که برای سرویس چت خودتون یه message bus بنویسید. منظورم یه production ready messsage buse نیست، فقط یه message bus ساده باشه که functionality های اصلی رو داشته باشه. انجام دادن این پروژه خودش کلی نکات مهندسی و distributed system داره که برنامه نویس رو مجبور به یادگیری اون ها میکنه. این موضوع به شما کمک میکنه که خیلی خوب بفهمید nats چطوری کار میکنه و این طور تمرین هاست که به مرور زمان شمارو به یه senior engineer تبدیل میکنه

من ایده distributed chat رو خیلی دوست دارم و برای سال بعد میخوام دوره ultimate concurrency رو با این ایده ارائه بدم

#bill_kennedy

@gocasts

سوال بعدی که مطرح شد این بود که از نگاه یه teach lead که چندین engineer رو مدیریت میکنه و باید task هارو بهشون assign کنه یه چالشی که وجود داره اینه که بسیاری از این مهندسین از زبان های قدیمی تر php و c# میان و شما باید به عنوان tech lead هم به quality کد فکر کنی و هم به سرعت توسعه. شما به عنوان tech lead چطور میتونید بین سرعت توسعه و کیفیت کد تناسب ایجاد کنید؟

که بیل جواب داد هر کسی که به تیمش اضافه میشه هفته اول باید دوره های ultimate go و ultimate service رو ببینه که با idiom ها و فلسفه کد زدن تو شرکت بیل آشنا بشه
در مورد سرعت توسعه هم گفت که شما در هنگام plan کردن باید خیلی توجه کنید به مدت زمانی که یه برنامه نویس واقعا میتونه کد بنویسه و اینطوری نیست که بتونه تمام مدت ساعت کارشو کد بزنه و در طول هفته ممکنه نیروی به هر دلیلی حالش خوب نباشه و غیره. بنابراین باید کل ساعت کار هفتگی واقعی برنامه نویس رو باید در حد معقولی ببینی و طبق اون به مشتری تخمین تحویل feature هارو بدی

#bill_kennedy

@gocasts

سوال بعدی که مطرح شد این بود که نزدیک به یک دهه است که داریم با گولنگ محصول توسعه میدیم و حالا قراره generic اضافه بشه. به نظر شما generic چه تاثیری روی تجربه ما با گولنگ خواهد داشت؟

بیل پاسخ داد که من نمیخوام از جنریک استفاده کنم پس نمیتونم تجربه مو بگم!
بیل ادامه داد که جنریک یک انتخابه اما من پیشنهاد میکنم که اگه میخواید حتما با جنریک یه سری experiment داشته باشید اما برنامه ریزی نکنید که در کدهاتون ازش استفاده کنید. چون مدتی طول میکشه که best practice هاش مشخص بشه
جنریک یعنی polymorphism، و ما در لحظه با وجود interface در گولنگ polymorphism داریم، اما interface یک run-time polymorphism هست و generic یک compile-time polymorphism هست. احتمالا جایی که تو کد interface{} استفاده میکنید و از reflection استفاده میکنید، این قسمت ها جایی هست که generic باید استفاده بشه که این یعنی همون استفاده classic و درست از generic. در غیر از اینجاها من لزومی بر استفاده اش نمیبینم.
من هم در مورد جنریک هیجان زده هستم، اما اینکه بخوام در پروداکشن ازش استفاده کنم؟ خیر

#bill_kennedy

@gocasts

سوال بعدی این بود که دغدغه ای که وجود داره اینه که چون جنریک یک feature جدید هست و همه در موردش هیجان زده هستن امکان داره کد های زیادی در سطح پروداکشن دچار generic pollution بشن که خیلی میتونه بد باشه، چیکار کنیم که این اتفاق نیفته؟

گفت این به شما و تیم شما بستگی داره که نظم و قانون داشته باشید، شما نباید به دنبال طراحی کردن polymorphism باشید، شما باید polymorphism رو explore کنید. اگه شما و کل تیم به این نتیجه رسیدید که تنها راه حل این مساله استفاده از generic هست، خیلی خب پس استفاده اش کنید. جنریک رو یه ابزار ببینید و مثل هر ابزار دیگه ای مطمئن بشید که باید ازش در جای درست استفاده کنید.

#bill_kennedy

@gocasts

سوال بعدی که پرسیده شد اینه که بر اساس تجربه شما، رایج ترین مشکلی که در نرم افزارهای گولنگی وجود داره چیه؟

گفت از نظر من مشکلی که خیلی دیده میشه اینه که افراد برای پروژه هاشون یک solid project structure ندارن. این code structure باید بگونه ای باشه که guideline و فلسفه داشته باشه. من خیلی میگم که نباید پکیج هایی وجود داشته باشه مثل common یا پکیجی مثل types که کل پروژه داره ازش استفاده میکنه. این وابسته کردن پروژه به یک پکیج خاص میتونه باعث بشه که کل پروژه بایک تغییر در این پکیج به هم بریزه. و این چیزیه که من در دوره ultimate service درس میدم

#bill_kennedy

@gocasts

سوال بعدی این بود که clean architecture یا hexagonal architecture یه معماری خیلی محبوبه که در پروژه های گولنگی استفاده میشه، آیا شما فکر میکنید این معماری برای گولنگ best fit هست یا این در مقابل فلسفه شماست؟

جواب داد که دهه ۹۰ میلادی یک کتابی منتشر شد که الگوهای رایج oop رو نوشته بود (منظورش gang of four بود) و من چندین بار تلاش میکردم که چالش های پیش روی خودمو سعی کنم بایکی از الگوهای اون کتاب منطبق کنم که بتونم از راه حل هاش استفاده کنم. اما اصلا باهاش راحت نبودم و دیگه هیچوقت چنین کاری رو نکردم. من برای پروژه هایی که دارم سعی میکنم بر اساس دانش و تجربه خودم و حتی اگه لازم باشه از دانش تجربه دیگران کمک میگیرم و بر اساس این تجربه و دانش سعی می کنم پروژه رو با حداقل ترین چیزهایی که لازم داره طراحی کنم. این کاریه که در ultimate service هم کردم. و من همیشه میگم که complexity اضافه به پروژه اضافه نکنید در حالیکه پروژه اصلا اون رو نیاز نداره. اضافه کردن complexity باعث کند شدن توسعه پروژه میشه و ship کردن کد رو دچار اخلال میکنه.

#bill_kennedy

@gocasts

سوال بعدی این بود که تو پروژه هامون چه موقع باید یه چالشی رو داخل پروژه حل کنیم و به پروژه complexity اضافه کنیم (مثل cache کردن) و چه موقع باید از ابزارهای خارجی استفاده کنیم (مثل redis) و پروژه هامون رو بهشون وابسته کنیم؟

بیل پاسخ داد که این موضوع خیلی به این بستگی داره که واقعا چالش چیه و چقدر complexity به پروژه اضافه میکنه؟
مثلا من توصیه میکنم برای نسخه اولیه سرویس با ساده سازی اونو به پروژه (سرویس) خودم اضافه میکردم، بعد اگه لازم بود به سرویس اضافه بشه ولی اگه مدیریت اون پیچیدگی خیلی چالش و دغدغه داشته باشه خب باید از سرویس خارجی استفاده بشه. و البته بستگی داره که شما یه تیم کوچیک ۲، ۳ نفره هستید یا یک شرکت بزرگ با کلی نیروی مختلف در حوزه های مختلف

#bill_kennedy

@gocasts

سوال بعدی این بود که یادگیری concurrency تو گولنگ کار ساده ای نیست، هم به این دلیل که نسبت به زبان های رایج دیگه شیوه متفاوتی داره و هم اینکه در پروژه های تیپیکال هم خود کتابخونه و پکیج هایی که استفاده میکنیم این موضوع رو هندل میکنن و برنامه نویس کمتر میتونه خودش با concurrency سر و کله بزنه، برای اینکه concurrency رو در حد production بتونیم یادبگیریم باید چیکار کنیم؟

بیل پاسخ داد که اول باید مطمئن بشید که concurrency برای رفع مساله ای که پیش روتونه لازمه. مفهوم concurrency یعنی out of order execution، یعنی شما چند تا کار رو میخوای انجام بدی و مهم نیست ترتیب اجراشون چی باشه. این میشه concurrency. شما باید به دنبال چالش هایی باشی که out of order execution لازم داشته باشن، مثل همون سرویس distributed chat. یا مثلا من تو تمریناتم یه مثال barber shop دارم که برای آموزش concurrency ازش استفاده میکنم.
من سعی میکنم چالش رو بصورت single thread حل کنم که به اندازه کافی سخت خواهد بود، بعد اگر تونستم از مزیت concurrency بهره ببرم کد رو refactor میکنم. کلا multi thread programming خیلی سخته و من نمیگم که گولنگ اونو ساده کرده، من میگم گولنگ به ما ابزار میده، اگه ازش درست استفاده کنیم، به ما کمک میکنه، اگه درست استفاده نکنیم به پروژه مون complexity اضافه کردیم.
اتفاقی که خیلی میفتاد و تو خیلی از کدها همه جا از channel استفاده میشد و تو ریفکتور میدیدی که حذفش میکردن! اتفاقی که ممکنه برای جنریک هم بیفته

فکر کنم این باشه
https://github.com/ardanlabs/gotraining/blob/master/topics/go/algorithms/fun/barber/shop/shop.go

#bill_kennedy

@gocasts

سوال بعدی که پرسیدم این بود که شما گولنگ رو بیشتر یه زبان data oriented میدونید تا object oriented. چه ویژگی های گولنگ باعث شده که اینطور فکر کنید؟

که اولش این نقل رو از rob pike گفت
Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

بعدش گفت که اگه شما data رو نشناسی در واقع problem رو نمیشناسی و نمیتونی حلش کنی. چون هر کدی که ما مینویسیم و هر تابعی فقط داره data transformation میکنه.
یه نکته خیلی مهم برای senior بودن شما، اینه که data semantic های گولنگ رو بشناسی و بدونی از کدوم چه وقت استفاده کنی. این که value semantic که یه نسخه از دیتارو کپی میکنه در پروسه زنجیره فراخوانی توابع (function call chain) و pointer semantic که داره دیتارو به اشتراک میذاره چه تفاوت هایی با هم دارن. و من value semantic رو خیلی استفاده میکنم چون مزایای خیلی زیادی داره، هرجا که بتونم ازش استفاده میکنم.
https://users.ece.utexas.edu/~adnan/pike.html

#bill_kennedy

@gocasts

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

بنده هم این موضوع رو تایید میکنم واقعا بیل خیلی با روی باز جواب میده و اگه سوالی دارید میتونید ازش بپرسید و برای یادگیری گولنگ خیلی میتونه کمکتون کنه

#bill_kennedy

@gocasts

توضیحاتی در مورد جلسه با بیل کندی
اون repository ی که گفتم
https://github.com/ardanlabs/gotraining/blob/master/topics/go/README.md

پادکستی که اشاره شد
https://changelog.com/gotime/172

دوره آموزشی که ازش نام بردم
https://courses.ardanlabs.com/courses/ultimate-service-3-0

#bill_kennedy

@gocasts

سلام به همه دوستان
امروز میخوام کمی در مورد این صحبت کنم که چطور کیفیت کار خودتون و محصولی که دارید توسعه میدید رو ارزیابی کنید.

مورد توجه استارت آپ ها، مدیرهای محصول و بچه های فنی

The four engineering metrics that will streamline your software delivery

در طول مدت این چند سالی که خدا توفیق داده تو استارت آپ ها و شرکت های مختلف نقش کوچیکی تو توسعه محصول نرم افزاری داشتم، همیشه این نکته برام سوال بود که با چه معیار و metricی میشه عملکرد تیم رو سنجید. احتمالا معیارهای خیلی زیاد و متفاوتی وجود داره. اما من معیارهایی که تو این مقاله ذکر شده رو خیلی دوست دارم و درست میدونم از این لحاظ که هدف رو توسعه محصول در نظر گرفته نه کیفیت فنی محصول یا چیز دیگه.

این مقاله نسبتا کوتاه رو میتونید از اینجا بخونید
https://stackoverflow.blog/2021/11/29/the-four-engineering-metrics-that-will-streamline-your-software-delivery


Deployment frequency
با چه فراوانی ای نسخه جدید روی پروداکشن میره. این مورد خیلی بستگی داره که محصول شما تو چه استیجی هست. اما اگه لانچ کردید، احتمالا هفته ای یک یا چند دیپلویمنت باید داشته باشید، اگه بیشتر از یک هفته طول میکشه احتمالا یه جای کار داره میلنگه!

Mean change lead time
چقدر طول میکشه از زمانی که کد commit میشه تا اینکه روی پروداکشن اجرا بشه. این موضوع بیشتر سرعت تیم فنی رو نشون میده و همچنین اینکه شما چقدر به پروسه ci/cd تو پروژه تون اهمیت میدید.

Mean time to recovery
چقدر طول میکشه از یه bugی که گزارش میشه هر failure دیگه ای recover بشه سیستم. این موضوع بیشتر استراتژی های failure recovery رو هدف قرار میده و یه نکته پنهان هم داره، اینکه شما چقدر observability و monitoring براتون مهمه. چون software خوب اونیه که observability بالایی داشته باشه. یکی از نکاتی که observability خیلی کمک میکنه همینه که شما سریعتر باگ و مشکل رو پیدا کنید و فیکس کنید.

Change failure rate
با چه نرخی release های جدید باعث ایجاد failure میشه. این هم طبیعتا کیفیت فنی محصول رو میرسونه، چقدر محصول reliable هست. این معیار یکی از اون معیارهایی ست که نه تنها کیفیت محصول بلکه کیفیت فنی اعضای توسعه دهنده رو هم بازگو میکنه. هر چقدر تیم شما با تجربه تر باشه، معماری درستی رو انتخاب کرده باشه و تلاش زیادی برای پیاده سازی و تست محصول کرده باشه این نرخ باید کمتر باشه.

البته کاملا متوجه هستم که محصولات نرم افزاری ذاتا خیلی متنوع هستن و بسته به اندازه تیم و بیزینس می‌تونه معیارهای خیلی متفاوتی وجود داشته باشه. اما من این معیار ها رو معیارهای خیلی خوب و درستی برای تیم های استارت آپی میبینم.
حتی شما به عنوان برنامه نویس میتونید با این معیارها کیفیت کار خودتون رو هم بسنجید که محصولی که تولید کردید چه نمره ای داره.

صبحتون بخیر و دمتون گرم 🌹

#software_delivery #engineering_metrics

@gocasts