یه مقاله بسیار کوتاه و جالب خوندم که یه مورد از soft skill هارو نقد و بررسی میکنه. و اونم نحوه برنامه ریزی و مدیریت زمان و جزییات task هاست. یکی از چیزایی که تو هر پروژه خیلی مهمه اینه که همه افراد تیم نسبت به هدف و محصول نهایی vision و دیدگاه کامل داشته باشن. مشکلی که خودم باهاش بارها برخورد کردم و به دفعات دیدم که همین مشکل باعث میشه افراد تیم به خاطر نداشتن دید کافی نسبت به هدف محصول و اولویت ها، deadline هارو miss کردن و توسعه و launch محصول حتی تا چند ماه عقب افتاده.

مقاله میگه برای پروژه ها باید Hard Edge داشته باشید و Soft Middle.
خب این یعنی چی؟ یعنی اینکه وقتی برای release یه featureی از محصول برنامه ریزی می کنید. یه deadline خیلی سفت و سخت بذارید، مثلا ۶ هفته و خیلی شفاف و کامل هم به همه افراد تیم منتقل کنید که انتظارتون از feature و ویژگی هاش چیه. ولی به افراد تیم اجازه بدید خودشون برای این ۶ هفته برنامه ریزی کنن. مثلا اگه قراره یه featureی زده بشه که احتیاج به یک یا چند third-party library داره، شما در مورد جزییات تعیین تکلیف نکنید که پیاده سازی فلان کتابخانه باید ۱ هفته ای تمام بشه، بعد هفته بعد باید فلان بشه و غیره..

ایرادی که خودم بارها دیدم اتفاق افتاده اینه که برای دید کوتاه مدت مثلا sprint های ۲ هفته ای، تیم ها برنامه خیلی مفصل و دقیقی میچینن با یه لیست کامل از کارهای ریز و درشتی که باید انجام بشه. اما هیچ وقت vision درست و کاملی به تیم نمیدن که هدف از همه این اسپرینت ها و task ها اینه که مثلا ۲ ماه دیگه یه محصول با فلان ویژگی ship بشه.

بهتره سعی کنیم ددلاین های خیلی سفت و سخت روی خروجی نهایی داشته باشیم. اما اجازه بدیم افراد، خودشون برای جزییات و task هاشون برنامه ریزی کنن. یکی از لازمه های رخ دادن چنین اتفاقی وجود داشتن trust بین همه افراد تیم هست که اتفاقا خیلی نکته مهمیه.

اگه بین افراد تیم trust وجود داشته باشه افراد متعهد خودشون میدونن که با چه ددلاینی چه چیزی رو باید تحویل بدن، ممکنه اون فرد بخواد ۴ تا کتابخونه دیگه رو هم تست کنه یا نکنه، این به خودش بستگی داره.

پیشنهاد میکنم حتما بخونید

https://www.colemanm.org/post/hard-edges-soft-middle


#soft_skills

@gocasts

Fallacy #1 - Network is Reliable!

سلام دوستان، اگه فکر میکنید که دونستن الگوهای distributed system ها به کار شما ارتباطی نداره بد نیست این ویدیو رو ببینید.
الگوی ارتباطی request/response یه الگوی خیلی رایج و شایع هست که خیلی از ما ها در بسیاری از پروژه هامون ازش استفاده میکنیم. با استفاده از retry pattern شما میتونید خیلی از مشکلات مرتبط با این الگو رو تا حدود زیادی مرتفع کنید.

این لینک ویدیو

https://youtu.be/gUeAzDokznQ

این لینک مقاله
https://gocasts.ir/go-retry-pattern?utm_source=telegram&utm_medium=message&utm_campaign=3

#distributedsystems #golang #retry_pattern

@gocasts

اگه در مورد سیستم های توزیع شده بیشتر میخواید بدونید بهتون یه دوره ۱۵۰۰ دلاری معرفی می کنم که برای ۹۰ روز رایگانه


این نمونه ویدیو که مرتبطه با ویدیویی که قرار دادم

https://www.youtube.com/watch?v=8fRzZtJ_SLk



اینم لینک دوره

