مقاله خوب و جذابی بود، پیشنهاد میکنم بخونید

یه جمله خیلی کلیدی داشت بنظرم که این جمله ست:
"As noted above, our major bottleneck is network IO, and Stephen mentioned this line from the SQLite documentation: "SQLite does not compete with client/server databases. SQLite competes with fopen()."

Rearchitecting: Redis to SQLite
https://wafris.org/blog/rearchitecting-for-sqlite


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515

@gocasts

وقتی نوبت به نوشتن manifestهای کوبرنتیز میرسه، اسم دو تا ابزار وسط میاد، یکی helm و دیگری kustomize.

به شخصه از این نظر که kustomize همون رویه manifest اصلی کوبرنتیز رو حفظ میکنه و خوانایی خوبی داره، ترجیحش میدم.

اما خب برای اینکه شما در multi environment بخواید استفاده کنید و تفاوت های محیط ها پیچیده باشه شاید helm گزینه بهتری باشه.


در کل هم فکر میکنم کامیونیتی بیشتر helm رو پذیرفته و پیدا کردن helm chart راحت تره برای خیلی از سرویس ها.

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

این مقاله توضیحاتی در مورد تفاوت هاشون داده.
https://blog.devops.dev/helm-vs-kustomize-when-to-use-which-tool-in-kubernetes-6500d72ca4b4


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515

@gocasts

داشتم یه نگاهی به کتاب foundations of scalable systems مینداختم که یه بخشی ش در مورد مقیاس پذیر کردن دیتابیس به کمک کش صحبت میکنه.

A well-designed caching scheme can be invaluable in scaling a system. Caching
works great for data that rarely changes and is accessed frequently, such as inventory
catalogs, event information, and contact data. If you can handle a large percentage,
say, 80% or more, of read requests from your cache, then you effectively buy extra
capacity at your databases as they never see a large proportion of requests.

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

استراتژی های caching یکی از همون اصول ساده و مهمه که به مقیاس پذیری سیستم خیلی کمک میکنه.

کش کردن استراتژی های مختلفی داره و نباید کورکورانه استفاده بشه، چالش و دغدغه هایی هم ایجاد میکنه مثل مساله invalidate کردن کش یا thundering herd که در موردش چند روز پیش صحبت کردم.

کش کردن تو لایه های مختلف استفاده میشه و شما میتونید از مزایای این استراتژی در همه لایه ها استفاده کنید.

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

برای کمتر شدن لود سرور میتونید از cdn استفاده کنید که assetهای شمارو کش کنه.

سرویس gateway شما میتونه یه سری api رو کش کنه که لود روی اپلیکیشن شما نیفته.

اپلیکیشن شما میتونه هم روی http server یه سروی api رو کش کنه و هم میتونه تو لایه کوئری زدن به دیتابیس یه سری کوئری ها رو کش کنه.

سرویس دیتابیس هم معمولا خودشون استراتژی های مختلفی دارن برای کش کردن کوئری ها.

سیستم فایل و دیسک هایی که دیتابیس ها استفاده میکنن هم خودشون pageهای دیسکی که بیشتر استفاده میشه رو کش میکنن.

سیستم عامل هم خودش چندین لایه کش داره.


بصورت آشکار و نهان کش یکی از راه های ساده و قوی هست، اما باید با فکر و تحلیل ازش استفاده کنید.

@gocasts

سه سال پیش در یک مجموعه پست، به صورت خلاصه کتاب designing distributed systems رو در تلگرام منتشر کردم.

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

نویسنده کتاب هم co-founder ابزار kubernetes هست.

با این هشتگ میتونید به خلاصه ها دسترسی داشته باشید.

#designing_distributed_systems_brendan_burns


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515


@gocasts

با ما بپّر، یه جایی قُلابت گیر میکنه!

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

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

با تسک دادن و به چالش کشیدن ذهنت برای طراحی سیستم، درگیرت میکنیم که یه جایی مفاهیم تو ذهنت کلیک بخوره.

سعی میکنیم چالش هایی که طراحی میکنیم به چالش های واقعی مهندسی نزدیک باشه که شرایط برای کلیک خوردن مفاهیم فراهم بشه.

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

تصویر حاضر، فیدبک یکی از بچه های شرکت کننده در دوره + تیمسازی ۳ هست

توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515


@gocasts

خلاصه ش اینکه تو شرکت خودروسازی Volvo دارن rust رو برای ECU ماشین ها استفاده می کنن و حالش رو میبرن


https://tweedegolf.nl/en/blog/137/rust-is-rolling-off-the-volvo-assembly-line


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515


@gocasts

آقای Martin Fowler رو احتمالا بشناسید، کتاب های زیادی در مورد مهندسی و معماری نرم افزار نوشته.

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

Software Architecture Guide
https://martinfowler.com/architecture/


