🐍 چرا پایتون ۳.۱۳ سریع‌تر و کاراتر شده؟

نسخه جدید Python 3.13، بهبودهای مهمی در زمینه پرفرمنس و قابلیت استفاده از چندین هسته پردازشی همراه شده که مسیر تازه‌ای برای برنامه‌نویسی باز می‌کنه. دو ویژگی مهم یعنی حالت Free-threaded و کامپایلر JIT رو مرور کنیم؟ همچنین امکان جدید REPL.

GIL و Free-threaded
از قدیم GIL (Global Interpreter Lock) توی پایتون یکی از چالش‌های اصلی بوده. این قفل باعث می‌شه که هر بار فقط یک ترد بتونه کدهای Python رو اجرا کنه. این مسئله زمانی که پردازش‌های سنگین CPU داری یا می‌خوای از پردازنده‌های چند هسته‌ای استفاده کنی، به یه مشکل تبدیل می‌شه. با ارائه حالت Free-threaded به صورت آزمایشی، Python 3.13 این امکان رو می‌ده که پردازش‌های موازی رو بهتر مدیریت کنن و از تمام هسته‌های CPU بهره ببرن. البته هنوز این حالت کاملاً بهینه نیست و روی کارایی پردازش‌های تک ترد اثر منفی داره. اما این یه قدم بزرگ برای Python محسوب می‌شه، چون می‌تونه در آینده به حذف کامل GIL منجر بشه.

کامپایلر JIT و بهینه‌سازی با «کپی و پچ»
کامپایلرهای JIT (Just-In-Time) به کدها اجازه می‌دن تا مستقیماً به کد ماشین تبدیل بشن و سریع‌تر اجرا بشن. تا پیش از این نسخه، بیشتر کامپایلرهای JIT در Python به شکل افزونه‌ و ابزارهای خارجی مثل PyPy در دسترس بودن. اما حالا Python 3.13 با یک کامپایلر JIT جدید به نام «کپی و پچ» ارائه شده که با استفاده از الگوریتم کپی و پر کردن بخش‌های مورد نیاز، مستقیماً کد ماشین رو تولید می‌کنه و از تبدیل‌های میانی صرف نظر می‌کنه. این الگوریتم باعث می‌شه Python به طور پیش‌فرض سریع‌تر عمل کنه و بیشتر از یک پردازنده معمولی استفاده کنه. در نتیجه، این کامپایلر Python رو به فضای زبان‌هایی مثل C و ++C نزدیک‌تر می‌کنه.

امکانات جدید در REPL
محیط REPL (Read-Eval-Print Loop) در Python 3.13 به‌روزرسانی‌های جالبی داشته. حالا قابلیت ویرایش چند خطی داره و دستورات متداول مثل exit و quit بهش اضافه شدن. همچنین، رنگ‌بندی پیش‌فرض و امکان مرور دستورات تاریخچه (F2) و حالت چسباندن (F3) تجربه کار با Python رو ساده‌تر و جذاب‌تر کرده. این تغییرات به Python کمک می‌کنه که برای مبتدی‌ها و حرفه‌ای‌ها به یه محیط کار راحت‌تر و مفیدتر تبدیل بشه. (اگر با REPL آشنایی ندارید توی کامنت خواهم نوشت 😊 )

سایر بهبودها
Python 3.13 به‌روزرسانی‌های مهم دیگه‌ای هم داشته، مثل Garbage Collector بهینه که تأخیرهای ناشی از پاکسازی حافظه رو کاهش می‌ده و پشتیبانی بهتر از دستگاه‌های موبایل.

در مورد توسعه‌دهندگان و شرکت‌هایی که روی Python کار می‌کنن، فان‌روسوم، خالق اصلی Python، پس از چند سال استراحت دوباره به تیم توسعه پایتون در مایکروسافت پیوست و همچنان به شکل فعالی در بهبود Python مشارکت داره. مایکروسافت هم با پشتیبانی از پروژه‌هایی مثل Pyjion که کامپایلر JIT مختص به Python هست، نقش مهمی در این بهبودها داره.

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

