🔵 عنوان مقاله
Avoiding Common sync.WaitGroup Mistakes

🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد که با وجود سادگی ظاهری sync.WaitGroup در گو، خطاهای رایجی مانند Add پس از آغاز Wait یا پس از شروع گوروتین‌ها، عدم توازن بین Add و Done، کپی‌کردن یا عبور به‌صورت مقداری، و استفادهٔ دوباره از یک WaitGroup می‌تواند به بن‌بست، شمارندهٔ منفی و نشت گوروتین منجر شود. از نسخهٔ 1.25 گو، ابزار go vet با افزودن بررسی‌های ویژه بسیاری از این الگوهای پرخطر را در زمان ساخت شناسایی می‌کند. با این حال، رعایت اصولی مانند پاس‌دادن اشاره‌گر، فراخوانی Add پیش از ساخت گوروتین‌ها، Done دقیقاً یک‌بار در هر گوروتین، و پرهیز از استفادهٔ مجدد WaitGroup همچنان ضروری است و در صورت نیاز می‌توان از ابزارهای سطح بالاتر مانند errgroup بهره برد.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

ویدیوی جدیدمون توی یوتیوب آپلود شد. توی این ویدیو یک سیستم agentic RAG به اسم Elysia از کمپانی weaviate را بررسی کردم. ویدیو این روشها را توضیح میده تا اینکه بخاد خود ابزار این کمپانی را بررسی کنه. و اینکه چه روش ها و تکنیک هایی استفاده کردند که خیلی جالبند و میشه توی سیستم های agentic RAG که طراحی میکنید به کار ببرید.
پ.ن. اسلاید ها همه با Gamma تولید شدند و من حدود ۲۰% تغییر دادم و مطلب اضافه کردم. که خوب کارم را راحت تر کرد.
Youtube: https://youtube.com/watch?v=uFovqoxTQqk…
Slides: https://docs.google.com/presentation/d/1nt3v_QCw4G3pF33UjFphw0BSaGDIl5nmYo0tugbJqcw/edit?usp=sharing

@DevTwitter | <Mehdi Allahyari/>

کانال میم کده میتونه کلی چیزای خفن با این در بیاره :)

یک کتاب فارسی به جای 7 کتاب
🔹پس از انتشار کتاب ۱۰۰۱ دستور لینوکس، کتاب جامع برای یادگیری لینوکس و همچنین مفاهیم بیشتر لینوکس LPIC1 برای شما آماده شده است. کتاب، آموزش گام‌به‌گام مباحث اصلی لینوکس را با منابع بین‌المللی معتبر ترکیب کرده تا مطالعه‌ای کاربردی و منسجم ارائه دهد.

🔹این کتاب تمامی مفاهیم و سرفصل‌های مورد نیاز آزمون‌های LPIC-1 را با کد 101-500و 102-500 و همچنین کتابهای زیر را پوشش می‌دهد و با جزئیات بیشتر دیگر نیازی به خواندن کتابهای پر هزینه زیر نیست، مانند:


🔸LPIC-1 Objectives V5.0 – Linux Professional Institute
🔸LPI Linux Certification in a Nutshell (O’Reilly, 3rd Edition)
🔸LPIC-1 Study Guide (Sybex)
🔸CompTIA Linux+ / LPIC-1 Cert Guide
🔸Practical LPIC-1 Study Guide
🔸LPIC-1 Certification Bible
🔸LPIC-1 Linux Certification in a Nutshell


🔻فرمت pdf
🔻تماما رنگی
🔻750 صفحه در قالب 27 فصل
🔻نویسنده :حسین سیلانی
🔻انتشارات نشر کیان دانش

🔹دریافت کتاب از آکادمی کندوی دانش
https://learninghive.ir

🔻فایل نمونه کتاب به همراه فهرست کامل کتاب
دریافت نمونه کتاب

پوریا یکی از خفن ترین دوستهای منه...دوره های خیلی خفنی میسازه و اینکه رایگان هم هست برای همیشه 😊چی بهتر از این ....
https://codehalic.ir/courses/nestjs-intermediate

من و دوستم یه کلون تلگرام با Next.js ساختیم!

گیت هاب: https://github.com/hamedakbarii/telegram-clone

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

@DevTwitter | <Unknown Talent | بچه برنامه نویس/>