Distributed Systems Design Fundamentals

https://learn.particular.net/courses/distributed-systems-design-fundamentals-online



#distributedsystems

@gocasts

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

موضوع جلسه چی باشه؟ موضوع جلسه میتونه هر هفته یک موضوع خاص در مورد گولنگ، مهندسی نرم افزار، یا حتی مرور و تحلیل یک کتاب، یک دوره ویدیویی و یا یک talk باشه. بعضی جلسات هم ممکنه جنبه آموزشی و live coding داشته باشه.

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

@gocasts

سلام دوستان، ببخشید که این چند وقت کانال آپدیت نشده. درگیر امیکرون هستم. ان شاءالله بعد از بهبودی با قدرت در خدمتم. امیکرون از چیزی که فکر میکنید به شما نزدیکتره، مواظب خودتون باشید ❤️❤️

معرفی دو تا کتاب

یکی از اشتباهاتی که خودم داشتم و متاسفانه میبینم اکثر برنامه نویس های جوان هم دچارش هستند، اینه که تمایل داریم تو یه مدت کوتاهی با انواع ابزارها و تکنولوژی ها تجربه کسب کنیم. این موضوع باعث میشه بعد از چند سال که به عقب برگردیم میبینیم که رزومه ای دارم «پر از تهی». یعنی وقتی نگاه میکنی میبینی که آره با پنج تا دیتابیس مختلف پروژه انجام دادی، اما حتی یکیش رو هم عمیق یاد نگرفتی. و این آسیب نه فقط در مورد دیتابیس، در مورد بقیه ابزارها و تکنولوژی ها هم هست. یه سری آدم ها مثل خود من در قدیم هم «ایده آل گرا» هستن، یعنی دوست دارن همه چیز رو عمیق یاد بگیرن، که با توجه به گستردگی موضوعات و عمر کوتاه انسان، این مورد هم منجر به همون دانش سطحی از همه چیز میشه که خیلی کمک کننده نیست.
کتابی که در حال حاضر مطالعه می کنم Designing Data-Intensive Applications هست که دانش عمیقی بصورت جنرال نسبت به Data store ها و data structure های رایج استفاده شده در دیتابیس ها میده. همچنین چون خودم بیشتر با دیتابیس mysql سر و کله میزنم قصد دارم این کتاب رو بخونم.
High Performance MySQL, 4th Edition

به شما قول میدم اگه فقط در یک استک (هر قسمتی فقط یک ابزار) تخصص داشته باشید فرصت های شغلی طلایی به سراغ شما میان. اینقدر اصطلاحا به دنبال buzzword ها نباشید. لازم نیست rest و grpc و thrift رو با هم بلد باشید. یا mysql و postgres و cassandra رو کار کرده باشید.
من نمیگم تجربه شون نکنید، ولی فقط یکی شون رو انتخاب کنید به عنوان هدف و تلاش کنید همون رو مسلط بشید. اونوقته که سنیور میشید، دانش سطحی از همه چیز شمارو سنیور نمیکنه. دانش عمیق از یه پکیج کوچیک راه درست تریه 🌹

در کامنت ها محمد جان @ilbeygi_m به نکته خیلی خوبی اشاره کرد. دوستان مطمئن باشید هیچ جادویی در مورد یادگیری عمیق وجود نداره، من برای آشنایی اولیه یا به اصطلاح hands-on شدن همیشه پیشنهاد میکنم ویدیو ببینید، اما در مورد عمیق شدن خیر. کتاب نتیجه چند سال تلاش و تجربه یک نویسنده است که سعی میکنه بصورت پله پله و عمیق همه چیز رو یاد بده، اما دوره های ویدیویی عموما برای یادگیری سطحی ساخته میشن. دلیل هم داره، دلیلشون مخاطب بیشتره. معمولا آموزش های عمیق مخاطبان خیلی کمتری دارن. به همین دلیله که آموزش های ویدیویی عموما به آموزش مباحث اولیه بیشتر میپردازن که من برای شروع پیشنهادشون میکنم ولی برای عمیق شدن خیر.

#designing_data_intensive_applications

#high_performance_mysql

