سلام به همه دوستان گل

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

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

🙋‍♂️ سوال
من ۲ تا microservice دارم که یک message broker بینشون هست.
سرویس اول یه worker داره که از یکی از جداول دیتابیس همه event هایی که وضعیت new دارند رو میخونه و داخل broker منتشر میکنه. بعد از انتشارشون وضعیت eventها رو آپدیت میکنه که دیگه ارسال نشن.
سرویس دوم مسئولیت پردازش eventهارو داره.
نگرانی من اینه اگه worker همه eventهارو داخل broker ریخت ولی نتونست وضعیتشون رو بروز کنه تو دیتابیس، خب دفعه بعد مجددا این eventهارو داخل broker میریزه و مشکل بوجود میاد، چیکار کنم؟


⚠️ پاسخ بسیار ناقص و احتمالا پر از غلط بنده
ببین شما باید idempotency رو رعایت کنی بین microservice هات. این خودکفایی یا همون idempotency اینو میگه که وقتی شما message driven کار میکنی سرویس هات باید انتظار اینو داشته باشن که یه unique message رو بیش از یکبار دریافت کنن ولی فقط یکبار proccess کنن. برای message broker ها سه تا service quality وجود داره
at most once delivery
exactly once delivery
at least once delivery

به خاطر همین مشکلات network و delivery و چیزهای دیگه exactly once delivery خیلی کار سختیه، حالت اول و سوم رایج تر بنظر میاد. در حالت at most delivery هر سرویس نهایتا یک بار یه event رو دریافت میکنه، پس اصلا نیاز نیست نگران idempotency باشه و بیشتر به درد بیزینس هایی میخوره که miss شدن یه event مشکلی ایجاد نکنه، مثلا notification های یه سایت خبری
حالت سوم که at least once delivery هست احتمال دریافت یه event بیش از یکبار وجود داره ولی خب تضمین میکنه حتما هر consumer یکبار اون event خاص رو حداقل دریافت میکنه.
در مورد چالش شما، شما حالت سوم رو لازم دارید، پس سرویس مقصد باید انتظار داشته باشه یه مسیج رو حتی چندبار دریافت کنه به خاطر مشکلاتی که گفتید، و این طبیعیه و مشکلی نداره. سمت سرویس consumer باید مثلا id پیام و job های process شده رو ذخیره کنه و با دریافت هر پیام جدید چک کنه آیا این پیام قبلا پردازش شده یا نه، اگه پردازش نشده بود پردازشش کنه.
اینطوری سرویس publisher دیگه نگران این نیست حالا اگه message تو broker رفت و جدول دیتابیس آپدیت نشد چی میشه، هیچی نمیشه، یه بار اضافه تر یه سری پیام رو میریزه تو broker که مشکلی نیست.
ضمنا یه سری broker ها مفهوم message deduplication دارن که برای اون حالت exactly once به کار میاد، اینطوریه که خود broker میاد id پیام های ریخته شده در broker رو نگه میداره (حتی تا مدتی بعد از consume شدنشون)، اینطوری اگه مجددا همون message رو با id تکراری بهش بدی خودش متوجه میشه و ignoreش میکنه

در مورد transactional outbox و idempotency و message deduplication سعی کن یه مطالعه ای داشته باشی، مرسی

https://segment.com/blog/exactly-once-delivery/

این پادکست هم شنیدنش شاید کمک کنه
Eventually consistent (managing data at scale)
https://changelog.com/gotime/206

#qa #distributed_systems

@gocasts

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

مثلا زبان C# یه زبان کامپایلری هست. اما کد شمارو به machine code کامپایل نمیکنه. بلکه به یه زبان میانه که اصطلاحا Common Intermediate Language (CIL) میگن کامپایل میکنه. سپس با استفاده از Common Language Runtime در زمان اجرا کد زبان میانه رو به کد زبان ماشین تبدیل میکنه. که اصطلاحا این کار رو Just-in-Time compile میگن. کاری مشابه به زبان Java. نکته مهم JIT اینه که کد رو کش میکنه. پس در واقع هر چقدر که از اجرای برنامه میگذره، برنامه شما سریعتر میشه!

اما خب زبان های مفسری هم بیکار ننشستن. اونا هم راه حل های خودشون رو دارن برای سریعتر اجرا شدن برنامه، یکی از متدوال ترین راه ها استفاده از compiled libraryهایی هستند که مثلا در زبان C++ نوشته شدن و در زبانی مثلا مثل Python شما فقط از API اون کتابخونه برای فراخوانی کد در زمان اجرا استفاده میکنید، بدون اینکه متوجه بشید این کد در چه زبانی نوشته شده و چطوری اجرا میشه

https://qr.ae/pv28iE

#compiled_language #interpreted_language

@gocasts

سلام به همه دوستان گل، امیدوارم که حالتون خوب باشه

سالروز شهادت امیرالمؤمنین را به محضر مقدس حضرت بقیه الله الاعظم علیه السلام و همه ی شیعیان حضرت تسلیت عرض می کنم.


Interface Pollution

