وقتی ساعت ۱ شب؛ مسواک زدی و داری میری بخوابی که یک دفعه یادت میاد:
نصف پیتزاها که مونده بود تو یخچال هست.

تورج شعبانخانی عزیز هم روحش شاد.
بابت این موسیقی فوق‌العاده ♥️

توی ۳ روز گذشته درگیر یکی از سرورهای لینوکسی مربوط به دیتابیس کلاینت بودیم،
تیم هوش مصنوعی از لحظه‌ای وارد شد که نیاز به آنالیزهای
near realtime
روی دیتاهای دیتابیس بوجود اومد.

اما یک مشکلی هم وجود داشت، زمان خیلی کم بود و پاسخ‌دهی دیتابیس توی بعضی وقتها خیلی طول می‌کشید (بعد آنالیز متوجه شدیم cpu خیلی درگیر می‌شه و حتی بعضی وقتا اجازه هیچ کاری رو نمی‌ده)
راه‌کار ساده اما زمان بر خرید و راه‌اندازی سرور قوی‌تر یا استفاده از دیتابیس بکاپ و ... برای تحلیل‌های تیم هوش مصنوعی.
مورد اول، زمان وجود نداشت
مورد دوم، near realtime بودن راه‌حل که خیلی مهم بود رو از دست می‌دادیم.

به لطف تجربیاتی که بعنوان
Server Administrator
داشتم، بجای دنبال کردن یا منتظر بودن برای راهکارهای تیم‌ها، ترجیح دادم به کمک دستور
sar
آنالیز فایل‌های
/proc
و به لطف اعتماد مدیر ارشد پروژه، ی سری تغییرات رو توی سرور اعمال کنم
مهمتر از همه فعال سازی
Linux Huge Pages
برای دیتابیس بود.

مشکل ما رو این مورد حل کرد، امیدوارم بدرد دوستان دیگه هم بخوره مخصوصاً اینکه پیدا کردن دلیل این مشکل و راه‌حل اون اصلا کار ساده‌ای نبود.

اینم ی بنچمارک جالب روی، postgresql هست :

Benchmark PostgreSQL with Huge Pages

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

Andrew NG
هم توی کورس‌های جدیدی که به تازگی منتشر شد خیلی خیلی روی این موضوع صحبت می‌کنه (چون واقعاً کار توی دنیای واقعی همین هست)

به تازگی تیم DeepLearning.ai بهمراه Landing.ai یک مسابقه رو راه‌اندازی کردند که اتفاقاً اینبار مدل ثابت هست و شما فقط و فقط دیتاهارو می‌تونید تغییر بدید (بسیار مفید) :

Competition Link

توی این گروه من نباید پند زندگی بدم :))

ولی وقتی شما قوانین یک جایی رو چندبار زیرپا می‌ذارید، در انتها نباید از افرادی که اونجا هستن طلب‌کار باشید و بهشون توهین کنید.

تقصیر خودتون بوده.


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

@SohrabContents

اوپن بی‌اس‌دی ۷.۸ منتشر شده و این تغییرات رو به همراه داشته:

۱. بهبود پشتیبانی از پلتفرم‌ها

arm64:

اضافه شدن پشتیبانی از Raspberry Pi 5.

بهبود مدیریت خطاها و جلوگیری از کرش در پردازش صفحات حافظه.

APM و hw.cpuspeed روی Snapdragon X Elite کار می‌کنند.

amd64:

رفع مشکل power button روی ThinkPadهای با AMD.

سایر معماری‌ها: اضافه شدن softintr خاص sparc64.

۲. بهبود کرنل

جلوگیری از کرش احتمالی کرنل با محدود کردن kern.seminfo.semopm.

تغییرات در fork(2) برای ارث‌بری PS_NOBTCFI و PS_PROFILE.

پیاده‌سازی POSIX-2024 close-on-fork flag (با تغییر کوچک امنیتی).

مدیریت بهتر lock nesting با witness(4).

SMP/چندپردازنده: پردازش شبکه و TCP روی چند CPU بصورت موازی.

نمایش وضعیت SEV/SEV-ES AMD و پشتیبانی از GHCB در مجازی‌سازها.

۳. Suspend / Hibernate و مدیریت انرژی

پشتیبانی از lid suspend/resume و wakeup interrupt روی AMD.

رفع مشکلات USB و گرافیک پس از Suspend/Resume.