اگر براتون جالب بود بگید تا از مزایای دونستن پایتون به عنوان دولوپر غیر پایتونی، به عنوان دیتابیس ادمین، به عنوان دواپس‌کار و... بنویسم 😊

بعد از اینکه خندیدید 😁
در مورد دلیل توصیه به استفاده نکردن از Exception صحبت کنیم؟

🎙🎧 الوعده، وفا!
ممنون از همه دوستانی که با نظر یا نقدشون کمک می‌کنن تا در جهت تولید محتوای مفیدتر بیشتر تلاش کنم.
اپیزود دوم آماده شد 🎉

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

تعداد لایک‌ها اینقدری بود که در مورد Exception ها صحبت کنیم 😁
این بنچمارک ساده رو نوشتم ( به زودی با توضیحات بیشتر و لینک گیت‌هاب ) که نشون بدم:

۱: بهبود پرفرمنس Exception در دات‌نت ۹
۲: تفاوت چشمگیر استفاده از Exception با روش‌های جایگزین

📌 یادمون باشه، این اعداد مطلقا به معنی «امروز عصر، عصرِ عدم استفاده از Exception» و اراجیف عامه‌پسند نیست!
بلکه هرچیز به جای خودش مناسبه، ما باید تا جای امکان کد با کیفیت‌تری تولید کنیم و به خوبی تستش کنیم. شرایط استثنا رو پیش‌بینی کنیم تا کمتر درگیر Exception شیم. تکنیک‌های جایگزین هم مثل:
‏Result یا Try Patterns که عملا از زبون‌های فانکشنال وام گرفتیم یا Return Codes یا الگوی OneOf و Either باید به درستی استفاده شن.

کتابخونه‌های ErrorOn یا FluentResults یا language-ext جزو همین روش‌های کمکی هستند


🧐 بازم بیشتر بدونیم یا بسه؟
مثلا اینکه Explicit Error Handling در Go چه تفاوتی با رویکرد پایتون و #C‌ داره؟

💡چرا تیم مایکروسافت اج در حال جایگزینی React با وب کامپوننت‌ها هستند!

تیم مرورگر مایکروسافت اج در تلاش هستند تا کامپوننت‌های رابط کاربری که با React توسعه داده شده رو با web componentها جایگزین کنند تا سرعت و عملکرد بهتری برای کاربرانشون فراهم کنند. ایده اصلی اینه که با استفاده از یک “معماری مبتنی بر مارک‌آپ”، وابستگی به جاوااسکریپت کاهش پیدا کنه و پردازش کمتری در سمت کلاینت صورت بگیره.

اندرو ریتز، مدیر تیم Edge Fundamentals مایکروسافت، توضیح می‌ده که هدف تیمش تبدیل حدود ۵۰٪ از رابط‌های کاربری وب مبتنی بر React در اج به وب‌کامپوننت‌ها تا پایان سال ۲۰۲۴ است. انگیزه اصلی این پروژه عملکرد ضعیف رابط‌های کاربری مبتنی بر React بود، به ویژه در دستگاه‌های ضعیف یا قدیمی. استفاده گسترده از React در مایکروسافت منجر به ایجاد یک باندل بزرگ و پیچیده شده بود که بر عملکرد تأثیر منفی داشت.

تیم اج در ابتدا از React برای تمایز رابط کاربری خود از کروم استفاده کرده بود، اما حالا با پروژه WebUI 2.0، به دنبال بهبود عملکرد با استفاده از وب کامپوننت‌ها هستند. به عنوان مثال، رابط کاربری “browser essentials” رو که با کلیک بر روی آیکون قلب در نوار مرورگر فعال می‌شود، با وب کامپوننت‌ها بازسازی کردند.

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

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

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



مقاله کامل رو می‌تونید از اینجا بخونید 🙂

🎙🔒 موضوع اپیزود بعدی پادکست، طراحی امن باشه؟

مفاهیم secure by design یا safe coding یا SSDLC است.

مخاطب پادکست شما رفقا هستید، پس نظر شما بسیار مهمه و اگر در توان و در ظرف کوچک دانسته‌هام باشه، خوشحال می‌شم چیزی تولید شه که مورد نظر شماست 😊

