توضیحی در مورد مدل قیمت گذاری FaaS
در FaaS مدل پرداخت per-request هست و اگه شما در دقیقه یا ساعت درخواست های کمی دارید این مدل خیلی بهتر از اینه که شما همیشه یه container داشته باشید که مجبور باشید به خاطر idle-timeش هم هزینه بدید. اما کم کم که تعداد درخواست ها زیاد میشه سرویس FaaS شما عملا همیشه در حال اجراست و اینجاست که دیگه مدل per-request خیلی هزینه بر میشه و داشتن یه container که همیشه در حال اجراست و به درخواست ها جواب میده راه حل بهتریه.

یه ایده جایگزین اینه که شما open-source FaaS رو روی Kubernetes اجرا کنید، اینطوری عملا هزینه virtual machine رو میپردازید ولی از مزایای FaaS هم بهره مند میشید.

#faas

#designing_distributed_systems_brendan_burns

@gocasts

الگوهای FaaS

The Decorator Pattern: Request or Response Transformation
الگوی decorator در زبان python شباهت زیادی به این الگو دارد. چون که decorator معمولا stateless هستند و معمولا بعد از نوشته شدن کد اصلی اضافه میشن.
مثال خیلی روشنش وقتیه که شما میخواید یه سری فیلد ها به request یا response سرویس تون اضافه کنید، اونجا FaaS میتونه خیلی کمک کننده باشه. همچنین به خاطر سادگی FaaS شما میتونید انواع مختلفی از decorator هارو روی سرویس تون تست کنید بدون اینکه سرویس اصلی تون دست بخوره و فقط اون هایی که رفتار مورد نظرتون رو دارن حفظ کنید یا حتی منتقلشون کنید داخل سرویس اصلی.

در الگوهای گذشته یه الگوی adapter داشتیم که به صورت یه container در جلوی container اصلی قرار میگرفت و همین کار رو میکرد. خب مشکل adapter اینه که شما مجبور هستید به همان میزان که سرویس اصلی قراره scale پیدا کنه adapter container رو هم scale بدید در حالیکه خیلی از عملیات ها مثل request transformation عملیات های سبکی هستند و نیازی به scale بالا ندارند، پس FaaS اینجا میتونه خیلی کمک کننده باشه.

#faas

#designing_distributed_systems_brendan_burns

@gocasts

Handling Event

بیشتر سیستم ها request driven هستند که یه حجم قابل توجهی از api request های کاربر رو handle میکنن. یک بخش دیگری از سیستم ها event driven هستند. تفاوت event و request در اینه که معمولا request جزئی از یک مجموعه تعامل (interaction) یا session هست. معمولا هر درخواست کاربر یک جزیی از تعامل کاربر با وب اپلیکیشن هست. در طرف مقابل event ها معمولا single-instance و asynchronous هستند. معمولا event ها مهم هستند و باید اجرا بشن اما نکته ای که وجود داره اینه که معمولا event ها در زنجیره اصلی تعامل نیستند و با ناهمگامی زمانی هم میشه اجراشون کرد. مثلا ارسال ایمیل خوش آمدگویی به کاربران جدید یه event هست که کامل مستقل از تعامل اصلی کاربر با سیستم هست. به همچنین ارسال notification برای کاربران.

به دلیل ذات مستقل بودن و stateless بودن event ها و همچنین با در نظر گرفتن این نکته که نرخ اتفاق افتادن event ها میتونه خیلی متغیر باشه، معماری FaaS یه گزینه خیلی ایده آل برای سیستم های event driven هستند.
همچنین eventهای جدید بصورت dynamic به سرویس اضافه میشن و به خاطر lightweight بودن deployment توابع، FaaS میتونه گزینه ایده آلی برای اضافه کردن event handler ها برای سرویس ها باشه. علاوه بر این به خاطر مستقل بودن توابع، باعث میشه پیچیدگی سیستم کم بشه و developer فقط روی کارهایی که برای رسیدگی به یه single event داره تمرکز کنه نه چیز دیگه ای.

یه مثال مناسب برای event ها میتونه two-factor authentication باشه، جای اینکه سرویس اصلی مجبور به generate کردن کد بشه و اونو بخواد برای کاربر پیامک کنه، سرویس اصلی فقط کافیه یک web-hook request به FaaS بفرسته، و FaaS میتونه خودش پس از جنریت کردن کد برای کاربر ارسالش کنه.