پیش‌اختصاص فضای Hibernate برای جلوگیری از خطا.

۴. درایورها و DRM

آپدیت drm(4) به Linux 6.12.50.

درایورهای جدید برای Qualcomm Snapdragon DRM و DisplayPort.

بهبود شبکه و WiFi: پشتیبانی از Intel AX210، SoftLRO، TSO و Rx checksum برای برخی کارت‌ها.

۵. VMM / مجازی‌سازی

پشتیبانی از AMD SEV-ES برای ماشین‌های مجازی امن.

بهبود vmm/vmd، پشتیبانی از kvm-clock برای مهمان لینوکس.

حذف send/receive vmd، امنیت بالاتر برای PCI config space.

۶. Userland و ابزارها

تغییر pkg-config به pkgconf 2.4.3 (عملکرد بهتر).

ابزار watch(1) جدید.

بهبود fdisk و vi برای استاندارد POSIX و جلوگیری از کرش.

تغییرات امنیتی: OTP در login_yubikey و فایل‌های PKCS#8 امن‌تر.

بهبود flockfile(3) و سازگاری با UTF-8.

۷. شبکه

TCP/IPv6 موازی روی چند CPU.

SoftLRO برای برخی درایورها، بهبود PF firewall.

رفع مشکلات DHCPv6 و RPKI client با پردازش چند رشته‌ای.

افزودن lldpd, bpflogd و بهبود nc(1) با SOCKS4A و ALPN.

۸. امنیت

بهبود pledge(2) برای stdio و IPv6 TCLASS.

حفاظت بهتر از PCB و kernel stack با guard page.

رفع مشکلات OpenSSH در username و commandline injection.

هشدار در SSH برای الگوریتم‌های Post-Quantum ضعیف.

پشتیبانی بهتر از agent sockets در ssh-agent و مسیر امن‌تر (~/.ssh/agent).

۹. OpenSSH 10.2

بهبود DSCP/IPQoS و مدیریت کانال‌های فعال.

رفع مشکلات MaxStartups و certificate handling.

پشتیبانی از ed25519 روی PKCS#11.

قابلیت SIGINFO برای گزارش وضعیت کانال‌ها و sessionها.

۱۰. LibreSSL 4.2.0

بهبود داخلی AES و عملیات ECC در زمان ثابت.

رفع خطاهای memory leak و use-after-free در CMS و PKCS7.

بهبود تست‌ها با Wycheproof و پوشش بیشتر regression tests.

تغییرات امنیتی و سازگاری با استانداردهای NIST.

از بین این تغییرات پشتیبانی از رزبری‌پای ۵ جالب به نظر می‌رسه چون فری‌بی‌اس‌دی هنوز پشتیبانی کاملی نداره و صرفاً یک پورت جنریک آرم۶۴ دارن که با همون روشی که ویندوز رو اجرا می‌کنی روش باید اجرا کنی :))

@SohrabContents

اصلLSP یکی از اصول مهم SOLID هستش که میگه:
"Objects of a subclass should be replaceable with objects of their superclass without affecting the correctness of the program."

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

چرا LSP مهمه ؟

1.تاثیر در پایداری کد

2. باعثه کاهش باگ‌های پروژه میشه

3. انعطاف‌پذیری: با رعایت LSP میتونید به راحتی کلاس‌های فرزند رو جایگزین کلاس‌های والد کنید بدون اینکه نیاز به تغییرات زیادی در کد داشته باشین.

📌 نقض LSP و مشکلاتش

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

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

✅️ راه‌حل: یه طراحیه صحیح

برای جلوگیری از نقض LSP باید کلاس‌ها به‌گونه‌ای طراحی بشن که تنها ویژگی‌های مرتبط رو ارث ببرند. مثلا، میشه رفتارهایی که به پرواز مربوط هستن رو در یک کلاس جداگانه قرار داد و رفتارهایی که به ویژگی‌های دیگر مربوط میشن رو در کلاس‌های دیگر مدیریت کرد.

این طراحی باعث میشه که هر کلاسه فرزند فقط ویژگی‌های مرتبط با خودشو داشته باشه و امکان جایگزینی کلاس‌ها بدون بروز مشکل وجود داشته باشه.

خلاصش که:

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

#SOLID #LSP