@gocasts

چرا انتخاب uuid به عنوان primary key میتونه به شدت performance دیتابیس شمارو تحت تاثیر قرار بده؟

نمیتونم بگم این ویدیو چقدر دید خوبی میده به ما که چطور با دیتابیس برخورد کنیم. وقتی که دانش کافی و شناخت کافی از دیتابیس نداریم، خیلی تصمیمات اشتباهی میگیریم که در ابتدای راه خودشو بروز نمیده، حتی اگه هیچوقت scale نکنه اپلیکیشن ما شاید هیچوقت متوجه اشتباهمون نشیم. اما روی scale همه چیز متفاوته.
من تو بعضی از پروژه هام uuid رو به عنوان primary key در نظر میگرفتم. با دیدن این ویدیو به همین سادگی متوجه شدم چقدر این تصمیم اشتباهه، با این تصمیم چقدر دارم دیتابیس رو اذیت می کنم 🙂

خلاصه مطلب رو بخوام بگم اینه که هر دیتابیسی برای خودش یه بلاک کوچیک دیتا به اسم page داره و براش یه default page size داره، که همه read و write ها از طریق این page ها صورت میگیره. مثلا در postgres هر page بصورت پیشفرض ۸ کیلوبایت هست و در mysql هر page بصورت پیشفرض ۱۶ کیلوبایت هست. دیتابیس ها یه چیزی دارن به اسم buffer pool که اینpage هارو وقتی از disk میخونن در memory کش میکنن که بتونن عملکرد خوبی داشته باشن. خب قضیه از اینجا شروع میشه که اگه physical disk شما مثلا ssd باشه، خود ssd قاعده و قانون خودشو داره، در ssd هم ما block storage داریم یا همون page ولی اونجا page ها مثلا ۴ کیلوبایتی هستن، پس عملا هر وقت یه دیتابیس بخواد یه page خودشو روی disk بریزه داره بیشتر از یه عملیات io انجام میده و حتی یه سری کارهای بیشتر مثل shuffling و مپ کردن lba یا همون logical blcok address.

خب تا اینجا مشخص شد که دیتابیس ها برای write کردن دیتاشون روی disk به اندازه کافی دردسر دارن.
حالا بریم سراغ index های دیتابیس، که خود این ایندکس ها دارن توی یه سری page ذخیره میشن. اگه دیتای ایندکس مرتب شده نبود (که هست) کار دیتابیس ساده بود، همینطوری دیتای جدید رو پشت سر هم توی page ذخیره میکرد، تا جایی که به انتهای page میرسید و یه page جدید ایجاد میکرد.

ولی الان مساله اینه که ایندکس ها اساسا یه سری دیتای مرتب شده هستن و order مهمه. بنابراین اگه دیتای جدیدی که قراره ذخیره بشه قرار باشه وسط یه سری دیتای ایندکس شده ذخیره بشه، ما مجبور هستیم اون وسط یه جای خالی ایجاد کنیم و دیتای جدید رو ایندکس کنیم.
خب این کار باز تا وقتی که page ما به اندازه کافی جا برای ذخیره کردن همه رکوردها داشته باشه اوکیه. اما وقتی که به جایی میرسیم که page پر شده و قراره یه رکورد جدید رو وسط ایندکس های قدیمی قرار بدیم، مجبور میشیم page splitting انجام بدیم. فرض کنید میخوایم ایندکس ۴ رو به عنوان یه رکورد جدید تو pageی ایندکس کنیم که دیتای ۱ تا ۳ و ۵ تا ۱۰ رو داره. دیتابیس مجبور میشه یه page جدید بسازه و مثلا دیتای ۱ تا ۷ رو تو page قدیم و دیتای ۷ تا ۱۰ رو در page جدید ذخیره کنه.
اینو هم اشاره کنم که دیتابیس ها معمولا این کار رو نمیکنن، چون خیلی cost داره، اونا یه حرکت خیلی ساده تر میزنن، میگن اوکی، حالا که قراره ایندکس ۴ بیاد، و page جا نداره، ما یه page جدید میسازیم که ایندکس ۵ تا ۱۰ رو ذخیره کنه و یه page قدیمی هم دیتای ۱ تا ۴ رو ذخیره کنه. یه مساله ای که اینجا پیش میاد اینه که اینجا ما ۲ تا page داریم که هرکدومشون کلی فضای خالی دارن، و شما روی تعداد زیاد دیتا و ایندکس ببینید که چه تعداد page ایندکسی خواهید داشت که split شده هستن و کلی فضای خالی تو هر page وجود داره.
به این اتفاق میگن index fragmentation که ایندکس شما مدام شکسته میشه بین یه سری page. این fragmentation کجا شمارو دچار مشکل میکنه؟ وقتی که میخواید کوئری بزنید، اگه قبلا دیتابیس مجبور بود دیتای یه page رو بخونه برای کوئری شما الان مجبوره دو تا page رو بخونه و اصطلاحا ۲ تا logical io انجام بده. اینم در نظر بگیرید که این ۲ تا logical io با توجه به ساختار مثلا ssd عملا خیلی بیشتر از ۲ تا io هست، چون هر page دیتابیس خودش میتونه روی چندین بلاک ssd جداگانه ذخیره بشه و باید سمت ssd کلی کار انجام بشه که این ۲ تا logical io کامل بشه.

