DevTwitter | توییت برنامه نویسی

امنیت:  Go با Secret mode از اسرار شما محافظت می‌کند! تیم Go در حال افزودن یک ویژگی امنیتی حیاتی به نام runtime/secret است. اما این قابلیت جدید چیست و چرا یک تغییر بزرگ برای امنیت برنامه‌ هاست؟ مشکل اصلی چه بود؟ تا امروز، توسعه‌ دهندگان برای پاک کردن کلیدهای حساس از حافظه، مجبور بودند به "هک‌ های ناجور" (unholy hacks) و استفاده از reflection روی بیاورند. چرا؟ چون خود Go هیچ تضمینی برای پاک کردن فوری اطلاعات از RAM نمی‌داد و کلیدها ممکن بود در memory dump لو بروند. راه حل secret چیست؟ حالا Go یک راهکار استاندارد و داخلی فراهم کرده! با استفاده از تابع secret.Do، کد حساس شما درون یک بلاک امن اجرا می‌شود. به محض خروج از این بلاک، Go فوراً و با دقت تمام داده‌های حساس (روی stack و registers) را پاک می‌کند. نتیجه نهایی: امنیت واقعی در سطح حافظه: کلیدها بلافاصله پس از استفاده، نابود می‌شوند. راهکار استاندارد و رسمی: دیگر نیازی به reflection یا ترفند های غیراستاندارد نیست. توانمند سازی کتابخانه‌ ها: این ویژگی به توسعه‌ دهندگان کتابخانه‌ های رمزنگاری قدرت می‌ دهد تا ابزارهای امن‌ تری برای کل جامعه Go بسازند. این ویژگی که از یک بحث طولانی در سال ۲۰۱۷ شروع شد، قرار است در نسخه‌  Go 1.26 ارائه شود و یک گام بزرگ برای امنیت کل اکوسیستم است. https://github.com/golang/go/issues/21865 @DevTwitter | <Saeed Shamsi/>

🐍🍉 یلدا رسید… وقتشه حرفه‌ای پایتون یاد بگیری! 💥 دوره جامع برنامه‌نویسی پایتون 🎁 ۱۰٪ تخفیف ویژه یلدا ⏰ فقط تا ۳۰ آذر ⚠️ ظرفیت محدود – اگه امروز ثبت‌نام نکنی، جا می‌مونی! 💻 صفر تا صد پایتون + پروژه عملی 🚀 مناسب دانشجویان و افرادی که می‌خوان برنامه‌نویسی رو جدی یاد بگیرن 👉 ثبت‌نام فوری: 🔗https://B2n.ir/wx8898 ❗️ بلندترین شب سال، بهترین تصمیم حرفه‌ای تو! ➖➖➖➖➖➖➖➖➖➖➖➖ ☎️ مشاوره و ثبت‌نام: 02167641999 📲مشاوره تلگرام: 09222477250 Telegram Bot ➖➖➖➖➖➖➖➖➖➖➖➖ ✓ جهاد دانشگاهی صنعتی شریف؛ یک پله بالاتر از تخصص

پلتفرم آنلاینOpenShip برای مدیریت و اجرای سفارشات که تو تجارت الکترونیک (e-commerce) کاربرد داره سرویس روی مدیریت چندکاناله سفارشات و فرایند fulfillment (چگونگی تکمیل، بسته‌بندی و ارسال سفارش‌هاست) نسخه دمو هم داره و میتونی دیپلوی کنی و اوپن سورس هم هست http://github.com/openshiporg/openship @DevTwitter | <Shayan GeeDook/>

با توجه با گزارش‌های دریافتی، استفاده از آسیب‌پذیری تازه کشف شده در React به شکل گسترده در کشور فعال شده است، به کلیه کسب‌وکارهایی که از React استفاده می‌کنند توصیه اکید می‌شود که پچ‌های این آسیب‌پذیری را اعمال کنند. https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components @DevTwitter | <Behzad Akbari/>