🎙🖥 دورهمی آنلاین در مورد دغدغه عرفان 😁

کامنت امروز عرفان در مورد اینکه مباحث بنیادین چجوری یادمون بمونه، یا اصلا لازمه یا نه و... باعث شد به فکر این بیوفتم که دورهمی آنلاین داشته باشیم:
- موضوعات دیزاین و معماری و الگوهای طراحی و... رو «تا چه حد»، «چجوری»، یاد بگیریم که روشون مسلط باشیم و یادمون نره؟
- اصلا نیازه که همه چیز رو بلد باشیم؟ (چجوری تعادل رو بین نگاه واقع‌بینانه فردی با نگاه واقع‌بینانه نسبت به بازار کار و مصاحبه‌های شغلی پیدا کنیم)
- نقشه راه یادگیری و شغلی رو چجوری تدوین کنیم

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

زمان پیشنهادی: فردا جمعه ۲۷ مهر (۱۸ اکتبر) ساعت ۱۹ به وقت تهران، مدت زمان: ۴۵ تا ۶۰ دقیقه.

لینک گوگل میت، حضور همه باعث خوشحالیه و اگر صلاح دونستید به دوستانی که علاقه‌مند به موضوع هستند معرفی کنید 😊

🛎🛎🛎 یک ساعت دیگه شروع می‌کنیم 😊
همه دعوتن، خوشحال می‌شم ببینمتون...
لینک گوگل میت

🎬 ویدیو جلسه دورهمی که شامل گپ و گفت در مورد مطالب زیر بود آپلود شد

- منحنی فراموشی مطالب، منحنی یادگیری، تکنیک تکرار مطالب
- یادگیری نرم‌افزار در ۱۰ سال!
- تا چه حد و چگونه باید مباحث طراحی، معماری و الگوهای طراحی را یاد بگیریم تا بر آن‌ها مسلط شویم و فراموش نکنیم؟
- آیا لازم است که همه چیز را بلد باشیم؟ چگونه تعادل را بین یادگیری فردی و نیازهای واقعی بازار کار و مصاحبه‌های شغلی پیدا کنیم؟
- چگونه نقشه راه یادگیری و مسیر شغلی خود را تدوین کنیم؟
https://youtu.be/Ry2wZDNtv3c

امروز صبح خبری دیدم که قابل انتظار بود ولی ناراحت‌کننده! سایت codeproject.com تعطیل می‌شود!

سال‌ها قبل از پیدایش stackoverflow یا github یا حتی مرحوم codeplex، مرجع یادگیری و به‌روز موندن و اشتراک تجربه و کد همین codeproject بود.

من دات‌نت رو با نسخه ۱ شروع کردم 👴🏻 زمانیکه کتاب و منابع خیلی محدود بود.
و سهمی که codeproject در یادگیری من داشت خیلی زیاد بود (خصوصا مفاهیم شیء‌گرایی).

برای مدت طولانی، مقالاتی که دوست داشتم رو با کدهای ضمیمه‌اش PDF می‌کردم و ازشون برای خودم کتابخونه درست کرده بودم...

💡 ولی سایتی که خودش باعث به‌روز موندن بقیه بود، به‌روز نموند و از رقابت جا موند!

حتی مقالاتی که در مورد معماری زیرساخت و سرورها و تنظیمات دیتابیس‌های codeproject بود به من خیلی کمک کرد (بعدترها stackoverflow و نشر تجربه عالیشون از زیرساختشون یادگیری عالی برام داشت)

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

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

بیاین چند تا عدد رو ببینیم تا اهمیت طراحی امن رو بهتر درک کنیم (گرچه فجایع امنیتی سرویس‌های دولتی و خصوصی ایران طی چند سال گذشته هیچ عقوبت خاصی نداشته براشون!)

گوگل سال ۲۰۲۲ بالغ بر ۱۲ میلیون دلار، و مایکروسافت تنها طی سال ۲۰۲۱ مبلغ ۱۳.۷ میلیون دلار به هکرهای اخلاق‌گرا بابت برنامه باگ‌بانتی پرداخت کردن.

