Syntax | سینتکس

описание

Focus: Web Lan: Python & Go Website: https://syntaxfa.ir Quick connect: https://quick-connect.syntaxfa.ir Github: https://github.com/syntaxfa Group: https://t.me/Syntax_fa_group

← к каналу @Syntax_fa

3 190

подписчиков

Охват к подписчикам

44,4%

ERR

Реакции к просмотрам

0,91%

347 на 26 постов

Пересылки к просмотрам

1,27%

483

Постов в день

0,0

всего 26

Где отзываются чаще

доля реакций к просмотрам

31 июл.وقتی هوش مصنوعی دست مسلمونا میوفته #fun @Syntax_fa3,53%
17 июл.معرفی telegram outreach تو تلگرام یه سری تبلیغات میبینید که تو پیوی ارسال میشن. این پروژه دقیقا همینکارو انجام میده. اکانت های تلگرامی که دارید رو وارد میکنید و سشنشون ساخته میشه. بعد میرید تسک میسازید که یوزر های کدوم گروه رو کراول کنه و لیمیت هارو مشخص میکنید مثلا 500 تا از یوزر های گروه سینتکس. لیست ممبر های گروه رو نمیگیره. بجاش پیام های گروه رو استخراج میکنه و یوزر های فعالشون رو از این طریق پیدا میکنه. بعدش مشخص میکنید که با کدوم اکانت‌ ها به یوزر های کدوم گروه که تو مرحله قبلی بدست آوردید چه پیام هایی رو ارسال کنه. پیام ها میتونه تکست باشه یا بصورت ویس باشه. توی README پروژه نحوه استفاده ازش رو قرار دادیم. لینک: https://github.com/alireza-fa/telegram-outreach @syntax_fa1,71%
2 авг.تو دنیای برنامه‌نویسی برای چه کاری ساخته شدی؟ معمولاً بزرگترین دغدغه‌ی کسایی که تازه می‌خوان وارد دنیای جذاب صفر و یک بشن اینه که: «اصلاً از کجا شروع کنم؟» بک‌اند؟ فرانت‌اند؟ هوش مصنوعی یا امنیت؟ تو این تست ما با چند تا سناریوی تحلیلی و ظریفِ روزمره، مدل…1,69%
8 июл.مفهوم Idempotent یعنی چیه؟ چرا این مفهوم همه جا دیده میشه؟ اگه یه مدتی برنامه‌نویسی کرده باشید، احتمالاً اسم Idempotent به گوشتون خورده. ممکنه این اصطلاح رو توی APIها، پایگاه داده، سیستم‌های توزیع‌شده، صف‌های پیام یا حتی ابزارهای DevOps دیده باشید. اما واقعاً Idempotent یعنی چی؟ بیاید با یه مثال ساده شروع کنیم. فرض کنید یه کلید برق داریم که فقط وظیفه‌ش روشن کردن چراغه. اگه چراغ خاموش باشه و کلید رو بزنید، چراغ روشن میشه. حالا اگه دوباره همون کلید رو بزنید چی میشه؟ هیچ اتفاق جدیدی نمی‌افته؛ چراغ همچنان روشنه. مهم نیست این کار رو یک بار انجام بدید یا ده بار؛ نتیجه‌ی نهایی همیشه یکیه. دقیقاً به چنین رفتاری میگن Idempotent. حالا یه مثال برعکس. فرض کنید دکمه‌ای داریم که هر بار فشار دادنش، ۱۰۰ هزار تومان به موجودی کیف پول اضافه می‌کنه. بار اول موجودی ۱۰۰ هزار تومان زیاد میشه، بار دوم دوباره ۱۰۰ هزار تومان اضافه میشه و بار سوم هم همین اتفاق تکرار میشه. اینجا هر بار اجرای عملیات، وضعیت سیستم رو تغییر میده. پس این عملیات Idempotent نیست. تعریف رسمی Idempotent هم تقریباً همینه؛ اگه یه عملیات رو یک بار اجرا کنیم یا چند بار پشت سر هم، وضعیت نهایی سیستم باید یکسان باشه. یه نکته‌ی مهم اینجاست که Idempotent بودن به این معنی نیست که خروجی عملیات همیشه یکی باشه. ممکنه هر بار اطلاعات متفاوتی برگرده، زمان اجرا فرق کنه یا حتی پیام متفاوتی نمایش داده بشه. چیزی که مهمه اینه که اجرای دوباره‌ی همون عملیات، وضعیت سیستم رو بیشتر از دفعه‌ی اول تغییر نده. یکی از اشتباه‌های رایج اینه که Idempotent رو با عملیاتی که هیچ تغییری ایجاد نمی‌کنه، اشتباه می‌گیرن. در حالی که یه عملیات Idempotent می‌تونه وضعیت سیستم رو تغییر بده؛ فقط این تغییر باید فقط بار اول اتفاق بیفته. مثلاً اگه عملیاتی وضعیت یه کاربر رو از «غیرفعال» به «فعال» تغییر بده، بار اول وضعیت عوض میشه، اما اگه دوباره همون عملیات اجرا بشه، دیگه تغییری ایجاد نمی‌کنه. پس این عملیات همچنان Idempotent محسوب میشه. از اون طرف، عملیات‌هایی مثل «افزایش موجودی»، «افزایش تعداد بازدید»، «ارسال ایمیل» یا «ثبت سفارش جدید» معمولاً Idempotent نیستن؛ چون هر بار اجرا شدنشون یه اثر جدید روی سیستم میذاره. دلیل اهمیت Idempotent فقط ساده‌تر شدن منطق برنامه نیست. توی سیستم‌های واقعی همیشه ممکنه شبکه قطع بشه، درخواست Timeout بشه، کلاینت دوباره درخواست رو Retry کنه یا یه Job دوباره اجرا بشه. اگه عملیات شما Idempotent باشه، دیگه مهم نیست همون عملیات چند بار اجرا بشه؛ نتیجه‌ی نهایی تغییری نمی‌کنه و سیستم توی وضعیت درستی باقی می‌مونه. به خاطر همین، این مفهوم تقریباً توی همه‌ی شاخه‌های مهندسی نرم‌افزار دیده میشه؛ از طراحی APIها گرفته تا پایگاه داده، Message Queueها، Event-Driven Architecture، Infrastructure و حتی ابزارهای مدیریت سرور. در نهایت، Idempotent یه تکنولوژی یا قابلیت خاص نیست؛ یه ویژگی برای طراحی عملیاته. هر وقت بتونید عملیاتی طراحی کنید که اجرای دوباره‌ی اون، وضعیت نهایی سیستم رو تغییر نده، اون عملیات Idempotent محسوب میشه. #programming #software_engineering @Syntax_fa1,39%
16 июл.بازنویسی Bun از Zig به Rust؛ کاملاً با هوش مصنوعی همون‌طور که احتمالاً می‌دونید، Bun یک JavaScript Runtime مدرنه که با تمرکز روی سرعت ساخته شده. این پروژه در ابتدا با Zig توسعه پیدا کرد؛ چون Zig به یک تیم کوچک اجازه می‌داد بدون سربار Garbage Collector و Runtimeهای سنگین، خیلی سریع یک Runtime پرسرعت بسازه. دسترسی مستقیم به حافظه، سادگی زبان و تعامل خوب با C باعث شد معماری و طراحی سطح پایین Bun حول Zig شکل بگیره؛ موضوعی که Jarred Sumner، خالق Bun، هم بارها بهش اشاره کرده. اما در ماه می امسال، تیم Bun اعلام کرد که قصد داره کل پروژه رو به Rust مهاجرت بده. حالا این بازنویسی انجام شده و کدهای Rust هم وارد شاخه اصلی پروژه شدن. نکته‌ی عجیب اینجاست که تقریباً تمام این کدها توسط Claude Code تولید شدن و علاوه بر بازنویسی، تعدادی از باگ‌های قدیمی هم در همین فرآیند برطرف شدن. آیا مشکل از Zig بود؟ از نگاه تیم Bun، مشکل اصلی خود Zig نبود؛ بلکه مدیریت دستی حافظه در کنار Garbage Collector جاوااسکریپت بود. این ترکیب باعث نشت حافظه، کرش و هزینه‌ی بالای نگهداری کد می‌شد و با بزرگ‌تر شدن پروژه، اتکا به دقت برنامه‌نویس دیگر کافی نبود. با این حال، جرد تأکید می‌کنه که Zig نقش مهمی در موفقیت اولیه Bun داشته و بخش بزرگی از معماری و عملکرد فعلی پروژه مدیون همون انتخاب اولیه است. در مقابل، اندرو کلی، خالق Zig، بارها گفته مشکل از زبان Zig نبوده، بلکه از نحوه‌ی استفاده‌ی Bun از اون بوده. حتی جایی گفته بود داخل تیم Zig، از Bun به‌عنوان مثالی استفاده می‌کنیم که «چطور نباید با Zig برنامه نوشت». چرا Rust؟ بخش بزرگی از باگ‌های Bun به مدیریت حافظه مربوط می‌شد. در Rust این دسته از خطاها معمولاً هنگام کامپایل شناسایی می‌شن و مکانیزم Ownership و Drop هم آزادسازی حافظه رو مدیریت می‌کنن. در نتیجه، به جای اینکه توسعه‌دهنده همیشه مراقب همه‌چیز باشه، کامپایلر جلوی بخش زیادی از اشتباهات رو می‌گیره. البته بازنویسی پروژه‌ای با بیش از ۵۳۵ هزار خط کد Zig اصلاً تصمیم ساده‌ای نبود. انجام دستی این کار حداقل یک سال زمان می‌برد و عملاً توسعه‌ی Bun رو متوقف می‌کرد. تیم ابتدا سعی کرد با Smart Pointerهای الهام‌گرفته از Rust و سخت‌گیرتر کردن قوانین کدنویسی، مشکلات رو داخل Zig حل کنه، اما در نهایت تصمیم گرفت از Claude Code برای بازنویسی کامل پروژه استفاده کنه. کلاد چطور این بازنویسی را انجام داد؟ جرد می‌گه ماجرا به سادگی این نبود که به Claude بگه «کل Bun رو به Rust تبدیل کن». قبل از شروع، ساعت‌ها صرف طراحی Workflowها و استراتژی بازنویسی شد. در نهایت، حدود ۵۰ Workflow مختلف به مدت ۱۱ روز تقریباً بدون توقف اجرا شدن؛ با هزینه‌ای نزدیک به ۱۶۵ هزار دلار. هر Workflow وظیفه‌ی مشخصی داشت؛ از تبدیل الگوهای Zig به Rust و رفع خطاهای کامپایل گرفته تا اجرای bun test و bun build. پاس کردن تست‌ها و در نهایت Refactor کد. جرد هم به‌جای اصلاح مستقیم خروجی‌ها، Workflowها و Promptها رو بهبود می‌داد تا هر بار کیفیت خروجی بهتر بشه. برای اعتماد به بیش از یک میلیون خط کد تولیدشده توسط هوش مصنوعی هم از روشی شبیه Code Review واقعی استفاده شد. یک Claude کد رو می‌نوشت و چند Claude دیگه، در Contextهای جداگانه، فقط وظیفه داشتن ایرادها و باگ‌ها رو پیدا کنن. نویسنده‌ی کد Reviewer نبود و Reviewer هم اجازه‌ی تغییر کد رو نداشت. بعد از تبدیل همه‌ی فایل‌ها، مرحله‌ی اصلی یعنی رفع خطاها و پاس کردن تست‌ها شروع شد. این چرخه بارها تکرار شد تا در نهایت تمام تست‌های Bun روی همه‌ی پلتفرم‌ها با موفقیت پاس شدن و کد وارد شاخه‌ی اصلی پروژه شد. آیا این بازنویسی موفق خواهد بود؟ در کوتاه‌مدت احتمالاً بله. تست‌ها مسیرهای اصلی رو پوشش می‌دن، نسخه‌های Canary مشکلات واضح رو پیدا می‌کنن و Rust هم بخش بزرگی از خطاهای مدیریت حافظه رو حذف می‌کنه. اما سؤال اصلی بلندمدته. اگر چند ماه بعد یک باگ پیچیده‌ی Concurrency یا یک حالت مرزی عجیب ظاهر بشه، مهندسی که مسئول دیباگ کردنشه با کدی روبه‌رو می‌شه که تقریباً هیچ انسانی اون رو به‌طور کامل ننوشته یا خط‌به‌خط درکش نکرده. در نهایت، شرط‌بندی اصلی این پروژه نه روی Zig و Rust، بلکه روی این سؤاله که آیا یک Codebase عظیم که عمدتاً توسط هوش مصنوعی تولید شده، در بلندمدت هم قابل نگهداری و قابل اعتماد خواهد بود یا نه. از طرف دیگه، بعضی‌ها هم معتقدن این اتفاق فقط یک بازنویسی فنی نبوده و بخشی از یک کمپین بازاریابی برای Claude محسوب می‌شه. پاسخ اینکه این تصمیم در نهایت موفق خواهد بود یا نه، فعلاً مشخص نیست؛ چیزی که فقط با گذر زمان معلوم می‌شه. مقاله ای که خود جرد منتشر کرده و در مورد این تغییرات توضیح داده: https://bun.com/blog/bun-in-rust #News @Syntax_fa1,21%
1 июл.همیشه برام جالب بود که ما دولوپرها می‌تونیم پیچیده‌ترین لاجیک‌ها رو تو کدهامون هندل کنیم، اما وقتی نوبت به باگ‌های ذهن و تله‌های رفتاری خودمون می‌رسه، هیچ دیباگری نداریم. این دغدغه باعث شد تو ماه‌های گذشته، منطق بک‌اند رو با مفاهیم عمیق روان‌شناسی تحلیلی و کهن‌الگوها ترکیب کنم. خروجی این ترکیب شده پروژه‌ی جدیدم: زروانا. زروانا یه لابراتوارِ مبتنی بر هوش مصنوعیه که دیتای پراکنده ذهن شما (از خواب‌ها و کابوس‌ها گرفته تا تست‌های روان‌سنجی) رو می‌گیره، پردازش می‌کنه و بهتون می‌گه دقیقاً کجای ناخودآگاهتون گیر کردید و کدوم سایه داره تصمیماتون رو کنترل می‌کنه. از نظر فنی و اینکه چطور پیاده سازیش کردم تو پست های آینده دربارش صحبت میکنم. دوست دارم شما بچه‌های کامیونیتی فنی جزو اولین نفراتی باشید که این سیستم رو تست می‌کنید. روی دیباگ کردنش حساب کردم. لینک زروانا: https://t.me/ZervanaBot1,21%
18 июл.پکیج پایتونی gevent چرا gevent اصلاً متولد شد؟ قبل از اینکه کلمات کلیدی async و await وارد پایتون شوند، برنامه‌نویس‌ها برای مدیریت هزاران درخواست همزمان (مشکل C10k) یک دردسر بزرگ داشتند. استفاده از Threadهای سیستم‌عامل برای پایتون بسیار سنگین بود و حافظه زیادی مصرف می‌کرد. فریم‌ورک‌هایی مثل Twisted هم بودند که بر اساس Callback کار می‌کردند، اما خواندن و دیباگ کردن کدهای آن‌ها شبیه یک کابوس (Callback Hell) بود. اینجا بود که gevent با یک ایده درخشان وارد شد: کد را به شکل ساده و همگام (Sync) بنویس، اما ما آن را در پس‌زمینه به صورت ناهمگام (Async) و با سرعت نور اجرا می‌کنیم! gevent این کار را با استفاده از گرین‌لت‌ها (Greenlets) که میکروتردهای بسیار سبکی در سطح C هستند، انجام داد. الان با وجود asyncio، پرونده gevent بسته شده است؟ با اینکه asyncio استاندارد مدرن و آینده پایتون است، اما gevent هنوز یک برگ برنده بزرگ دارد: پروژه‌های قدیمی (Legacy). اگر شما یک پروژه بزرگ جنگو (Django) یا فلسک (Flask) دارید که با کدهای معمولی نوشته شده، نمی‌توانید یک‌شبه ده‌ها هزار خط کد را به async/await تبدیل کنید. gevent با تکنیک Monkey Patching به شما اجازه می‌دهد بدون تغییر دادن حتی یک خط از منطق اصلی برنامه‌تان، عملکرد I/O سرور را چند برابر کنید. مثال در سلری: فرض کنید باید ۱۰۰ ایمیل بفرستید یا از ۱۰۰ سایت دیتا استخراج کنید (کارهای I/O Bound).اگر در Celery از حالت پیش‌فرض (Prefork/Processes) استفاده کنید و فقط ۲ عدد Worker داشته باشید، در هر لحظه فقط ۲ تسک انجام می‌شود. بقیه تسک‌ها باید در صف منتظر بمانند تا این دو تمام شوند. این یعنی اتلاف زمان! اما اگر Worker را با gevent اجرا کنید: celery -A my_project worker -P gevent -c 100 همان ۲ پروسس حالا می‌توانند هر ۱۰۰ تسک را همزمان مدیریت کنند! وقتی تسک اول منتظر جواب سرور ایمیل است، gevent سریعاً سراغ تسک دوم می‌رود. با کمترین مصرف رم و CPU، سرعت اجرای تسک‌های شبکه‌ای شما ده‌ها برابر می‌شود. #gevent @Syntax_fa1,13%
14 июн.این تلگرام چیه که همش آپدیت خفن میده و تمومیم نداره. قابلیت های جدید تلگرام rich formatter برای نوشتن پست @Syntax_fa1,05%
29 июн.کانکارنسی فقط «همزمان اجرا شدن» نیست. خیلی‌ها فکر می‌کنند اگر دو عملیات همزمان اجرا شوند، با مسئله‌ی Concurrency روبه‌رو هستیم. اما اگر این دو عملیات هیچ ارتباطی با هم نداشته باشند، در واقع مشکلی وجود ندارد. برای مثال: یک سرویس در حال فشرده‌سازی تصویر است. سرویس دیگری در حال پردازش ویدئو است. این دو ممکن است کانکارنت اجرا شوند، اما چون روی داده‌ی مشترکی کار نمی‌کنند، نیازی به هماهنگی خاصی ندارند. مشکل واقعی زمانی شروع می‌شود که چند عملیات به یک داده‌ی مشترک و قابل تغییر (Shared Mutable State) دسترسی داشته باشند. فرض کنید دو تراکنش همزمان روی موجودی یک حساب بانکی کار می‌کنند: تراکنش اول: 50 واحد از موجودی کم می‌کند. تراکنش دوم: 100 واحد به موجودی اضافه می‌کند. در اینجا دیگر فقط «همزمان بودن» مهم نیست؛ بلکه ترتیب اجرا و نحوه‌ی تعامل این دو عملیات می‌تواند نتیجه‌ی نهایی را تغییر دهد. اگر این تعامل به‌درستی مدیریت نشود، ممکن است داده‌ها ناسازگار شوند یا حتی تغییرات یکی از تراکنش‌ها از بین برود. به همین دلیل، Concurrency را می‌توان این‌گونه تعریف کرد: کانکارنسی یعنی مدیریت صحیح دسترسی همزمان چند عملیات به یک وضعیت (State) مشترک، به‌گونه‌ای که مستقل از ترتیب اجرای آن‌ها، نتیجه همچنان صحیح باقی بماند. به همین خاطر است که مفاهیمی مانند Isolation ، Locking ، MVCC و Serializability در سیستم‌های پایگاه داده به وجود آمده‌اند؛ هدف همه‌ی آن‌ها یک چیز است: حفظ صحت داده‌ها، حتی زمانی که چند عملیات به طور همزمان در حال اجرا هستند. #programming #system_design @Syntax_fa1,02%
5 июн.موقع جنگ جوری لینوکسمو اومده بودم بهینه کرده بودم که یه کیلوبایتم هدر نره. وقتشه همه تغییراتو به حالت قبل برگردونم1,01%
3 июл.متد جدید HTTP؛ آشنایی با QUERY اگر تا حالا با REST یا HTTP کار کرده باشید، قطعا با متدهای GET، POST، PUT، PATCH و DELETE آشنایی دارید. اما بعد از حدود ۱۶ سال، یک متد جدید به پروتکل HTTP اضافه شده که اسمش QUERY هست. بیاید با یه مثال ببینیم اصلاً چرا چنین متدی به وجود اومده. فرض کنید یه endpoint به اسم orders داریم که از Pagination، Filter، Sort و موارد مشابه پشتیبانی می‌کنه. معمولاً برای دریافت اطلاعات از متد GET استفاده می‌کنیم و پارامترها رو هم به صورت Query String داخل URL می‌فرستیم. GET /orders?status=paid&limit=20&offset=0 این روش سال‌هاست که استفاده میشه و تو اکثر مواقع هم کاملاً منطقیه، اما چند تا محدودیت داره: • طول URL محدوده (معمولاً حدود ۸۰۰۰ کاراکتر یا حتی کمتر، بسته به سرور و مرورگر) • پارامترها داخل URL قرار می‌گیرن و ممکنه توی لاگ‌های سرور ثبت بشن. • ساختن کوئری‌های پیچیده مثل فیلترهای پیشرفته، SQL، JSONPath و... سخت یا حتی غیرممکنه. • انکودینگ کردن پارامترهای پیچیده هم دردسرهای خودش رو داره. معمولاً وقتی به این محدودیت‌ها می‌رسیم، خیلی‌ها به جای GET از POST استفاده می‌کنن و پارامترها رو داخل Body درخواست می‌ذارن. POST /orders HTTP/1.1 Host: api.example.org Content-Type: application/x-www-form-urlencoded select=surname,givenname,email&limit=10&match="email=@example." این روش مشکل محدودیت URL رو حل می‌کنه، اما خودش چند تا ایراد مهم داره: • متد POST ذاتاً Idempotent نیست؛ یعنی اگر وسط ارسال درخواست ارتباط قطع بشه، نمی‌شه با خیال راحت همون درخواست رو دوباره ارسال کرد، چون ممکنه عملیات دوباره انجام بشه. • پاسخ‌های POST به صورت پیش‌فرض از Cache استاندارد HTTP استفاده نمی‌کنن. • پروکسی ها و CDNها نمی‌تونن تشخیص بدن که ارسال مجدد این درخواست امن هست یا نه. • هر فریم‌ورک هم معمولاً راهکار خودش رو برای پیاده‌سازی چیزی مثل Safe POST داره و استاندارد یکپارچه‌ای وجود نداره. اینجاست که QUERY وارد میشه. ایده‌ی اصلی QUERY اینه که بهترین ویژگی‌های GET و POST رو با هم ترکیب کنه. از یه طرف مثل GET فقط برای خوندن اطلاعات استفاده میشه و هیچ تغییری روی وضعیت سرور ایجاد نمی‌کنه، و از طرف دیگه مثل POST می‌تونه داده‌های پیچیده رو داخل Body درخواست ارسال کنه. در نتیجه درخواست‌هامون به این شکل درمیاد: QUERY /orders HTTP/1.1 Host: api.example.org Content-Type: application/x-www-form-urlencoded Accept: application/json select=surname,givenname,email&limit=10&match="email=@example." به این ترتیب دیگه محدودیت طول URL وجود نداره و می‌تونید هر نوع فیلتر پیچیده، کوئری، JSONPath یا هر داده‌ی دیگه‌ای رو داخل Body ارسال کنید. اما مزیت QUERY فقط این نیست. یکی از مهم‌ترین ویژگی‌های این متد، Idempotent بودنشه. یعنی اگر به هر دلیلی ارتباط شبکه قطع بشه، کلاینت می‌تونه همون درخواست رو دوباره ارسال کنه و مطمئن باشه نتیجه دقیقاً همون نتیجه‌ی قبلی خواهد بود. برخلاف POST که ارسال مجددش ممکنه باعث ایجاد داده‌های تکراری یا اجرای دوباره‌ی عملیات بشه. از طرف دیگه، چون QUERY یک متد Safe محسوب میشه و فقط برای دریافت داده استفاده میشه، زیرساخت‌های HTTP مثل مرورگرها، Proxyها و CDNها می‌تونن پاسخش رو مثل GET کش کنن. یعنی درخواست‌های پیچیده‌ای که قبلاً مجبور بودیم با POST بفرستیم، حالا می‌تونن از مزایای Cache استاندارد HTTP هم استفاده کنن. یکی دیگه از قابلیت‌های جالب QUERY اینه که سرور می‌تونه برای خودِ درخواست یک URI دائمی ایجاد کنه. یعنی به جای اینکه فقط نتیجه‌ی جستجو قابل دسترس باشه، خود Query هم یک آدرس اختصاصی خواهد داشت. هر بار که اون آدرس فراخوانی بشه، همون جستجو دوباره روی داده‌های جدید اجرا میشه. این قابلیت برای Share کردن جستجوها، Bookmark کردنشون یا اجرای دوره‌ای یک Query بدون ارسال دوباره‌ی Body خیلی کاربردیه. در نهایت، متد QUERY به صورت رسمی استاندارد شده، اما هنوز راه زیادی تا استفاده‌ی گسترده ازش باقی مونده. بعضی از اکوسیستم‌ها مثل Go و Java کار روی پشتیبانی ازش رو شروع کردن و احتمالاً در آینده اسم این متد رو بیشتر خواهیم شنید. البته فعلاً پشتیبانی ازش محدود به چند کتابخونه و سرور خاصه و هنوز اکثر فریم‌ورک‌ها و API Gatewayها ازش پشتیبانی کامل ندارن. اگر دوست دارید بیشتر درباره این متد بدونید، پیشنهاد می‌کنم RFC مربوط بهش رو هم بخونید: https://www.rfc-editor.org/info/rfc10008 #programming @Syntax_fa0,98%
2 авг.تو دنیای برنامه‌نویسی برای چه کاری ساخته شدی؟ معمولاً بزرگترین دغدغه‌ی کسایی که تازه می‌خوان وارد دنیای جذاب صفر و یک بشن اینه که: «اصلاً از کجا شروع کنم؟» بک‌اند؟ فرانت‌اند؟ هوش مصنوعی یا امنیت؟ تو این تست ما با چند تا سناریوی تحلیلی و ظریفِ روزمره، مدل ذهنی و شیوه حل مسئله‌ت رو می‌سنجیم تا بهت بگیم کدوم شاخه از دنیای نرم‌افزار، بیشترین هماهنگی رو با دی‌ان‌ای روانیت داره. 𝒁𝒆𝒓𝒗𝒂𝒏𝒂0,91%