🔶 ناسا به ‌طور رسمی اعلام کرد که از ۵ سپتامبر، شهروندان چینی حتی با ویزای معتبر ایالات متحده نیز از دسترسی به تأسیسات، شبکه ‌ها و برنامه ‌های این سازمان منع شده‌اند. این تصمیم به‌دلیل نگرانی‌های امنیتی و تشدید رقابت ‌های فضایی با چین اتخاذ شده است.

#خبر

@TheRaymondDev

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

توی ایران چندین نوع اشک مصنوعی داریم چیز هایی که من توی بازار زیاد دیدم اشک های تک دوز آرتلاک و ارتیپیک و سینالونه، و یا ژل لیپوزیک و هیچ کدوم نسخه پزشک لازم ندارن.

از همشون استفاده کردم، آرتلاک مال شرکت بوش اند لمبه و خیلی خیلی معتبره، وقتی توی چشم ریخته می‌شه چشم راحتی بیشتری نسبت به آرتپیک و سینالون که ایرانیه داره ولی نتیجه زیاد تفاوتی نداره. هر ویالشون تا 24 ساعت قابل استفاده مجدده و هر 2 ساعت می‌تونید بریزید چشمتون.

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


قیمت هاشون هم امروز چند تا گرفتم به این صورت بود :
آرتلاک دونه ای 7 تومن؛ آرتلاک ادونس دونه ای 30 تومن؛ آرتپیک 6 تومن؛ ژل لیپوزیک 330 تومن که برای 28 روز یا کمتر استفاده میشه. همچنین نسخه ادونس آرتلاک حتی میتونه خشکی های شدید هم جوابگو باشه و مواد نگهدارنده نداره و بی ضرر، اگه خشکی معمولی دارید بقیشون هم جوابه.


@Linuxor

🔶 در حال کار برای افزودن زبان فارسی و انگلیسی به پروژه تسک پایر هستم.

@TheRaymondDev

کلا توی نرم افزار ما چیزی به اسم حذف نداریم، توی دیتابیس یه is_deleted می‌زاریم و دیگه به کاربر نشونش نمی‌دیم؛ ولی این چک کردن هی is_deleted توی کد های مختلف سخت می‌شه یه راه حل دیگه ساخت جدول trash هست که یه ستون رشته ای به اسم table_name داره و یه ستون دیتایی به اسم table_data داره درسرش کمتره؛ می‌تونید تستش کنید.


@Linuxor

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

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

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

اینجارو ببینید پر سیستم دیزاینه، هم ‌می‌تونید توش کامپوننت های آماده پیدا کنید هم می‌تونید Voice & Tone پیدا کنید مثلا پیام خطا یا دستورالعملی می‌نویسی، چه لحن و ادبیاتی داشته باش و فایل های آماده فیگما و فتوشاپ و کلی سورس کد دیگه

https://github.com/alexpate/awesome-design-systems

@DevTwitter | <Nimo/>

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

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

نکته‌ی دیگه این هستش که تصمیم گرفتیم یک git repo درست کنیم جهت قرار دادن منابع و مطالبی که توی reading group بهشون بر میخوریم. از بین دوستان، یاسمین داوطلب شد که مدیریت ریپو رو دست بگیره. توی این repo علاوه‌ بر مقالات اصلی، مقالات و کتب جانی هم قرار میدیم. یک روحیه‌ی خیلی قشنگی که بچه‌ها دارن، این هستش که بسیار مشتاقن تا کارهای عملی و پیاده‌سازی هم انجام بدیم. از این رو برای هر مبحثی که می‌خونیم، هر کسی توی این ریپو پروژه‌های عملی مربوط به اون حوزه‌ی خاص که state of the art هستند رو قرار میده. علاوه بر اون تصمیم گرفتیم که پروژه‌های کوچکی هم تعریف کنیم که خودمون هم دست بکار بشیم.

برای مثال مطالب هفته‌ی اول دوره مربوط بود به Hoare Logic و زبان GCL بود. اگر به ریپو مراجعه کنید، علاوه بر مقالات و کتب جانبی، لیستی از پروژه ها مثل Dafny, Boogie, Why3 و KeY رو مشاهده میکنید که همگی زبان‌های برنامه‌نویسی و verification هستند که Hoare Logic رو ساپورت میکنن و همه‌شون Deductive Verifier دارند برای اثبات درستی برنامه‌ها.

علاوه‌بر اینا ۳ تا پروژه هم تعریف شده که به زودی یکی از این‌ها رو استارت میزنیم و ببینیم تا کجا می‌تونیم پیش ببریمش.

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

خلاصه که آقا همش Fun و عشق و صفاست.