@GoldenCodeir 🔥
(منبع👇🏾)
https://www.linkedin.com/posts/ali-mohammadi-5b7375389_solid-lsp-liskovabrsubstitution-activity-7387569961008943104-XDW2?utm_source=share&utm_medium=member_android&rcm=ACoAAF-g0BsBHAA03jv74SJdJwUrgHFqATrvXb8

اصلLSP یکی از اصول مهم SOLID هستش که میگه:
"Objects of a subclass should be replaceable with objects of their superclass without affecting the correctness of the program."

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

چرا LSP مهمه ؟

1.تاثیر در پایداری کد

2. باعثه کاهش باگ‌های پروژه میشه

3. انعطاف‌پذیری: با رعایت LSP میتونید به راحتی کلاس‌های فرزند رو جایگزین کلاس‌های والد کنید بدون اینکه نیاز به تغییرات زیادی در کد داشته باشین.

📌 نقض LSP و مشکلاتش

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

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

✅️ راه‌حل: یه طراحیه صحیح

برای جلوگیری از نقض LSP باید کلاس‌ها به‌گونه‌ای طراحی بشن که تنها ویژگی‌های مرتبط رو ارث ببرند. مثلا، میشه رفتارهایی که به پرواز مربوط هستن رو در یک کلاس جداگانه قرار داد و رفتارهایی که به ویژگی‌های دیگر مربوط میشن رو در کلاس‌های دیگر مدیریت کرد.

این طراحی باعث میشه که هر کلاسه فرزند فقط ویژگی‌های مرتبط با خودشو داشته باشه و امکان جایگزینی کلاس‌ها بدون بروز مشکل وجود داشته باشه.

خلاصش که:

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

#SOLID #LSP

@GoldenCodeir 🔥
(منبع👇🏾)
https://www.linkedin.com/posts/ali-mohammadi-5b7375389_solid-lsp-liskovabrsubstitution-activity-7387569961008943104-XDW2?utm_source=share&utm_medium=member_android&rcm=ACoAAF-g0BsBHAA03jv74SJdJwUrgHFqATrvXb8

🔶 جنگ تعرفه ‌ای: باز آفرینی مدرن جنگ تریاک چین علیه امپراتوری بریتانیا

جنگ تجاری آمریکا و چین، تکراری آشکار از جنگ ‌های تریاک قرن نوزدهم است؛ زمانی که بریتانیا برای حل مشکلات تجاری خود، چین را مورد زورگویی قرار داد. امروز نیز آمریکا، در حالی که در دریایی از کسری تجاری غرق شده، از خشم به خود می‌پیچد چون چین دلار های بی‌ پشتوانه و بی‌ اعتبارش را نمی‌پذیرد و رفتار متناقض و غیر قابل اعتماد واشنگتن را زیر سؤال می‌برد. آمریکا با سفت ‌تر کردن حلقه نظامی پیرامون چین و تلاش برای مسدود کردن مسیر های تجاری، در حالی که متحدان منطقه‌ای‌ا ش را تحریک می‌کند، بوی تکبّر امپریالیستی از این جنگ تعرفه ‌ای به مشام می‌رسد و خطری که یاد آور گذشته شرم ‌آور بریتانیاست.

بازگشت جنگ تریاک: طمع بریتانیا، الگوی آمریکا

در دهه‌های ۱۸۰۰، بریتانیا برای خرید چای، ابریشم و چینی از چین، مقادیر عظیمی نقره از دست می‌داد، در حالی که چینی‌ها از خرید کالاهای انگلیسی سر باز می‌ زدند. درمانده از این وضعیت، بریتانیا تریاک را به چین تحمیل کرد، میلیون‌ها نفر را به دام اعتیاد انداخت و با شعله‌ور کردن جنگ ‌های تریاک، دوران «قرن تحقیر» چین را آغاز نمود و امروز آمریکا همان مسیر طمع را دنبال می‌کند؛ از اینکه چین زیر بار خواسته ‌های ناعادلانه تجاری ‌اش نمی‌رود، خشمگین است و با تعرفه ‌ها و تهدیدها می‌کوشد پکن را به تسلیم وادارد.

آشفتگی اقتصادی آمریکا: رد شدن دلار های "کاغذی بی ارزش"

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

تهدید نظامی: محاصره و بازی با مهره ‌های نیابتی