#faas

#designing_distributed_systems_brendan_burns

@gocasts

Event-Based Pipeline
دسته ای از application ها وجود دارن که بهتره اونارو بصورت یه pipelineی از decoupled event ها ببینیم. در الگوی event pipeline هر node یک function یا webhook هست و ارتباط این نودها از طریق network و http request هست. هیچ shared stateی بین نودها وجود نداره البته از context یا reference point های مشابه میشه استفاده کرد اگه لازم باشه informationی بین node ها share بشه.

سوالی که ممکنه پیش بیاد اینه که تفاوت event pipeline با microservice architecture چیه؟
دو تا تفاوت اصلی وجود داره. تفاوت اول، تفاوت ماهیت function و long-running service هاست. معماری event-base pipeline ذاتا event driven هست اما microservice ها معمولا مجموعه ای از چند long-running service هستند.
تفاوت دوم در asynchronous بودن event-base pipeline و همچنین تنوع event هایی هست که میتونن با هم تشکیل یک pipeline رو بدن، بر عکس microservice که معمولا سرویس هایی زیرمجموعه دارای اشتراکات زیادی هستن.

#faas

#designing_distributed_systems_brendan_burns

@gocasts

تجربه شخصی از FaaS
ما یه سرویس link preview داشتیم که روی کلاستر aws اجرا میشد و وظیفه اش این بود که برای پیام های جدید کاربران که حاوی لینک بود بره از لینک مورد نظر یه open-graph data بگیره، یا اگه لینک مربوط به social network ها بود به شیوه خاص خودش لینک رو scrape کنه و دیتای مورد نیاز رو جمع کنه. ضمنا دیتا رو باید تو دیتابیس ذخیره میکرد که دفعات بعد از دیتابیس دیتارو لود کنه.
یه مشکل دیگه هم که بود این بود که سایت های پربازدید معمولا درخواست های از مبدا سرورهای aws رو block میکنن. به همین دلیل مجبور بودیم یه سری http proxy همیشه توی دیتابیس آپدیت کنیم که از طریق اون درخواست ها ارسال بشه.
نرخ تعداد درخواست های link preview هم خیلی متغیر بود گاها خیلی کم بود گاهی هم پیش میومد زیاد باشه.
با این راه حل ما هم داشتیم هزینه containerی که همیشه این سرویس رو up نگه میداشت رو میدادیم هم هزینه دیتابیس میدادیم (از rds آمازون استفاده میکردیم) و هم مشکل proxy رو باید حل میکردیم.

راه حل جایگزینی که دوستم ارائه داد این بود که یه تابع ساده پایتونی نوشت که یه لینک میگرفت و دیتای مورد نیاز رو scrape میکرد و پاسخ رو پس میداد. این تابع رو بصورت FaaS رو اگه اشتباه نکنم روی Heroku بالا آورد (که ۱ میلیون درخواست اولش رایگان بود...). نیاز به storage هم نداشت چون سرویس پشت cache system بود (فکر کنم cloudfront) و فقط درخواست هایی که حاوی لینک جدید بودن function رو اجرا میکردن (تو معماری قبلی سرویس همیشه در حال اجرا بود و کلی resource مصرف میکرد)، بقیه رو خود cache جواب میداد. مشکل proxy هم دیگه نداشتیم.
عملا هم کلی هزینه کم شد، و هم کد و معماری ساده تر شد.

در انتها هم شاید بد نباشه پروژه OpenFaaS رو یه نگاهی بندازید.
https://github.com/openfaas/faas
https://www.openfaas.com

این پادکست هم شاید شنیدنش بد نباشه.
https://ardanlabs.buzzsprout.com/1466944/9750624-finding-a-model-for-open-source-with-alex-ellis

این کتاب هم من خیلی دوست دارم داشته باشم اگه گیر آوردید به منم بدید 🙂
Serverless for Everyone Else

https://openfaas.gumroad.com/l/serverless-for-everyone-else


#faas #open_faas

#designing_distributed_systems_brendan_burns

@gocasts

سلام دوستان، این ویدیو رو اگه دوست داشتید ببینید.
Functional Programming in 40 Minutes • Russ Olsen • GOTO 2018
https://www.youtube.com/watch?v=0if71HOyVjY