@gocasts

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

https://news.1rj.ru/str/durov/355


@gocasts

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

اما این ابزار بنظرم جالب بود، خودم تا حالا امتحانش نکردم، شاید اگه دنبال توسعه خیلی سریع یه سری crud api ساده باشید این ابزار خیلی تسریع کنه روند توسعه رو براتون.

Sponge is a powerful Go development framework, it's easy to develop web and microservice projects.

go-sponge.com
https://github.com/zhufuyi/sponge


@gocasts

واقعا لذت بردم از این مقاله

نکات ساده و مهمی رو درباره تست نویسی با گولنگ میگه، یه ابزار رو هم معرفی میکنه برای visualize کردن تست ها که خودش نوشته و کمبودش حس میشد در tooling گولنگ.

خودم بارها حین اجرای تست ها در پایپلاین های ci/cd به مشکلات متفاوتی برخوردم در مورد نحوه اجرای موازی یا سریالی تست ها، مخصوصا setup و cleanup کردن ها و migration های دیتابیس برای پکیج های متفاوت که تست دارند میتونه چالش زا باشه و تست ها رو با random behaviour و random failure مواجه کنه.

Optimising and Visualising Go Tests Parallelism: Why more cores don't speed up your Go tests
https://threedots.tech/post/go-test-parallelism/

در مورد تست نویسی این ویدیوهارو در یوتیوب دو سه سال پیش ضبط کردم، بد نیست ببینید
https://news.1rj.ru/str/gocasts/153


همچنین این سری مقاله ای که معرفی کردم ساده و خوبه، سر فرصت بخونید و استفاده کنید
https://news.1rj.ru/str/gocasts/37



توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515


@gocasts

#unit_test #test #gocasts #golang

خیلی performance برات مهمه؟ پس احتمالا خوندن این مطلب برات جذاب باشه.

بخشی از کتاب «Efficient Go» رو میخوندم، دقت کنید به کلمه «Efficient» که به معنی «کارآمد» یا «اثربخش» هست. کارآمد بودن لزوما به معنی سریع بودن نیست، لزوما به معنی کمترین مصرف منابع نیست، لزوما به معنی مقیاس پذیر بودن نیست.

خیلی از دیدگاه نویسنده خوشم اومد که تلاش میکنه مخاطب رو تشویق کنه که «نرم افزار کارآمد» بنویسه.


نویسنده معنای software performance رو «how well software runs» یا «به چه میزان نرم افزار خوب کار میکنه» میدونه و سه تا آیتم اصلی رو در نظر میگیره به عنوان اجزای performance که یکی «accurace» هست، یکی «speed» و یکی هم «efficiency».

که accuracy رو میشه نسبت به میزان خطاهای سیستم سنجید. و speed هم میتونه latency یا throughput باشه.
نویسنده efficiency رو نسبتی از بهینگی مصرف منابع در مقایسه با منابع اختصاص یافته میدونه. مثلا فرض کنید که برای خوندن ۶۴ بایت دیتای ارزشمند، نرم افزار شما ۴۲۰ بایت از حافظه RAM رو اشغال کنه، در این صورت بهینگی شما ۱۵ درصد هست.

البته نویسنده اشاره میکنه که efficiency یا کارآمدی تک بعدی نیست و میزان زمان cpu و ابعاد دیگه هم بسته به نوع تسک و کار انجام شده باید در نظر گرفت.


همچنین نویسنده میزان performance رو چنین فرمولی در نظر میگیره:
performance = (accuracy * efficiency * speed)

و میگه که بهبود هر کدوم از آیتم های ذکر شده به بهبود performance کمک میکنه و میتونه reliability, availability, resiliency, overall latency رو بهبود بده.


Efficient Go
https://www.oreilly.com/library/view/efficient-go/9781098105709/



توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515

@gocasts

#golang #performance #efficiency

معرفی یه دوره ناب

چهار سال پیش به توصیه استاد عزیز مصطفی جان صولتی شروع کردم به دیدن دوره ویدیویی uncle bob

و نمیتونم بگم دیدن این دوره، حتی در حد ۱۰، ۱۵ جلسه اولش، چقدر به شما دید خوبی میده در مورد مسائل مختلف مهندسی نرم افزار

این دوره رو نبینید که نکاتش رو حفظ کنید، این دوره رو ببینید که از قدرت تحلیل بهره مند بشید.

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

اون موقع وقت و حوصله بیشتر بود و نکته برداری میکردم و تحلیل میکردم، به همه تون دیدن این سری ویدیویی رو توصیه میکنم

https://cleancoders.com/library/all


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515


@gocasts


#uncle_bob #clean_architecture #clean_code #software

به لطف خدا یکسال از شروع تیمسازی گذشت!