مدت ها به این موضوع فکر کردم. و وقتی این عبارت به فکر میکنم، اولین چیزی که به ذهنم میاد اینه که خب interface pollution معنی عامیانه ش این میشه که الکی الکی برای هر کاری همه جا interface بسازیم.
یه ذره که بیشتر تحقیق کردم دیدم در اصل این قضیه وقتی ایجاد میشه که به قول uncle bob شما اصطلاحا یه سری fat interface دارید. مثلا در نظر بگیرید که شما یه repository interface تعریف کردید، که برای entity های مختلف کاربرد داره و مثلا ۱۵، ۲۰ یا حتی بیشتر متد داره. حالا تصور کنید که یکی از سرویس هاتون که از همین repository استفاده میکنه و فقط ۲، ۳ تا متدش رو فراخوانی میکنه. حالا تصور کنید این سرویس به خاطر مسائل perofrmanceی یا هر چیز دیگه ای میخواد از یه repository دیگه استفاده کنه که مثلا in-memory باشه که latency خواندن و نوشتن داده ها در دیتابیس کمتر بشه. خب اون adapter جدید مجبور میشه الکی الکی متدهایی رو پیاده سازی کنه که لازمشون نداره. در حالیکه اگه interface ها به اندازه و کوچکتر تعریف میشدند، این مشکل نبود. این قضیه با رعایت کردن اصل چهارم SOLID یعنی Interface Segregation Principle قابل حل شدنه.

مثلا ما در پروژه adamak برای هر سرویس یک repository در نظر گرفتیم و با این کار سعی کردیم اصل چهارم SOLID رو رعایت کنیم.
https://severinperez.medium.com/avoiding-interface-pollution-with-the-interface-segregation-principle-5d3859c21013


اما حالا اگه در مورد golang بخوایم صحبت کنیم. نکات دیگه ای هم مهمه که خود من هم گاها رعایتشون نمیکنم. برای اینکه در کدهایی که با زبان Go مینویسید مشکل interface pollution اتفاق نیفته، میشه یه سری کارها کرد
اول اینکه از تعریف کردن interface تا حد امکان بپرهیزید. مگر اینکه پکیج شما واقعا generic-use functions داشته باشه. مثلا تابع Copy یکی از این توابع است. که پکیج io برای آن Writer و Reader را به صورت interface تعریف کرده.

دوم اینکه اگر کاربر یا همان کلاینت های پکیج شما به سطحی از «وارونگی کنترل» یا همان inversion of control احتیاج دارند بهتر است در scope خودشان این کار را انجام دهند. کاری که ما با نوشتن interface هایی مثل store در پروژه adamak انجام می دهیم.
https://github.com/gocastsian/adamak/blob/main/contract/user_store.go

دقت کنید این کار را در scope مرتبط با interactor مورد نظر انجام میدهیم (البته در پکیج contract) و هیچ پکیج خارجی ای را مجبور به expose کردن interface نمیکنیم.
همین قضیه برای تست نوشتن هم صدق می کند. گاها کلاینت ها از شما می خواهند یک interface را در پکیج خود expose کنید که کار mock کردن را برای آنها ساده تر کنید. که در اینجا هم می توان به آنها گفت که کلاینت در scope خودش یک interface تعریف کند که تنها متدهای مورد نیازش را در آن interface قرار می دهد.


type acknowledger interface {
Ack(sub string, id ...string) error
}

type mockClient struct{}

func (c *mockClient) Ack(sub string, id ...string) error {
return nil
}

var acker acknowledger = pubsub.New(...)

acker = &mockClient{} // in the test package


باز دقت کنید که تعریف interface در صورت لزوم توسط پکیج (کلاینت) استفاده کننده در همان scope تعریف می شود و پکیج شما لازم نیست interfaceی را expose کند.
https://rakyll.org/interface-pollution/

البته باید در نظر بگیریم که adamak یک web service هست و شاید مثال زدن از آن برای این قضیه سخت باشه. چون عملا خیلی از پکیج های adamak خودشون کلاینت هستند و پکیج های عمومی کمتر توسعه داده میشه در اینطور سرویس ها.


#interface_pollution #solid #golang
@gocasts

سلام رفیق!

دوستان امیدوارم حالتون خوب باشه

برای اینکه ارتباط بهتری باهاتون داشته باشم قصد دارم ان شاءالله در قالب یه خبرنامه در خدمتتون باشم.
لطفا اگه تمایل داشتید در خبرنامه عضو بشید.

فعالیت GoCasts همچنان مثل قبل ادامه خواهد داشت. احتمالا فعالیت !Hey Mate دامنه گسترده تری از دنیای نرم افزار رو ان شاءالله پوشش خواهد داد.

https://heymate.ir/?utm_source=telegram&utm_medium=message&utm_campaign=1

#heymate

@gocasts

سلام خدمت همه عزیزان
یه voice برای یکی از عزیزان ارسال کردم، دیدم شاید به کار شما هم بیاد