شاید تعجب کنید که چرا دارم در مورد functional programming صحبت می کنم.
اینکه چرا زبان های functional رو دنبال می کنم در آینده خواهم گفت.

ضمنا oop اونی که ما فکر میکنیم و اونی که زبان های معروف به oop سعی می کنن به ما بفهمونن نیست. برای تایید حرفم کافیه بریم سراغ خالق عبارت oop یعنی Alan Kay. شاید اگه به شما بگن functional ترین زبان دنیارو انتخاب کنید، احتمالا همه تون LISP رو انتخاب میکنید که صرفا یه سری پرانتزه و وسط پرانتزا یه سری کاراکتر هم میبینی😂😂. مثلا این تابع Factorial هست در زبان LISP

(define (factorial n) (cond ((= n 0) 1) (t (* n (factorial (- n 1))))))


حالا حرف alan kay رو بخونید:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP.

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

من تقریبا یک سالی میشه که خیلی دنبال میکنم زبان های functional رو مثل elixir، زبان های fp دیگه ای هم هستن مثل closure و haskell و erlang که خیلی محبوب هستن

گولنگ تقریبا یه زبان object oriented هست، تو همیشه باید دغدغه struct و state فیلدهاشو داشته باشی، اینکه چه متدی چه فیلدی رو آپدیت میکنه و بعد از اینکه یه زنجیره ای از متدهارو روی structت فراخوانی میکنی عملا دیگه غیرقابل پیش بینی هست که state اون آبجکت چیه

کلا نوشتن pure function تو هر زبانی خیلی ساده و لذتبخشه. یه تابع خیلی ساده و باحال که به عنوان ورودی یه سری مقدار میگیره و به عنوان خروجی یه مقدار جدید میده. دیتای ورودی رو تغییر نمیده، هیچ گونه side-effectی هم نداره، side-effect اینطوری میشد که مثلا وسط تابع ت یه کوئری به دیتابیس میزدی، یا یه سرویس و api دیگه رو فراخوانی میکردی و یا حتی یه چیزی تو فایل میریختی، اینا میشد side-effect.

تو برنامه نویسی به این توابع میگن pure function یعنی تابعی که هیچ side-effectی نداره، ورودی میگیره و یه خروجی تحویل میده

ایده functional programming خیلی قشنگه، اونجا همه چیز pure function هست، همه data structure ها هم immutable هستن، یعنی تو حتی اگه بخوای هم نمیتونی دیتای ورودی رو تغییر بدی، تو فقط میتونی دیتا رو کپی کنی و روی کپی تغییرات ایجاد کنی، اینطوری side-effect روی ورودی هم نداری

من تجربیاتی که تو این یک ساله از برنامه نویس های مختلف خوندم اینه که هر کسی برنامه نویس functional رو کار کرده به شدت لذت برده از زبان های functional، هم به شدت حجم کدی که مینویسن کمتره، هم معمولا کد تمیزتره و ساختار درستی داره، هم اینکه خیلی باگ پیدا کردن راحت تره. و در یک کلام productivity خیلی خوبی بهت میده، از این نظر که از زمان گرفتن ایده و کد نوشتن و اجرا کردنش روی پروداکشن زمان کمی بگذره، گولنگ هم تو productivity خیلی خوبه به همین دلیل محبوب شده، اما اصلا functional نیست و نمیخواد باشه، چون بزرگترین شرط functional بودن immutability هست که data structure های گولنگی ندارن بجز string که این یکی فقط immutable هست.

خیلی functional programming به ریاضی نزدیکه. مثلا من اگه بهت بگم تو زبان گولنگ مقدار y تو کد زیر چیه میگی ۴
var x = 2
var y = x + 2
اما اگه مقدار x رو بهت نگم، میگی که معلوم نیست، اول باید مقدار x در سمت راست معلوم بشه بعدش میشه مقدار y رو محاسبه کرد. چون تو برنامه نویسی زبان های oop عادت کردیم عملگر = رو assignment ببینیم، که همیشه اول مقدار سمت راست رو محاسبه میکنه و در متغیر سمت چپ ذخیره میکنه