به همین دلیله که دیتابیس ها یه کانفیگی برای page هاشون دارن به اسم fillfactor که شما میتونی تنظیم کنی مثلا تا ۸۰ درصد هر page استفاده بشه و ۲۰ درصد بمونه برای ایندکس های جدید که splitting تا حدودی مدیریت بشه. تنظیم این fillfactor با توجه به نوع دیتای شما خیلی میتونه روی performance تاثیر بذاره.

#database #index #sql #uuid #hussein_nasser

@gocasts

حالا فاجعه uuid به عنوان primary key کجا اتفاق میفته؟ خب uuid عملا random هست و هیچ ترتیب خاصی نداره و وقتی دیتابیس بخواد از uuid به عنوان ایندکس استفاده کنه، چون نمیتونه به این راحتی ها ترتیب کلیدهارو حدس بزنه، مجبور میشه یه تعداد خیلی زیادی page بسازه، در واقع به زبان ساده تر احتمال اینکه رکورد جدید شما بخواد در همان page قبلی ایندکس بشه صفره! و این یعنی اینکه pageی که کش شده به کار نمیاد و باید page دیگه ای کش بشه!!

How index page splits affect SQL performance | The Backend Engineering Show
https://www.youtube.com/watch?v=fnR215jy-X8


ضمنا برام جالب شد فرصت کنم این دوره ش رو ببینم
Fundamentals of Database Engineering
Learn ACID, Indexing, Partitioning, Sharding, Concurrency control, Replication, DB Engines, Best Practices and More!

https://www.udemy.com/course/database-engines-crash-course


#database #index #sql #uuid #hussein_nasser

@gocasts

سلام صبح اول هفته همه دوستان بخیر
طبق نتیجه نظرسنجی ان شاءالله جلسات هفتگی رو برقرار می کنیم. البته هنوز قطعی نیست که هر هفته باشه، ممکنه که ۲ هفته یکبار برگزار بشه، بستگی به کیفیت جلسات داره.
حالا برای شروع به لطف خدا این هفته دوشنبه ۱۸ بهمن ساعت ۱۹ اولین جلسه رو برگزار می کنیم.
در مورد موضوع جلسه لطفا هر پیشنهادی دارید تا آخر امروز تو کامنت ها بگید، و من امشب سعی می کنم موضوع جلسه رو قطعی کنم.

امیدوارم هفته خیلی خوبی پیش رو داشته باشید

دوستان گفتن در مورد clean code و software architecture باشه جلسه اول، من سعی می کنم در این مورد تو جلسه اول توضیحاتی بدم و اینکه جلسه اول یه جلسه آشنایی باشه با دوستان، همدیگه رو بیشتر بشناسیم و ببینیم برنامه ریزی موضوعی جلسات چطور باشه
ان شاء الله دوشنبه ساعت ۱۹ منتظرتون هستم 🌹