سال ۲۰۱۷ شرکت Equifax فقط ۷۰۰ میلیون دلار جریمه شد بابت ضعف برطرف نشده امنیتی در فریم‌ورک جاوایی Apache Struts که منجر به نشت ۱۴۷ میلیون مشتریش شد و در کل ۱.۴ میلیارد دلار هزینه روی دستش گذاشت!

متا سال ۲۰۲۲ طی یک فقره جریمه، ۲۲۷ میلیون دلار پرداخت کرد بابت نشت اطلاعاتش...

💡 🎙 منتظر نسخه بعدی پادکست باشید. سعی می‌کنم مرور خوبی روی مفاهیم طراحی امن، shift-left testing، کدنویسی امن داشته باشم...

به بهانه دیدار اسکات هنزلمن، در مورد نقش‌های سازمانی مثل
Developer Advocate
Developer Evangelist
Developer Relations Engineer
DevRel
بیشتر بدونیم؟ گپ بزنیم؟ نقش چنین افرادی، مسیر شغلی، وظایف و...؟

پینوشت: از اینکه تونستم از این آدم بابت سال‌ها یادگیری که ازش داشتم حضوری تشکر کنم، و بگم چقدر سافت‌اسکیل‌هایی که ازش آموختم ارزشمند بودن، خیلی خوشحالم 😊

✨✨ خبر خوب...

به‌روز رسانی: Webstorm هم شامل همین رویه شد، برای استفاده غیرتجاری رایگان شد.

✨ ‏Diff Authoring Time روشی برای اندازه عملکرد توسعه‌دهنده‌ها

آخرین نسخه پادکست Meta Tech، به موضوع ارزیابی و افزایش بهره‌وری توسعه‌دهنده‌ها از طریق متریک جدیدی به نام "Diff Authoring Time" (DAT) اختصاص داده. خلاصه‌ای از نکات مهم و روش‌های متا برای سنجش و بهبود بهره‌وری توسعه‌دهندگان با استفاده از این متریک DAT

—-
⚠️ این متن در مورد شرکت متا است، شرکتی بی بیش از ۴۵هزار توسعه‌دهنده که ه فیسبوک، اینستاگرام، واتساپ و کلی ابزار high-tech تولید می‌کنند. متا از git استفاده نمی‌کنه و Mercurial رو به‌عنوان سیستم کنترل سورس داخلی خودش استفاده می‌کنه. پس خیلی با عموم شرکت‌ها فرق داره، این متن رو خواهشا با دید آگاهی و ایده گرفتن در مورد «نگاه سیستماتیک به ارزیابی عملکرد» افراد ببینیم! خواهشا راه نیوفتیم از فردا توی هر شرکتی تایم بگیریم ببینیم کی کارا تره 😅
—-

🔸 مقدمه و معرفی: ‏DAT چیه و چرا اهمیت داره؟
در متا به هر تغییر توی کد diff یا همون pull request توی بقیه سیستم‌ها می‌گن. DAT قراره زمان واقعی‌ای که برنامه‌نویس‌ها برای ساخت و تغییر diffها صرف می‌کنن رو اندازه بگیره. حالا شاید بپرسید "چرا اصلاً بخوایم این کار رو بکنیم؟" خب، اگه یه سیستم داشتی که دقیقاً نشون بده کجاها زمان زیادی صرف می‌شه یا کجاها کار گره می‌خوره، می‌تونستی با دید بازتر روی ابزارهای درست سرمایه‌گذاری کنی و تجربه کاری رو بهتر کنی. مثلاً می‌فهمی کجاها باید به بهینه‌سازی سرعت ابزارها بپردازی تا تیم‌ها سریع‌تر به نتیجه برسن.