این فلو از سرویس Opal گوگل میتونه بهتون ایده های عالی برای سئو و مطالب سایت و رقبا بده همچنین خیلی راحت با دستیار خودش قابل کنترل و تغییرات است که شخصی سازی کنید یک لول جدید برای سئو سازیتون بردارید! https://opal.google/?flow=drive:/1gF9nPpRJZ58HNEEXTK5Bcu2U9c0TeYsY&shared&mode=app @DevTwitter | <POURYA/>

ترجمه فارسی | The Pragmatic Programmer این کتاب فقط درباره کدنویسی نیست؛ درباره‌ی طرز فکر یک برنامه‌نویس حرفه‌ایه. یاد می‌ده چطور مسئولیت کارت رو بپذیری، تصمیم‌های بهتر بگیری و کدی بنویسی که قابل اعتماد و قابل نگهداری باشه. بعد از سال‌ها هنوز هم یکی از مهم‌ترین منابع رشد حرفه‌ای برنامه‌نویس‌هاست؛ از جونیور تا سنیور. https://github.com/hheydarian/the-pragmatic-programmer-parsion @DevTwitter | <Hamed Heydarian/>

اگه بک‌اند کار می‌کنی و می‌خوای بدون حاشیه، از تغییرات مهم و منابع درست باخبر شی، این کانال رو از دست نده 👇 https://t.me/+lBSf8SchaApkMzhk

یادمه وقتی تازه برنامه‌نویسی رو شروع کرده بودم و با جاوا کار می‌کردم، زبان‌های دیگه برام مسخره به نظر می‌اومدن. مثلاً PHP که همه مسخره‌اش می‌کردن و می‌گفتن در حال مرگه! وردپرس هم که می‌گفتن بچه‌بازیه و اکثر وردپرس‌کارها مورد تمسخر قرار می‌گرفتند. تا این‌که به‌خاطر این‌که کد بک‌اند پروژه اندرویدم باگ داشت و برنامه‌نویسش درگیر بود، خودم مجبور شدم یاد بگیرم و درستش کنم. کم‌کم بهش علاقه‌مند شدم و دیدم هم درآمد خوبی داره و هم چون قدیمیه، برنامه‌های زیادی بر مبنای اون نوشته شده که نیاز به توسعه و نگه‌داری دارن. برای همین اغلب من کسی بودم که می‌رفتم خراب‌کاری بقیه رو جمع می‌کردم! پروژه‌های وردپرسی با ۶۰ تا افزونه، کلی سایت هک‌شده، و حتی کدهای بزرگ و قدیمی که نمی‌شد بهشون دست زد، ولی به‌خاطر هزینه و زمان، امکان بازنویسی‌شون هم نبود. اون‌جا فهمیدم که عدم تخصص خیلی‌ها باعث ایجاد نیاز به افراد متخصص می‌شه. اما آیا من همه پروژه‌ها رو پاک می‌کردم و از اول می‌نوشتم؟ یا می‌گفتم بیاید براتون سایت اختصاصی با لاراول بزنم؟ اگه صرفاً دنبال پول بودم، این کار منطقی بود؛ ولی چون نمی‌خواستم اعتبارم رو خراب کنم، شروع می‌کردم به رفع مشکلات امنیتی، حذف و کدنویسی افزونه‌های اضافی و در نهایت قابل‌استفاده کردن پروژه. اگه بدونید سایت ویکی‌پدیا که بازدید میلیاردی داره و هر صفحه‌اش چند صد میلیون بار دیده می‌شه از PHP استفاده می‌کنه و حاضره ماهی یک میلیارد تومان به شما حقوق بده تا با اون کار کنید، باز هم می‌گید PHP بده؟ یا تحت تأثیر پست‌های لینکدین بی‌خیالش می‌شید؟ خود من چون وارد حوزه هوش مصنوعی و کلاد شدم، تمرکزم رو روی پایتون گذاشتم؛ ولی هنوز کلی شرکت و نرم‌افزار هستن که از PHP استفاده می‌کنن و چون بازنویسی‌شون ممکن نیست، با همون ادامه می‌دن. پس هنوز بازار کار خوبی داره و حتی می‌تونید باهاش مهاجرت کنید. الان در عصر هوش مصنوعی، زبان برنامه‌نویسی شده «انگلیسی»! دیگه نه زبان مهمه، نه فریم‌ورک، نه تکنولوژی. تنها چیزی که مهمه مهارت‌های مهندسی نرم‌افزار، عمیق بودن در حوزه‌های مختلف و در نهایت توانایی انجام یک چرخه کامل توسعه نرم‌افزار از صفر تا صد هست. زبان برنامه‌نویسی حتی ۲۰ درصد ماجرا هم نیست! تخصص در یک حوزه، توانایی حل مسئله، روحیه کار تیمی، انتقادپذیری، توانایی دادن فیدبک و در نهایت داشتن خروجی بهینه، فاکتورهای اصلی هستن. اگه پستی می‌بینید که محتوای اشتباه داره، لطفاً لایک نکنید تا افراد تازه‌کار دچار اشتباه نشن. لایک شما نشانه تأیید اون مطلبه و باعث انتشار بیشترش می‌شه @DevTwitter | <Mohammad Ghafarifar/>