توی معماری سیستم یک اصطلاحی داریم به اسم؛
distributed monolithic
که خب یک anti-pattern هست برای معماری micro-service اول هفته با یک شرکتی برای مشاوره صحبت کردیم (کارشون رو قبول نکردم ولی یک قرارداد کوچک بستم برای اینکه بگم مشکل فعلی سیستم کجاس)

معماری سیستم مثلاً قرار بوده micro-service باشه؛ در نگاه اول هم هست و حتی از تمام ابزارهای لازم هم داره استفاده می‌شه اما به اشتباه.

کل سیستم رو امروز کنار هم چیدم و روی یک سرور بالا آوردم (بجای چندتا سرور) و تبدیلش کردم به multi app monolithic اولش خیلی ناراحت و نگران بودند که پرفورمنس خراب میشه و ازین حرفا ولی بعد توی تست‌ها دیدند که حداقل ۲ برابر سرعت پاسخ و تعداد درخواست‌هایی که هندل میشه بیشتره.

البته من مطمئن بودم که اینطوری می‌شه به سه دلیل :
۱- به وضوح anti pattern رو می‌دیدم
۲- تعداد درخواست‌های بین سرویس‌ها زیاد بود
۳- خیلی از زمان پروفایلنگ، برای درخواست بین سرویس‌ها هدر می‌رفت روی نتورک. (که خب حتی async هم نبود که حداقل cpu هدر نره)

این موضوع دلیلی شد؛ بیام چندتا تعریف اشتباه که دائم می‌شنوم رو انتقال بدم:

۱- توی ماکروسرویس هر سرویس باید دیتابیس جدا داشته باشه.

این تعریف درسته، اما تفسیر غلط ازش زیاده؛ مثلاً ۹۹٪ فکر می‌کنند این یعنی برای هر سرویس باید یک سرور Postgres جدا داشته باشند، نه لزوماً مفهوم این تعریف اینه که:
مثلاً سرویس auth شما نره دیتای سرویس payment رو بخونه حتی اگر جفتشون روی یک دیتابیس هستند (فقط دوتا تیبل جداشده) و برای گرفتن دیتای مورد نیازش به سرویس payment درخواست بده

۲- هر تابع، متد یا ... باید single responsibility داشته باشه.

بله درسته، این یکی از موارد مهم هست اما تفسیر اشتباه ازش زیاده، مثلاً:
فرض کنید سرویس payment بالا، بعد از اینکه پرداخت انجام شد باید به بخش انبارداری تیکت بزنیم که پرداخت موفق بوده موجودی رو کم کن، به بخش حسابداری بزنیم که فاکتور صادر شده پرداخت شد و مثلاً به بخش ارسال کالا هم بگیم چیو بسته‌بندی و ارسال کنه به چه آدرسی ...

اینو دیدم که میگم، به طرف میگم، خب عالی توابع اینکارها رو بذار یک‌جا داخل یک تابع و درخواست بده اگر مشکلی توی پرداخت پیش اومد همه باهم باید rollback بخوره (توجه به بحث قبل شما حق نداری، تیبل سرویس‌های دیگه رو دستکاری کنی)؛ برگشته می‌گه پس Single Responsiblity چی می‌شه ؟

یک ساعت داشتم براش توضیح میدم؛ که این تابع SRP رو رعایت می‌کنه چون تو فقط داری میگی من پول رو پرداخت کردم موفق بود یا نه.


۳- ماکروسرویس بهتره ...

نه چون یک چیزی سخت‌تر هست پیاده‌سازیش لزوماً بهتر نیست، بسیار بسیار پروژه دیدم که گفتم خب همه‌ی چیزایی که اینا لازم دارن اگر monolithic بود، هم سریعتر بود هم سرعت توسعه‌اش بیشتر بود هم نیاز به این همه دولوپر نداشت.


چندتا برداشت اشتباه دیگه هم بود که متأسفانه یادم نیست دیگه،‌ ولی تبدیل سیستم به یک monolithic واقعی توی این پروژه نتایج خیلی بهتری داشت.
حتی برای مرحله بعدی هم پیشنهاد کردم اول سراغ
Load balance
و بالا آوردن چندتا instance از همین monolithic برند، بعد برای تبدیل به micro-sercive از یکی که معماری رو واقعاً بلد هست کمک بگیرند نه کسی که پوشه پوشه کردن فایلای پایتونش رو فقط یاد گرفته.


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

ترجمه اشتباه لغوی یک کلمه، باعث میشه معنی یک جمله بطور کامل عوض بشه.