Arsham's Tech Mastery

داشتم readme پکیج httpexpect رو میخوندم (این پکیج برای HTTP and REST API E2E testing استفاده میشه. (همش اسمه نمیشه ترجمش کرد 😅️️️️️️) دیدم داره از jsonpath هم استفاده میکنه، از اونجایی که قدرت کانسپت jsonpath توی کامندلاین کوبر رو دوست دارم، این پکیج هم نظرمو جلب کردم. پکیج اش رو دیدم و اولین خط readme نوشته شده بود: This was mostly an experiment to learn go and test using closures to interpret a JSON path. You should use https://github.com/PaesslerAG/jsonpath instead. آخ جون فرصت کانتریبیوت! ولی صبر کن، اول بریم پول ریکوئست هارو بخونیم ببینیم کسی قبلا انجامش نداده؟ خود کلمه jsonpath رو سرچ کردم و به این پول ریکوئست رسیدم: https://github.com/gavv/httpexpect/pull/49 تحلیل هایی که ویکتور در جواب به این پول ریکوئست داشته رو خیلی دوست داشتم، مثلا این: https://github.com/gavv/httpexpect/pull/49#issuecomment-408675078 و بعدش هم بلافاصله رفته سه تا ایشو روی پکیج اولی باز کرده... ایشو ها رو پکیج اولی فیکس شدن اما رو دومی نه و ویکتور دلیلی نمیبینه این تغییر رو انجام بده، اما گفته که استقبال میکنه از کسی که تغییر بده، مکالمه مال پنج سال پیشه، بریم ببینیم پکیج دومی درست شده؟ یه پروژه تستی میسازیم و هر دو پروژه رو امتحان میکنیم (فکر کنم لازم به توضیح نباشه که این پروژه تستی قرار نیست زیاد زنده باشه! همچنین قرار نیست بزرگ یا تمیز باشه، کد اش رو میزارم کامنت) از نتایج مشخصه که پکیج دوم هنوز فیکس نشده، مجددا کانتریبیوت هاشو چک میکنید، ایشو هاشو چک میکنید، اگه قبلا کسی مطرحش نکرده بود، ایشو اش رو ایجاد میکنید و منتظر نظر maintainer ها میمونید تا نظرشون رو راجع به این تغییر بگن. برای من راستش صرفه نداشت از این بیشتر پیش برم، ولی مسیری که رفتم نکته های آموزشی داشت که حیفیم اومد شیر نکنم.

اومدم پا لپتاپ یهو دیدم یه موش خرمای خوشگل آبی رو لپتامه 😂 خواهرم برام عروسک گوفر درست کرده بود 😍😂 <<----->> اگه کسی دوست داشت از این گوفر های خوشگل داشته باشه میتونه بهم پیام بده یا از غرفه با سلام خواهرم بخره. ✌️🏼 https://basalam.com/shikopik576/product/856329

قبل اسنپ با یه شرکت خارجی خوبی مصاحبه داشتم، ولی متاسفانه به دلیل نداشتن تجربه کافی observability# و ابزار هاش رد شدم، بنابراین این پست رو براتون نوشتم که شما رد نشید 😁 <<----->> به طور کلی ما سه تا پارامتر مهم تو این بحث داریم، - لاگ (Log) - متریک (Metric) - تریس (Trace) راجع‌ به لاگ قبلا یه صحبت هایی شده مخصوصا تو گروه گپمون با آقای حکایتی، هرچند که کافی نبوده و خیلی جا بحث داره هنوز. <<----->> الان میخوام یه نکته راجع به metric یادم افتاد بهتون بگم. ما دو دسته اصلی از متریک ها داریم: - متریک های بیزنسی - متریک های نرم افزاری متریک های بیزنسی وابسته به بیزنس متفاوته، مثلا برا یه فروشگاه میتونه اینا باشه: تعداد فروش کالا های دسته لوازم منزل، تعداد سبد خرید های پرداخت نشده، تعداد سفارشات مرجوع شده، تعداد کد تخفیف های استفاده شده و... برای اسنپ مثلا، تعداد سفر ها (و حالت های مختلفش از جمله قبول شده، رسیده, کنسل شده) در تایم‌فریم های مختلف (دقیقه، روز، ماه) در شهر های مختلف و... این متریک ها میتونن برای تیم های غیر فنی بسیار حیاتی و مهم باشن، مورد مطالعه قرار میگیرن، و برای رشد شرکت برنامه ریزی میشه... برای خود تیم فنی هم کاربرد داره، مثلا اگه هر کدوم از این متریک ها یهو دچار افت شدید بشه، احتمالا باید یه اکشن تکنیکال داشته باشیم. یه دسته دیگه هم که متریک های تکنیکال بود، مثلا مصرف رم و CPU، تعداد درخواست در ثانیه، ریسپانس تایم، تعداد درخواست ها با ریسپانس 4xx یا 5xx، مثلا اگه 5xx هامون از یه حدی بیشتر بشه، قطعا مشکلی وجود داره. تو بعضی موارد مثلا تعداد کانکشن های وب سوکت، یا اگه اپلیکشن گولنگی بود تعداد گوروتین ها (برای مطمئن شدن از نبود گوروتین لیک) و... <<----->> اینکه هر ابزار چطور این متریک هارو اندازه گیری میکنه وابسته به ابزارش متفاوته، ابزار های زیادی هم هستن (مثلا پرمتئوس، سیگنوز و...) که راستش هدف من نیست و مقاله و آموزش خوب براشون زیاد هست، ولی مفهومی همین مسئله رو بیشتر بررسی خواهیم کرد. <<----->> خوشحال میشم نظراتتون رو راجع به متریک برام کامنت کنید، کجاها استفاده کردید؟ و...

خیلی فاصله هست بین آرزو، هدف، ایده و طرح، این چهارکلمه خیلی اشتباها باهم قاطی میشن. برا خیلیامون به عنوان مهندس نرم افزار، احتمالا پیش اومده که شخصی "آرزو داره" که مالک بیزنسی باشه، بیزنسی که به واسطه سالها تجربه و تلاش کلی آدم و سرمایه و شانس! و... شده "بیزنس" مثالش میشه همون درخواست اپلیکیشن اسنپ با پنج میلیون که تو پونیشا میبینیم. میان میگن برامون (مثلا) اینستاگرام بزن، اوکی ایده خاصی داری بهش اضافه کنی؟ نه سرمایه گذار قوی؟ نه پلن مارکتینگ خفنی داری؟ نه هیچگونه تجربه ای تو بیزنس داری؟ نه شرح نیازمندی و...؟ نه چی داری؟ آرزوی پول دار شدن به واسطه آشنایی با شمای مهندس نرم افزار! خب عزیزم، نرم افزار یه قسمتی از بیزنسه، ممکنه گاهی اوقات مهمترین قسمتش باشه، اما بازم یه قسمتیشه، هر بیزنسی، داخلی و خارجی و...، هزار تا چالش داره. بازم من همیشه تو این موارد سعی میکنم در نقش حمایتگر، کمک کنم که اون آدم از جدیت حرفی که میزنه مطلع بشه، و اگه واقعا مشتاق بود، مسیرشو شروع کنه. منم رویاها و ایده های خودمو دارم، و دارم براشون تلاش میکنم (نتورک، مطالعه، پس انداز و...). یه سری کامنت و منبع هم بعدا زیر این پست میزارم.✌️

میخوایم یه سیستم طراحی کنیم، حله، بزن بریم یه دو سه تا کلاستر کافکا بزاریم و هفت هشت تا سرویس و خلاصه دیزاین سیستم رو دراریم!!!! داداش کجا با این عجله وایسا با هم بریم 😅 <<----->> یکی از پادکست هایی که دنبال میکنم پادکست gotime هست (فوق العادست)، که یکی از اپیزود های اخیرش راجع به کافکا بود، و یکی از مدیرای کلاودفلر (Matthew Boyle) که چندسالی هست داره با کافکا کار میکنه (ایشون همچنین نویسنده کتاب ddd in go هم هستن) راجع به یه سری سوالات صحبت میکنه، مثلا کافکا چه مشکلاتی رو حل میکنه؟ چرا انداختن یه تکنولوژی مثل کافکا وسط مشکلات نمیتونه همه چی رو درست کنه؟ پیچیدگی های کافکا و... <<----->> تو این پست بیشتر از این چیزی نمیگم، مت همه چیزو گفته، ولی راجع به پادکستش، پادکست رو به کمک یکی از پروژه هاییم که فعلا تو وضعیت "probably failed" هست دانلود و متنش رو استخراج کردم و براتون گذاشتم تو کامنت. گوش دادن بهش و دنبال کردن متنش، جدا از چیزایی که یاد میگیرید، به زبانتون هم خیلی کمک میکنه، چون افراد داخل پادکست خیلی واقعی تر از مثلا tutorial و دوره صحبت میکنن. امیدوارم این پروژه من هم درست بشه بیشتر براتون پادکست بزارم. 😅 <<----->> https://podcasts.google.com/feed/aHR0cHM6Ly9jaGFuZ2Vsb2cuY29tL2dvdGltZS9mZWVk/episode/Y2hhbmdlbG9nLmNvbS8yLzIyOTY

اولین بار که اسم پترن circuit breaker توی مایکروسرویس رو شنیدم، فکر کردم اووو چه اسم خفنی! بعد دیدم عه، همون فیوز خودمونه 😄 از اونجایی که این کلمه رو از دنیای الکترونیک قرض گرفتن، من هم اول یه خلاصه ای از کارکردش تو دنیای الکترونیک ارائه میدم. فیوز وسیله ایه که وقتی جریانات برق ناسالمه، مدار رو قطع میکنه که به وسایل الکتریکی آسیب نرسه، بنابراین ما برای مدار دو حالت داریم - بسته: وقتی که همه چی رو به راهه - باز: وقتی که مدار قطعه نکته: توی این بحث، کلمه trip معنی پریدن (قطع شدن) فیوز رو میده. <<----->> حالا این پترن چه کاربردی توی مایکروسرویس داره؟ فکر کنید شما یه کلاینت دارید، یه api gateway که بهش میگیم سرویس الف و یه سرویس که توسط gateway کال میشه و بهش میگیم سرویس ب حالا اگه سرویس ب کند باشه یا بعد ۶۰ ثانیه تایم آوت بده یا سری مشکلات از این قبیل، سرویس الف هم با همین تاخیر ها جواب کاربر رو میده و کاربر تجربه بدی خواهد داشت، شما خودتون رو به عنوان کاربر تصور کنید، دیر جواب نگرفتن بهتره یا زود جواب نگرفتن؟ (داریم راجع به سناریویی حرف میزنیم که در هر صورت جواب نمیگیریم) این پترن دقیقا اینجا به کار میاد (البته کاربرد های دیگه هم داره) ما این پترن رو تو سرویس الف پیاده سازی میکنیم، و میگیم که اگه سرویس ب رو صدا زدی و جوابی نداد، مدار رو قطع کن، و با یه مکانیسمی، دوباره سلامت سرویس ب رو چک کن و اگه درست شده بود دوباره مدار رو وصل کن، ولی تو مدتی که مدار قطعه، سرویس الف سرویس ب رو صدا نمیزنه و جواب درخواست های کاربر رو هم با فرض قطع بودن سرویس ب میده. <<----->> برای پیاده سازی این پترن توی زبان های مختلف پکیج هست و به سادگی میتونید پیداشون کنید. برای گولنگ این پکیج هست: https://github.com/rubyist/circuitbreaker که اگه دوست داشتید میتونید کلون کنید و کدش رو بخونید، کدش کمه و ساده، یه سری پترن های ساده کانکارنسی هم به زیبایی پیاده سازی کرده. برای خوندن کدش میتونید از فایل circuitbreaker.go شروع کنید و از توابع NewXxxBreaker در واقع انواع مختلفی از فیوز داریم و تفاوتشون هم تو نحوه قطع شدن و دوباره وصل شدنشونه، البته میتونید هم توابع قطع و وصل رو از بیرون بنابر شرایط دلخواه خودتون صدا بزنید. <<----->> خیلی خلاصه کردم مطلب رو، اگر حس میکنید جایی نیاز بهبود داره یا خواستید از کاربرد هاش تو پروژه های خودتون بگید خوشحال میشم برامون کامنت بزارید.

یه سایت خفنی پیدا کردم، ایده اش واقعااا جذاب بود، https://console.algora.io/home/projects کسب درآمد از اپن سورس، به ازای ایشو ها و پول ریکوئست هاتون بهتون پول میدن، یا کسایی که بیزنس هایی با محصول اپن سورس دارن و براشون میصرفه میتونن مشکلاتشون رو تو این سایت مطرح کنن و به ازای فیکس شدنش پول پرداخت کنن. کانال یوتیوبشون هم دوست داشتم، تقریبا همون چیزیه که این کانال رو به خاطرش زدم، بررسی کد پروژه های اپن سورس (با چند تا از دوستان هم جلساتی رفتیم، ولی پابلیک نبوده، پابلیک هم تولید خواهیم کرد) لینک ایشو بانتی هاشم گذاشتم تو کامنت

🔗 با همفکری و همراهی چند تن از دوستان جلساتی در باب تبیین چرایی اهمیت یادگیری #فلسفه_علم برای هر #اندیشمند و #خردمند ی ترتیب دادیم. جلسات مطابق معمول در سرور دیسکورد (زمان جلسات در بخش ایونت های سرور مشخص می باشد) برگزار میشه. در کامنت های همین پست، در صورت صلاحدید و اجازه دوستان در جلسه صوت جلسات را قرار میدم. 🤝 در این جلسات با انتخاب جمعی، کتاب فلسفه علم از سمیر اکاشا را هم بررسی خواهیم کرد. 🧠 در جلسات پاسخ خواهیم داد که چرا یادگیری فلسفه علم محدود به هیچ فرد خاصی نمیشه و هر #دانش_مند ی باید حداقل های این علم بین رشته ای را یاد بگیره تا بتونه #تصمیم_سازی های با کیفیت تری داشته باشه.

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

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

package main

// ** Type A and its method
type TypeA struct{}

func (ta TypeA) GetInner() Inner {
 return Inner{}
}

// ** Type B and its method
type TypeB struct{}

func (tb TypeB) GetInner() Inner {
 return Inner{}
}

// ** Another type that A and B return
type Inner struct{}

func (i Inner) Method(int) string {
 return ""
}

// ** Interfaces
type InnerType interface {
 Method(int) string
}

type GeneralType interface {
 GetInner() InnerType
}

func main() {
 var _ InnerType = Inner{}
 var _ GeneralType = TypeA{}
}

کد رو با سوال بررسی کنیم، آیا ما در خط اول تابع main خطا خواهیم داشت؟ منظورم اینه که آیا استراکت Inner میتونه اینترفیس InnerType رو satisfy کنه؟ در خط دوم چطور؟ آیا استراکت TypeA میونه اینترفیس GeneralType رو اقنا (satisfy) کنه؟ <<---->> من اینجا متغیر هارو خیلی ساده کردم و همه متد های اضافه و... رو پاک کردم، بنابراین ممکنه وقتی تو ادیتور بزنید براتون بدیهی باشه که چرا خطا میگیرید، ولی خب برای من یه تله ذهنی داشت، وقتی که این اررور رو گرفتم:

cannot use TypeA{} (value of type TypeA) as GeneralType value in variable declaration: TypeA does not implement GeneralType (wrong type for method GetInner)
  have GetInner() Inner
  want GetInner() InnerType

ناخودآگاه فکر کردم want و have که یه چیزن؟ چون Inner میتونه InnerType رو satisfy کنه، و دقیقا نکته اینجاست که "میتونه" اما اینکار رو نمیکنه! <<---->> یه مثال ساده تر:

package main

import "fmt"

type I interface {
    foo(any)
}

type S struct {}

func (s S) foo(i int) {
    fmt.Println(i)
}

func main() {
    var _ I = S{}
}

در این مثال، تابع foo(int) و تابع foo(any) دو تایپ متفاوت هستن، اگرچه که آرگومان هاشون به هم میخوره، اما خود تابع متفاوته، همین مسئله راجع به خروجی تابع هم صادقه. <<---->> آخرین نکته ای که اضافه کنم، در مثال اول، هر دو متد GetInner قرار شد که اینترفیس InnerType رو برگردونن، یعنی خود تایپ خروجی دقیقا مثل signature داخل اینترفیس بشه، و مشکل حل شد.

برنامه نویسی فانکشنال (functional programming), اولین پارادایم برنامه نویسیه (از نظر زمانی)‌ که طی سالهای اخیر، بیش از پیش مورد توجه قرار گرفته. این الگو (#paradigm) نیازمند شرایط مختلفی هست که لازمه ازشون مطلع باشید تا بتونید ازش استفاده کنید. (قابل توجه عزیزانی که فکر میکنن اگه به جای کلاس از تابع استفاده کنن کار تمومه و دیگه از فردا هم مارو تحویل نمیگرن چون فانکشنال کد میزنن 😁) مهترین اصلش Immutable variables/state هست که اینم بیان جالبی ازش بود:

Variables in functional languages, do not vary!

و بر اساس همین نکته، خیلی چیزا تغییر میکنه، مثلا توابع نباید ساید افکت* داشته باشن و باید pure باشن. یا مثلا دیگه حلقه به اون شکلی که یه iterator به اسم i داشته باشید که هر سری افزایشش بدید نداریم. حلقه بی حلقه 🤯 چیکار میکنن به جاش؟ خب بستگی داره، مثلا بعضی زبانا (Clojure, Lisp و تا حدی Erlang*) اصالتا برای فانکشنال بودن ساخته شدن و ساختار های خاصی برای این پارادایم دارن. تو بقیه زبانا، ممکنه به جای حلقه بخواید از recursion استفاده کنید. <<----->> حالا سوالی که میمونه، به نظرتون استفاده از این پارادایم تو زبانایی مثل js چقدر منطقیه؟ تو گولنگ چطور؟ <<----->> ستاره هایی که گذاشتم رو توضیح بدم، ساید افکت: یعنی اینکه تابع رو چند بار با ورودی یکسان کال کنید اما خروجی یکسان نگیرید! دلیلش میتونه وابستگی به متغیر های گلوبال یا... باشه‌. زبان Erlang هم اصالتا فانکشنال نیست، ولی تو کامیونیتی های فانکشنال پرطرفداره. <<----->> به عنوان منبع، این ویدئو از کانال شگفت انگیز CodeAesthetic رو معرفی میکنم: https://youtu.be/nuML9SmdbJ4?si=-JaEBx3i2CpbKZuK و فصل شیش ام کتاب clean architecture رابرت مارتین هم به همین موضوع برنامه نویسی فانکشنال پرداخته. یه ویدئو هم جادی داشت که خودتون پیداش کنید 😁

کار خوب رو باید نشر داد، همینجوری داشتم گشت میزدم که با این پلی لیست مواجه شدم: https://www.youtube.com/playlist?list=PLSb_1jGG1FRMm4o--2eRrAMoTBHLOl_Gf قرار بود خودم یه دوره بدم برای مباحث پیشرفته تر گیت، ولی این پلی لیست صادق ظاهرا قراره پوشش بده و بحث اسکوآش و کانفلیکت و... هم رو هم خوب گفته. توی کامنت هم البته بچه ها دوره های خوبی معرفی کردن حتما ببینید. خودمم قبلنا این دوتا دوره رو دیده بودم خوب بودن: Intermediate: https://www.youtube.com/watch?v=Uszj_k0DGsg Advanced: https://www.youtube.com/watch?v=qsTthZi23VE البته بازم تو بحث گیت هیچی تجربه hands-on نمیشه، ولی دانشش رو که داشته باشید تو شرایطش خیلی راحت میتونید دانشتون رو اعمال کنید و نگران نباشید.

هفته گذشته یه مقاله نوشتم راجع به چلنج هایی که ممکنه موقع اضافه کردن tracing به اپلیکیشن گولنگتون باهاش مواجه بشید (خودم مواجه شدم) و امروز صبح تکمیل شد. این مقاله از سری مقالات TechStory هست، یعنی آموزش نیست و نگفتم که چیکار کنید، بلکه گفتم در طول مسیر یه تسک خاص چیکار کردم، چه مشکلی بود، و چطور حل شد. لطفا حتما بهم فیدبک بدید که سبک مقاله اش به طور کلی جالبه یا نه، و اینکه چطور میتونه بهتر بشه. لینک مقاله: https://dev.to/arshamalh/techstory-how-to-add-distributed-tracing-using-jaeger-and-opentelemetry-into-a-golang-application-1p37

بسی لذت بردم از خوندن این مقاله درس بزرگش استفاده از راه حال های خیلی ساده حتی برای scale خیلی بزرگی مثل pinterest هست یکی از نکات جالب این مقاله استفاده از دیتابیس های master بود و از slave فقط برای بکاپ استفاده میکردن، همه read و writeهای production روی master هست و دیگه مشکلی بابت lagهای slave که میتونه خیلی bug-prone باشه ندارن. جالبه که در انتخاب دیتابیس maturity دیتابیس رو اولویت قرار دادن و دیتابیس MySQL رو به MongoDB و Cassandra ترجیح دادن با اینکه راه حل های مدرن تر قابلیت auto-scaling دارن. حقیقتا به شخصه هم MySQL رو دوست دارم، هم ساده ست و هم mature و هم کلی ابزار خوب مثل ProxySQL براش هست. https://proxysql.com برای shard کردن روی هر سرور EC2 یه سرویس MySQL بالا آوردن و هر سرویس MySQL در حالت master-master روی هاست بکاپ replicate میشه، این مستر بکاپ فقط برای وقتی هست که مستر اصلی fail بشه. روی پروداکشن همه read و writeها توسط master اصلی انجام میشه و این کار رو pinterest خیلی توصیه میکنه چون ساده میشه همه چیز. هر نسخه از سرویس MySQL میتونه شامل چندین database باشه که اسم دیتابیس ها unique هست در سرتاسر ناوگان (کلاسترهای) MySQL. یه تصمیم دیگه ای هم که گرفتن اینه که وقتی داده ای در یک shard ذخیره میشه دیگه هیچ وقت به shard دیگه ای منتقل نمیشه. ولی برای افزایش ظرفیت یک shard میشه کل اون shard رو به یک ماشین دیگه منتقل کرد. دغدغه دیگه شون هم طبیعتا ساخت uuid بوده نحوه ساختن UUIDشون خیلی جالبه، اینطوریه که سه بخش داره، بخش اول میشه شناسه shard بخش دوم میشه شناسه جدول، مثلا جدول pin ها شناسه ش ۱ هست و بخش سوم هم میشه شناسه عددی id رکورد در جدول pins که یه auto-increment integer هست. یکی از کارهای جالب دیگه شون اینه که جدول دیتابیس شون کلا یه فیلد blob داره که یه فیلد TEXT هست که داده های serializeشده json رو ذخیره میکنن. علتش هم اینه که میگن اضافه کردن ستون به دیتابیس توسط دستور alter table خیلی هزینه بر هست ولی اضافه کردن فیلد به json نه. سمت اپلیکیشن ها هم سعی میکنن برای فیلدهای جدید تعریف شده default value در نظر بگیرن که اگه داده قدیمی jsonی اون فیلدهارو نداشت مشکلی پیش نیاد. برای edit کردن یک رکورد دیتابیس هم از select for update استفاده میکنن که read lock بگیرن روی اون record دیتابیس. http://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html

> BEGIN > SELECT blob FROM db03429.pins WHERE local_id=7075733 FOR UPDATE [Modify the json blob] > UPDATE db03429.pins SET blob=’<modified blob>’ WHERE local_id=7075733 > COMMIT

Sharding Pinterest: How we scaled our MySQL fleet https://medium.com/pinterest-engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f @gocasts

دیروز با یکی از بچه ها جلسه داشتم، یه مقاله ای رو که براش عجیب بود برام فرستاد که راهنماییش کنم، لینک مقاله رو در آخر میزارم ولی این قطعه کد از مقاله رو نگاه کنید:

t.Run(tt.name, func(t *testing.T) {
 repo := &mocks.IPaymentRepository{}
 if !tt.wantErr {
  repo.On("CreatePayment", tt.args.payment).Return(tt.want, nil)
 } else {
  repo.On("CreatePayment", tt.args.payment).Return(tt.want, errors.New("Failed to create payment"))
 }
 got, err := repo.CreatePayment(tt.args.payment)
 if (err != nil) != tt.wantErr {
  t.Errorf("Repository.CreatePayment() error = %v, wantErr %v", err, tt.wantErr)
  return
 }
 if got != tt.want {
  t.Errorf("Repository.CreatePayment() = %v, want %v", got, tt.want)
 }
})

نیاز نیست لاجیک کدشو بدونید که متوجه بشید کجاش اشتباهه، خلاصشو بگم، اومده یه ماک ساخته به اسم IPaymentRepository بعد ست کرده که ماک اش چی بگیره چی برگردونه و... نکته جالب اینه که همون آبجکت رو ارزیابی (assert) کرده بعدش. یعنی بهش گفته x رو که بهت دادم y برگردون، بعد مستقیما x رو بهش داده که ببینه y برمیگردونه یا نه! (خب اصلا باید برگردونه، ما از ماک استفاده میکنیم که گارانتی کنیم چیزی که میخوایم رو حتما برمیگردونه) احتمالا بعدش هم بهش گفته آباریکلا بچه خوب! بیشتر به نظر میرسه که تارگت تست مقاله نویس محترم، mockery بوده و نه کد خودش! <<----->> حالا چرا به این موضوع اشاره کردم؟ چون قبلا زیاد جاهایی دیدم که اینجوری تست کنن، و از طرفی این مقاله موجب به غلط افتادن دوستان هم میشه. <<----->> حالا کاربرد درست ماک چیه؟ ماک رو مینویسید برای بقیه تست هاتون نه برا خود اون چیزی که ماک شده. که البته بحث مفصلیه و تو یه پست جا نمیشه. <<----->> یه نکته دیگه، یکم فارق از این پست اینکه نظر کامیونیتی تا جایی که من میدونم بر اینه که دیتابیس نباید ماک بشه، چون پیچیدگی زیادی خواهد داشت، دیتابیس رو برای تست هامون یه دیتابیس موقت میاریم بالا و بعد تموم شدن تست میندازیمش. البته ریپازیتوری ماک میشه و توابع بیزنسی میتونن تو تست ها ازش استفاده کنن. باز اینم مفصل تر تو یه پستی توضیح میدم.

تو این مقاله توضیح داده شده که گیتهاب چطور ورژن دیتابیس MySQL خودش رو از 5.7 به 8.0 ارتقا داده، بیشتر از 1200 تا هاست که بیشتر از 300 ترابایت دیتا دارن و به بیشتر از پنج میلیون کوئری در ثانیه جواب میدن‌. https://github.blog/2023-12-07-upgrading-github-com-to-mysql-8-0/

باعث افتخارمه دوستان بیشتری رو ببینم‌ 🙌🏼 دوستانی که قبلا باهم جلسه داشتیم هم اگه دوست داشتن دوباره جلسه رزرو کنن و تکنیکال تر صحبت کنیم، اونایی که ریویو نوشتن (یا میخوان بنویسن 😉) هم دمشون گرم. ❤️ https://www.linkedin.com/posts/arshamalh_every-once-in-while-people-reach-out-to-activity-7138586457434222592-ddnc

معرفی کتاب: Test-Driven Development in Go By Adelina Simion کتاب خوبیه در مجموع و پیشنهاد میکنم اگه به تست نویسی علاقه مندید حتما بخونیدش... و حتی اگر هم تست نویسی به تنهایی براتون جذابه اما روش tdd براتون جذابیت نداره، زیاد فرقی نمیکنه و بازم نکات کتاب بسیار مفید خواهد بود. کتابایی که موضوع و هدفشون مشخصه رو دوست دارم، این کتاب هم موضوعش مشخصا تست نویسی در اکوسیستم حول زبان گولنگه. ولی خب همین هم به قدری گسترده است که قطعا تو سیصد صفحه نمیشه تو موضوعاتش عمیق شد (و نشده) کل کتاب به سه بخش تقسیم شده <<----->> بخش اول (The big picture) تئوری های زیادی داره، ولی زبونش روونه و میتونید با سرعت و کیفیت خوبی پیشش ببرید. یه جاهایی هم یکم مباحث غیر تست نویسی رو پوشش داده (مثلا اررور هندلینگ، ماژول و پکیج و حتی اجایل)، اونقدر زیاد توضیحشون نداده که از اصل موضوع کتاب دور بشه (که خوبه) خود unit testing رو توضیح داده، بعد هم ماک کردن و assertion و بعدش هم table driven development تو این فصل که تئوری زیاد داره، حتما نکاتی که به نظرتون مهم میاد رو علامت گذاری کنید و یه مرور روشون داشته باشید. <<----->> بخش دوم خب این کتاب رو اون موقع که من گرفتم خیلی تازه چاپ شده بود، و کتابای تازه چاپ شده هم نرخ خطا (اشتباه چاپی، خطای توی مثال ها و...) یه خورده بیشتره، البته از اونورم یه خوبی داره که آپدیته. خطاهای این کتاب زیاد نبود، ولی یه جاهایی برای فهمیدن مثال ها، لازمه کدش رو دوباره بنویسید و قسمت های ناقصش رو تکمیل کنید که متوجه بشید چی به چیه، همچنین پیشنهاد میشه از روز اول نمونه کد هاش رو بگیرید: https://github.com/PacktPublishing/Test-Driven-Development-in-Go تو این بخش هم راجع به end-to-end & integration test صحبت میشه و یه جاهاییشم به BDD اشاره میکنه و چندتا نکته راجع بهش میگه. همچنین به تست دیتابیس اشاره میکنه، ولی به نظرم، از اونجایی که کتاب کوچیکیه، باید حتما تمرین و کد خونی (#کد_بخونیم) هم کنارش داشته باشید که اثر بخشی خوبی داشته باشه. تو بخش های بعدیشم نکات خوبی راجع به ریفکتور کردن و تست مایکروسرویس ها میگه. <<----->> بخش سوم هم به همین شکل، نوع محتوا مثل فصل های قبل: - توضیح مطالب جانبی - پوشش نسبتا سطحی مطالب (البته عمیق تر از پست های مدیوم 😉) - نیازمند تمرین و مطالعه جانبی - پیوستگی مطالب و تشریح مرحله به مرحله سر فصل ها هم که تست کد های کانکارنت، تست های مرزی، و جنریک ها... و پیشنهاد میکنم قبل ورود به بخش سوم، بخش دوم به خوبی تمرین بشه که مطالبش تثبیت بشه. <<----->> از این نوع معرفی کتاب راضی بودید؟ چیارو میگفتم بهتر بود؟

فضای مجازی (social media) مثل شمشیر دولبه است، و منظورم هم فقط تو بحث یادگیریه (بقیه لبه هاش رو کار ندارم) میشه بیشتر توضیح بدی؟ 🤔 چند وقتی بود ذهنم درگیر شیوه یادگیریمون شده بود، همه جا پر شده از پست های یک صفحه ای و محتوای سریع، که ما هم تو تایم های پرتمون میریم میخونیم و دلخوش به اینیم که اوکی! من حتی تایم استراحتم هم پست لینکداین خوندم و یه چیزی یاد گرفتم! اگرچه که دروغ هم نیست و واقعا یه چیزای کمی یاد میگیریم، اما وقتی که این سبک از یادگیری زیاد میشه، به مرور متوجه میشید که - زمان مشخص (dedicated) برای مطالعه (به جای زمانای کوتاه و پرت)، - و محتوای پیوسته (به جای تک صفحه و نیم صفحه هایی تو موضوعات مختلف) کاملا حس متفاوتی از یادگیری خواهد داشت. البته این مطالب سریع خوبی هایی هم داره، تو ذهنمون سوال ایجاد میکنه و بهمون کلید واژه میده برای تحقیق بیشتر... اما این سوالات ایجاد شده جواب نمیخوان؟ و کِی قراره دنبال پاسخشون بگردیم؟ و چیزایی که یادگرفتیم رو با کیفیت یادبگیریم؟ و ببینیم کلید واژه هامون به کجا ختم میشه؟ از طرفی این مطالب اعتیاد آورن، و اعتیاد هم خانمان سوز، مخصوصا که توجیه اش هم یادگیری باشه! (موجب اضطراب و... هم میشه که دیگه دور میشیم از بحث اصلی) راه حل؟ محتوای پیوسته (کتاب یا دوره کامل)، حتی اگه تو تایم های پرت باشه بازم موثره، اما داشتن زمان مشخص برای یادگیری هم میتونه کمک شگفت انگیزی کنه. من تو تایم های پرت ام با دولینگو تمرین میکردم (الانم ۷۰۷ روز پیوسته آلمانی تمرین کردم) و از تجربه ای که داشتم، چیزای کوییز طوری برای تایم های پرت جوابه، البته راه زیاده، شما هم از راه حل های خودتون بگید، ولی بازم چه اصراریه که تا آخرین قطره وقتمون رو صرف یادگیری کنیم؟ به تازگی کتابی از یکی از دوستام هدیه گرفتم و خوندم به اسم "در ستایش اتلاف وقت"، ولی گول کلمه "اتلاف وقت" داخلش رو نخورید! حالت تمسخر به وضع امروز ما داره، که چطور تو بند اینترنت و فضای مجازی هستیم و از طرفی برای ثانیه به ثانیه زمانمون برنامه داریم و به ذهنمون حتی فرصت نمیدیم که اطلاعات قبلی رو هضم کنه. در آخر هم میخوام لینک بدم به مقاله یکی از دوستانم که یه لیدر با تجربست و حرفاش برام بسیار ارزشمنده. https://nghaedsharafi.substack.com/p/escape-the-fast-food-media-rut-aka توضیح کتابی که معرفی کردم هم در کامنت گذاشتم.