اما تو زبان های functional مثل elixir عملگر = مثل همون عملگر = ریاضیات عمل میکنه و بهش pattern matching میگن.
تو ریاضی اگه این معادله رو با مقدار y برابر با ۳ بهت بدن خیلی سریع میگی x میشه ۲ و دیگه نمیگی اول باید مقدار x معلوم باشه، کافیه مقدار یکی از مجهولات در هر طرف معادله مشخص باشه که بشه مقدار دیگری رو تشخیص داد.
y= x + 1

دقیقا تو زبان های functional هم همینطوره، این دقیقا اتفاقیه که با pattern matching در elixir میفته. تو همه چیز رو تابع ریاضی میبینی، یه ورودی میگیری و یه خروجی داری همین. فوق العاده برنامه نویسی رو ساده، لذتبخش و راحت میکنه


مثلا discord با ۵۰۰ میلیون کاربر با elixir نوشته شده، یا whatsapp با بیش از ۲ میلیارد کاربر با erlang نوشته شده که زبان های functional هستن.

#functional_programming #elixir #lisp #pattern_matching

@gocasts

«با نرم افزارهایی که توسعه دادی، به چند کسب و کار زندگی بخشیدی؟»

- معیار مهندس نرم افزار خوب
- نقشه راه مهندسی نرم افزار

مهم ترین نکته ویدیو اینه که ما باید mindsetمون رو عوض کنیم. همیشه برای شروع پروژه به این فکر میکنیم که از چه زبان و تکنولوژی ای استفاده کنیم که نرم افزار از نظر فنی کیفیت بهتری داشته باشه، در حالیکه mindsetی که برای کسب و کار حیاتیه اینه که همه چیز به موقع deliver بشه که زندگی کسب و کار به خطر نیفته. بقیه چیزارو میشه بعدا حل کرد اما کسب و کار مرده رو نمیشه زنده کرد.

دوست خوبم @nasermirzaei89 یک ویدیو از Martin Fowler رو کامنت کرده بود که ارتباط زیادی به بحث داره، مفیده که ببینید
https://www.youtube.com/watch?v=4E3xfR6IBII

@gocasts

Design by Contract
شیوه ای که golang بخش مهمی از simplicityش رو مدیونشه

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

آشنایی با DBC کمک میکنه خیلی عمیق تر interface های تعریف شده در کتابخونه های استاندارد گولنگ رو متوجه بشیم، و قطعا کمک میکنه ما هم قراردادهای بهتری برای سرویس و ماژول هامون تعریف کنیم.
نکته خیلی مهم DBC اینه که اگه خوب متوجه ش باشیم، نه تنها فهم ابزارهای موجود که یکیش میشه کتابخونه های استاندارد گولنگ رو بهتر متوجه بشیم و ما هم بهتر در گولنگ کد بزنیم. بلکه میشه به خیلی لایه های بالاتر تعمیمش داد. اگه داریم سرویسی مینویسیم که قراره یه apiی ارائه بده به یه سری کلاینت، که میتونه شامل همه rest api هایی که مینویسیم هم باشه، خیلی کمک میکنه طراحی بهتری برای api ها داشته باشیم، حتی و اگه داریم در شرکت های بزرگ کار میکنیم میتونیم تعامل بین تیمی رو تقویت کنیم و تعامل خیلی سازنده تری داشته باشیم.

این لینک draft مقاله، ببخشید که خیلی خامه، ولی مطمئن هستم اگه با دقت همین draft رو مطالعه کنید متوجه منظورم خواهید شد.
https://docs.google.com/document/d/11_Tj46PiJ0OK_smYr6wKYyRVMDCVzgqCzBgVjqtwwvo/edit?usp=sharing

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

منابع
برای اینکه با design by contract آشنا بشید اصل مقاله رو میتونید اینجا بخونید
http://se.inf.ethz.ch/~meyer/publications/old/dbc_chapter.pdf

همچنین خوندن فلسفه let it crash هم در اینجا توصیه میشه
https://media.pragprog.com/noscripts/jaerlang2/errors.pdf

و اگه بتونید قسمت Design by Contract از کتاب The Pragmatic Programmer, 20th Anniversary Edition رو هم بخونید که چه عالی
https://pragprog.com/noscripts/tpp20/the-pragmatic-programmer-20th-anniversary-edition/


@gocasts

