Choosing the Right Number of Leaves

خب حالا که مزایای موازی سازی رو متوجه شدیم، سوال اصلی اینه که چه تعداد نود برگ برای سیستم در نظر بگیریم، شاید در نگاه اول اینطور به نظر بیاد که هر چه تعداد نودهای برگ بیشتر بشه سریعتر میشه با درخواست ها پاسخ گفت، اما اینطور نیست...
باید در نظر داشته باشید که distribute کردن هر درخواست بین نودهای مختلف overheadهایی داره، مثل parse کردن درخواست های http و ارسال درخواست روی شبکه
همچنی یه مساله ای هست که به «straggler problem» معروفه. مساله چیه؟ در الگوی scatter/gather مدت زمان پاسخگویی به اندازه سرعت کندترین نود هست، پس اگه شما ۵ تا نود با حداکثر ۵ میلی ثانیه latency داشته باشید خیلی بهتره از داشتن ۱۰۰ تا نود با حداکثر ۲۰ میلی ثانیه latency. به این نکته توجه کنید که هر چه تعداد node ها بیشتر بشه احتمال اینکه یه نود با latency بالا وجود داشته باشه بیشتره..


#designing_distributed_systems_brendan_burns

@gocasts

بیاید با هم فکر کنیم مثلا چه use-case هایی میشه واسه این الگو پیدا کرد!

اگه بخوام مثالی بزنم که این الگو کارآمد باشه شاید بشه سیستم هایی که با نقشه سر و کار دارند رو مثال زد. چون تو این سیستم ها حجم داده ذاتا زیاده و در عین حال حجم محاسباتی که real-time هم باید صورت بگیره زیاده.
مثلا مسیریابی بین دو نقطه مبدا و مقصد رو در نظر بگیرید:
- حجم دیتایی که باید پردازش بشه که با در نظر گرفتن شرایط ترافیک و غیره بخواد مسیر بهینه رو به شما پیشنهاد بده خیلی زیاده.
- انجام محاسبات بین دو نقطه میانی (برای یافتن مسیر بهینه محلی) مستقل از شرایط نقاط دیگه است

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

البته من تجربه کار با چنین سرویس هایی رو نداشتم، و قطعا ملاحظات خیلی بیشتری در این سیستم ها باید در نظر گرفته بشه، اما فکر میکنم این الگو بتونه در حل چالش چنین مساله ای کمک کنه!


#designing_distributed_systems_brendan_burns

@gocasts

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

اینارو گفتم که امروز آقای Ian Lance Taylor رو به شما معرفی کنیم، ایشون از اوایل دهه ۹۰ میلادی روی gcc کار میکنه و کسی هست که gccgo رو از همون سال ۲۰۰۹ شروع کرده به ساختن.
اگه نمیدونید gccgo چی هست میشه gcc frontend for go language، که میشه کامپایلر غیر رسمی go روی gcc
در اینکه عملکرد gccgo بدتر از خود gc رسمی گولنگ هست شکی نیست، اما چون عملکرد gccgo بدتره دلیل نمیشه در موردش نخونید، با دنبال کردن مطالب و باگ و چالش هاش، کلی مطلب مفید در مورد زبان گولنگ و عملکرد کامپایلرها یاد میگیرد.

برای اطلاعات بیشتر در مورد gccgo میتونید لینک های زیر رو ببینید
https://gcc.gnu.org/onlinedocs/gccgo/
https://meltware.com/2019/01/16/gccgo-benchmarks-2019.html
https://stackoverflow.com/questions/25811445/what-are-the-primary-differences-between-gc-and-gccgo#:~:text=Compared%20to%20gc%2C%20gccgo%20is,the%20processors%20that%20GCC%20supports.

https://golang.org/doc/install/gccgo


در نهایت میخوام پست های آقای Ian Lance Taylor که در مورد golang هست رو به شما معرفی کنم، اکثر پست ها مربوط به سال های ۲۰۰۹ و ۲۰۱۰ هست و با خوندنش دید بهتری نسبت به go internal خواهید داشت قطعا.

Go
https://www.airs.com/blog/archives/273

Go Channels
https://www.airs.com/blog/archives/275

Go Interfaces
https://www.airs.com/blog/archives/277

Go Interface Values
https://www.airs.com/blog/archives/281

Go New/Make
https://www.airs.com/blog/archives/283

A GCC Frontend
https://www.airs.com/blog/archives/287

Generics
https://www.airs.com/blog/archives/291

Go Linkage Names
https://www.airs.com/blog/archives/309

Thread Sanitizer
https://www.airs.com/blog/archives/321

Signed or Unsinged
https://www.airs.com/blog/archives/327

Software Paradigms
https://www.airs.com/blog/archives/342

Container Models
https://www.airs.com/blog/archives/349

Destructors
https://www.airs.com/blog/archives/362

gccgo panic/recover
https://www.airs.com/blog/archives/376

GCC Summit
https://www.airs.com/blog/archives/435

Versioning
https://www.airs.com/blog/archives/442

Gccgo in GCC
https://www.airs.com/blog/archives/448

Race Conditions
https://www.airs.com/blog/archives/482

Go experience report: the append function
https://www.airs.com/blog/archives/559

#the_right_person
#golang #gcc
#go_internal

@gocasts

این ویدیو به زیبایی هر چه تمام تر انواع consistency model هارو توضیح میده، مخصوصا eventual consistency رو که در سیستم های توزیع شده خیلی استفاده میشه.
https://www.youtube.com/watch?v=Fm8iUFM2iWU&list=WL&index=6

آقای Chris Colohan بیش از ۱۰ سال در گوگل روی ساخت انواع سیستم های توزیع شده کار کردند و درسی رو به رایگان ارائه میدن به همین نام که میتونید مطالبش رو از این لینک دنبال کنید

http://www.distributedsystemscourse.com

@gocasts

سلام دوستان وقت بخیر
احتمالا اسم آقای Bill Kenedy به گوشتون خورده باشه، ایشون یکی از بهترین اساتیدی هستند که گولنگ رو آموزش میدن، اخیرا هم کتاب Ultimate GO رو منتشر کردن که مباحث خیلی پیشرفته ای رو در زمینه گولنگ پوشش میده.
احتمالا با برخی از مقالات خیلی خوبشون که تحت بلاگ Ardan labs هم منتشر میشه آشنا هستید.
قراره که ان شاءالله روز ۱۲ آبان ساعت ۱۸ و ۳۰ به وقت تهران یک meetup یک ساعته با ایشون داشته باشیم، خیلی خوشحال میشم اگه در کامنت های همین پست موضوعاتی که دوست دارید در جلسه پوشش داده بشه رو ذکر کنید.

https://twitter.com/goinggodotnet

https://www.ardanlabs.com/blog/

https://courses.ardanlabs.com

@gocasts

موضوع جلسه چی باشه؟

هدف اصلی من از این جلسه آشنایی ایشون با کامیونیتی ایرانه و فعالیت هایی که میشه تا یه موضوع خاص..
@gocasts

سلام دوستان
موضوعاتی که فعلا پیشنهاد شده که میتونه یک یا چند تا از این ها باشه بسته به مدت زمان بحث، این ها هستند:
- ویژگی های 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