بیش از ۲۰ برنامه نویس در تیمسازی دو پروژه فعال بودند که یه تعدادی از بچه ها استخدام بودند و دنبال شغل نبودند، و از بین افراد باقی مانده حداقل ۵ نفر استخدام شدند.

بیش از ۱۵۰ درخواست merge request پذیرفته شد و مرج شد

بیش از ۷۰ ساعت جلسه آنلاین تیمسازی داشتیم در ۵۰ هفته گذشته


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

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


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515


@gocasts

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

داشتن آشنایی حداقلی با این زبان بهتون ایده میده که نقش کامپایلر و مفسر چیه و یه کامپیوتر به چه شکلی برنامه های مارو اجرا میکنه.

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

آشنایی حداقلی ش رو به همه تون پیشنهاد میکنم.

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

https://www.amazon.com/80X86-IBM-Compatible-Computers-Programming/dp/0137584830

https://B2n.ir/h54058

این سه تا مقاله میتونه شروع خوبی باشه

https://shikaan.github.io/assembly/x86/guide/2024/09/08/x86-64-introduction-hello.html

https://shikaan.github.io/assembly/x86/guide/2024/09/16/x86-64-conditionals.html

https://shikaan.github.io/assembly/x86/guide/2024/09/26/x86-64-functions.html


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://news.1rj.ru/str/gocasts/515


@gocasts

من خودم به شخصه سعی میکنم از همون اول repository پروژه رو تنظیم کنم که fast forward mergeهارو بپذیره.

اینطور با استراتژی feature branching پیش میرم و هر موقع که قرار بود با main مرج بشه برنچ مد نظر باز یه بار rebase یا merge میکنم برنچ رو (ترجیح rebase هست) و در نهایت یه commit به عنوان merge commit روی برنچ main اون feature branch رو مرج میکنم بصورت fast-forward.

اینجا در موردش بیشتر میتونید بخونید
What Is a Git Merge Fast Forward?
https://blog.mergify.com/what-is-a-git-merge-fast-forward/


Git Branching Strategies
https://newsletter.techworld-with-milan.com/p/git-branching-strategies

@gocasts

تا حالا شده در محیط کار احساس ناکافی بودن کنید؟ یا اینکه از سمت مدیرتون فیدبک ضعیف بودن دریافت کنید؟ یا حتی اعتماد به نفس تون رو از دست داده باشید که احتمالا من برای این کار خوب نیستم؟


همین اول کار بگم بهتره که تلاش کنید «اعتماد به نفس» رو درونی کنید، وابسته ش نکنید به عوامل خارجی و یا فیدبک دیگران. من نمیگم «غرور کاذب» داشته باشید، نه. ولی «اعتماد به نفس» اگه در شما درونی باشه، بهتون کمک میکنه در مواجهه با اتفاقات تصمیم درستی بگیرید، و جای اینکه در خودتون به دنبال تغییر باشید، در محیط دنبال تغییر بگردید.


اگه فیدبک بدی گرفتید از مدیرتون قبل از اینکه به فکر سرزنش خودتون باشید و یا حتی نکوهش مدیر، ببینید چه قسمت هایی از پروسه کاری و تعامل تون با مدیر مشکل داره، سعی کنید اول نحوه تعامل تون رو اصلاح کنید و یا پروسه هایی که به طور روزمره در کارتون برای انجام تسک ها دارید رو بازبینی کنید.
به طور مثال میگم، دوست عزیزی چند وقت پیش ناراحت بود از اینکه کدی که نوشته شده، توسط مدیرش بطور کامل بازنویسی شده، و این موضوع باعث شده که احساس خوبی نداشته باشه.
یا میگفت که شخص پروداکت تغییرات زیادی درخواست میده در حین کار در حالیکه در نهایت مسئولیت تغییرات رو هم نمیپذیره.
خب من حدس میزنم که در این مورد نه مدیر فنی مقصره و نه شخص برنامه نویس، اینجا پروسه تعامل و انجام تسک مشکل داره، تسک بهتره قبل از انجام refine بشه از نظر بیزینسی و داکیومنت بشه و همچنین قبل از انجام حتما solution design فنی داشته باشه. شرکت بهتره ساختار و چارچوب code review داشته باشه و فرآیند کد ریویو بصورت زود به زود انجام بشه.
خیلی اقدامات وجود داره که میتونه روند کاری شما و تیم و شرکت تون رو بهتر کنه، دنبال مقصر نباشید، جنگ روانی و اعصاب برای خودتون و دیگران ایجاد نکنید. با اراده تلاش کنید پروسه های تعاملی و کاری رو بهبود بدید و در این مورد با مدیرتون خیلی شفاف صحبت کنید.



@gocasts

آپدیت تیمسازی + فیدبک یکی از دوستان نسبت به دوره