چرا آسیب‌پذیری اخیر ری‌اکت فقط توی معماری RSC دیده شد و نه در SSR؟ تو روزهای اخیر یک آسیب‌پذیری جدی توی ری‌اکت مطرح شد که به کامپوننت‌های سمت سرور مربوط بود. این اسیب پذیری لزوما مربوط به ورژن نبود. چون به فرض اگر نکست بالای ۱۴ بودیم اما کماکان page router استفاده میکردیم هیچ خطری وجود نداشت خب حالا app router با page router چه تفاوتی دارن؟ جواب این سؤال توی تفاوت عمیق معماری SSR و RSC قرار داره. معماری SSR دقیقاً چه کاری انجام میده؟ تو این مدل، ری‌اکت روی سرور اجرا میشه و خروجی نهایی به شکل HTML کامل ساخته میشه و برای مرورگر فرستاده میشه. بعد از اون، کد جاوااسکریپت توی مرورگر دانلود میشه و فرآیند هیدریشن انجام میشه. نکته‌ی مهم اینجاست که HTML فقط یک خروجی نهایی و ایستاست. این خروجی نه ساختار کامپوننت‌ها رو نگه می‌داره، نه منطق اجرا رو منتقل می‌کنه و نه مرزی بین کد سمت سرور و کلاینت مشخص می‌کنه. به همین خاطر، سطح حمله توی این معماری معمولاً محدود میشه به چیزهایی مثل XSS یا template injection و خود ری‌اکت توی سمت کلاینت نقش فعالی توی تفسیر داده‌های ورودی نداره. معماری RSC چه چیزی رو عوض کرد؟ توی معماری RSC، کامپوننت‌ها واقعاً روی سرور اجرا میشن و نتیجه‌ی اجرای اون‌ها به‌جای HTML، به شکل ساختار درختی ری‌اکت به سمت کلاینت میره. این انتقال با استفاده از یک پروتکل اختصاصی به اسم React Flight انجام میشه. به زبان ساده‌تر، مرورگر دیگه فقط یک خروجی آماده تحویل نمی‌گیره، بلکه اطلاعات لازم برای ساخت رابط کاربری رو دریافت می‌کنه. حالا Flight شامل چه نوع اطلاعاتی میشه؟ توی این پروتکل، داده‌هایی جابه‌جا میشن که شامل نوع کامپوننت‌ها، پراپ‌ها، مرز بین کد سمت سرور و کلاینت و همین‌طور ارجاع به ماژول‌هایی هستن که باید توی کلاینت بارگذاری بشن. توی سمت دریافت‌کننده، ری‌اکت این داده‌ها رو parse می‌کنه، ارجاع‌ها رو resolve می‌کنه و اگه لازم باشه بعضی بخش‌ها رو به شکل lazy لود می‌کنه. ️ چرا این تغییر سطح حمله‌ی جدید درست می‌کنه؟ توی مهندسی نرم‌افزار یک قانون ساده وجود داره: هرچی داده به لایه‌ی اجرا نزدیک‌تر باشه، ریسک امنیتی هم بالاتر میره. اینجا داده‌ای که از بیرون وارد سیستم میشه، مستقیم وارد مسیری شامل parse، resolve و تصمیم‌گیری اجرایی میشه. اگه توی هرکدوم از این مرحله‌ها اعتبارسنجی یا محدودسازی درست انجام نشه، یک سطح حمله‌ی جدید شکل می‌گیره. چرا چنین ریسکی توی SSR وجود نداشت؟ توی معماری SSR، چیزی که به مرورگر فرستاده میشه صرفاً HTMLه. این فرمت نه زبان اجرایی حساب میشه، نه ارجاع ماژولی داره و نه منطق پویا رو منتقل می‌کنه. به همین خاطر، پردازشش ‌ توی مرورگرها بهینه و ایزوله شده و سطح تعاملش با منطق اجرایی برنامه خیلی محدوده. در مقابل، Flight یک پروتکل جدیده، پیچیده‌ست و خیلی به لایه‌ی اجرای برنامه نزدیکه و همین نزدیکی، دلیل اصلی بالا رفتن ریسک امنیتی محسوب میشه. جمع‌بندی نهایی این اتفاق بیشتر یادآوری می‌کنه که هر معماری‌ای که داده رو به اجرای مستقیم نزدیک‌تر می‌کنه، ناچار هزینه‌ی امنیتی بیشتری هم می‌ده. ری‌اکت برای رسیدن به عملکرد بهتر، کم کردن حجم جاوااسکریپت و حرکت به سمت معماری server-first مجبور شد Flight رو معرفی کنه و همین انتخاب، دلیل تفاوت این آسیب‌پذیری با معماری SSR شد. @DevTwitter | <Ali Noori/>