یه راه خیلی موثر برای تقویت دانش مهندسی نرم افزار و زبان Go بصورت همزمان که اعتبار رزومه ای خیلی خوبی هم داره، همه تونم میشناسید ولی کسی عمل نمیکنه!

اینم یه لیست که خیلی محدوده و خیلی بیشتر از اینها میتونید پروژه خوب گولنگی پیدا کنید
https://github.com/ethereum/go-ethereum
https://github.com/pingcap/tidb
https://github.com/meshbird/meshbird
https://github.com/dgraph-io/dgraph
https://github.com/dapr/dapr
https://github.com/chrislusf/seaweedfs
https://github.com/etcd-io/etcd
https://github.com/hyperledger/fabric
https://github.com/micro/micro
https://github.com/rqlite/rqlite
https://github.com/uber/cadence
https://github.com/nsqio/nsq
https://github.com/hashicorp/consul
https://github.com/jaegertracing/jaeger
https://github.com/cockroachdb/cockroach
https://github.com/pion/ion

عضویت در خبرنامه Hey Mate 👇
heymate.ir

@gocasts

سلام به همگی، امیدوارم حالتون خوب باشه

اولین جلسه GoCasts ان شاءالله فردا دوشنبه ۱۲ اردیبهشت، ساعت ۱۸ تا ۱۹ برگزار میشه

امسال احتمالا جلسات ۲ هفته یک بار برگزار بشن

این هفته سعی میکنیم در مورد data serialization و data flow ها صحبت کنیم

@gocasts

عضویت در خبرنامه Hey Mate 👇
heymate.ir

سلام دوستان، ان شاءالله جلسه ۱۸:۱۵ دقیقه با ۱۵ دقیقه تاخیر برگزار میشه در گوگل میت

لینک جلسه
https://meet.google.com/dsg-rvun-kns

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

فیلم جلسه در یوتیوب بارگذاری شد
اینم لینک مقدمه جلسه
https://blog.heymate.ir/data-encoding-zm7hyn9lt2gu?utm_source=telegram&utm_medium=message&utm_campaign=9

لینک ویدیو
https://youtu.be/0aqhFMkIq3s

فیدبک و اصلاحیه امید حکایتی جان
https://news.1rj.ru/str/c/1525472919/1231

#gocasts_weekly #data_encoding #designing_data_intensive_applications

@gocasts


عضویت در خبرنامه Hey Mate 👇
heymate.ir

توضیحات در مورد لایه entity و دیدگاه کلی معماری پروژه آدمک

https://github.com/gocastsian/adamak

#clean_code #software_architecture #project_structure #entity

@gocasts


عضویت در خبرنامه Hey Mate 👇
heymate.ir

توضیحات در مورد لایه interactor و بحث Inversion of Control در SOLID و validator و contract

#software_architecture #project_structure #interactor #solid

@gocasts

با تشکر از دوست خوبم @finiteloop بابت اصلاحیه
من اشتباها inversion of control رو جای Interface Segregation در SOLID گفتم که درستش میشه Dependency Inversion یعنی حرف D در SOLID

عضویت در خبرنامه Hey Mate 👇
heymate.ir

توضیحات مرتبط با delivery layer و adapter

https://github.com/gocastsian/adamak

#software_architecture #project_structure #adapter #delivery #port

@gocasts


عضویت در خبرنامه Hey Mate 👇
heymate.ir

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

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

https://news.1rj.ru/str/AliMDSchool/229


@gocasts

سلام به همگی
اسلایدهایی که در جلسه قبل ارائه شد رو خدمتتون ارسال میکنم

Encoding and Evolution


@gocasts

عضویت در خبرنامه Hey Mate 👇
heymate.ir

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

@gocasts


عضویت در خبرنامه Hey Mate 👇
heymate.ir

میلاد جان در ادامه افزود 😁:
من رزومه ام رو با لینکدین ساختم شاید اینم براشون جالب باشه
از لینکدین استفاده کنن رزومه استاندارد خوبی میتونن بگیرن

@gocasts

#resume

سلام دوستان

نمیدونم بگم چقدر از شنیدن این خبر خوشحال شدم، الهی که همگی تون زیر سایه مهر خداوند و لطف امام زمان خوب و خوش و موفق باشید 🌹

در مورد نقشه راه هم باز تاکید میکنم که دوستان لطفا جدی بگیرید، نقشه راه در عین حال که کوتاه و سریعه، واقعا سعی کردم همه آن چیزی که احتیاج دارید تجربه کنید تا بتونید به عنوان Go Developer استخدام بشید رو پوشش بده. تو دنیای امروزی روی هر موضوعی دست بذاری به تعداد همه آدم ها منبع متفاوت و متنوع پیدا می کنید. من اصلا نمیگم چه منبعی رو بخونید یا نخونید، من فقط میگم «پایبند» بمونید به منبعی که دارید و حتما چند تا پروژه هرچند کوچک رو هم «تا آخر» انجام بدید.

لطفا نقشه راه رو جدی بگیرد❤️

@gocasts

عضویت در خبرنامه Hey Mate 👇
heymate.ir