Forwarded from Rust for Python developers
یک نکته قابل توجهی که میگه و تو گروه هم ما راجبش بحث کردیم.
اینه که توی مارکت
برای همین ۹۹٪ شما وقتی میگید من دارم
هیچ شکی نیست که قطعا همه جونیورها هم یک روزی سنیور خواهند شد! ولی اگر توی
اینه که توی مارکت
Rust برنامهنویسهای Junior بیشتر وجود داره (که خب استخدام نشدن هم دلیلش همین هست) اکثر شرکتهایی که میرند سمت زبان Rust نیاز به کسی دارند که بیزینس رو خوب بلد باشه یا توی زبان برنامهنویسی و ... ایی که قبلا کار کرده Senior باشه و حالا Rust هم بتونه کد بزنه!برای همین ۹۹٪ شما وقتی میگید من دارم
Rust میخونم؛ میگم: اشتباه میکنی.هیچ شکی نیست که قطعا همه جونیورها هم یک روزی سنیور خواهند شد! ولی اگر توی
Python, Go, ... شروع کنید که مارکت همین الان کار برای جونیور داره؛ احتمالا خیلی سریعتر پیشرفت میکنید؛ تجربیات مهم رو بدست میارید و سنیور میشید!Forwarded from Md Daily (Mahan)
داشتم یه مقاله فوقالعاده از یه تجربه عملیاتی سنگین میخوندم با عنوان: «چطور یک میلیارد رکورد رو از DB1 به DB2 جابجا کردیم؛ بدون Downtime» 🚀
نویسنده مقاله (و تیمش) با یه چالش بزرگ روبرو بودن: دیتابیس قدیمیشون که دیتای حساس مالی (پرداخت، سفارش و...) رو نگه میداشت، از ۱ میلیارد رکورد رد شده بود و به شدت کند شده بود, Queryهایی که ثانیهای طول میکشید، `Batch Job`ها (کارهایی که دستهای مثل تسویه حسابها) ساعتی طول میکشید. Scale کردن (افزایش مقیاس) دیگه جواب نمیداد و باید مهاجرت میکردن، اونم بدون حتی یک ثانیه Downtime (قطعی).
این خلاصهی قدمبهقدم کاریه که انجام دادن:
1️⃣ جابجایی دیتای قدیمی (Bulk Migration)
برای انتقال
✔️ جدول رو بر اساس رنج
✔️ موقع بارگذاری، ایندکسهای ثانویه و `Constraint`ها (قیدها) رو غیرفعال کردن (تا سرعت
✔️ چندتا ورکر رو
✔️ بعد از انتقال هر تیکه، یه
2️⃣ مدیریت ترافیک زنده (Dual Writes)
چالش اصلی، دیتای جدیدی بود که همزمان با مهاجرت داشت وارد میشد.
✔️ اپلیکیشن رو طوری تغییر دادن که
✔️ برای اینکه مطمئن بشن دیتایی گم نمیشه، اگه نوشتن تو دیتابیس جدیده خراب میشد، اون رویداد (event) رو مینداختن توی یه `Retry Queue` کافکا (صفی برای کارهای شکستخورده که باید دوباره امتحان بشن).
✔️ یه
✔️ برای جلوگیری از تکراری ثبت شدن دیتا (موقع تلاش مجدد)، همهی نوشتنها رو با آیدی یکتا
3️⃣ تست پنهانی در پروداکشن (Shadow Reads)
خب، دیتاها سینک بودن. ولی آیا دیتابیس جدیده زیر بار واقعی جواب میداد؟
✔️ اینجا از
✔️ مشتریها هنوز داشتن از دیتابیس قدیمی میخوندن اما در پشت صحنه، اپلیکیشن همون `Query` رو روی دیتابیس جدیده هم میزد و نتایج رو با هم مقایسه میکرد.
✔️ این کار باعث شد کلی باگ ریز ولی حیاتی رو پیدا کنن که تو تستها معلوم نمیشد: مثلاً تفاوت رفتار Timezone ها (منطقههای زمانی)، تبدیل `NULL`ها (مقادیر پوچ) به مقادیر پیشفرض، و تفاوت در Collation (قواعد مرتبسازی و مقایسه متنها) (که باعث میشد مرتبسازی نتایج فرق کنه).
4️⃣ لحظه جابجایی نهایی (The Cutover)
روز
✔️ قبل از سوییچ، با اجرای کوئریهای مصنوعی، کش دیتابیس جدید رو
✔️ ساعت ۴:۳۰ صبح (کمترین ترافیک) با زدن یه
5️⃣ رصد کردن (Observability) 📊
نویسنده میگه چیزی که واقعاً نجاتشون داد، SQL خفن نبود، بلکه
✔️ با Replication Lag (میزان عقب بودن دیتابیسهای کپی از دیتابیس اصلی)
✔️ با `Deadlock`ها (وقتی دوتا پروسه قفل منتظر هم میمونن)
✔️ با
✔️ با شمارندهی عدم تطابق نتایج در
✔️ و از همه مهمتر: `KPI`های بیزینسی (شاخصهای کلیدی عملکرد مثل سفارش در دقیقه).
ما چی می تونیم یاد بگیریم؟💡
مهاجرتهای بزرگ، یه «مسئله دیتابیسی» نیستن، بلکه یه «مسئله System Design (طراحی سیستم)» هستن.
شما یه میلیارد ردیف رو یهو جابجا نمیکنید، بلکه
در نهایت: Zero Downtime (قطعی صفر) شانسی نیست؛ طراحیه.
—-
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
نویسنده مقاله (و تیمش) با یه چالش بزرگ روبرو بودن: دیتابیس قدیمیشون که دیتای حساس مالی (پرداخت، سفارش و...) رو نگه میداشت، از ۱ میلیارد رکورد رد شده بود و به شدت کند شده بود, Queryهایی که ثانیهای طول میکشید، `Batch Job`ها (کارهایی که دستهای مثل تسویه حسابها) ساعتی طول میکشید. Scale کردن (افزایش مقیاس) دیگه جواب نمیداد و باید مهاجرت میکردن، اونم بدون حتی یک ثانیه Downtime (قطعی).
این خلاصهی قدمبهقدم کاریه که انجام دادن:
برای انتقال
Cold data (دیتای قدیمی که دیگه تغییر نمیکنه)، نیومدن یه Dump (فایل خروجی) گنده بگیرن. به جاش:Primary Key (کلید اصلی جدول) به Chunk (تکههای کوچیک دیتا) تقسیم کردن.Insert (ثبت دیتا) بالا بره).Parallel (موازی) برای انتقال این تیکهها ران کردن.Checksum (یه جور کد محاسباتی برای چک کردن یکی بودن دیتا) میگرفتن تا مطمئن بشن دیتا دقیقاً کپی شده.چالش اصلی، دیتای جدیدی بود که همزمان با مهاجرت داشت وارد میشد.
Dual Writes (نوشتن همزمان در دو دیتابیس) انجام بده (یعنی هر دیتای جدید رو همزمان هم تو دیتابیس قدیمی و هم تو دیتابیس جدید بنویسه).Consumer (سرویسی که از صف کافکا دیتا میخونه) جدا اون صف رو میخوند و اونقدر تلاش میکرد تا بالاخره تو دیتابیس جدیده هم ثبت بشه.Idempotent (یعنی اگه یه کاری رو چند بار هم اجرا کنی، نتیجه نهایی یکی باشه) کرده بودن.خب، دیتاها سینک بودن. ولی آیا دیتابیس جدیده زیر بار واقعی جواب میداد؟
Shadow Reads (خوندن پنهانی از دیتابیس جدید برای تست) استفاده کردن.✔️ این کار باعث شد کلی باگ ریز ولی حیاتی رو پیدا کنن که تو تستها معلوم نمیشد: مثلاً تفاوت رفتار Timezone ها (منطقههای زمانی)، تبدیل `NULL`ها (مقادیر پوچ) به مقادیر پیشفرض، و تفاوت در Collation (قواعد مرتبسازی و مقایسه متنها) (که باعث میشد مرتبسازی نتایج فرق کنه).
روز
Cutover (لحظه جابجایی کامل و سوییچ کردن)، ریسک اصلی این بود که Cache (حافظه موقت) دیتابیس جدیده «سرد» (Cold) بود و اولین کوئریها ممکن بود خیلی کند باشن.Pre-warm (گرم کردن کش با دیتای الکی) کردن.Feature Flag (یه جور کلید نرمافزاری برای روشن/خاموش کردن قابلیتها)، همهی Read ها (خوندنها) رو به سمت دیتابیس جدید فرستادن. (برای اطمینان، Dual Writes رو هنوز روشن نگه داشتن تا راه برگشت امن داشته باشن).نویسنده میگه چیزی که واقعاً نجاتشون داد، SQL خفن نبود، بلکه
Observability (قابلیت رصد کامل سیستم) بود. اونا وسواسی همهچیز رو مانیتور میکردن:Cache Hit Ratio (درصدی از دیتا که از کش خونده میشه نه از دیسک)Shadow Readsما چی می تونیم یاد بگیریم؟
مهاجرتهای بزرگ، یه «مسئله دیتابیسی» نیستن، بلکه یه «مسئله System Design (طراحی سیستم)» هستن.
شما یه میلیارد ردیف رو یهو جابجا نمیکنید، بلکه
batch امن به batch امن»، «ورودی WAL (فایلی که دیتابیس قبل از هر کاری، تغییرات رو اول اونجا مینویسه) به WAL» و «Checksum به Checksum» این کار رو میکنید.در نهایت: Zero Downtime (قطعی صفر) شانسی نیست؛ طراحیه.
—-
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Gopher Academy
اخیرا درگیر کوچ کردن از یه سیستم مونولیت قدیمی با Symfony به میکروسرویس با Golang هستم. اونایی که تجربه این مدل کوچ کردن هارو توی سیستم های زیر بار و قدیمی دارن میدونن که مشکل اصلی دیتابیس و جلو رفتن بر اساس اسکیمای فعلی هست و این مدل کوچ ها باید تقریبا بدون Breaking Changes اتفاق بیوفته.
اینجا بود که با SqlBoiler توی زبان Go آشنا شدم.
مزایای SqlBoiler:
۱. ساخت Struct در یک چشم به هم زدن:
به جای اینکه ساعتها بشینم و دستی Structهای گو رو بر اساس جدولهای دیتابیس بنویسم، SQLBoiler در عرض چند ثانیه تمام مدلهای Type-Safe ما رو ساخت. وقتم رو خرید، خیلی زیاد!
۲. تمرکز بر دیتابیس (Database-First):
چون دیتابیس ما از قبل وجود داشت، این ابزار خیلی راحت خودشو با Schema ما سینک کرد. انگار ساخته شده بود برای همین وضعیت!
۳. کوئریهای ایمن و هوشمند:
دیگه نگران خطاهای احمقانه زمان اجرا (Runtime) نیستم. با تولید کوئریهای Strongly Typed، هر اشتباهی توی نام ستون یا جدول باشه، همون موقع
کامپایل گیر میده.
۴. فقط چیزهای ضروری رو بگیر:
قابلیت Whitelist/Blacklist جدولها و ستونها فوقالعاده است. توی محیط میکروسرویس که هر سرویس فقط به یه بخش دیتابیس نیاز داره، با این قابلیت فقط مدلهای مرتبط رو تولید کردم و کد اضافی رو حذف کردم.
اینم لینک گیتهابش:
https://github.com/aarondl/sqlboiler
<Sepehr Mohseni/>
اینجا بود که با SqlBoiler توی زبان Go آشنا شدم.
مزایای SqlBoiler:
۱. ساخت Struct در یک چشم به هم زدن:
به جای اینکه ساعتها بشینم و دستی Structهای گو رو بر اساس جدولهای دیتابیس بنویسم، SQLBoiler در عرض چند ثانیه تمام مدلهای Type-Safe ما رو ساخت. وقتم رو خرید، خیلی زیاد!
۲. تمرکز بر دیتابیس (Database-First):
چون دیتابیس ما از قبل وجود داشت، این ابزار خیلی راحت خودشو با Schema ما سینک کرد. انگار ساخته شده بود برای همین وضعیت!
۳. کوئریهای ایمن و هوشمند:
دیگه نگران خطاهای احمقانه زمان اجرا (Runtime) نیستم. با تولید کوئریهای Strongly Typed، هر اشتباهی توی نام ستون یا جدول باشه، همون موقع
کامپایل گیر میده.
۴. فقط چیزهای ضروری رو بگیر:
قابلیت Whitelist/Blacklist جدولها و ستونها فوقالعاده است. توی محیط میکروسرویس که هر سرویس فقط به یه بخش دیتابیس نیاز داره، با این قابلیت فقط مدلهای مرتبط رو تولید کردم و کد اضافی رو حذف کردم.
اینم لینک گیتهابش:
https://github.com/aarondl/sqlboiler
<Sepehr Mohseni/>
GitHub
GitHub - aarondl/sqlboiler: Generate a Go ORM tailored to your database schema.
Generate a Go ORM tailored to your database schema. - aarondl/sqlboiler
Forwarded from Shayan GeeDook🐧
https://hheydarian.github.io/Gitab/
درود دوستان چطورین؟
یه سایتی رو دیدم که بشدت کار ارزشمندی رو دارن انجام میدن و بشدت مورد احترام هستن.
دیدم که یکی از دوستانی که باهاشون ارتباط بودم در زمان جنگ یه رپویی گذاشته که ترجمه هارو دارن انجام میدن و حتما اگر شما هم میتونید کمکی کنید حتما به اشتراک بگذارید و مشارکت کنید اگر دوست داشتید
دمتون گرم
@shayangeedook
درود دوستان چطورین؟
یه سایتی رو دیدم که بشدت کار ارزشمندی رو دارن انجام میدن و بشدت مورد احترام هستن.
دیدم که یکی از دوستانی که باهاشون ارتباط بودم در زمان جنگ یه رپویی گذاشته که ترجمه هارو دارن انجام میدن و حتما اگر شما هم میتونید کمکی کنید حتما به اشتراک بگذارید و مشارکت کنید اگر دوست داشتید
دمتون گرم
@shayangeedook
hheydarian.github.io
Gitab | گیتاب
ترجمههای فارسی کتابهای فنی — سریع، مینیمال و قابل اتکا.
Forwarded from Linuxor ?
الان که هوش مصنوعی ترسی نداره زمانی که هوش مصنوعی بتونه جوک خنده دار بگه باید ازش ترسید... نه بهخاطر جوک هاش بلکه بهخاطر خلاقیتش و توانایی استفاده و درک زمان حال؛ جوک خنده دار گفتن یعنی اینکه خلاقیت خیلی بالا رفته و میتونه از موضوعات حال (نه حتی گذشته، چون جوک های قدیمی معمولا خنده دار نیستن) چیز جدید بسازه.
این یعنی میتونه بره ترید کنه سود بده (چون اخبار زمان حال رو میتونه بخونه) یا برنامه نویسی کنه و یه سایت بسازه که ما واقعا ازش خوشمون بیاد. (کسی از دیجیکالای 5 سال پیش خوشش نمیاد)
@Linuxor
این یعنی میتونه بره ترید کنه سود بده (چون اخبار زمان حال رو میتونه بخونه) یا برنامه نویسی کنه و یه سایت بسازه که ما واقعا ازش خوشمون بیاد. (کسی از دیجیکالای 5 سال پیش خوشش نمیاد)
@Linuxor
Forwarded from Future Pulse Persian
دارم پادکست پاول دوروف مال تلگرام رو میبینم
نکته جالبش اینجا اگر برادر نابغش نبود هیچ وقت تلگرامی وجود نداشت
نکته دیگه اینه اگر دقت کرده باشید پاول برعکس مارک زاکربرگ ، ایلان ماسک و . . .
زندگی خیلی لاکچری داره ولی ایلان و زاکربرگ همیشه ساده پوشن و خیلی زنی بی آلایشی از خودشون نشون میدن
حتی مارک و ایلان نهایتا ۶ تا ۸ ساعت میخوابن و پاول ۱۲ ساعت
دلیلش از نظر من خیلی جالبه
ایلان و زاکربرگ تمام سهام شرکتشون برای خودشون نیست! سرمایه گذار های بزرگی پشتشونه و هروقت بیان خودشون رو اینطور نشون بدن قطعابا فشار زیادی مواجه میشن
ولی پاول مالک خودش هست و برادرش و کلا ۴۰ برنامه نویس
هیچ وقت هم جواب به کسی نمیده
نکات خیلی زیادی داره این شخص پیشنهاد میکنم حتما درموردش مطالعه کنید
https://www.youtube.com/watch?v=qjPH9njnaVU
نکته جالبش اینجا اگر برادر نابغش نبود هیچ وقت تلگرامی وجود نداشت
نکته دیگه اینه اگر دقت کرده باشید پاول برعکس مارک زاکربرگ ، ایلان ماسک و . . .
زندگی خیلی لاکچری داره ولی ایلان و زاکربرگ همیشه ساده پوشن و خیلی زنی بی آلایشی از خودشون نشون میدن
حتی مارک و ایلان نهایتا ۶ تا ۸ ساعت میخوابن و پاول ۱۲ ساعت
دلیلش از نظر من خیلی جالبه
ایلان و زاکربرگ تمام سهام شرکتشون برای خودشون نیست! سرمایه گذار های بزرگی پشتشونه و هروقت بیان خودشون رو اینطور نشون بدن قطعابا فشار زیادی مواجه میشن
ولی پاول مالک خودش هست و برادرش و کلا ۴۰ برنامه نویس
هیچ وقت هم جواب به کسی نمیده
نکات خیلی زیادی داره این شخص پیشنهاد میکنم حتما درموردش مطالعه کنید
https://www.youtube.com/watch?v=qjPH9njnaVU
Forwarded from DevTwitter | توییت برنامه نویسی
Forwarded from Ninja Learn | نینجا لرن (Mohammad)
اقا گپه ما چشه توش چت نمیکنید :(
Forwarded from Linuxor ?
Forwarded from معرفی توییترهای دانشگاهی
@sut_tw
@srbtwitter
@esfuni_twitter
@devtwitter
@yazd_tweet
@uoktweet
@shirazu_twitter
@sut_tweet
@tweet_Mahart
@arakstudentt
@NITtw
@ub_tweet
@auttw
@auttweet
@sbutw
@swIUTter
@Kashanuni_Twitter
@TwitterAUT
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 به عنوان برنامه نویس وردپرس که افزونه ورود موبایل پیامکی وردپرس نوشتم, این شرکت های پیامکی چه اصراری است که برای دریافت API آن و نوشتن درایور مربوطه کلی مدرک هویتی بفرستیم؟
چون می خواهیم تست کنیم و این همه مدرک می خوای چکار کنید؟ از دستت کلافه شدم.
قرار نیست در سرویس پیامکی فعالیت رسمی داشته باشیم.
#وردپرس
@TheRaymondDev
چون می خواهیم تست کنیم و این همه مدرک می خوای چکار کنید؟ از دستت کلافه شدم.
قرار نیست در سرویس پیامکی فعالیت رسمی داشته باشیم.
#وردپرس
@TheRaymondDev
Forwarded from Ditty | دیتی
۱۰۰ بار سریعتر از 𝗘𝗦𝗟𝗶𝗻𝘁 ؟! 😃
- واقعاً یکی از معضلات پروژههای بزرگ وقتیه که ابزارهایی مثل Linter و Formatter و روی اونها اجرا میشه
- جدیداً با توصیه Evan You (خالق Vue و Vite و …) با پروژهای به اسم Oxc آشنا شدم که مجموعهای از چند ابزار #جاوااسکریپتی هست که با زبان Rust نوشته شده و ادعا میکنه که سرعت و عملکرد فوقالعادی در مقایسه با رقبا داره
- این ابزارها شامل Parser و Linter و Formatter و Minifier و … هست و توی پروژههایی مثل Vite+ و Shopify و Turborepo استفاده شده و برای مثال ادعا میکنه ۱۰۰ برابر سریع تر از ESLint و ۴۰ برابر سریعتر از Babel هست
- یکی از ابزارهای این پروژه Oxlint هست که از اکثر دستورات فعلی ESLint و … پشتیبانی میکنه. اگه اندازهٔ پروژهتون خیلی بزرگ نیست و از ESlint استفاده میکنین، میتونین اون رو کاملاً با Oxlint جایگزین کنین
- برای آشنایی بیشتر با این پروژه این صفحه رو ببینین:
https://oxc.rs/docs/guide/usage/linter.html
#tools
- واقعاً یکی از معضلات پروژههای بزرگ وقتیه که ابزارهایی مثل Linter و Formatter و روی اونها اجرا میشه
- جدیداً با توصیه Evan You (خالق Vue و Vite و …) با پروژهای به اسم Oxc آشنا شدم که مجموعهای از چند ابزار #جاوااسکریپتی هست که با زبان Rust نوشته شده و ادعا میکنه که سرعت و عملکرد فوقالعادی در مقایسه با رقبا داره
- این ابزارها شامل Parser و Linter و Formatter و Minifier و … هست و توی پروژههایی مثل Vite+ و Shopify و Turborepo استفاده شده و برای مثال ادعا میکنه ۱۰۰ برابر سریع تر از ESLint و ۴۰ برابر سریعتر از Babel هست
- یکی از ابزارهای این پروژه Oxlint هست که از اکثر دستورات فعلی ESLint و … پشتیبانی میکنه. اگه اندازهٔ پروژهتون خیلی بزرگ نیست و از ESlint استفاده میکنین، میتونین اون رو کاملاً با Oxlint جایگزین کنین
- برای آشنایی بیشتر با این پروژه این صفحه رو ببینین:
https://oxc.rs/docs/guide/usage/linter.html
#tools
Oxc
Oxlint
A collection of high-performance JavaScript tools written in Rust
Forwarded from Gopher Academy
🔵 عنوان مقاله
A Modern Approach to Preventing CSRF/CORF in Go
🟢 خلاصه مقاله:
این مقاله یک رویکرد مدرن برای مقابله با حملات CSRF/CORF در Go معرفی میکند. بهجای تکیه بر tokens، در Go 1.25 یک middleware به نام http.CrossOriginProtection ارائه شده که با استفاده از سیگنالهای امنیتی مرورگر (مانند Fetch Metadata و سیاستهای SameSite) میان درخواستهای امن هممبداء و درخواستهای مشکوک بینمبداء تفکیک ایجاد میکند. این میانافزار بهطور پیشفرض درخواستهای امن را میپذیرد و درخواستهای تغییردهنده حالت از مبداءهای نامطمئن را مسدود میکند، درحالیکه برای مسیرهای ضروری (مثل OAuth callback یا webhook) قابلیت allowlist دارد و با CORS نیز سازگار است. نتیجه، کاهش پیچیدگی پیادهسازی CSRF، تکیه بر قابلیتهای جدید مرورگرها، و استقرار مرحلهای (از حالت گزارش تا اعمال) است؛ ضمن اینکه جایگزین احراز هویت و کنترل دسترسی نیست، بلکه مکمل آنهاست.
#Go #CSRF #WebSecurity #FetchMetadata #SameSite #Middleware #GoLang #Security
🟣لینک مقاله:
https://golangweekly.com/link/175634/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
A Modern Approach to Preventing CSRF/CORF in Go
🟢 خلاصه مقاله:
این مقاله یک رویکرد مدرن برای مقابله با حملات CSRF/CORF در Go معرفی میکند. بهجای تکیه بر tokens، در Go 1.25 یک middleware به نام http.CrossOriginProtection ارائه شده که با استفاده از سیگنالهای امنیتی مرورگر (مانند Fetch Metadata و سیاستهای SameSite) میان درخواستهای امن هممبداء و درخواستهای مشکوک بینمبداء تفکیک ایجاد میکند. این میانافزار بهطور پیشفرض درخواستهای امن را میپذیرد و درخواستهای تغییردهنده حالت از مبداءهای نامطمئن را مسدود میکند، درحالیکه برای مسیرهای ضروری (مثل OAuth callback یا webhook) قابلیت allowlist دارد و با CORS نیز سازگار است. نتیجه، کاهش پیچیدگی پیادهسازی CSRF، تکیه بر قابلیتهای جدید مرورگرها، و استقرار مرحلهای (از حالت گزارش تا اعمال) است؛ ضمن اینکه جایگزین احراز هویت و کنترل دسترسی نیست، بلکه مکمل آنهاست.
#Go #CSRF #WebSecurity #FetchMetadata #SameSite #Middleware #GoLang #Security
🟣لینک مقاله:
https://golangweekly.com/link/175634/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
www.alexedwards.net
A modern approach to preventing CSRF in Go - Alex Edwards
Forwarded from DevTwitter | توییت برنامه نویسی
یه سایتی هست به اسم «موزه طراحی وب» که نسخههای قدیمی وبسایتها و اپهای معروف رو جمع کرده.
اینها اولین نسخههای Windows 98 و توییتر هستند.
نوستالژی خالص
https://webdesignmuseum.org
@DevTwitter | <Mohammad/>
اینها اولین نسخههای Windows 98 و توییتر هستند.
نوستالژی خالص
https://webdesignmuseum.org
@DevTwitter | <Mohammad/>
Forwarded from DevTwitter | توییت برنامه نویسی
تجربهٔ شگفتانگیز و مفید یک میلیون نود کوبرنیتیز:
https://github.com/bchess/k8s-1m
@DevTwitter | <Amiria/>
https://github.com/bchess/k8s-1m
@DevTwitter | <Amiria/>
Forwarded from Gopher Academy
🔵 عنوان مقاله
Gist of Go: Atomics
🟢 خلاصه مقاله:
در Go، atomics مجموعهای از عملیات سطحپایین در بسته sync/atomic هستند که امکان دسترسی thread-safe و lock-free به مقادیر حافظه مشترک را میدهند. آنها برای متغیرهای ساده (مثل شمارندهها، فلگهای وضعیت، و تعویض ایمن یک اشارهگر پیکربندی) بسیار سریع و مناسباند و با Load/Store، Add/Swap و CAS رابطههای happens-before لازم را تضمین میکنند. وقتی نیاز به حفظ ناهمبستگیهای چندفیلدی دارید یا بهروزرسانی چندمرحلهای میخواهید، استفاده از mutex یا کانالها شفافتر و کمخطرتر است. از اختلاط دسترسی atomic و non-atomic به یک متغیر خودداری کنید، به همترازی و false sharing توجه کنید، و برای دادههای read-mostly از atomic.Value بهره ببرید. نتیجه: در سناریوهای محدود، همزمانی بدون mutex واقعا شدنی است—به شرط رعایت دقیق مدل حافظه و الگوهای درست.
#golang #concurrency #atomics #lockfree #CAS #multithreading #memorymodel
🟣لینک مقاله:
https://golangweekly.com/link/175632/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Gist of Go: Atomics
🟢 خلاصه مقاله:
در Go، atomics مجموعهای از عملیات سطحپایین در بسته sync/atomic هستند که امکان دسترسی thread-safe و lock-free به مقادیر حافظه مشترک را میدهند. آنها برای متغیرهای ساده (مثل شمارندهها، فلگهای وضعیت، و تعویض ایمن یک اشارهگر پیکربندی) بسیار سریع و مناسباند و با Load/Store، Add/Swap و CAS رابطههای happens-before لازم را تضمین میکنند. وقتی نیاز به حفظ ناهمبستگیهای چندفیلدی دارید یا بهروزرسانی چندمرحلهای میخواهید، استفاده از mutex یا کانالها شفافتر و کمخطرتر است. از اختلاط دسترسی atomic و non-atomic به یک متغیر خودداری کنید، به همترازی و false sharing توجه کنید، و برای دادههای read-mostly از atomic.Value بهره ببرید. نتیجه: در سناریوهای محدود، همزمانی بدون mutex واقعا شدنی است—به شرط رعایت دقیق مدل حافظه و الگوهای درست.
#golang #concurrency #atomics #lockfree #CAS #multithreading #memorymodel
🟣لینک مقاله:
https://golangweekly.com/link/175632/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
antonz.org
Gist of Go: Atomics
Concurrent-safe operations without explicit synchronization.
Forwarded from Woland's Linux Journal (Woland)
مخزن عظیمی از کتابهای برنامهنویسی رایگان به تمامی زبانهای جهان!
این مخزن با ۳۷۳.۰۰۰ ستاره لیست کاملی از کتابهای برنامهنویسی رایگان رو توی خودش جمع کرده که شامل کتابهای فارسی هم میشه.
👉🔗 free-programming-books
#کتاب
#معرفی
این مخزن با ۳۷۳.۰۰۰ ستاره لیست کاملی از کتابهای برنامهنویسی رایگان رو توی خودش جمع کرده که شامل کتابهای فارسی هم میشه.
👉🔗 free-programming-books
#کتاب
#معرفی