یکی از لحظات ضد حال برای هر دولوپر یا مهندس دوآپس یا کلا هر کسی که با داکر کار میکنه، لحظه‌ایه که بعد از کلی تلاش برای نوشتن Dockerfile، می‌بینه ایمیج نهایی که قرار بود سبک و اوکی باشه، ولی خب حجمش سر به فلک کشیده. ایمیج‌های حجیم یعنی زمان طولانی‌تر برای docker pull/push، اشغال فضای دیسک روی نودهای کلاستر، کند شدن پایپ‌لاین CI/CD و ... حالا چطوری بفهمیم دقیقاً چی باعث این حجم شده؟ پکیج‌های OS؟ فایل‌های کش؟ اینجاست که ابزار dive میاد وسط. ابزار Dive یک رابط کاربری ترمینالی (TUI) فوق‌العاده ساده اما باحال داره که به شما اجازه می‌ده ساختار ایمیج داکر رو "لایه به لایه" کالبدشکافی کنید. یه سری از امکاناتی که بهتون میده اینا هست: تحلیل لایه‌ای: دقیقاً بهتون نشون می‌ده هر دستور RUN, COPY یا ADD توی داکرفایل، چه فایل‌هایی رو اضافه کرده و چقدر به حجم نهایی اضافه شده. پیدا کردن فضای هدر رفته: این جذاب‌ترین ویژگی dive هست. بهتون نشون می‌ده چه فایل‌هایی توی یک لایه اضافه شدن و توی لایه بعدی پاک شدن (مثلاً کش‌های apt یا npm). این فایل‌ها دیگه تو ایمیج نهایی دیده نمی‌شن، اما چون لایه‌های داکر Read-only هستن، همچنان فضا اشغال می‌کنن. حالا نکته فنی ماجرا: استفاده از dive قبل از نهایی کردن Dockerfile، شاید منجر به کشف‌هایی بشه که حجم ایمیج رو به مقدار قابل توجهی کاهش می‌ده. مثلاً می‌فهمید که فراموش کردید توی همون لایه‌ای که پکیج نصب کردید، دستور پاکسازی کش رو هم اجرا کنید. اگر تا حالا از dive استفاده نکردید، پیشنهاد می‌کنم یه تستی بکنید حتما. Official Repo: https://github.com/wagoodman/dive#installation @DevTwitter | <Amin Mohammadi Sigaroodi/>