🔸 نحوه پیاده‌سازی و جمع‌آوری داده‌ها
تله‌متری سیستم + داده‌های IDE: این متریک با استفاده از داده‌های سیستم‌عامل و محیط‌های توسعه (IDE) زمان واقعی فعالیت‌های کدنویسی توسعه‌دهندگان رو ثبت می‌کنه.
الگوریتم‌های ردیابی فعالیت: هر زمان توسعه‌دهنده در IDE فعاله، تایمر DAT روشن می‌شه. این تایمر هنگام وقفه‌های کاری (مثل ترک کردن سیستم) متوقف می‌شه. این نسخه، پنجمین تکرار الگوریتم DAT است که بهینه‌سازی‌ها و دقتش به‌مرور افزایش یافته.
پشتیبانی چند محیطی: DAT به‌طور کامل در محیط‌های متداول توسعه مثل VS Code و Android Studio اجرا می‌شه. اگر توسعه‌دهنده همزمان روی چند diff کار کنه، DAT می‌تونه فعالیت رو به تفکیک IDE‌های مختلف شناسایی و زمان‌بندی کنه.

🔸 داده‌های کلیدی و یافته‌ها
میانگین زمان DAT: به‌طور متوسط، هر diff حدود ۵۰ دقیقه زمان می‌بره. این زمان شامل فعالیت‌های IDE و ابزارهای مرتبط با کدنویسی می‌شه.
سطح پوشش: DAT در حال حاضر ۸۷ درصد diffهای واجد شرایط (diffهای نوشته‌شده توسط توسعه‌دهنده) رو پوشش می‌ده، و الباقی موارد به دلیل استفاده از ابزار، از دامنه اندازه‌گیری خارج می‌شه.

🔸 فرآیند اعتبارسنجی و بهبود DAT
فرایند اعتبارسنجی چندمرحله‌ای: برای اطمینان از صحت داده‌های جمع‌آوری‌شده، تیم متا سه مرحله اعتبارسنجی رو روی DAT انجام داده که این اعتبارسنجی شامل بررسی نمونه‌ای، مقایسه با نسخه‌های قبلی DAT، و سنجش میزان پوشش و دقت اون می‌شه.
تست‌های A/B: یکی از کاربردهای مهم DAT در آزمایش‌های A/B برای ارزیابی تأثیر ویژگی‌های جدید IDE‌ها و زبان‌های برنامه‌نویسیه. مثلاً اگر ویژگی جدیدی به یک زبان اضافه بشه، تیم توسعه می‌تونه با استفاده از DAT تأثیرش رو روی بهره‌وری توسعه‌دهنده‌ها بررسی کنه.

🔸 کاربردهای DAT و تحلیل داده‌ها
تحلیل مقایسه‌ای بین تیم‌ها: DAT امکان مقایسه تیم‌ها یا ابزارهای مختلف رو فراهم می‌کنه تا بتونه تغییرات بهره‌وری رو شناسایی کنه.
شناسایی نقاط ضعف و بهبود فرآیندها: با بررسی DAT، تیم‌ها می‌تونن بخش‌هایی از فرآیند کدنویسی رو که باعث کاهش بهره‌وری شده، شناسایی و بهبود بدن.
بررسی تأثیر ابزارها و افزونه‌های جدید: آزمایش و مقایسه ابزارهای جدید با استفاده از DAT به تیم‌ها کمک می‌کنه تا تأثیر تغییرات رو با داده‌های کمی ارزیابی کنن.

🔸 آینده DAT
توسعه و ساده‌سازی DAT: هدف تیم توسعه‌دهنده DAT در نسخه‌های آتی، ترکیب و ساده‌سازی این متریک به نحویه که تنها یک عدد نهایی برای زمان ایجاد diff ارائه کنه.
پشتیبانی از کدنویسی خودکار توسط هوش مصنوعی: با رشد استفاده از هوش مصنوعی و کدهای تولید شده توسط LLMها، DAT به سمتی می‌ره که بتونه این نوع فعالیت‌ها رو هم به عنوان بخش جدیدی از بهره‌وری پوشش بده.

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

✍️ توی کامنت همین رأی‌گیری، چند خطی در مورد مزایا و کاربردهاشون برای توسعه‌دهنده و دواپس‌کار نوشتم. از جنبه platform engineering هم بهش پرداختم و دو مورد تجربه خودم از استفاده ازشون در خصوص Platform نوشتم.

اخیرا یه مشکل تو روش محاسبه تفاوت بین نسخه‌های مختلف فایل‌ها توی git کشف شده که می‌تونه باعث بشه حجم ریپازیتوری‌ها چند برابر بشه. این مشکل باعث افت کارایی و مصرف بیش‌ازحد فضای ذخیره‌سازی می‌شه.