#design_by_contract #golang #simplicity #let_it_crash #joe_armstrong

سلام دوستان، @NikanCraft جان در یکی از گروه ها سوالی پرسید، فکر کردم مفید باشه پاسخم رو با شما به اشتراک بذارم

چه چیزی یه سینیور رو سینیور می‌کنه؟

دانش + تجربه
که دوتاش با انجام یکی دو تا پروژه به دست نمیاد. زمان میخواد، تو ایران مرسوم شده برنامه نویس های با دو سال به بالا تجربه رو سنیور میگن، ولی هیچ جای دنیا ازین خبرا نیست!
در نهایت، اصلا مهم نیست شما لقبتون سنیور باشه یا جونیور یا میدلول، از همین حالا به خودتون بگید سنیور، کی به کیه!
ولی مهم ترین نکته ای که برای ارتقای سطح کیفی خودتون باید در نظر بگیرید، توسعه شخصی به طور پیوسته است. مهم نیست در لحظه چقدر انرژی میذارید برای یادگیری و کسب تجربه از پروژه های مختلف، مهم اینه که چقدر این روند ادامه داره، اگه دو تا سه سال به توسعه خودتون بپردازید اونوقت تو ایران که قطعا سنیور هستید بقیه جاها هم هرچی باشید خوب هستید مهم نیست اسمش چیه 🙂
برای توسعه شخصی هم اگه از بنده حقیر بپرسن میگم
یک- باید تا میتونید بخونید، بخونید، بخونید. خوندن(به هرشکلش) هم در مورد تکنولوژی ای که باهاش کار میکنید هم به طور کلی در حوزه ای که هستید، مثلا اگه web کار میکنید در مورد ماهیت وب، تکنولوژی های فرانت، بکند، دیتابیس، اگه تو حوزه امنیت کار میکنید که خودش یه دنیای دیگه است، دنیای هوش مصنوعی هم همینطور. کسی زودتر سنیور میشه که دانش سطحی خوبی نسبت به خیلی از جوانب حوزه ای که کار میکنه داشته باشه، و یه دانش نسبتا عمیق نسبت به تخصص خودش.
دو - تا میتونید تو پروژه های مختلف و چالش های متفاوت مشارکت داشته باشید، این مشارکت تیمی soft skill شما رو هم که خیلی مهمه تقویت میکنه

اگرم با هدف ۲ سال و ۳ سال و ۵ سال اومدید تو این حوزه همه چیزایی که گفتم رو فراموش کنید، تا میتونید فقط کار کنید و سعی کنید یه بیزینسی به یه طریقی راه بندازید، چون من نگاهم به مهندسی نرم افزار یه چیزی تو این مایه هاست (Joe Armstrong)، تو ۶۵ سالگی تازه به بلوغ میرسی 😁
بنده حقیر بعد از ۱۰، ۱۲ سال جونیور هم نیستم
https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer)

بنده حقیر به شخصه اول راهم، بعد از ۱۰، ۱۲ سال، شاید به سختی جونیور باشم! اگه خدا عمر و سلامتی و عزت بده فکر میکنم تا ۶۰، ۶۵ سالگی حداقل تو این حرفه بمونم، پس خیلی کوتاه مدت و عجولانه برای آینده تون تصمیم نگیرید. 🌹

@gocasts

سلام دوستان
در ادامه پست قبلی، سعی کردم در یک ویدیو توضیح بدم که اگه مفهوم کلی design by contract رو متوجه بشیم، چطور میتونیم کد بهتری در گولنگ بنویسیم، امیدوارم که مفید باشه براتون

اینم لینک ویدیو در یوتیوب
https://youtu.be/uibCosfk4-Y

#golang #design_by_contract #simplicity

@gocasts

سلام دوستان، یه بوتکمپ بهتون معرفی می کنم برای یادگیری عمیق گولنگ از صفر صفر!

https://gocasts.ir/learning-golang-with-caleb-doxsey?utm_source=telegram&utm_medium=message&utm_campaign=1

@gocasts

#golang #bootcamp

چطوری یه فریمورک scalable برای پروژه های گولنگی انتخاب کنم؟

https://youtu.be/S15s8CIvz60

#scalability #golang #web #framework

@gocasts

یه مقاله بسیار کوتاه و جالب خوندم که یه مورد از 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