وقتشه کارهات رو اتومات کنی! 🔥 فقط ۲۴ ساعت فرصت داری که دوره اتوماسیون با n8n کوئراکالج رو با ٪۴۰ تخفیف ویژه انتشار ثبت‌نام کنی! ✅ توی این دوره با تمرین و پروژه‌های متعدد یاد می‌گیریم چطور فرآیند‌های خودکار بسازیم، مثل: - ربات تلگرامی تولید و ارسال پست - پردازش فایل‌های PDF با مدل‌های زبانی - ربات تلگرامی نمایش قیمت لحظه‌ای ✨ بدون پیش‌‌نیاز 💳 امکان پرداخت قسطی 🔗 https://quera.org/r/9y4t8

من با استفاده از LangGraph و پترن Reflexion یک ریپو ساختم که: عامل از خطاهاش درس می‌گیره، قانون‌ها رو تو حافظه بلندمدت ذخیره می‌کنه، توی تسک‌های جدید، دیگه اون اشتباه رو تکرار نمی‌کنه، بهش میگن Continuous Learning! که مهمه! لینک ریپو : https://github.com/alipyth/Continuous-Learning-AI-PoC @DevTwitter | <Mr.J/>

بازیِ برنامه‌نویسی داره کلاً عوض میشه و اگر حواستون نباشه، ممکنه جا بمونید! دانشگاه استنفورد یه دوره جدید راه انداخته به اسم «The Modern Software Developer» که حرف حسابش اینه: دورانِ صرفاً «کد زدن» با دست داره تموم میشه. الان دیگه شما باید یاد بگیرید چطوری با AI Agentها کار کنید، چطوری از ابزارهایی مثل Cursor و Warp استفاده کنید و در واقع به جای کدنویس، «معمار» و «مدیر» هوش مصنوعی باشید. تو این دوره دقیقاً دارن یاد میدن که چطور فرایند توسعه نرم‌افزار داره از «تایپ کردن سینتکس» به «تعامل با AI» برای ساخت سیستم‌های پیچیده تغییر می‌کنه. خلاصه اینکه آینده‌ی شغلی شما دیگه فقط به دونستن الگوریتم نیست، به اینه که چقدر خوب می‌تونید از این ابزارهای جدید کار بکشید. تمام مطالب اعم از اسلایدها و پروژه ها را هم گذاشتند. پیشنهاد می‌کنم حتماً یه سر به سرفصل‌هاش بزنید تا ببینید دنیا دست کیه: https://themodernsoftware.dev @DevTwitter | <Mehdi Allahyari/>

دوتا از مشکلاتی که باعث میشدن نتونم با ai studio google کار کنم زیاد و دست و دلم بهش نره، 1- فونت افتضاحش و 2- راست‌چین نبودنش بود. که با این دوتا اکستنشن کروم حلش کردم: 1- Fontonic: https://chromewebstore.google.com/detail/fontonic-change-fonts/hnjlnpipbcbgllcjgbcjfgepmeomdcog 2- RTL ALL: https://chromewebstore.google.com/detail/rtl-all/eilpimgcclncpehhmnnplnfokcmdiefa?hl=en @DevTwitter | <Matin SenPai/>

با Green Tea، گولنگ سریع‌تر از همیشه می‌شه! تیم Go در حال ایجاد یک تغییر بزرگ در Garbage Collector (GC) است که اسمش را Green Tea گذاشته‌اند. اما این «چای سبز» چیست و چرا مهمه؟ مشکل اصلی چه بود؟ تصور کنید فقط بخش کوچکی از حافظه‌ی برنامه‌تان تغییر می‌کرد. GC قدیمی Go مجبور بود برای پیدا کردن آن، کل حافظه را اسکن کند. این یعنی کلی کار اضافه و هدر رفتن منابع CPU. راه حل Green Tea چیست؟ حالا GC هوشمندانه عمل می‌کند: به جای اسکن کل حافظه، فقط بخش‌هایی را بررسی می‌کند که واقعاً تغییری داشته‌اند. همین کار ساده، فرآیند را فوق‌العاده سریع و بهینه می‌کند. (heap به segmentهای کوچک تقسیم میشه و فقط بخش‌های تغییر کرده اسکن میشن) نتیجه نهایی: کاهش چشمگیر مصرف CPU  (تا ۴۰% بهبود). عملکرد روان‌تر برنامه و وقفه‌های بسیار کمتر. این قابلیت در Go 1.25 به صورت آزمایشی (GOEXPERIMENT=greenteagc) در دسترس است و قرار است در نسخه‌ی 1.26 به عنوان GC پیش‌فرض استفاده شود. حتماً امتحانش کنید! https://go.dev/blog/greenteagc @DevTwitter | <Saeed Shamsi/>

