سلام به همه دوستان خوبم
امیدوارم نوروز خوبی رو تا به اینجا سپری کرده باشید.

در مورد چالش معماری اول، من سعی کردم راه حل های پیشنهادی رو به صورت خلاصه در مقاله بررسی کنم و راه حل پیشنهادی خودم که transactional outbox بود رو شرح بدم. امیدوارم که مفید باشه، اینم لینک مقاله:
https://gocasts.ir/software-architecture-challenge-1?utm_source=telegram&utm_medium=message&utm_campaign=8

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

MarshalMan
koorosh_sa
mehdi_sadeghi_1996
OmidHekayati
Mohamadrezamomeni96
AmirHasanCE


#gocasts_challenge
#architecture

@gocasts

اصلاحیه: من در نیازمندی ها inconsistency نداشتن رو معیار قرار داده بودم، که امیدجان حکایتی به درستی اشاره کردند که باید مشخص بشه و از inconsistency نبودن، نمیشه لزوما برداشت eventual consistency داشت، حالا فارغ از اینکه بخوایم سر این موضوع بحث کنیم، تذکر ایشون بجاست و من باید رسما از عبارت eventual consistency استفاده میکردم نه inconsistency نداشتن
مرسی از شما
@OmidHekayati

سلام دوستان
اخیرا این بحث مطرح شده که توییتر قابلیت ویرایش رو اضافه کنه
این لینکی که گذاشم از طرف یکی از مهندسین سابق توییتر هست در مورد مشکلات مهندسی اضافه کردن قابلیت ادیت به سیستمی که بیش از یک دهه برای read در scale بالا بهینه شده
https://twitter.com/mjackson/status/1511790796135022598?s=19

در کتاب designing data intensive applications و احتمالا کلی جای دیگه هم میتونید از راه حل های استفاده شده در توییتر برای ساختن feed شخصی سازی شده از توییت ها برای هر کاربر بصورت اختصاصی آگاه بشید.
توییتر از ساختار hybrid استفاده میکنه (حداقل تا چند سال پیش). در این ساختار وقتی کاربری یک توییت رو منتشر میکنه، برای تک تک کاربرانی که کاربر مورد نظر رو follow می کنند، یک نسخه از توییت در message queue اختصاصی اون شخص قرار میگیره. اینطوری feed هر کاربر بصورت خودکار ساخته میشه و هر وقت کاربر بخواد feedش رو چک کنه توییتر لازم نیست هیچ کاری بکنه جز اینکه message های message queue اختصاصی اون شخص رو consume کنه.
اما این کار یه اشکالی داره، اشکالش اینه اگه کاربر منتشر کننده تعداد فالوئرهای زیادی داشته باشه مثلا ۲۰ میلیون کاربر، اونوقت توییتر مجبور میشه ۲۰ میلیون write در لحظه انتشار توییت انجام بده که خیلی عملیات سنگینیه. واسه همین از روش hybrid استفاده می‌کنه یعنی کاربرانی که فالوئر زیادی دارن توییت هاشونو در message queue وارد نمیکنه، بلکه اپلیکیشن کلاینت وقتی میخواد feed توییت رو لود کنه هم یه سری توییت از message queue میگیره و هم یه درخواست میزنه و لیست توییت های جدید کاربران پرمخاطبی که کاربر دنبال میکنه رو میگیره و این دو تارو ترکیب میکنه. اینطوری reaponse time خیلی معقول باقی میمونه چون تعداد فالوئرهای پرکاربر و توییت هاشون محدوده
حالا مشکلی که در این thread بهش اشاره کرده اینه که سیستمی که برای بیش از یک دهه روی read بهینه شده خیلی سخته بهش قابلیت edit اضافه کنن چون خیلی چیزارو بهم میریزه.

شما ایده ای ندارید؟

اصلاحیه:
با تشکر از امید جان حکایتی بابت تذکر
طبق این مقاله
http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html

البته مقاله قدیمی هست ولی چندین جاش تاکید کرده صرفا tweetid در سرویس تایملاین ذخیره میشه

Then it will start inserting the Tweet ID of the tweet into all those lists throughout the Redis cluster

What is being stored is the tweet ID of the generated tweet, the user ID of the originator of the tweet, and 4 bytes of bits used to mark if it’s a retweet or a reply or something else.

Since the timeline only contains tweet IDs they must “hydrate” those tweets

#software_design #twitter

@gocasts

هر چقدر از خوبی این مقاله بگم، کم گفتم!
واقعیتش من اصلا در مورد Generics ذوق زده نشدم و همچنان تا وقتی که واقعا در کارم لازمش نداشته باشم سمتش نمیرم

این مقاله تکنیکال به زیبایی هر چه تمام تر نحوه پیاده سازی Generics در Go رو توضیح میده و کاملا شفاف توضیح میده که چرا در خیلی از موارد استفاده از Generics کد شما رو کندتر میکنه. برای من هم عجیبه که چرا در طراحی Generics اضافه شدن runtime overhead رو به کند شدن مرحله کامپایل ترجیح دادند. مقاله خیلی تکنیکاله ولی حتما مقدمه و موخره ش رو حداقل بخونید.

Generics can make your Go code slower
https://planetscale.com/blog/generics-can-make-your-go-code-slower

#generics #golang

@gocasts

سلام به همه عزیزان

ولادت امام حسن مجتبی علیه السلام هم مبارک 🌹❤️

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

ایمان جان جز بهترین افراد ایرانی هست که روی پروژه لاراول خیلی contribute داره و چندین تا پلاگین خوب هم برای لاراول نوشته. با اینکه هیچوقت علاقه ای به php نداشتم ولی واقعا احترام زیادی براشون قائلم. لقب web artisans به حق مناسبشونه. نه تنها php/laravel، بلکه ruby on rails و python/django و جدیدا elixir/phoenix هم به همچنین. خیلی اوقات چالشی که برای ما در گولنگ خیلی حل کردنش سخته، در فریمورک های مذکور بهترین راه حل ها براش ارائه شده.
بشدت پیشنهاد میکنم حتما سعی کنید باهاشون آشنا بشید و کمی در مورد best practice هاشون بخونید. فارغ از اینکه دید مهندسی نرم افزار خیلی بهتری میگیرید، ممکنه یه روزی به کارتونم بیاد. چون خیلی از شرکت های بزرگ چه داخلی، چه خارجی احتمالا یه سری از legacy project هاشون با یکی از این فریمورک ها هست و وقتی وارد شرکت می‌شید دونستن این موارد مزیت محسوب میشه.

اینم کانال آقا ایمان
https://news.1rj.ru/str/codino

در مورد ایمان جان، میتونید اینجا کامیت های مرج شده ش روی لاراول رو ببینید.
https://github.com/laravel/framework/pulls?q=is%3Apr+is%3Amerged+author%3Aimanghafoori1+


من خودم بعضی از دوره هاشو خریداری کردم، نه فقط به خاطر اینکه php یاد بگیرم، بلکه بیشتر به خاطر اینکه بفهمم best practice ها در لاراول چیه و کدومشون رو میتونم استفاده کنم. ضمنا اصولی مثل SOLID یادگیریش در یه زبان fully OOP شاید راحت تر از گولنگ باشه که بیشتر data oriented هست.

بازم تاکید میکنم این پیام اصلا تبلیغاتی نیست و نکاتی که اشاره کردم واقعا میتونه کاربردی باشه.


دم همه تون گرم 🌹

ان شاء الله خداوند عمر و سلامتی بده از هفته بعد جلسات GoCasts رو از سر میگیریم 💪

@gocasts

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

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

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

🙋‍♂️ سوال
من ۲ تا 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