سلام وقت همگی بخیر
جلسه فردا در گوگل میت برگزار میشه.
چون گوگل میت محدودیت ۶۰ دقیقه داره، سعی می کنیم راس ساعت ۱۹ شروع کنیم و راس ساعت ۲۰ جلسه رو تموم کنیم.
امیدوارم که برای همه مون یه شروع خوب باشه ان شاءالله

اینم لینک جلسه
https://meet.google.com/axo-xhmz-qfw

#meeting

@gocasts

دوستان، جلسه شروع شد، ما ۵ دقیقه منتظر بقیه دوستان میمونیم

دوستان، ممنون از اینکه تشریف آوردید، خیلی لطف کردید، ان شاءالله که بتونیم جلسات بعد هم کار رو بخوبی پیش ببریم.

خیلی خیلی ممنون محمد جان بابت فیدبک سازنده ت، ان شاء الله سعی میکنم تا جایی که در توانم هست برطرف کنم. منتظرم بقیه دوستان هم انتقادات سازنده شون رو ارائه بدن که ان شاء الله خیلی بهتر پیش بریم.

بازم تاکید می کنم که ان شاء الله ظرف چند روز آینده فیلم جلسه منتشر میشه، امیدوارم که مفید باشه 🌹

@bugoverflow

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

https://www.youtube.com/watch?v=F0Wufb50wYY

اگه حوصله تماشای فیلم رو ندارید، من سعی کردم خیلی خلاصه نکات مهم جلسه رو تو این مقاله بگم، میتونید بخونید
https://gocasts.ir/software-architecture?utm_source=telegram&utm_medium=message&utm_campaign=5

#software_architecture

@gocasts

در جلسه دوم فردا شب، ۲۵ بهمن ساعت ۱۹، ان شاء الله سعی میکنیم یک بیزینس رو انتخاب کنیم و سعی کنیم یه سرویس Rest بنویسیم با در نظر گرفتن معیارهای معماری خوب، از clean architecture هم برای پیاده سازی کمک میگیریم.

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

#gocasts_weekly

@gocasts

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

خوبه که حتما قبل از جلسه کد رو مطالعه کنید.

https://github.com/gocastsian/adamak

#gocasts_weekly
#clean_architecture

@gocasts

سلام به همه دوستان
اینم لینک جلسه

من تا ۱۹ و ۵ دقیقه منتظر میمونم و بعد شروع میکنم

meet.google.com/nes-xrrj-ucn

مرسی از همه دوستانی که تشریف آوردند، جلسه خیلی خوب بود، منظورم ارائه من نیست، مشارکت بچه هاست که از تجربه هاشون گفتن
من پروژه رو با معیارهایی که مد نظرم هست ریفکتور میکنم و بعدش دوستان میتونن روش PR بزنن

ان شاءالله سعی می کنیم با قدرت بیشتر پیش بریم

خیلی ممنون از حضورتون

سلام به همه دوستان عزیز
عیدتون مبارک
ولادت امام علی علیه السلام، اسوه مردانگی و پهلوانی و مروت، پدر یتیمان عالم مبارک 🌹

ویدیو ضبط شده جلسه دوم رو به لطف خدا آپلود کردم.

من یه اصلاحیه بدم یا بهتره بگم شفاف سازی کنم که منظور از Interface Adapters خود interface ها نیست، بلکه adapter هایی هست که interface هارو پیاده سازی میکنه
و اون لایه frameworks و drivers هم میشه اون driver و framework هایی که اون adapter ها استفاده میکنن در پیاده سازیشون
مثلا dbRepo میشه interface adapter (لایه ۳) و gorm میشه اون framework (لایه ۴)
همانطور هم که uncle bob میگه ما معمولا کد زیادی در لایه ۴ نمینویسیم و بیشتر استفاده کننده هستیم

اینم لینک جلسه
https://www.youtube.com/watch?v=sHQIk17A-Tg

ان شاء الله سعی میکنم تا جمعه ریفکتور کنم و خبرتون کنم، بعدش منتظر سوال و فیدبک و pr هاتون هستم برای جلسه بعد

#gocasts_weekly

@gocasts