داستان هم از اونجایی شروع شد که یکی از مهندس‌های ارشد مایکروسافت، جاناتان کریمر، درباره یه ریپازیتوری جاوااسکریپت خیلی بزرگ که تیمشون روش کار می‌کنه پست کرده. یه مونو ریپو (یه ریپازیتوری که پروژه‌های مرتبط زیادی رو نگه‌می‌داره). بیش از ۱۰۰۰ کاربر فعال ماهانه و حدود ۲۰ میلیون خط کد وجود داشته. طبق گزارش کریمر، کلون کردن این ریپازیتوری ۱۷۸ گیگابایت از فضای دیسک رو مصرف کرده که خیلی بیشتر از چیزی بوده که انتظارش رو داشتن.

تیمشون برای بررسی مشکل با یکی از کانتریبیوترهای git به اسم Derrick Stolee، که قبلا تو GitHub بوده و حالا تو مایکروسافت مهندس ارشد هست، مشورت کردن. استولی متوجه می‌شه که...

متن کامل داستان رو اینجا نوشتم 😁

* به‌زودی مشکل instant view تلگرام دسکتاپ به متون راست‌به‌چپ (فارسی) حل می‌شه (هنوز مطمئن نیستم ولی باگی که گزارش کردم رو تلگرام تایید کرده و commit کرده روی گیت‌هاب)

یک خبر خوب! کوپایلوت گیت‌هاب که احتمالا خیلی‌هامون ازش استفاده می‌کنیم و انصافا ابزار خوبیه، به زودی از مدل‌های شرکت‌های دیگه‌ای به جز OpenAI پشتیباینی می‌کنه، یعنی مثلا اگر Claude برای شما مناسب‌تره می‌تونید تعیین کنید ازش استفاده کنه.

البته کماکان بعید می‌دونم کسی Gemini گوگل رو ترجیح بده 🤭

💡 البته این از نظر بیزنسی و طراحی محصول هم درس‌هایی داره برای کسایی که علاقه‌مند باشن!

لینک اصل خبر

💡 تیم SQLite در حال توسعه ابزاری برای رپلیکیشن است

حالا تیم SQLite در حال تدارک ابزاری برای ایجاد رپلیکیشن مدل snapshot است، حتی در شرایطی که عملیات خواندن و نوشتن در حال انجام باشه.

ابزار sqlite3-rsync می‌تونه پایگاه داده مبدا رو به یک مکان محلی (همون ماشین) یا راه دور (ماشین دیگه و از طریق شبکه) کپی کنه. در ضمن، در صورت کپی از راه دور، از پروتکل SSH برای رمزگذاری داده‌ها استفاده می‌کنه. مقصد، که در مستندات اولیه با نام REPLICA (نسخه‌ی تکراری) معرفی شده، می‌تونه از قبل وجود داشته باشه و اتصالاتش در حین فرآیند رپلیکیشن برقرار و فعال بمونه، اگرچه این اتصالات فقط خواندنی هستن.

توضیح کامل این ابزار رو با شرح در مورد انواع رپلیکیشن و جزئیات بیشتر اینجا نوشتم

اگر دوست داشتید بخونید، نظرتون رو بگید و یا به اشتراک بگذارید 😊

🍿📽 آخر هفته فیلم ببینیم؟
دو تا مستند جالب برای اونایی که هم دوست دارن آخر هفته خوش بگذرونن هم با تمرکز حداقلی به دونسته‌هاشون اضافه شه.

The Code: Story of Linux documentary
یه مستند خوب در مورد پیدایش لینوکس

How A Small Team of Developers Created React at Facebook
داستان اینکه چجوری React.js توی فیس‌بوک به وجود اومد

امیدوارم دوست داشته باشین، اگر دیدید نظر بدید، به دوستانتون معرفی کنید و اگر پیشنهادی داشتید بنویسید.

اگر دوست داشتید شاید هفته‌های آینده هم فیلم و مستند نرم‌افزاری معرفی کنم. 😊