یه لایبرری هست به اسم Thanos.js و کارش اینه که حجم پروژه رو تا 50% کاهش میده. شاید بپرسید چطوری؟ من خوبم شما چطوری :)))) حالا جدی شاید فکر کنید چجوری همچین کاری میکنه. میاد نصف فایل های پروژه رو به صورت رندوم حذف می‌کنه به نظرتون میتونه کاربردی باشه؟ @DevTwitter | <Parsa Esmaeili/>

رود بر تمام دوستان خلاصه ‌ی داستان: یک اسکریپت Go داشتم که برای اضافه یا آپدیت کردن Secrets و Varriables های محیط گیت‌هاب اکشن نوشته بودم، یه دستی به سر روش کشیدم و ریپوش رو با نام GajIN پابلیک کردم تا شما هم بتونید استفاده کنید https://github.com/azolfagharj/gajin @DevTwitter | <Alireza Zolfaghar/>

برای یادگیری گولنگ تصمیم گرفتم به جای کورس دیدن، با https://gobyexample.com و study & learn جی‌پی‌تی جلو برم. با اینکه یه کورس هم دانلود کردم که اگر جایی رو واقعا نفهمیدم،‌ برم سراغش حس میکنم با یه سره کورس دیدن وقتم تلف میشه و دیگه اون دوران گذشته @DevTwitter | <Matin SenPai/>

بهینه سازی گولنگ برای سیستم های پردازشی با حجم بالای داده این مقاله نکات جالبی نوشته برای وقتی که یه سرویس گولنگی داری که باید real-time از دیتابیس Postgres بخونه و به Elasticsearch بنویسه. البته نکاتی که گفته کاربردشون محدود به این ابزارها نمیشه و در سناریوهای مشابه هم میشه استفاده شون کرد. طبق تجربه در این مسیر احتمالا سه تا چالش اصلی داری: دیسک دیتابیس که پر میشه اگه کند بخونی، حافظه که منفجر میشه اگه زیاد buffer کنی، و GC که CPU رو می‌بلعه اگه زیاد allocate کنی. یکی از اولین جاهایی که باید بهینه کنی، JSON serialization هست. کتابخانه استاندارد encoding/json امن و راحته، ولی برای حجم بالا کند میشه. جایگزین‌هایی مثل jsoniter با کاهش reflection overhead می‌تونن توان عملیاتی رو به شکل محسوسی بالا ببرن. البته جایگزین کردنش چالش هایی هم داره و باید edge case ها رو تست کنی. قدم بعدی sync.Pool هست. هر event که از replication slot میاد، struct میسازی، buffer برای JSON میگیری، slice و map میسازی. زیر لود بالا، این آبشار allocationها GC رو دیوونه میکنه. با pool کردن bufferها و structهای پرتکرار، تعداد allocationها رو به شدت کم میکنی و GC pause time میاد پایین. همچنین GC tuning باید آخرین کار باشه، نه اولین. اول allocationها رو کم کن، بعد serialization رو بهینه کن، بعد اگه هنوز spike داشتی برو سراغ تنظیمات GC. از Go 1.25 هم یه GC آزمایشی جدید اومده که برای سرویس‌های throughput-heavy مناسبه. https://packagemain.tech/p/golang-optimizations-for-highvolume?triedRedirect=true @DevTwitter | <Hossein Nazari/>