این هفته ها با بچه های تیمسازی ۳ بیشتر مشغول solution design و آماده کردن code structure برای پروژه ای هستیم که یه پلتفرم برای رستوران و کافه ها باشه، و سعی کردیم با جدا کردن domain های بیزینسی یه سری microservice رو توسعه بدیم.

هر چند که به شخصه دغدغه ای بابت monolith یا microservice بودن ندارم و دلایلم رو در دوره روی کد گفتم که چرا این سوال اون قدرها هم سوال مهمی نیست، هر چند که microserivce بودن overheadهای خودشو داره.

تخفیف پاییز «دوره +‌تیمسازی» در آبان ماه هم پابرجاست

دوره +‌ تیمسازی بکند و گولنگ Go Casts
لینک خرید دوره + تیمسازی با ۵۰ درصد تخفیف به مبلغ ۴ میلیون و ۵۰۰ هزار تومان

https://gocasts.ir

همه چیز در مورد دوره و تیمسازی در این پست توضیح داده شده
https://news.1rj.ru/str/gocasts/434

تو این پست هم میتونید فیدبک های دوره و تیمسازی و استخدام بچه هارو بخونید
https://news.1rj.ru/str/gocasts/441

دوستانی که در خرید دوره تردید دارند میتونن برای مشاوره کوتاه تلفنی، فرم زیر رو پر کنند که باهاشون تماس بگیرم
https://survey.porsline.ir/s/ATeQL4b4

@gocasts

سلام دوستان
اگه تجربه ای با redis callback listener رو key expiration دارید بهم بگید لطفا، چه در گولنگ و چه در زبان های دیگه.


میخوام بدونم چالش خاصی برای پیاده سازی و پرفورمنس داره یا خیر.


کجا میخوام استفاده ش کنم؟ پیاده سازی retry برای تسک ها

به سری جاب تو ردیس دارم، که قراره http request بشه، حالا میخوام اگه fail شد دوباره به عنوان کلید بذارمش تو ردیس با یه ttl که موعد ttl رسید ایونت حذف شدنش از ردیس رو بگیرم و مجدد اجراش کنم، حالا اگه retry threshold هم رسیده بود که کاریش ندارم و در صورت fail دیگه ignore ش میکنم. اون مقدار retry count هم تو همون value مربوط به کلید ردیس ذخیره میکنم.

راه حل زیاده ولی بنظرم این راه حل ساده ایه برای وقتی که خیلی miss شدن جاب حیاتی نباشه.

تجربه و پیشنهادی داشتید بگید.


@gocasts

نگرانی از آینده شغلی دغدغه خیلی هاست.
این نگرانی فکر میکنم تو شروع مسیر بیشتره و تاثیرگذار تر.

نگرانی ها متفاوت هست مثلا یکی دغدغه ش اینه که تو مسیر جدید به درآمد کافی میرسم یا نه، یکی دغدغه هوش مصنوعی رو داره که نکنه شغل من حذف بشه و فلان بشه.

چیزی که من بهش فکر میکنم اینه که در نهایت شما باید موفق شدن رو اول از همه به خودتون ثابت کنید.

مهم نیست اون موفقیت چقدر دوام داره، چقدر درآمد میاره و غیره...

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

راه رسیدن به موفقیت هم اول و آخرش به تلاش شما وابسته ست.

وقتی که یک مهارت رو کسب میکنید و به موفقیت نسبی میرسید، چند اتفاق مهم رخ میده:

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

دوم اینکه در مسیر کسب مهارت کلی روزنه و فرصت جدید به روی شما باز میشه که تا وارد مسیر نشی و شروع به جنگیدن نکنی نمیتونی پیداشون کنی

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

خلاصه ش اینه که اگه دنبال بهونه میگردی که تلاش نکنی، نیاموزی و نجنگی، بهونه خیلی زیاده.

@gocasts

ما توی داروخانه دیجی‌کالا دنبال مهندسین نرم‌افزاری هستیم که با Go و چند ابزار دیگه تجربه داشته باشن.

لینک موقعیت شغلی

https://jobinja.ir/companies/digikala/jobs/AvLY


@gocasts

مقاله جالبی بود
خیلی فنی و عمیق توضیح داده، ولی کلا خوبه که بدونید این فیچر dedup برای OpenZFS میتونه write to disk رو efficientتر کنه اگه performance نسخه جدیدش قابل قبول باشه.


OpenZFS deduplication is good now and you shouldn't use it
https://despairlabs.com/blog/posts/2024-10-27-openzfs-dedup-is-good-dont-use-it/?utm_source=substack&utm_medium=email

این قضیه مخصوصا تو سرویس های blob storage میتونه کمک کنه، مثلا ceph که به عنوان یکی از solutionهای معروف برای blob storage استفاده میشه از zfs استفاده میکنه به عنوان backend volume
https://docs.ceph.com/en/reef/dev/ceph-volume/zfs/

@gocasts