آمریکا فقط با تعرفه نمی‌جنگد, بلکه قدرت نظامی خود را نیز به نمایش گذاشته است. با ایجاد پایگاه ‌ها و ائتلاف ‌هایی در اطراف چین در منطقه هند و اقیانوس آرام، به دنبال محاصره پکن و کنترل مسیر های حیاتی تجاری مانند دریای چین جنوبی است. در کنار این، با تحریک کشور های منطقه، آنها را به رویارویی با چین ترغیب می‌کند. این رفتار تهاجمی بوی امپریالیسم کلاسیک می‌دهد و شباهتی خطرناک به مسیر جنگ ‌طلبانه بریتانیا دارد؛ مسیری که می‌تواند دوباره منطقه را به آتش بکشد.

بازسازی بی ‌پروا: مسیر سقوط آمریکا

این جنگ تعرفه‌ ای، بازسازی بی‌ ملاحظه‌ای از جنگ ‌های تریاک است؛ با این تفاوت که این‌ بار آمریکا نقش امپراتوری رو به زوال را بازی می‌کند که می‌خواهد با زور، قدرت ازدست ‌رفته‌اش را پس بگیرد. ترکیب زورگویی اقتصادی، تهدید نظامی و بازی‌های نیابتی، آمریکا را به سوی فاجعه می‌کشاند. اگر واشنگتن از این مسیر عقب ‌نشینی نکند، ممکن است تاریخ ننگین بریتانیا را با عواقبی به ‌مراتب ویرانگرتر تکرار کند.

نویسنده : Angelo Giuliano

#منهای_برنامه_نویسی

@TheRaymondDev

اگر شطرنج ها رو دنبال کردین، یه برنامه بامزه در پیش رو است. رقابت ماراتن پاییزی لی‌چس. فکر کنم در طول ۲۴ ساعت می تونین هر وقت می تونین بازی کنین و حالش رو ببرین در یک مسابقه مانند واقعی. منم ثبت نام کردم ولی روز شلوغی افتاده و احتمالا خیلی بازی نمی کنم؛ ولی جای نگرانی نیست. همون چند دست هم خوبه دیگه

https://lichess.org/tournament/autumn25

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


آپدیت: خودم بازی نمی کنم. به دلایلی مربی داره با اکانتم بازی می کنه. خلاصه نتایج رو دیدین تعجب نکنین (: بعدا تو توضیحات اکانت اضافه می کنم (:

#شطرنج

🔶 اولین وظایفی که تعریف کردیم که اینکه تم قدیمی TaskPire را به تم جدید (Preline UI) تغییر دهیم و پنل کاربری را باز طراحی کنیم.

@TheRaymondDev

🔶 اولین وظایفی که تعریف کردیم که اینکه تم قدیمی TaskPire را به تم جدید (Preline UI) سازمانی تغییر دهیم و پنل کاربری را باز طراحی کنیم.

@TheRaymondDev

سایت دیوار گویا هک شده !

وقتی سرچ می‌کنید خرید فلش دیوار یا مثلا خرید بخاری یا خرید هر چیزی تایتل سایت یه سایت چینی 新华网 می‌اره (که یه سایت خبری چینیه)

با پشتیبانی دیوار متاسفانه نتونستم تماس بگیرم ولی گویا عامل هک رو برطرف کردن چون این متن 新华网 داخل element های سایتشون نیست. همچنین با Agent گوگل هم درخواست رو شبیه سازی کردم و چیزی ندیدم یعنی این متن ایندکس شده از قبله و عامل هک احتمالا برطرف شده. امیدوارم که همینطور بوده باشه و برطرف شده باشه اگر توضیحات فنی در این باره دارید یا در دیوار مشغول توسعه هستید توضیحاتتون رو ارائه کنید به صورت عمومی منتشرش کنیم تا این اتفاق برای بقیه کسب و کار ها تکرار نشه.



@Linuxor

🚨🤯 پرونده‌های ۱۱ سپتامبر: از پنهان‌کاری تا تئوری توطئه! برج ۷ چرا فروریخت؟ چه کسی از حمله سود برد و چرا آوارها به آسیا منتقل شدند؟! ✈️

🎥قسمت چهارم

این قسمت چهارم از مستند افشاگرانه "پرونده‌های ۱۱ سپتامبر"، به بررسی جنجالی‌ترین تئوری‌های توطئه پیرامون حملات ۱۱ سپتامبر می‌پردازد. تاکر کارلسون در این اپیزود، سوالات بدون پاسخ کمیسیون ۹/۱۱ درباره فروریختن ساختمان ۷ (WTC 7) بدون برخورد هواپیما، انتقال فوری آوارها به خارج از کشور، و همچنین وجود معاملات سهام "پوت آپشن" لحظاتی قبل از حملات را زیر ذره‌بین می‌برد. آیا دولت آمریکا عامدانه زمینه را برای رشد تئوری‌های توطئه فراهم کرد؟

📽 زیرنویس فارسی
🧠 مناسب برای همه، چه مبتدی چه حرفه‌ای
🌐 ترجمه این ویدیو با وب‌سایت isega.ro انجام شده — حتماً سر بزن!
📌 برای دیدن قسمت‌های بعدی کانال رو دنبال کن:
📺🌐 @AiSegaro
🚀 هر روز یک قدم نزدیک‌تر به آینده‌ای هوشمند!
📤 بازنشر آزاد با ذکر منبع 🙏❤️

چند هفته پیش، موقع کار با Go به یه deadlock کلاسیک برخوردم :)

fatal error: all goroutines are asleep - deadlock

حرف های متین در رابطه با deadlock و semaphore به همراه این تجربه من، باعث شد کمی کنجکاوی کنم...

فرض کن یه workload داری که حدود %90 زمانش صرف I/O-bound tasks میشه و فقط %10 CPU-bound داره.
اگر برای هر task یه thread جدا بسازی، بیشتر threadها بلاک میشن و CPU عملاً idle میمونه. حتی ساختن هزاران thread هم باعث memory overhead، frequent context switch و cache eviction میشه و در نهایت throughput واقعی پایین میاد.

اینجا داشتم به مدل event-driven / async I/O فکر میکردم که فوق‌العاده جواب میده فقط با چند thread واقعی میتونی هزاران task I/O-bound رو همزمان مدیریت کنی. وقتی یه task منتظر I/O هست، thread میره سراغ task بعدی و CPU بلاک نمیشه. تو node.js با libuv یا Rust با tokio یا هر مدل event-loop، تمام I/Oها تو event queue باقی میمونن و وقتی آماده شدن، callback یا future اجرا میشه. نتیجه؟ high throughput، low memory footprint، predictable tail latency و تقریباً هیچ deadlock کلاسیکی رخ نمیده D:

برای CPU-bound tasks، اگر تعداد taskها بدون محدودیت باشه، oversubscription اتفاق میفته و frequent context switch باعث میشه throughput واقعی پایین بیاد. استفاده از Worker Pool یا semaphore، concurrency رو کنترل میکنه و CPU همیشه نزدیک %100 utilization کار میکنه.

نکته کلیدی درباره deadlock و race condition: deadlock اینه وقتی رخ میده که taskها منتظر هم باشن مدل event-driven این مشکل رو تقریباً حذف میکنه. اما race condition روی shared state هنوز ممکنه، که با atomic operation یا mutex-like constructs میشه کنترلش کرد.

پی‌نوشت: از go سر یه چیزاش بدم میاد ولی خب، از طرفی بعضی وقتا دوسش دارم :))

اَحپِف‌اِیْسم 🍋

دیروز با حسین درباره‌ی ایده‌ی اجرای یک معماری ۳ تا مستر و ۲ تا رپلیکا با mysql صحبت میکردیم.
هدف این بود که high availability و read scalability رو هم‌زمان داشته باشیم ولی هرچی جلوتر رفتیم، چالش‌های جذابی رو فهمیدیم. D:

چیز هایی که یادم مونده رو باهاتون به اشتراک میذارم.

در باب Split-Brain وقتی سه مستر داری، quorum حیاتی میشه.
اگر یکی از نودها از cluster جدا بشه و هر دو طرف خودشون رو «اصلی» فرض کنن، داده split میشه.
حتی Group Replication با majority vote هم اگه latency بالا باشه، ممکنه از sync quorum بیفته.

وقتی Replication در سطح binlog روی TCP انجام میشه، و هر میلی‌ثانیه تأخیر میتونه باعث افزایش replication lag بشه.
در WAN setups، packet loss باعث time drift در replication queue میشه و consistency به هم میریزه.

نکته مهم async replicas در لحظه‌ی failover، تضمین ACID ندارن.
ممکنه replication thread هنوز ناهماهنگ باشه.
راه‌حل هایی که بعد صحبت مون بررسی کردم semi-sync یا binlog position fencing هنگام switchover بودن

تشخیص لحظه‌ی سقوط نود باید سریع باشه، ولی نه اونقدر سریع که false positive بده.
,واسه ProxySQL health-checkها باید با grace period تنظیم کرد تا transient network glitch باعث promotion اشتباه نشه.

من برام atomic بکاپ از قبل گفت و گو مون خیلی منو به فکر برد که گزینه ای که مطرح کردم LVM snapshot بودش ولی بدون coordination با replication، snapshot ممکنه نیمه‌نوشته بشه.

در رابطه با چالش async replication بین replica ها باعث write skew میشه.
یعنی یک query ممکنه داده‌ای رو بخونه که در replica هنوز sync نشده.

در سطح اپیکیشن واسه مایگریشن اشاره کردیم وقتی چند مستر داری باید idempotent و deterministic باشه.
که من liquibase رو به وسط آوردم که باید state-aware باشه در غیر این صورت دو نود همزمان schema conflict میزنن

من واسه تست سیستم در سطح web api به k6 اشاره کردم تا تست رو به real DB hook بشه تا latency propagation رو دیده شه و برای DB-level، replication lag و lock contention توی متریک‌ های Prometheus قابل دیدن باشه.

واسه DR plan به نظرم باید با off-site snapshot replication کار کنه...
به خاطر همین DRBD یا minio برای block-level mirror یا snapshot sync گزینه‌ های انتخابیم بودن.

واسه coordination و auto election در multi-master، consensus layer به Raft اشاره شد که برای خود من خیلی جذابه. در رابطه با انتخابات election latency ممکنه تا چند ثانیه طول بکشه اگر در اون زمان write انجام بشه میتونه inconsistency بشه.

و پایان گفت و گو مون حسین به Write-Ahead Log نتفلكس اشاره کرد قبل از replication log نوشته میشه تا durability حفظ بشه. لینک استوری مدیومی که برام فرستاد رو میذارم اگه دوست داشتید مطالعه کنید.

و در آخر عرضی نیست :)

اَحپِف‌اِیْسم 🍋

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۵۷۶

بخشای بر آن بنده که خوابش نبود
بخشای بر آن تشنه که آبش نبود
بخشای که هر کاو نکند بخشایش
در پیش خدا هیچ ثوابش نبود

#مولانا | گنجور
📍@iipoem

🔵 عنوان مقاله
The “10x” Commandments of Highly Effective Go

🟢 خلاصه مقاله:
** مقاله با تمثیلی شوخ‌طبعانه، «ده فرمان» برای توسعه‌دهندگان Go ارائه می‌کند؛ نه چیزِ تازه، بلکه ده راهنمای کلی و کاربردی برای نوشتن کد ساده، خوانا و قابل نگه‌داری. محورهای اصلی شامل سادگی و خوانایی، اینترفیس‌های کوچک، مدیریت صریح خطا، همزمانی قابل پیش‌بینی با goroutine و channel، سازمان‌دهی درست پکیج‌ها، تست و بنچمارک، مستندسازی و بهینه‌سازی مبتنی بر اندازه‌گیری است. هر اصل با نمونه‌های عملی در GoLand همراه شده: استفاده از inspections برای شناسایی کد غیر‌ idiomatic، refactor به سمت اینترفیس‌های کوچک، الگوهای آماده برای error handling، اجرای تست و بنچمارک، دیباگ همزمانی، یکپارچه‌سازی linters و پروفایلینگ برای سنجش کارایی. برچسب «10x» فقط کمکی برای به‌خاطر سپردن است؛ پیام اصلی این است که با تکیه بر عادت‌های درست و بهره‌گیری از GoLand، انجام کار درست آسان‌تر می‌شود.

#Go #Golang #GoLand #SoftwareEngineering #BestPractices #Testing #Refactoring #Productivity

🟣لینک مقاله:
https://golangweekly.com/link/175970/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

حالا برنامه سازی پیشرفته رو با سی‌شارپ نمی‌دونم کجای دلم بذارم.
مشکلم سی‌شارپ نیستا، مشکلم اون ویندوز فرمه :)))

امیدوارم جی‌تی‌کی قبول کنن ازم.

https://github.com/gircore/gir.core

@DevTwitter | <Sohrab Behdani/>