رفتن به مطلب
مرجع رسمی سی‌پلاس‌پلاس ایران

کامبیز اسدزاده

بنیـــان گذار
 نمایش نمایه  مشاهده فعالیت های این کاربر

  • تعداد ارسال ها

    505

  • تاریخ عضویت

  • روز های برد

    266

نوشته‌های وبلاگ ارسال شده توسط کامبیز اسدزاده

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

    بررسی مجوز‌های جامع Qt
    ابزار Qt، یک چهارچوب قدرتمند برنامه‌نویسی چندسکویی است که انواع مختلفی از مجوزها را ارائه می‌دهد تا به نیازهای متنوع کاربران خود پاسخ دهد. با توجه به تاریخچهٔ غنی‌ای که به آغاز توسعهٔ آن باز می‌گردد، Qt به تدریج به یکی از اصلی‌ترین بازیگران در زمینه توسعه نرم‌افزار تبدیل شده است که در این مقاله به آن اشاره می‌کنیم.
    Qt تحت چندین گزینه مجوز مختلف قرار دارد که برای توسعه نرم‌افزارهای مختلف مناسب هستند که به صورت زیر تعریف شده‌اند.
    مجوز تجاری Qt فریم‌ورک کیوت، زیر مجوزهای تجاری مناسبی را برای توسعه نرم‌افزارهای تجاری فراهم کرده است که کاربران نمی‌خواهند کد منبع خود را با دیگران به اشتراک بگذارند یا نمی‌توانند با شرایط نسخه 3 مجوز GNU LGPL (GNU Lesser General Public License) سازگاری یابند. مجوز LGPL Qt این مجوز برای توسعه نرم‌افزارهای Qt مناسب است، تا زمانی که شما می‌توانید با شرایط نسخه 3 مجوز GNU LGPL (یا GNU GPL نسخه 3) سازگار باشید. مجوز بازار Qt (Qt Marketplace) اجزای Qt تحت توافق‌نامه مجوز بازار Qt مناسب برای توسعه نرم‌افزارهای Qt هستند، معمولاً با شرایط مجوز تجاری یا GNU LGPL (یا GNU GPL نسخه 3) برنامه‌ریزی می‌شوند. استفاده از کد، از طریق مجوزهای متن‌باز
    فریم‌ورک Qt شامل کدهای شخص ثالثی است که تحت مجوزهای خاص متن‌باز از نویسندگان اصلی مجوزدهی شده‌اند.
    برخی از سوأل و پرسش‌های جامعه و تیم کیوت در رابطه با مجوز‌ها و اهداف آن‌ها در توسعه
    چرا Qt همچنین زیر مجوز نرم‌افزار متن باز نیز منتشر می‌شود؟
    ما به جنبش نرم‌افزار آزاد اعتقاد داریم که استفاده از نرم‌افزار با حقوق وظایف خاصی همراه است. استفاده از مجوزهای نرم‌افزار متن باز، به کاربران چهار درجه اصلی از آزادی را در استفاده از برنامه‌ها یا دستگاه‌های Qt می‌دهد:
    آزادی اجرای برنامه برای هر هدفی. آزادی مطالعه نحوه عمل برنامه و سازگارسازی آن با نیازهای خاص. آزادی توزیع نسخه‌های کپی شده تا بتوانید به همسایه خود کمک کنید. آزادی بهبود برنامه و انتشار بهبود‌های خود به عموم، تا کل جامعه بهره‌مند شود. این آزادی‌ها غیرقابل مذاکره و مطلق هستند، نمی‌توان آنها را به صورت انتخابی یا جزئی تجربه کرد، شما همچنین موظف به انتقال آنها به کاربران خود هستید.
    چرا شما توافقی با KDE در مورد مجوزهای خود دارید؟ KDE چیست و تاریخچهٔ Qt و KDE چگونه است؟
    توافق بین Qt و KDE دربارهٔ مجوزها، ریشه در تاریخچهٔ مشترک این دو نهاد دارد. KDE (kde.org) مخفف محیط کاری دسکتاپ (Desktop Environment) است که یک جامعهٔ بین‌المللی نرم‌افزار آزاد است و در سال ۱۹۹۶ تأسیس شد. KDE به خاطر محیط کاری Plasma Desktop شناخته می‌شود که به عنوان محیط کاری پیش‌فرض در بسیاری از توزیع‌های لینوکس به کار می‌رود. نرم‌افزارهای KDE بر پایهٔ چارچوب Qt ساخته می‌شوند. در اوایل توسعهٔ Qt، این چارچوب از یک مدل مجوز دوگانه برخوردار بود و کد منبع آن تحت مجوزهای متن باز اختصاصی قابل دسترس بود. با درک اهمیت Qt برای پروژه‌های خود، KDE تلاش کرد تا توافقاتی برای اطمینان از دسترسی به Qt تحت مجوزهای مناسب متن باز، حتی اگر Trolltech (شرکت بنیان‌گذار Qt) به تصرف بشود یا ورشکست شود، به دست آورد. نتیجهٔ این تفاهم، بنیاد آزاد KDE Qt (KDE Free Qt Foundation) تأسیس شد و توافق‌نامه بنیاد آزاد KDE Qt ایجاد شد.
    بنیاد آزاد KDE Qt یک سازمان با هدف ایمن کردن دسترسی به چارچوب Qt برای توسعهٔ نرم‌افزارهای آزاد و به‌ویژه برای توسعهٔ نرم‌افزارهای KDE است. این بنیاد در ابتدا توسط Trolltech و سازمان غیرانتفاعی حقوقی KDE (KDE e.V.) در سال ۱۹۹۸ تأسیس شد و یک توافق‌نامهٔ مجوز دارد که تأمین می‌کند که Qt برای پلتفرم‌های اصلی دسکتاپ و موبایل تحت مجوزهای LGPLv3 و GPLv3 در دسترس است. این توافق‌نامه در طی سال‌ها چندین بار به‌روزرسانی شده است، عمدتاً به دلیل انجام معاملات مرتبط با Qt یا به‌روزرسانی مجوزها و پلتفرم‌ها.
     
    عدم رعایت محدودیت‌های مجوزهای LGPL/GPL چه تبعاتی دارد؟
    اگر نرم‌افزاری که از این کتابخانه‌های مجوز متن‌باز استفاده می‌کند، به طور کامل الزامات مجوز را رعایت نکند، شما حق استفادهٔ مجوز و حقوق توزیع مرتبط با آن را از دست خواهید داد. همچنین لازم به ذکر است که در بیشتر کشورها، نقض حقوق نسخهٔ پدیدآورندگان یک نقض تشریعی است، نه نقض قرارداد، و بنابراین تدابیر تشریعی مرتبط با این موضوع اعمال می‌شود. برای کسب اطلاعات بیشتر در مورد GPL، می‌توانید به صفحه FAQ GPL از لینک آن مراجعه کنید.
     
    آیا می‌توانم از نسخهٔ متن باز جوامع برای توسعه محصول تجاری خود استفاده کنم؟
    این بستگی به نحوهٔ ارائه و ارائهٔ محصول شما دارد. نسخهٔ متن باز Qt اصلی به طور عمده تحت مجوز LGPL نسخه 3 و GPLv2/v3 منتشر می‌شود. شما باید الزامات مجوزهای این گونه را که در زمان استفاده از Qt در محصول خود باید رعایت کنید.
     
    تفاوت بین LGPLv2 و LGPLv3 چیست؟
    LGPLv3 نسخه فعلی مجوز GNU Lesser General Public License است. LGPLv2.1 یک نسخه قدیمی‌تر است و برای پروژه‌های جدید توصیه نمی‌شود. هر دو مجوز همان هدف را دارند، یعنی حفاظت از آزادی کاربران برای استفاده و اصلاح نرم‌افزار تحت مجوز LGPL.
    LGPLv3 این هدف را به وضوح بیان می‌کند. شما باید چیز‌هایی را برای کاربر نهایی فراهم کنید تا نسخه اصلاح شدهٔ کتابخانه تحت مجوز LGPLv3 را نصب کرده و نرم‌افزار خود را با استفاده از آن کتابخانه اصلاح شده اجرا کند. در عمل، این به عنوان مثال به موارد زیر اشاره دارد:
    Tivoization – به وضوح اجازه ندهید دستگاه‌های بسته سازی‌شده ایجاد شود که کاربر نهایی حقوق مجوز LGPL برای کتابخانه‌های متن باز Qt را ندارد. DRM و رمزگذاری سخت‌افزاری – نمی‌توان از این تعهدات برای دور زدن این تعهدات استفاده کرد. انتقام از پتنت نرم‌افزار – جایی که تمام کاربران نرم‌افزار مجوزها را دارند، که این باعث بی‌معنی شدن انتقام از پتنت نرم‌افزارهایی که ممکن است در نرم‌افزار منتشر شده، می‌شود.  
    وظایف من چیستند هنگام استفاده از Qt تحت مجوز LGPL؟
    در ابتدا، باید توجه داشته باشید که تمامی ماژول‌های متن باز Qt تحت مجوز LGPLv3 در دسترس نیستند. برخی از ماژول‌ها برای استفاده در نرم‌افزارهای متن باز تحت GPLv3 قرار دارند و برخی از اجزاء توسعه‌یافته توسط شخص ثالث مانند موتور وب Chromium تحت مجوز LGPLv2.1 در دسترس قرار گرفته‌اند.
    زمانی که از ماژول‌ها و کتابخانه‌های Qt تحت مجوز LGPLv3 استفاده می‌کنید، برخی از وظایفی که باید رعایت کنید به شرح زیر است:
    هنگام استفاده از نرم‌افزار متن باز، باید از مجوز هر نمونه، قطعه کد منبع، ماژول و کتابخانه‌ای که در پروژه خود استفاده می‌کنید، آگاه باشید و مجوزهای مرتبط را ردیابی کنید. باید کد منبع کامل کتابخانه‌های Qt که استفاده کرده‌اید را به همراه تمام اصلاحات اعمال شده یا اعمال شده، به کاربران یا مشتریان خود ارائه دهید. به عنوان یک گزینه دیگر، می‌توانید پیشنهاد نامه‌ای با دستورالعمل‌هایی در مورد چگونگی دریافت کد منبع ارائه دهید. لطفاً توجه داشته باشید که این باید تحت کنترل شما باشد، بنابراین ارائه یک لینک به کد منبع ارائه‌شده توسط پروژه Qt یا شرکت Qt کافی نیست. مجوز LGPL به شما این امکان را می‌دهد که کد منبع خود نرم‌افزار را به عنوان «کاری که از کتابخانه استفاده می‌کند» خصوصی نگه‌دارید. به طور معمول، در اینجا پیشنهاد می‌شود که از اتصال پویا استفاده کنید (برای کامپایل استاتیک این مورد مجاز نیست و نیاز به تهیهٔ مجوز دارد). کاربر نهایی باید قادر باشد نرم‌افزار شما را با یک نسخه مختلف یا اصلاح‌شده از کتابخانه Qt مجدداً لینک کند. با LGPLv3، به وضوح ذکر شده است که کاربر باید قادر باشد باینری مجدداً لینک‌شده را بر روی دستگاه هدف خود اجرا کند. این وظیفه به شما محول است که کاربر را با همه ابزارهای لازم برای فعال کردن این فرآیند تجهیز کنید. برای دستگاه‌های جاسازی‌شده، این شامل فراهم‌کردن تمام ابزارهایی است که برای کامپایل کتابخانه استفاده‌شده به کاربران مورد نیاز است. برای اجزاء مجوزده LGPLv3، شما موظف به ارائه دستورالعمل‌های کامل در مورد نصب کتابخانه اصلاح‌شده بر روی دستگاه هدف هستید (این با LGPLv2.1 به طور واضح بیان نشده است، اگرچه اجرای برنامه در برابر نسخهٔ اصلاح شدهٔ کتابخانه با هدف اعلام شده در مجوز است). کاربری که از یک برنامه یا دستگاه که از نرم‌افزار متن باز تحت مجوز LGPL استفاده می‌کند، باید از حقوق خود مطلع شود، با ارائه یک نسخه از مجوز LGPL به کاربر نهایی و نمایش اعلان مشهور در مورد استفاده‌ شما از نرم‌افزار متن باز باید اعلام شود. این آزادی‌ها به هیچ وجه توسط شرایط دیگر مجوز گزینشی نمی‌توانند محدود شوند؛ اگر یک برنامه به کلی از تمام وظایفی که در بالا ذکر شده است پیروی نکند، اجازه توزیع آن به هیچ وجه داده نمی‌شود. همچنین باید اطمینان حاصل کنید که از هیچ ماژولی که تحت مجوز GPL استفاده نمی‌کنید.  
    آیا نیاز است که از مجوز LGPL هنگام استفاده از نسخهٔ تجاری Qt نگران باشم؟
    به طور معمول، خیر. هنگام استفاده از نسخهٔ تجاری مجوزگذاری شده Qt، ما تقریباً تمامی بخش‌ها را تحت شرایط یک مجوز تجاری ارائه می‌دهیم.
    هرچند، چندین ماژول در Qt از کد منبع پروژه‌های متن باز شخص ثالث مانند Qt WebEngine استفاده می‌کنند که از پروژه Chromium با مجوز LGPLv2.1 استفاده می‌کند. بنابراین، هنگام استفاده از این ماژول‌ها، شما باید از تعهدات مجوز مرتبط رعایت کنید، در مورد Chromium این موضوع به مجوز LGPLv2.1 اشاره دارد.
    تمامی ماژول‌ها و وابستگی‌های شخص ثالثی که توسط ماژول‌های مختلف Qt استفاده می‌شوند، در مستندات Qt برای هر نسخه از Qt مستند شده‌اند.
    به عنوان یک کاربر مجوز تجاری، در عمل، تنها نیاز دارید که به تعهدات مجوز LGPLv2.1 اهمیت بدهید، و تنها اگر از Qt WebEngine استفاده کنید.
     
    چه کاری باید انجام دهم؟
    مطمئن نیستم که مطابق مجوزهای متن باز هستم؟ از مجوزهای متن باز گیج شده‌ام، چه باید انجام دهم؟
    همیشه خوشحال هستیم که با شما درباره وضعیتتان صحبت کنیم، اما ما در جایی نیستیم که مشاوره حقوقی ارائه دهیم. همیشه توصیه می‌شود با یک وکیل که با مجوزهای متن باز آشنا است، تماس بگیرید تا یک بررسی کامل از پروژه شما صورت گیرد و تصمیم گیری شود که آیا شما می‌توانید تمامی تعهدات مجوزهای متن باز مربوطه (مانند LGPLv/GPLv) را انجام دهید یا خیر.
     
    مجوز تجاری Qt چگونه کار می کند؟ آیا همه توسعه دهندگان من باید مجوز معتبر Qt داشته باشند؟
    در رابطه با مجوز‌های تجاری، هر کاربر Qt باید مجوز تجاری Qt مختص خود را داشته باشد. طراحان رابط کاربری، هنرمندان فنی، توسعه‌دهندگان نرم‌افزار یا مهندسان اتوماسیون تست ممکن است انواع مختلفی از مجوزهای Qt داشته باشند، اما هر فرد باید یک مجوز اشتراک معتبر داشته باشد.
     
    آیا می‌توانم کد نوشته‌شده با Qt متن باز را با Qt تجاری مجوزگذاری شده ترکیب کنم؟
    خیر.
    اگر می‌خواهید از Qt متن باز به یک مجوز تجاری مهاجرت کنید، لطفاً با فروشگاه Qt تماس بگیرید.
    برای این سوال، موارد بیشتری نیز در لینک FAQ مجوزگذاری تجاری Qt وجود دارد.
     
    آیا امکان توزیع برنامه‌های توسعه یافته با نسخهٔ متن باز Qt از طریق فروشگاه‌های عمومی وجود دارد؟
    هر فروشگاه اپلیکیشن شرایط و مقررات منحصر به فردی دارد که ممکن است با توزیع برنامه‌ها تحت مجوزهای LGPL یا GPL سازگار یا سازگار نباشد.
    مجوز تجاری Qt با شرایط و مقررات تمامی فروشگاه‌های اپلیکیشن معتبر سازگار است و بنابراین معمولاً بهترین گزینه برای توزیع یک برنامه به صورت منبع بسته در فروشگاه‌های مختلف است.
     
    من شروع به توسعه یک محصول با استفاده از نسخهٔ متن باز Qt کرده‌ام، حالا می‌توانم یک نسخهٔ تجاری از Qt خریداری کرده و کدم را تحت آن مجوز قرار دهم؟
    بله. پروژه‌های توزیع‌شده تحت نسخهٔ تجاری Qt نیز باید تحت نسخهٔ تجاری Qt توسعه یابند.
    اگر قبلاً توسعه را با نسخهٔ متن باز Qt شروع کرده‌اید، ما به همکاری برای یافتن یک راه‌حل برای انتقال پایه کد شما از حاکمیت متن باز به مجوز تجاری می‌پردازیم.
    اگر از ابتدا مطمئن نیستید که از کدام مجوز یا نسخه برای شروع توسعه استفاده کنید، توصیه می‌شود با The Qt Company تماس بگیرید تا بر اساس نیازهای توسعه‌ی خود شما راهنمایی شود.
     
    ممکن است در یک برنامه از کتابخانه‌های دارای مجوز LGPLv2.1 و LGPLv3 استفاده کرد؟
    بله، امکان استفاده از هر دو نسخهٔ مجوز LGPLv2.1 و LGPLv3 در یک برنامه وجود دارد، به عنوان مثال با استفاده از آن‌ها به عنوان کتابخانه‌های جداگانه به عنوان shared libraries. انجام این کار نیاز به تغییر مجوز در هیچ یک از کتابخانه‌ها ندارد و در صورت نیاز، امکان انتخاب یک مجوز مولد برای برنامه وجود دارد.
     
    ماتریس سازگاری GNU نشان می‌دهد که من نمی‌توانم LGPLv2 و LGPLv3 را ترکیب کنم؟
    اگر کد LGPLv2.1 و کد LGPLv3 در کتابخانه‌های جداگانه به عنوان shared libraries قرار داده شوند، می‌توانند در یک برنامه استفاده شوند، و شما می‌توانید برنامه خود را با یک مجوز مالکیتی / LGPLv2.1 / LGPLv3 به دلخواه خود مجوزگذاری کنید.
     
    در مورد نسخهٔ مجوز LGPL/GPL که شما استفاده می‌کنید، چه کسانی مهم هستند؟
    شما، مشتریان شما و کاربران نهایی، مگر اینکه از Qt تحت یک مجوز تجاری استفاده کنید. مجوزهای copyleft مانند LGPL و GPL به این معناست که مجوز با محصول شما به مشتریان و کاربران یا راه‌حل شما همراه می‌شود.
     
    با توجه به تمامی توضیحات موجود، به طور خلاصه چه زمانی نیاز به تهیهٔ مجوز‌های کیوت داریم؟
    تهیهٔ مجوز کتابخانه Qt بستگی به نوع کاربرد و نیازهای پروژه دارد. جوانب مختلفی که تعیین می‌کنند چه زمانی نیاز به مجوز Qt داریم و چه مواردی ممکن است بدون نیاز به مجوز باشند.
    استفادهٔ شخصی: نیاز به مجوز: اگر برنامه‌نویس قصد استفاده از Qt را برای توسعهٔ پروژهٔ شخصی و خصوصی دارد بدون انتشار کد منبع، نیاز به مجوز ندارد. در این حالت، می‌توان از Qt به صورت رایگان استفاده کرد. بدون نیاز به مجوز: استفاده از Qt برای پروژه‌های شخصی بدون هدف انتشار کد منبع با محدودیتی همراه نخواهد بود. توسعهٔ نرم‌افزار باز (Open Source): نیاز به مجوز: اگر قصد توسعهٔ یک نرم‌افزار منبع باز با Qt را دارید و می‌خواهید کد منبع خود را نیز تحت یک مجوز Open Source انتشار دهید، نیاز به مجوز GPL یا LGPL خواهید داشت. بدون نیاز به مجوز: اگر نیازی به انتشار کد منبع ندارید و از Qt برای پروژه منبع باز خود استفاده می‌کنید، می‌توانید از نسخهٔ Qt با مجوز LGPL بدون مشکل استفاده کنید. توسعهٔ نرم‌افزار تجاری (Commercial Software): نیاز به مجوز: اگر قصد توسعهٔ نرم‌افزار تجاری دارید و نمی‌خواهید کد منبع خود را انتشار دهید، نیاز به مجوز تجاری Qt دارید. بدون نیاز به مجوز: اگر از Qt برای توسعهٔ یک نرم‌افزار تجاری استفاده می‌کنید و توافق به اشتراک‌گذاری کد منبع ندارید، می‌توانید از نسخهٔ تجاری Qt بهره‌مند شوید. توسعهٔ نرم‌افزار تحت LGPL: نیاز به مجوز: اگر می‌خواهید نرم‌افزار تجاری توسعه دهید، اما نیاز به استفاده از کتابخانه Qt دارید و می‌خواهید تغییرات خود را در کتابخانه منتشر کنید، باید از مجوز LGPL استفاده کنید. بدون نیاز به مجوز: اگر قصد استفاده از Qt را در یک نرم‌افزار تجاری با حفظ محرمانگی کد دارید، می‌توانید از مجوز تجاری Qt بهره‌مند شوید. برخی از نکات را نیز باید در نظر بگیرید، مانند نوع کامپایل و نوع مجوز‌های قابل پذیرش در فروشگاه‌ها که عموماً همهٔ آن‌ها را توضیح دادیم به چه صورت هستند.
  2. کامبیز اسدزاده
    توضیحاتی که در این پست ارائه می‌کنم، به منظور این نیست که بگم چیزی بد هست یا چیزی خوب! یکی بهتر است و دیگری بدتر! اما دوست دارم بیشتر با جو تبلیغاتی غالب روی چیزی نظر ندیم و در برنامه‌نویسی هم شخصاً تمایل دارم به بالاترین سطح ممکن از آزادی عمل در یک ابزار برسم که همه چیز رو برای یک برنامه‌نویس فراهم می‌کنه. مثالی که قبلاً زده بودم همون بحث باغ‌وحش و حیاط وحش بهترین مثال ممکن هست که می‌تونستم بزنم ولی خب اهل تفکر باید باشی تا بفهمی چی گفتم. بذار یه چیز‌هایی در مورد Rust و C و ++C بهتون بگم تا دیگه نیازی برای ادامهٔ بحث‌های پیش پا افتاده نباشه (این بحث‌ها مسخرست و صرفاً وقت شما رو می‌گیره، اما آگاهی داشتن در موردش می‌تونه دیدگاه بهتری برای پیشروی بهتون بده) اما موضوعاتی که بهش اشاره می‌کنم رو اگه کمی عمیق‌تر بهش دقت کنی، خواهی دید که چرا چیزی مثل سی‌پلاس‌پلاس واقعاً بی‌رقیبه.
    قبل از هر چیز بهتره مروری از به وجود اومدن این زبان‌ها رو داشته باشیم:
    وقتی در دههٔ ۷۰ میلادی زبان C به وجود اومد، به عنوان یک ابزار به شدت قابل تحسین با ۱۰۰٪ آزادگی عمل معرفی شد، شما هر سیستم و هر ساختاری رو که می‌خواستی می‌تونستی باهاش بسازی! به هر حال کامپیوتر یک جهان جدیدی بود و هر چیزی در اون می‌تونست یک فرصت باشه؛ همین الآن بعد از گذشت ۵۲ سال خیلی‌ها فکر می‌کنن این زبان منسوخ شده! در حالی که طبق آخرین مستندات N3096 استاندارد C23 در  ۲ آوریل ۲۰۲۳ به صورت پیش‌نمایش منتشر شده و هنوز هم در حال توسعه و پیشرفته! یادتونه گفتم هیچ ابزار و فناوری‌ای تا زمانی که در حال توسعه باشه، غلطه که بهش بگیم منسوخ شد!

    تقریباً ۳۹ سال پیش، وقتی سی‌پلاس‌پلاس به وجود اومد کاملاً ویژگی‌های C رو به ارث برد، در واقع هر چیزی که C داره، هم مشکلات و هم مزایا در ++C هم وجود داره اما خیلی فراتر از مباحثی که فکرش رو می‌کردند به یک باره توسعه‌پذیر شد. خیلی خب باید بپذیریم مشکلاتی که C داشته را هم در بعضی جاها ++C خواهد داشت، اما نه به صورت یک مانع! چون برای همشون راهکار وجود داره، هیچ چیز بی دلیل ساخته نمیشه، این رو مطمئن باش به‌روز رسانی‌ها بی دلیل نیستند.
    در مورد Rust، که ۸ سال پیش وقتی به وجود اومد که حتی به ۱۰ سال هم عمر و پختگیش نمیرسه صرفاً تمرکزش به ادامهٔ مسیر‌های مشابه زبان‌های مدیریت شده بود اما در حوزه‌ها و منظور‌های متنوع‌تر که این موضوع جذابش می‌کنه. راست یک زبان سیستمی هست اما با دارا بودن خاصیت Ownership که به همراه یک سری قوانین مثل Transfer Rules و Borrowing خیال شما رو از بحث ایمنی راحت می‌کنه.
    همین موضوع مسیر Rust رو با C و ++C جدا می‌کنه و قابل قیاس نیستند که در ادامه می‌گم چرا.
    موضوع مدیریت خودکار حافظه
    این بحث برتری حساب نمیشه چون توی سی++ مدرن ما راهکار‌های مشخصی برای مدیریت این مسائل داریم. خب یعنی چی یه ابزار داشته باشیم که بیاد امکان برنامه‌نویسی سیستمی رو بده اما مطمئن؟! قطعاً یه جای کار داره می‌لنگه! عین اینه که بگی من اینترنت دارم ولی فیلترینگ شدیدی روش هست، بله نمی‌ذاره من آزادانه و اونطور که می‌خوام پیش برم، هرجا ریسکی بود به عهدهٔ خودمه هرجا خیری بود باز به نفع خودمه. زور و فشار هیچ‌وقت موجب پیشرفت عمیق نمیشه حتی در فناوری! چون شما اختیار عمل ندارید و محبورید با محدودیت‌هایی که اعمال می‌شه پیش‌روی کنید.
    ساختار مهمی که راست داره بحث موضوع Ownership یا همون مالکیت هست، این یعنی چی؟
    یعنی مالک خودش شیء‌ای هست که مسئولیت مدیریت حافظهٔ اختصاص داده شده به یک شیء رو به عهده می‌گیره. در کنار این موضوع قانون انتقال یا همون Transfer می‌گه که هر شیء‌ای فقط یک مالک داره و مالکیت اون‌ها تنها می‌تونه به یک شیء دیگر منتقل بشه! این یک قانون اصلی و مهم در راست هست که برای تضمین این موضوع قانون امانت یا همون Borrowing می‌گه که اگه می‌خوای از یک شیء به عنوان مالک نهایی استفاده کنی، می‌تونی مالکیت به شکل امانت رو به شی‌ء دیگری انتقال بدی که در حالت قرضی یا موقتی ممکن هست اما اجازه نداری هرطور که دلت خواست ازش استفاده کنی.
    خب این قانون محدودیت‌های شدیدی رو ایجاد می‌کنه، اما در عوض بله تضمین می‌کنه که مدیریت حافظه مطمئن هست.
    این باعث می‌شه خطاهای حافظه به خاطر وجود مالکیت اختصاصی، که در زمان کامپایل، کامپایلر تعیین می‌کنه که چه زمانی باید حافظه آزاد بشه رو جلوگیری می‌کنه.
     شما نمی‌تونید به صورت آزاد روی مدیریت حافظه حرفی برای گفتن داشته باشید چون شما آزادی عمل ندارید. در مقابل در سی‌پلاس‌پلاس بدون هیچ محدودیتی از این موضوع بهره می‌برید.  دسترسی به لایه‌های سخت‌افزاری عمیق و پشتیبانی از abi‌های سیستم‌عامل‌ها به صورت کامل تحت راست ممکن نیست مگر اینکه به صورت اختصاصی نسبت به هر abi در اختیار شما خارج از استاندارد‌ها قرار بگیره، چیزی که در سی‌پلاس‌پلاس همه چیز به صورت استاندارد در اختیار توسعه‌دهنده قرار می‌گیره.  کتابخانه‌های استاندارد Rust قابلیت کنترل مستقیم روی ترد (نخ)‌ها رو ارائه نمی‌کنه هرچند مدعی هستن که از روش‌های crate در کامپایلر راست در زمان اجرا با استفاده از thread_priority‌ها قابل پیاده‌سازی هست اما با این حال، هیچ‌وقت در سطح فوریتی به اندازهٔ API‌های استاندارد ++C قابل استفاده نیست، حتی C هم در این حد و اندازه امکان مدیریت سخت‌افزار رو برای شما نمیده.  در صورتی که در Rust لایهٔ امنیتی رو فعال هست (چیزی که به صورت پیش‌فرض در راست فعال هست) دیگه امکان دسترسی به لایه‌های سخت‌افزاری رو از دست خواهید داد. در حالی که سی++ این امکان رو به صورت کاملاً آزاد در اختیار شما قرار میده و شما با پذیرش خطر اون اگر تسلط خوبی داشته باشید می‌تونید به بهترین شکل ممکن دسترسی نامحدود به این موضوع رو در اختیار بگیرید. شما در راست فقط حق انتخاب بر مبنای قوائد از پیش تعریف شده رو دارید، یا ایمن باش و محدود باش، یا ایمن نباش و باز هم محدود باش! این در سی++ برعکسه! شما یا باید کد ایمن بنویسی و در عین حال به بالاترین کارآیی دسترسی داشته باشی، یا باید به خاطر عدم داشتن تسلط بالا خطر‌هاش رو بپذیری که صد البته برای کاهش مسائل راهکار‌های استاندارد‌های جدید بهترین گزینست.  تمام چیزی که راست ادعا کرده کلاً بر مبنای محدودیت‌های اعمال شده هست، برای مثال شما هیچ راه استاندارد و بومی شده‌ای برای دسترسی API‌های سیستمی به شیوهٔ مستقل از سکو رو ندارید مگر مواردی چون windows-rs و مشابهش که کاملاً خارج از بحث استاندارد و به نوع سوم در دسترس توسعه‌دهنده‌ها قرار می‌گیرند و مناسب چند-سکویی واقعی نیست.  جامعهٔ پخته و اکو‌سیستم راست هیچ‌وقت به اندازهٔ زبان‌های C و ++C گسترده نیست و کتابخانه‌های استانداردِ بی‌شماری از این بابت در اختیار توسعه‌دهنده‌ها قرار نگرفته و این قابلیت مقایسه با عمق مستنداتی که طی چندین دهه برای زبان‌های دیگه موجود هست رو نداره.  راست به معنای واقعی کلمه یک زبان ایمن هست اما با فعال بودن لایهٔ ایمنی، قدرتمند نیست و زیرساخت‌های سنگین که قدرت مانور کامل روی سخت‌افزار رو به شما بده.  راست به هیچ عنوان بهینگی لازم رو به خاطر قوائد ایمنی در زمان اجرا (Run-Time) رو نداره در حالی که در ++C شما بهینگی به شدت بالایی رو برای زمان اجرا می‌تونید اعمال کنید.  در راست که مدعیه یک زبان سطح‌پایین هست، ما مفهومی به عنوان Placement new نداریم، حتی معنا هم براش نداره چون دیگه محدودیت مالکیت (Onwership) با این موضوع هم خونی نداره و چنین ادعاهایی رو راحت رد می‌کنه.  در سطوح پیشرفته، توسعه‌دهنده در ++C با استفاده از Placement new، می‌تونه یک شیء رو در یک مکان خاص از حافظه ایجاد کنه، بدون اینکه حافظه جدیدی بهش اختصاص بده! این امکان به شما اجازه میده که به طور دقیق مشخص کنید کجا باید یک شیء ایجاد بشه! چیزی که حتی در C هم به اندازهٔ ++C در مورد کنترل، سازگاری و انعطاف‌پذیری در مدیریت حافظه رو به ارائه نمی‌کنه.  و اما در مورد بحث مسائل زمان اجرا و کامپایل، بله راست به دلیل ویژگی‌هایی که داره در زمان کامپایل مشکلات قابل بروز در زمان اجرا رو کنترل می‌کنه، در مقابل استاندارد‌های جدید از سی‌پلاس‌پلاس نیز ویژگی‌هایی مثل Contracts‌ها و Concepts‌ها رو برای این منظور در نظر گرفته که اگه با استاندارد جدید آشنا نباشید طبیعتاً کد‌های شما در زمان اجرا ممکنه ایمن نباشه. خلاصهٔ کلام اینه که هر زبانی در جای خودش مزایا و معایب خودش رو داره که معمولاً برای تبلیغات و حمایت شدن توسط جامعه، طبیعیه که باید بعضی از مسائل رو نادیده بگیره و بعضی از مزایا رو بیشتر مطرح کنه. در مورد راست هم همینطور، در مورد سی‌پلاس‌پلاس هم همینطور! نا نمی‌تونیم بگیم همه چیز بده یا همه چیز خوبه! قطعاً در مقابل امنیت شک نکنید باید یک سری چیز‌ها رو در نظر بگیرید و در مورد آزادی توسعه توسط یک زبان هم همچنین. به‌روز رسانی‌های اخیر سی‌پلاس‌پلاس طوری پیش رفته که وقتی بخوای به عنوان یک زبان مدرن ازش استفاده کنی، اصولاً دیگه جای بحثی از نظر ترس و وحشت یا مشکلات حافظه یا چنین مسائلی باقی نمی‌مونه. این بر می‌گرده به توسعه‌دهنده که واقعاً از چه نسل و استانداردی تبعیت می‌کنه.
  3. کامبیز اسدزاده
    در این مقاله من قصد دارم به معرفی ده فریم‌ورک برتر جهان در بازهٔ سال‌های ۲۰۱۹ و ۲۰۲۰ اشاره کنم که در حوزهٔ صنعت وب کاربرد دارند. معمولاً در سایت‌ها، وبلاگ‌ها و گروه‌های تلگرامی حرف از فریم‌ورک‌های شناخته شده‌ای مانند Asp.net core و یا Laravel به گوش می‌رسد. اما واقعیت این است که فریم‌ورک‌هایی که در مورد آن‌ها بحث می‌شود جایگاه خاصی در بین فریم‌ورک‌های قدرتمند و به عنوانی ناشناخته مانند Drogon، h2o، ulib و غیره ندارند! جالب است بدانید فریم‌ورک‌هایی که در ادامه نام‌هایشان را می‌شنوید به قدری سریع و قدرتمند هستند که مو بر تنِ شما سیخ خواهد کرد! برای مثال در این مقایسه جایگاه فریم‌ورک‌های دات‌نت به بالاتر از ۵۰ و لاراول به بیشتر از ۲۰۰ رتبه می‌رسد! این در حالی است که بر خلاف انتظارِ عام، فریم‌ورک‌های تحت سی/سی++ و راست به عنوان سریع‌ترین فریم‌ورک‌ها شناخته می‌شوند. در واقع مقایسه بر اساس نتایج گرفته شده از مرجع Techempower می‌باشد که هر ساله یک مقایسه در رابطه با کارآیی و کیفیت فریم‌ورک‌های وب می‌پردازد. سنجشِ فوق بر اساس وظایفی مانند سریال‌سازی جی‌سان، دسترسی به پایگاه داده و عملیات سمت سرور، پردازش و غیره می‌باشد. در این آزمایش‌ها عملکرد فریم‌ورک بر روی سیستم‌عامل، به صورت فول‌اِستک و میکرو اندازه‌گیری شده است که هر کدام را در رتبهٔ خاصی از وضعیت آن سوق می‌دهد.

    بهترین فریم‌ورک‌ها از نظر بنچ‌مارک (کارآیی) در سال ۲۰۱۹ در دورِ ۱۸ بین ۲۲۰ فریم‌ورک متعلق به h2o و ulib بوده است. کتابخانهٔ h2o یکی از قوی‌ترین مواردی است که می‌توان به آن اشاره کرد. در سال ۲۰۲۰ این رتبه‌بندی به نفعِ فریم‌ورک جدید‌تری به نام دراگون (Drogon) و مجدداً ulib جمع بندی شده است که نشان می‌دهد فریم‌ورک ulib به عنوان یکی از برترین فریم‌ورک‌های نوشته شده تحت سی و سی++ و همچنین دراگون تحت استاندارد‌های ۱۴ و ۱۷ زبان برنامه‌نویسی سی‌پلاس‌پلاس معرفی شده است.
    بنابرین بهتر است در مورد دراگون بیشتر بدانیم:
    این فریم‌ورک تحت زبان برنامه‌نویسی ++C در استاندارد ۱۴ و ۱۷ توسعه یافته و بر روی سکو‌های لینوکس، مک و ویندوز قابل اجراست. دراگون تحت ویژگی non-blocking I/O کار می‌کند و سرعت را همراه با دقت بسیار بالایی به خصوص بر روی پلتفرم‌های FreeBSD تضمین می‌کند.
    لینک مخزن توسعه و کد‌های دراگون.
    مثال از کد اولیه:
    #include <drogon/drogon.h> using namespace drogon; int main() { app().setLogPath("./") .setLogLevel(trantor::Logger::kWarn) .addListener("0.0.0.0", 80) .setThreadNum(16) .enableRunAsDaemon() .run(); } با توجه به مقایسه‌های صورت گرفته در آزمایش‌های مختلف زیر رتبه‌بندی فریم‌ورک‌ها مشخص می‌شود. آزمایش‌های فوق بر روی پردازندهٔ Dell R440 Xeon Gold صورت گرفته است که در این لینک آمده است.
    JSON serialization

    Single query

    Multiple queries

    Fortunes

    Data updates

    Plaintext

    آزمایش‌های مربوطه تنها به ۱۰ مورد اول اشاره کرده است، بنابراین برای مشاهدهٔ لیست بیشتر و جزئیات آن‌ها به مرجع آن مراجعه کنید.
  4. کامبیز اسدزاده
    سلام و درود،
    این اواخر راجع به مشورت و راهنمایی‌ها خیلی ساده به قضیه نگاه می‌شه، همه فکر کردن کشکه و فقط با دونستن JS یا QML می‌شه محصول ساخت. البته این مثال JS و QML یک مثال هست و این مسئله در همهٔ ابزار‌ها و حول محور حوزهٔ کامپیوتر و نرم‌افزار به چشم می‌خوره، هرچند روی داستان ساده هست اما حتی پشت این کار‌های ساده کلی زمان باید صرف بشه. همین گرفتن یک دادهٔ ساده از سمت سرور و تجزیه کردنش سمت JS نیاز به یک دانش خوب در مورد معماری Api‌داره، نیاز به آگاهی از استاندارد‌های Http داره، نیاز به تخصص کافی در ریز به ریز مسائل داره، نیاز به آگاهی لازم در مورد شبکه و نحوهٔ مدیریتش داره، نیاز به درک خوب راجع به کلاس‌های شبکه و نحوهٔ مدیریت بسته‌ها داره و صد‌ها جور مسئلهٔ دیگه.

    یا راهنمایی نکنیم یا می‌کنیم همه چیز رو ساده نشون ندیم!
    به خصوص برای کسایی که سال‌ها یه چیز دیگه خوندن و الآن قراره وارد این حوزه بشن.
    قشنگ واقعیت رو باید به نمایش گذاشت، و اگرنه به اشتراک گذاری چهارتا UI خفن که بگین با QML هم میشه کاری نداره، سه سوته می‌شه این‌ها رو طراحی کرد.
    اگر کسی اطلاعات کافی و پایهٔ تخصصی نداشته باشه و همینطور متکی به یک ابزار یا زبان پیش بره چه اتفاق می‌افته؟ از نظر من قطعاً بهتون از نظر تجربی آسیب میزنه، ساخت یک محصول واقعاً به این سادگی‌ها نیست که تو گروه‌های تلگرامی داریم راجع بهش صحبت می‌کنیم! قضیه خیلی پیچیده‌تر از این‌هاست. فراموش نکن در این حوزه اگه یک کار ساده رو سریع انجام میدیم یا به نتیجه می‌رسونیم دلیلش به خاطر سال‌ها زمان و تلاشه، امکان نداره کسی حتی با ۲..۳ سال تجربه یک کار رو سریع بتونه صفر تا صد انجام بده و مشکلی نداشته باشه یا نتیجهٔ اون در سطح یک استاندارد معتبر باشه.
    ساخت محصول اصول داره که اولین مرحلش شفاف‌سازی و نقشهٔ توسعه و ایده‌پردازی درسته، نباید مثل بعضی از مشتری‌ها باشه که پشت تلفن زنگ می‌زنن می‌گن یه سایت می‌خوایم یا یه اپلیکیشن چند می‌گیری و بعدش شروع کنن به چک و چونه زدن و شما هم کیف کنی بگی که آره دیگه مشتری دارم!
    شما تا زمانی که جزء به جزء محصول رو آگاه نباشید، یعنی تا زمانی که دقیق متوجه نشید نیاز چی هست و روش حلش رو متوجه نباشید منطقی نیست که واردش بشید. چون همین مرحلهٔ نیاز‌سنجی به قدری مهمه که فرآیند مسیر و نقشهٔ توسعهٔ یک محصول رو نشونتون میده و اگه درست تشخیص ندین و ابزار‌ها و راه‌کار‌ها رو درست انتخاب نکنید بی برو برگرد با مشکل مواجه می‌شید.
    مشکلاتش می‌تونه به این صورت باشه:
    - سردرگمی
    - عدم توانایی کالبد‌شکافی مسئله
    - عدم توانایی حل مسئله
    - عدم توانایی انتخاب یک روش یا ابزار صحیح و مناسب
    - عدم تعامل شما با مشتری
    - عدم رضایت شما از حق‌الزحمه
    - عدم رضایت مشتری از نتیجهٔ کار
    - عدم توانایی در پاسخ‌دهی به اعضا و شرکای کلیدی دیگه در محصولات تجاری و بزرگ!
    - و هزاران مسئلهٔ دیگه که همشون نتیجهٔ تشخیص نا درسته.
    - در کنارش مهمترین خاصیتی که پیدا می‌کنه این خواهد بود در اوج نادانی احساس خواهد کرد که همه چیز دان هست! به قولی همه چیز گیگ!
    از نظر من حداقل مواردی که (به طور خیلی خیلی خلاصه و محدود) نیاز هست تا یک متخصص بتونه پاسخ‌گوی‌ تصمیم‌گیری نقشهٔ توسعهٔ یک محصول برای مشتری در ابعاد مختلف و سطوح متفاوت از حوزه‌های موجود در قالب اصولی باشه به صورت زیر هستند:
    ۱- آشنا مبانی کامپیوتر که امر طبیعیه (شامل درک و فهم مسائل و نحوهٔ حلشون متناسب با پلتفرم اجرایی محصول)
    ۲- آشنا به ساختار نوع محصول استاندارد در یک حوزه مثل: وب، آی‌او‌اس، اندروید یا دسکتاپ‌های مختلف مثل لینوکس، مک و ویندوز، اینترنت اشیاء و دیگر موارد.
    ۳- آشنا به فلسفهٔ بک‌اند و فرانت‌اند یا ترکیبی از این دو به همراه ابزار‌های مناسب.
    ۴- آشنا به اصول طراحی UI/UX به عنوان یک نیاز و یک فاکتور مهم در ساخت محصولی که وابسته به عملکرد کاربر داره و در حوزهٔ فرانت‌اند مهم و کاربردی هست.
    ۵- آشنا به اصول SOLID و امثالش مهم هستند.
    ۶- آشنا اصول برنامه‌ریزی ساخت بانک اطلاعاتی، اینکه از چه بانک اطلاعاتی‌ای استفاده کنی و چرا؟
    ۷- آشنا به ارتباطات داده‌ای، جداول و ارتباط بین فیلد‌ها، جدوال و روش‌های درست تبادل اطلاعات مابینی داده‌ها.
    ۸- آشنا و تسلط کافی به یک محیط توسعه و ادغام ابزار‌ها و محیط طراحی برای هدف.
    ۹- آشنا به معماری ساختار و رابط‌های برنامه‌نویسی (Api)
    ۱۰- آشنا به استاندارد‌های Http، درک و مدیریت درخواست، پاسخ‌ها و ...
    ۱۱- آشنا به الگو‌های طراحی برنامه‌نویسی (DP)
    ۱۲- آشنا به روش‌های نگه‌داری و آزمایش نرم‌افزار و کد‌ها به خصوص درک مبحث Fault tolerance.
    ۱۳- آشنا به روش‌های اطمینان‌سازی و ایمن‌سازی پردازش‌های داخلی نرم‌افزار برای جلوگیری یا دشوار سازی نفوز و خراب‌کاری
    ۱۴- آشنا به روش‌ها و معماری‌های احراز هویت و نحوهٔ ادغامش با نرم‌افزار مثل:JWT, OAuth, AWS و غیره...
    ۱۵- آشنا به نوع پارادایم‌های زبان برنامه‌نویسی، در قالب‌های  (دستوری) Imperative و  (اعلانی) Declarative مثل OOP، functional و دیگر موارد.
    ۱۶- آشنا به سبک معماری نرم‌افزاری (Microservice یا مثلاً Monolith) مزایا و معایبشون.
    ۱۷- آشنا به سبک معماری طراحی مانند MVC در طراحی بدنهٔ محصول.
    ۱۸- آشنا به سبک و الگو‌های طراحی ساختاری در بک‌اند مانند Builder، Abstract، Factory و غیره.
    ۱۹- آشنا به ساختار یک زبان (در صورتی که می‌خواین جوابگوی مسائلِ پیش آمده باشید) کالبد‌شکافی زیر‌پوستی و عمیق یک زبان مهمه.
    ۲۰- آشنا و درک کامپایلر‌ها و مفسر‌ها، تفاوت‌ها و شیوه‌های عملکردیشون نسبت به کد‌های بهینه شده و عادی.
    ۲۱- آشنا و درک مدل‌های مختلفی از سیستم‌های توزیع شده مثل IaaS، PaaS، SaaS یا FaaS.
    ۲۲- آشنا به ابزار‌های ساخت و فرآیند کاری اون‌ها مثل CMake، NMake، QMake و غیره.
    ۲۳- آشنا به روش‌های مدیریت وابستگی‌های نرم‌افزار و ابزار‌های لازم برای بسته‌بندی بهتر خروجی.
    ۲۴- آشنا به روش‌های کد‌نویسی قابل آزمایش (Unit Test) و استفاده از ابزار‌هایی مثل CTest, GTest, Catch2 و غیره.
    ۲۵- آشنا به توسعهٔ آزمون محور (Test Driven- Development)
    ۲۶- آشنا به گام‌ها و شرایط نسخه‌نگاری و مراحل توسعهٔ نرم‌افزار (SDP)
    ۲۷- آشنا به روش‌های امنیت در کد و توسعه به شیوه‌های بررسی از طریق Fuzz-Test، Sanitizer، آنالیزر‌های پویا و ایستا و غیره...
    ۲۸-آشنا به قوائد طراحی بر پایهٔ خدمات مبتدی بر معماری ابری برای خدمات پیامی، وب‌سرویس‌ها، پردازش و غیره.
    ۲۹- در سطوح وب آشنا به مکانیزم شاخص بندی، فاکتور‌های SEO و شیوه‌‌های درست بهبود صفحات وب.
    ۳۰- آشنا به روش‌های به کار گیری و پیاده‌سازی ثبت کننده‌ٔ وقایع در دل محصول و روش‌های بازخورد برای توسعهٔ بهتر به همراه مانیتورینگ، نظارت و تریسینگ.
    ۳۱- در شرایط لزوم آشنا به نحوهٔ به کار گیری و دلیل استفاده از فناوری‌هایی مثل Redis، Memcached و غیره.
    ۳۲- آشنا و درک صحیح از مفاهیم هم‌زمانی (Concurrency) و روش‌های به کار گیری آن نسبت به زبان برنامه‌نویسی و شرایط مناسب استفاده.
    ۳۳- آشنا به سبک و قوائد و ساختار زبان‌های برنامه‌نویسی و فرآیند ساخت و ترجمه.
    ۳۴- و تا صد‌ها گزینهٔ دیگه می‌تونم لیست کنم اینجا که اگه انتخابتون زبان‌های نزدیک به سیستم باشه این داستان در ادامهٔ این توضیحات سر به فلک می‌کشه نمونش کامپایلر‌ها خودشون شونصد جور مباحث دارند، پلتفرم‌ها ومعماری‌های پردازنده‌ای هم در این زبان‌ها مهمن و شما حتی تا عمق سیستم‌عامل و رابط‌های اون‌ها و نحوهٔ رفتارشون باید اطلاعات کافی داشته باشید که هر کدوم به نوبهٔ خودشون هزاران صفحه می‌شه راجع بهشون کتاب معرفی کرد.
    این لیست چیزی بود که به زبان بسیار بسیار ساده شده و خیلی خلاصه به ذهنم رسید تا بدانید همچین هم الکی نیست ای عزیزانی که فتوا‌های صد من یه غاز میدین و این مسائل رو حل شده می‌دونید! 
    در ادامه اصل ماجرا خیلی فراتر از این‌ها هم هست که بخوای حساب کتاب کنی می‌بینی باید هفت خان رستم رو فتح کنی تا در تمامی سطوح پاسخگو باشی، این امر شدنی هست اما زمانی که شما محدود به یک موضوع باشید قطعاً درک همهٔ مسائل محدود و ناتوان در اجرای آن خواهید شد.
    * وقتی می‌گم آشنا قطعاً در حد حروف الفبا کافی نیست، باید در حد نیاز تسلط و درک کافی ازشون وجود داشته باشه.
    * همهٔ این‌ها رو باید در کمترین زمان ممکن نسبت به یک مشتری، محصول و نیاز تشخیص بدین و انتخاب کنید، به این کار می‌گن ارزیابی محصول بر اساس دانسته‌های فنی که تماماً متکی بر دانش و تجربهٔ شماست. (کارشناسی پروژه دقیقاً همین موضوع است).
    * برای بهتر شدن و حرفه‌ای تر شدن هم باید فراتر از این‌ها پیش برید و در قالب «مثلث دانش» بهبودش بدهید.
    * محصولات معتبر جهانی حاصلِ چنین نقشه‌های پیش‌بردی هستند و اصول تخصصی و مهندسی رو رعایت می‌کنن تا به یک درجهٔ کیفی موفق و زبان زد می‌رسند. شاید این مسائل از نظر یک برنامه‌نویس ساده و نه چندان با تجربه مهم نباشه، اما در سطح کیفی یک محصول نرم‌افزاری همهٔ این مسائل مهم تلقی می‌شوند.
    برای همین می‌گم گولِ توصیه‌های ساده و ظاهر چهارتا برنامه یا کیوت، دات‌نت و امثال این ابزار‌ها رو نخورید، پشت همهٔ نیاز‌های یک محصول به فاکتور‌های بسیاری باید توجه کنید. فردا بخواهید بدون آگاهی در این مسائل وارد پروژه‌هایی بشید که به ظاهر ساده هستند یا باید دست به گریبان دیگران باشید و توی گروه‌ها مدام سوأل پرسی کنید و یا باید بیخیال آن شوید؛ چون به هیچ یک از این فاکتور‌های مورد نیاز توسعه توجه نکردین! پس این اصول رو به عنوان سر نخ مطالعه کنید تا بخش بزرگی از سرگردانی‌های شما حل شود.
    این مواردی که این جا اشاره کردم، همونطور که گفتم بخش بسیار کوچکی از دنیای نیازمندی‌های ساخت و ساز و طراحی یک محصول واقعی در پیرامون نرم‌افزار و کامپیوتر هست، اما یک دل‌گرمی بدم به کسایی که با خودشون فکر می‌کنند چنین مسیر یا نقشه‌ای از راه که قراره پیش بگیرند سخته و همهٔ ماجرا این نیست (جزئیات رو در کتاب‌ها، موقعیت و فرصت‌های شغلی، شکست‌ها، موفقیت‌ها و آزمون و خطاها یاد خواهند گرفت) و نتیجهٔ اون می‌تونه مطابق همین حکایت زیر باشه:
     
     
  5. کامبیز اسدزاده
    شرکت اینتل یک کیت توسعه نرم‌افزار آزمایشی کوانتومی با نام Quantum SDK را منتشر کرد!
     این کیت یک سری ابزار و روش‌های برنامه‌نویسی را در اختیار توسعه‌دهندگان قرار می‌دهد که امکان برنامه‌نویسی الگوریتم‌های کوانتومی را در یک شبیه‌سازی ممکن می‌کند. این کیت از زبان برنامه‌نویسی ++C و کامپایلر LLVM برای برنامه‌نویسی الگوریتم‌های کوانتومی استفاده می‌کند و به سادگی می‌تواند با برنامه‌های C و ++C و پایتون به کار برده شود. این کیت، به نوعی باعث بزرگ شدن جامعه‌ٔ توسعه‌دهندگانی می‌شود که در زمینه‌ٔ کامپیوترهای کوانتومی فعالیت می‌کنند.
     

    این عکس نشان می‌دهد که شرکت اینتل، و افرادی که در آن کار می‌کنند، با استفاده از یک دستگاه پردازشی ۳۰۰ میلی‌متری، وافرین بر روی یک وافر کیوبیتی (بخشی از یک صفحه اتصال کوانتومی) سیلیسیوم بر روی یک ورقه کوچک انجام داده‌اند.
    – آن ماتسورا، مدیر برنامه‌های کاربردی و معماری کوانتومی، آزمایشگاه‌های اینتل
    درباره‌ی Intel Quantum SDK 1.0: نسخه‌ٔ 1.0 این SDK، شامل یک رابط برنامه‌نویسی مبتنی بر سی‌پلاس‌پلاس است که به برنامه‌نویسان کلاسیکی، زبان برنامه‌نویسی که با آن آشنایی دارند، را ارائه می‌دهد و امکان همکاری بین آن‌ها و برنامه‌نویسان کوانتومی را فراهم می‌کند. این کیت نیز، یک محیط اجرایی کوانتومی بهینه‌سازی شده برای اجرای الگوریتم‌های کوانتومی-کلاسیکی هیبریدی دارد. توسعه‌دهندگان می‌توانند از دو محیط مختلف برای شبیه‌سازی کیوبیت‌ها استفاده کنند، یکی برای نمایش بیشتر تعدادی کیوبیت‌های عمومی و دیگری، برای شبیه‌سازی سخت‌افزار کیوبیتی اینتل. محیط اولیه، یک شبیه‌ساز  کیوبیت عمومی بسیار عالی با کد منبع باز به نام Intel® Quantum Simulator (IQS) می‌باشد که برای 32 کیوبیت در یک گره و بیش از 40 کیوبیت در چندین گره، توانایی دارد. محیط دوم نیز با شبیه‌سازی سخت‌افزار کیوبیتی اینتل، شبیه‌سازی کوچک مدل کیوبیت‌های گرداننده اسپین سیلیکونی اینتل را فراهم می‌کند. کیوبیت‌های اینتل، از تخصص شرکت در تولید ترانزیستور سیلیکونی برای ساخت کامپیوترهای کوانتومی مقیاس گسترده استفاده می‌کنند.
     
    تحقیقات کوانتومی اینتل از دستگاه‌های کیوبیتی تا معماری سخت‌افزار کلی، معماری نرم‌افزار و برنامه‌ها را پوشش می‌دهد. Intel Quantum SDK یک کامپیوتر کوانتومی کامل در شبیه‌سازی است که همچنین قادر به اتصال به سخت‌افزار کوانتومی اینتل، از جمله چیپ کنترل Horse Ridge II و چیپ کیوبیت گرداننده اسپین اینتل است که بزودی در اختیار عموم قرار خواهد گرفت.

    کیت توسعه‌ٔ کوانتومی اینتل، به توسعه‌دهندگان این امکان را می‌دهد که انتخاب کنند کدام یک از دو محیط موردنیاز برای شبیه‌سازی کیوبیت‌ها استفاده شود:
    شبیه‌ساز بسیار عالی و با کد منبع باز کیوبیت عمومی، شبیه‌ساز کوانتومی اینتل (Intel Quantum Simulator) محیط هدف که سخت‌افزار کیوبیتی اینتل را شبیه‌سازی می‌کند و به شبیه‌سازی مدل کوچک کیوبیت‌های گرداننده اسپین سیلیکون اینتل امکان می‌دهد.
    اعلام شده که شرکت اینتل، متعهد به پیشروی در حوزه‌ٔ کامپیوترهای کوانتومی است و از جمله اینترنت از همه جا به عنوان یک روش برای جذب جامعه‌ٔ توسعه‌دهندگان می‌باشد. کاربران بتا این کیت، در حال بررسی انواع موارد مثل دینامیک سیالات، فیزیک نجوم وطراحی مواد هستند.

    تحقیقات کوانتومی اینتل از دستگاه‌های کیوبیتی تا معماری سخت‌افزار کلی، کنترل و معماری نرم‌افزار و برنامه‌ها را پوشش می‌دهد.
  6. کامبیز اسدزاده
    ساده‌ترین راه برای افزودن کد سفارشی به سایت‌هایی که بر پایهٔ وردپرس ساخته شده‌اند، بدون شکستن کد آن چیست؟
    زبان برنامه‌نویسیِ ++C یکی از محبوب‌ترین زبان‌های برنامه‌نویسی است. آخرین آمار نشان می‌دهد که این زبان با سرعت بسیار زیادی در حال توسعه و پوست‌اندازی است.

    این زبان، علیرغم اینکه بیش از 40 سال از عمرش می‌گذرد، همچنان زبان انتخابی برای بسیاری از برنامه‌نویسان در سراسر جهان است. برای بسیاری از موارد مانند برنامه‌های کاربردی دستکاری تصویر، بازی‌های سه بعدی، شبیه سازی‌ها، مرورگرهای وب و نرم‌افزارهای سازمانی استفاده می‌شود.
    دلیلش این است که سی‌پلاس‌پلاس در حال تکامل است، به انرژی سبز اهمیت می‌دهد و در عین حال کارآیی بسیار بالا و بهینه‌ای دارد. از آنجایی که این زبان پیچیده‌تر از سایر زبان‌های برنامه‌نویسی است، یک کمیتهٔ فرعی از یک سازمان چند سطحی وظیفه استانداردسازی آن را بر عهده دارد. سی‌پلاس‌پلاس اکنون از یک مدل قطار پیروی می‌کند و هر سه سال یکبار نسخه‌های جدید دریافت می‌کند که در مورد استاندارد‌های جدید، اخیراً مقالاتی منتشر شده است.
    سی‌پلاس‌پلاس معمولاً برای توسعهٔ نرم‌افزار در مقیاس بزرگ استفاده می‌شود، اما می‌توان از آن برای پروژه‌های توسعه وب نیز استفاده کرد. ممکن است تعجب کنید که چگونه از آن با وردپرس، یکی از محبوب‌ترین سیستم‌های مدیریت محتوا و سازندگان وب سایت امروزه استفاده کنید.
    در این باره قبلاً من مقالاتی را منتشر کرده‌ام که به صورت زیر آمده‌اند:
    در حالی که بسیاری از وب سایت‌ها با استفاده از وردپرس به عنوان پایه ساخته می‌شوند، این لزوماً به این معنی نیست که اکوسیستم وردپرس تکامل یافته یا کامل است. به عنوان مثال، وردپرس تمرکز زیادی بر تجربه‌کاربران و نیازهای وبلاگ نویسان دارد، به همین دلیل است که بر چهار زبان HTML، CSS، جاوا اسکریپت و PHP متکی است و این بدان معناست که برای توسعه‌دهندگانی که می‌خواهند به طور کامل از قدرت آن استفاده کنند، محدودیت‌هایی وجود دارد. در حالی که افزونه‌هایی مانند Custom Post Types برای گسترش عملکرد وردپرس وجود دارد و راه‌های زیادی برای افزودن قابلیت‌های جدید بدون شروع از ابتدا وجود ندارد.
    همچنین، افزودن کد ++C به طور مستقیم به یک سایت وردپرس توصیه نمی‌شود زیرا به طور بالقوه می‌تواند آسیب پذیری‌های امنیتی را ایجاد کند و وب سایت را خراب کند. با این حال، اگر نیاز خاصی به اجرای کد ++C در سایت وردپرس شما وجود دارد، در اینجا روش‌هایی که می‌توانید آن را انجام دهید گفته شده‌است:
    شما می توانید یک برنامه یا کتابخانه مستقل ++C ایجاد کنید و سپس آن را از طریق وب API در معرض دید قرار دهید، که می‌تواند توسط وردپرس مصرف شود. بیایید نگاهی به مراحل کلی بیندازیم:
    کد ++C خود را بنویسید و آن را در یک برنامه یا کتابخانه مستقل کامپایل کنید. عملکرد برنامه یا کتابخانه ++C را از طریق وب API به نمایش بگذارید. شما می‌توانید از یک کتابخانه به عنوان cpprestsdk برای ایجاد نقاط پایانی API استفاده کنید. برنامه یا کتابخانه ++C را بر روی یک سرور، یا در همان سرور سایت وردپرس خود یا در یک سرور جداگانه، مستقر کنید. در سایت وردپرس خود، از یک افزونه یا کد سفارشی برای درخواست HTTP به API و بازیابی نتایج استفاده کنید. شما می‌توانید از کتابخانه‌ای مانند cURL برای ارائه چنین درخواست‌هایی استفاده کنید. در صورت نیاز از نتایج بازیابی شده در سایت وردپرس خود استفاده کنید. راه دیگر برای افزودن قابلیت ++C به سایت وردپرس استفاده از افزونه‌ای است که به شما امکان می‌دهد کد ++C را مستقیماً در صفحات یا پست‌های وردپرس جاسازی کنید. مراحل بسته به افزونه‌ای که استفاده می‌کنید متفاوت است، اما در اینجا چند مرحله کلی وجود دارد که می‌تواند کمک کند.
    افزونه‌ای را که از کد ++C پشتیبانی می‌کند را در سایت وردپرس خود نصب کنید. یک صفحه یا پست جدید در وردپرس ایجاد کنید و کد کوتاه [cpp] را به قسمت محتوا اضافه کنید. در کد از نوع برچسب‌ِ [cpp]، کد ++C خود را اضافه کنید. صفحه یا پست را منتشر کنید و آن را مشاهده کنید تا کد جاسازی شده ++C را در عمل ببینید. مجدداً توجه داشته باشید که افزودن کد ++C به طور مستقیم به یک صفحه یا پست می‌تواند خطرناک باشد. مهم است که پیاده‌سازی خود را به طور کامل آزمایش کنید تا مطمئن شوید که ایمن و قابل اعتماد است. از هر روشی که استفاده می‌کنید، به یک پایه محکم در سی‌پلاس‌پلاس و مهارت‌های یکپارچه سازی وردپرس نیاز دارد. وقتی صحبت از وردپرس به میان می‌آید، شاید بهتر باشد از زبانی مانند PHP استفاده کنید.
    اگر می‌خواهید دربارهٔ ++C و نحوهٔ به حداکثر رساندن آن برای پروژه‌تان بیشتر بدانید، می‌توانید به آموزه‌های مربوط به سی‌پلاس‌پلاس در این سایت را بررسی کنید یا کتاب‌های پیشنهادی در بخش معرفی زبان را بخوانید. فراموش نکنید که سی‌پلاس‌پلاس یک زبان جذاب و همیشه در حال تکامل است و افزودن آن به مجموعه مهارت‌های شما سودمند است.
  7. کامبیز اسدزاده
    با سلام و درود،
    پیرو مقالهٔ قبلی در رابطه با بخشی از نهایی‌سازی‌های استاندارد ۲۳
     
    در این مقاله قصد داریم در رابطه با استاندارد ۲۶ و نهایی‌سازی‌های ۲۳ یک جمع‌بندی داشته باشیم که بسیار در شناخت و به‌روز رسانی سریع از پیشرفت این زبان را به ما نشان می‌دهد.

    طبق جلسات اخیر از کمیتهٔ استاندارد‌سازی، در اولین جلسه، کمیته بر اصلاح ویژگی‌های C++23 متمرکز شد که عبارتند از:
    عملگرstatic operator[] ویژگی static constexpr در توابع constexpr  محدودهٔ ایمن range-based در for تعامل std::print با سایر خروجی های کنسول رابط الگوی مونادیک برای std::expected خاصیتstatic_assert (false) و سایر ویژگی‌ها در جلسهٔ دوم، کمیته بر روی توسعه ویژگی‌های جدید برای C++26 کار کرد، از جمله:
    ویژگی‌های std::get و std::tuple_size ماکروی #embed بدست آوردن std::stacktrace از استثناء‌ها کرووتین‌های (coroutines) پشته‌ای در ویژگی‌های سی‌پلاس‌پلاس ۲۳ (static operator[])
    تابستان گذشته، کمیته ویژگی static operator() را به استاندارد C++23 اضافه کرد و امکان تعریف operator[] را برای چندین آرگومان فراهم کرد. مرحلهٔ منطقی بعدی دادن فرصت‌های برابر به این عملگرها بود، یعنی اضافه کردن توانایی نوشتنِ static operator[].
    enum class Color { red, green, blue }; struct kEnumToStringViewBimap { static constexpr std::string_view operator[](Color color) noexcept { switch(color) { case Color::red: return "red"; case Color::green: return "green"; case Color::blue: return "blue"; } } static constexpr Color operator[](std::string_view color) noexcept { if (color == "red") { return Color::red; } else if (color == "green") { return Color::green; } else if (color == "blue") { return Color::blue; } } }; // ... assert(kEnumToStringViewBimap{}["red"] == Color::red); آیا این کد واقعاً کارآمد برای تبدیل رشته به enum است؟
    ممکن است تعجب آور باشد، اما کد فوق در واقع بسیار کارآمد است. توسعه‌دهندگانِ کامپایلر از رویکردهای مشابهی استفاده می‌کنند و ما نیز تکنیک مشابهی را در چارچوب userver پیاده‌سازی کرده‌ایم. ما یک کلاس جداگانه به نام utils::TrivialBiMap با رابط‌کاربری راحت‌تر ایجاد کرده‌ایم.
    constexpr utils::TrivialBiMap kEnumToStringViewBimap = [](auto selector) { return selector() .Case("red", Color::red) .Case("green", Color::green) .Case("blue", Color::blue); }; راندمان بالا به لطف ویژگی‌ کامپایلرهای بهینه‌سازی مدرن به دست می‌آید (اما هنگام نوشتن یک راه حل کلی باید بسیار مراقب بود). پیشنهاد در سند P2589R1 تمام جزئیات لازم را شرح می‌دهد.
    ویژگی static constexpr در توابع constexpr
    استاندارد C++23 عملکرد خود را با افزودن constexpr به_chars/from_chars گسترش داده است. اما برخی از اجرا کننده‌گان با مشکل مواجه شدند. چندین کتابخانهٔ استاندارد حاوی آرایه‌های ثابتی برای تبدیل سریع string<>number بودند که به عنوان متغیرهای ثابت در توابع اعلام شدند. متأسفانه، این مانع استفاده از آنها در توابع constexpr شد. این مسئله قابل حل است، اما راه حل ها واقعاً ناشیانه به نظر می‌رسید. در نهایت، کمیته با اجازه دادن به استفاده از متغیرهای static constexpr در توابع constexpr، همانطور که در سند P2647R1 مشخص شد که مشکل را حل کرده‌ است. یک پیشرفت کوچک، اما خوشایند.
     
    محدودهٔ ایمن range-based در حلقهٔ for
    این احتمالاً هیجان انگیزترین خبری است که از دو نشست جلسهٔ استاندارد‌سازی‌های گذشته منتشر می‌شود! در مورد آن، اجازه دهید با یک معمای سرگرم کننده شروع کنیم: آیا می‌توانید اشکال موجود در کد را شناسایی کنید؟
    class SomeData { public: // ... const std::vector<int>& Get() const { return data_; } private: std::vector<int> data_; }; SomeData Foo(); int main() { for (int v: Foo().Get()) { std::cout << v << ','; } } هرچند پاسخ آن در این‌جا آمده است:
    The Foo() function returns a temporary object, and when the Get() method is called on this object, it returns a reference to the data inside the temporary object. The range-based for loop is then transformed into a code close to this one: auto && __range = Foo().Get() ; for (auto __begin = __range.begin(), __end = __range.end(); __begin != __end; ++__begin) { int v = *__begin; std::cout << v << ','; } Here, the first string is equivalent to this: const std::vector<int>& __range = Foo().Get() ; The result is a dangling reference. حلقه‌های مبتنی بر محدوده (Range-based for) شامل فرآیندهای زیربنایی زیادی هستند و در نتیجه، این نوع باگ‌ها ممکن است همیشه آشکار نباشند. در حالی که می‌توان این مشکلات را از طریق آزمایش‌های مربوط به sanitizers‌ها به طور مؤثر تشخیص داد، پروژه‌های نوین معمولاً آنها را به‌عنوان روش استاندارد شامل می‌شوند (پروژه‌های مطرحی مانند Yandex، از این قاعده مستثنی نیستند). با این حال، ایده‌آل است که در صورت امکان از چنین اشکالاتی به طور کامل اجتناب کنید. در RG21، ما اولین تلاش خود را برای بهبود این وضعیت چهار سال پیش با سند D0890R0 انجام دادیم. متأسفانه، این روند در مرحله بحث متوقف شد. خوشبختانه، Nicolai Josuttis ابتکار عمل را انتخاب کرد و در C++23، کدهای مشابه دیگر مرجع معلق (dangling reference) ایجاد نمی‌کنند. تمام اشیایی که در سمت راست : در یک حلقه for مبتنی بر محدوده (ranges) ایجاد می‌شوند، اکنون فقط هنگام خروج از حلقه از بین می‌روند. برای جزئیات فنیِ بیشتر، لطفاً به سند P2718R0 مراجعه کنید.
    ویژگی std::print
    در C++23، یک به‌روزرسانی کوچک اما قابل توجه برایstd::print وجود دارد: خروجی آن برای «همگام‌سازی» با سایر خروجی‌های داده تنظیم شده است. در حالی که بعید است کتابخانه‌های استاندارد در سیستم‌عامل‌های نوین تغییرات قابل توجهی را تجربه کنند، استاندارد به‌روز شده اکنون تضمین می‌کند که پیام‌ها به ترتیبی که در کد منبع ظاهر می‌شوند به کنسول خروجی ساطع می‌شوند:
    printf("first"); std::print("second");  
    رابط الگوی مونادیک برای std::expected
    یک ویژگی نسبتاً مهم در آخرین لحظه به C++23 اضافه شد: یک رابط مونادیک برای std::expected، مشابه رابط مونادیک که قبلاً برای std::optional موجود بود، اضافه شده است.
    using std::chrono::system_clock; std::expected<system_clock, std::string> from_iso_str(std::string_view time); std::expected<formats::bson::Timestamp, std::string> to_bson(system_clock time); std::expected<int, std::string> insert_into_db(formats::bson::Timestamp time); // Somewhere in the application code... from_iso_str(input_data) .and_then(&to_bson) .and_then(&insert_into_db) // Throws “Exception” if any of the previous steps resulted in an error .transform_error([](std::string_view error) -> std::string_view { throw Exception(error); }) ; می‌توانید شرح کاملی از تمام رابط‌های مونادیک برای std::expected  را در سند P2505R5 بیابید.
     
    خاصیتstatic_assert (false) و سایر ویژگی‌ها
    علاوه بر تغییرات قابل توجهی که در بالا ذکر شد، تعداد زیادی بازنگری برای حذف لبه‌های ناهموار جزئی و بهبود توسعه روزمره انجام شده است. به عنوان مثال، فرمت‌کننده‌ها برای std::thread::id و std::stacktrace (P2693 سند) تا بتوان از آنها با std::print و std::format استفاده کرد. به ویژه std::start_lifetime_a بررسی‌های زمان کامپایل اضافی را در سند P2679 دریافت کرده است. قابل توجه است که خاصیت static_assert(false) در توابع الگو (template function) دیگر بدون نمونه‌سازی تابع فعال نمی‌شود، به این معنی که کدی مانند زیر فقط در صورت ارسال نوع داده اشتباه، عیب‌یابی را کامپایل و صادر می‌کند:
    template <class T> int foo() { if constexpr (std::is_same_v<T, int>) { return 42; } else if constexpr (std::is_same_v<T, float>) { return 24; } else { static_assert(false, "T should be an int or a float"); } } علاوه بر تغییراتی که قبلاً ذکر شد، بهبودهای بیشماری در خاصیت (ranges) از C++23 انجام شده است. مهمترین آنها گنجاندن std::views::enumerate در سند P2164 است:
    #include <ranges> constexpr std::string_view days[] = { "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun", }; for(const auto & [index, value]: std::views::enumerate(days)) { print("{} {} \n", index, value); }  
    ویژگی‌های سی‌پلاس‌پلاس ۲۶
    ویژگی‌های std::get و std::tuple_size برای (aggregates) تجمیع
    یک ایدهٔ جدید و هیجان انگیز برای بهبود ++C وجود دارد که در حال حاضر به طور فعال در Yandex Go و چارچوب userver استفاده می‌شود و به لطف Boost.PFR برای هر کسی که آن را می‌خواهد در دسترس است.
    اگر در حال نوشتن یک کتابخانهٔ مبتنی بر الگو (template) و عمومی هستید، به احتمال زیاد باید از std::tuple و std::pair استفاده کنید. با این حال، برخی از مشکلات در این نوع وجود دارد. اولاً، آنها خواندن و درک کد را دشوار می‌کنند زیرا ورودی‌های نامِ واضحی ندارند، و تشخیص معنای چیزی مانندstd::get<0>(tuple) می‌تواند چالش برانگیز باشد. علاوه بر این، کاربران کتابخانهٔ شما ممکن است نخواهند مستقیماً با این انواع کار کنند و درست قبل از فراخوانیِ روش‌های شما، اشیاء‌ای از این نوع ایجاد می‌کنند که به دلیل کپی کردن داده‌ها می‌تواند ناکارآمد باشد. ثانیاً، std::tuple و std::pair بی‌اهمیت بودن انواعی را که ذخیره می کنند، «تبلیغ نمی کنند». در نتیجه، هنگام ارسال و برگرداندن std::tuple و std::pair از توابع، کامپایلر ممکن است کدی را با کارآیی پایین‌تر تولید کند. با این حال، aggregates (تجمیع‌ها) - ساختارهایی (struct) با میدان‌های عمومی و بدون عملکرد خاص - عاری از اشکالات ذکر شده هستند.
    ایده‌ای که پشت سند P2141R0 وجود دارد، این است که با کار کردن std::get و std::tuple_size آنها، امکان استفاده از تجمیع‌ها در کدهای عمومی را فراهم می‌کند. این به کاربران امکان می‌دهد تا ساختارهای خود را مستقیماً بدون کپی برداری غیر ضروری به کتابخانهٔ عمومی شما منتقل کنند. این ایده به خوبی توسط کمیته مورد استقبال قرار گرفت، و ما در آینده روی آزمایش و رسیدگی به هرگونه لبهٔ ناهموار و بالقوه در این زمینه کار خواهیم کرد.
     
    ماکروی #embed
    در حال حاضر، توسعهٔ فعالی روی یک استاندارد زبان C جدید (یک استاندارد بدون کلاس، بدون ++) وجود دارد که شامل بسیاری از ویژگی‌های مفیدی است که مدت‌هاست در ++C وجود داشته است (مانند: nullptr، auto، constexpr، static_assert، thread_local، [[noreturn]).])، و همچنین ویژگی‌های کاملاً جدید برای ++C. خبر خوب این است که برخی از ویژگی‌های جدید از استاندارد جدید C به C++26 منتقل می‌شوند. یکی از این موارد جدید، #embed است - یک دستورالعمل پیش پردازنده برای جایگزینی محتویات یک فایل به عنوان یک آرایه در زمان کامپایل:
    const std::byte icon_display_data[] = { #embed "art.png" }; شرح کامل این ایده در سند P1967 موجود است.
    بدست آوردن std::stacktrace از استثناء‌ها
    در اینجا، ایدهٔ سند P2370 در WG21 با یک شکست غیرمنتظره روبرو شده است. توانایی به دست آوردن ردیابی پشته از یک استثناء در اکثر زبان‌های برنامه‌نویسی وجود دارد. این ویژگی فوق‌العاده مفید است و به جای پیام‌های خطای غیر اطلاعاتی مانند Caught exception: map::at تشخیص‌های آموزنده‌تر و قابل فهم‌تر را امکان‌پذیر می‌کند که نمونه مثال آن به صورت زیر است:
    Caught exception: map::at, trace: 0# get_data_from_config(std::string_view) at /home/axolm/basic.cpp:600 1# bar(std::string_view) at /home/axolm/basic.cpp:6 2# main at /home/axolm/basic.cpp:17 هنگامی که در محیط یکپارچه سازی پیوسته (CI) استفاده می‌شود، این ویژگی می‌تواند فوق‌العاده مفید باشد. این به شما امکان می‌دهد تا به سرعت مسائل را در آزمون شناسایی کنید و از دردسر بازتولید مشکل به صورت محلی اجتناب کنید، که ممکن است همیشه امکان‌پذیر نباشد. متأسفانه کمیتهٔ بین‌المللی به طور کامل از این ایده استقبال نکرد. اما تیم توسعه نگرانی‌ها را بررسی می‌کند و روی اصلاح این ایده کار خواهد کرد تا بتواند حمایت بیشتری را کسب کند.
    کسانی که معمولاً می‌پرسند چه تفاوتی بین زبان‌های دیگر و استاندارد‌های سی‌++ وجود دارد، در این‌جا می‌توانند به این موضوع دقت کنند که زبانی مانند سی‌پلاس‌پلاس دارای کمیتهٔ استاندارد‌سازی بین‌المللی است و هر تغییری باید قابل توجیه باشد.
     
    کروتین‌های (coroutines) پشته
    سرانجام، پس از سال‌ها کار، استاندارد سی‌پلاس‌دلاس به افزودن پشتیبانی اولیه برای برنامه‌های پشته‌ای در C++26 نزدیک شده است (به سند P0876 مراجعه کنید). ارزش آن را دارد که بیشتر در مورد روال‌های پشته‌ای یا بدون پشته بررسی کنیم. برنامه‌های بدون پشته به پشتیبانی کامپایلر نیاز دارند و نمی‌توانند به تنهایی به عنوان یک کتابخانه پیاده‌سازی شوند. از سوی دیگر، کروتین‌های پشته‌ای را می‌توان به تنهایی پیاده‌سازی کرد - برای مثال، با Boost.Context.
    در حالت‌های قبلی، تخصیص حافظه کارآمدتر، بهینه‌سازی بالقوه بهتر کامپایلر و توانایی تخریب سریع آنها را ارائه می‌دهد. آنها همچنین در حال حاضر در C++20 در دسترس هستند. ادغام نمونه‌های اخیر در پروژه‌های موجود بسیار آسان‌تر است، زیرا نیازی به بازنویسی کامل در یک اصطلاح جدید مانند برنامه‌های بدون پشته ندارند. در واقع، آنها جزئیات پیاده‌سازی را به طور کامل از کاربر مخفی می‌کنند و آنها را قادر می‌سازند تا کد خطی ساده‌ای را که در لایه‌های زیرینِ ناهمزمانی هستند بنویسند.
    بدون پشته (Stackless)
    auto data = co_await socket.receive(); process(data); co_await socket.send(data); co_return; // requires function to return a special data type پشته‌ای (Stackfull)
    auto data = socket.receive(); process(data); socket.send(data); سند  P0876  قبلاً در زیرگروه اصلی قرار داشته است. پس از بحث و گفتگو، تصمیم گرفته شد که مهاجرت این گونه برنامه‌ها (coroutines) بین رشته‌‌های اجرایی ممنوع شود. دلیل اصلی این ممنوعیت این است که کامپایلرها دسترسی به TLS را بهینه کرده و مقادیر متغیرهای TLS را در حافظه پنهان ذخیره می‌کنند:
    thread_local int i = 0; // ... ++i; foo(); // Stackful coroutines can switch execution threads assert(i > 0); // The compiler saved the address in a register; we’re working with the TLS of another thread جمع‌بندی
    در نهایت استاندارد C++23 رسماً به مقامات بالاتر از کمیتهٔ ISO ارسال شده است و به زودی به عنوان یک استاندارد کامل منتشر خواهد شد. در همین حال، توسعه C++26 در نوسان کامل است و چشم‌اندازهای هیجان‌انگیزی برای خاصیت‌های متنوع وجود دارد. اگر ایده‌های نوآورانه‌ای برای بهبود ++C دارید، با خیال راحت آنها را به اشتراک بگذارید. یا - حتی بهتر - ارسال یک پیشنهاد را در نظر بگیرید.
  8. کامبیز اسدزاده
    با سلام، با توجه به گزارش آنتونی پولوخین که یکی از اعضای کمیتهٔ استاندارد‌سازی WG21 (سازمانی که توسعهٔ زبان برنامه‌نویسی سی‌پلاس‌پلاس را کنترل می‌کند). این کمیته سه بار در هر سال، هر بار در یک شهر جدید در سراسر جهان جلسه برگزار می‌کند. در طول این جلسات، پیشنهاداتی برای تغییر در زبان در نظر گرفته می‌شود. همچنین به توسعه‌دهنده‌های محلی سی++ کمک می‌کنند تا پیشنهادات خود را ارائه کنند. خلاصه‌ای از جلسهٔ ماه جولای با هدف نهایی شدن استاندارد ۲۳ که نشان می‌هد پیشرفت بزرگی به عنوان ویژگی‌های جدید استاندارد ۲۳ وجود دارد ارائه شده است:

    فهرست برخی از ویژگی‌ها به صورت زیر آمده‌است:
    std:mdspan std:flat_map std:flat_set freestanding std:print("Hello {}", "world") formatted ranges output constexpr for bitset, to_chars/from_chars std::string::substr() && import std; std::start_lifetime_as static operator() [[assume(x > 0)]] 16- and 128-bit floats std::generator و البته ویژگی‌های بسیار بیشتر از این.
    ویژگی std::mdspan
    از زمان اتخاذ عملگر opertator[] چند بعدی در آخرین جلسه، معرفیstd::mdspan به عنوان یک ویژگی ساده‌تر مطرح شده است و نتیجهٔ یک آرایهٔ چند بعدی غیر مالک به صورت زیر است:
    using Extents = std::extents<std::size_t, 42,="" 32,="" 64="">; double buffer[ Extents::static_extent(0) * Extents::static_extent(1) * Extents::static_extent(2) ]; std::mdspan<double, Extents=""> A{ buffer }; assert( 3 == A.rank() ); assert( 42 == A.extent(0) ); assert( 32 == A.extent(1) ); assert( 64 == A.extent(2) ); assert( A.size() == A.extent(0) * A.extent(1) * A.extent(2) ); assert( &A(0,0,0) == buffer ); این ویژگی حتی می‌تواند با سایر زبان‌های برنامه‌نویسی خارج از جعبه کار کند. به عنوان مثال، در پارامتر الگوی سوم خود، std::mdspan می‌تواند یکی از چندین کلاس طرح بندی از پیش تعریف شده را بگیرد:
    نوعstd::layout_right: سبک چیدمان برای C یا ++C، سطرها دارای شاخص صفر هستند. نوعstd::layout_left: سبک چیدمان برای Fortran یا Matlab، ستون‌ها دارای شاخص صفر هستند. شما می توانید تمام جزئیات را در سند P0009 بیابید. نویسندگان قول داده‌اند که در آینده نزدیک نمونه‌های زیادی از std:mdspan جدید ارائه کنند.
     
    ویژگی std::flat_map و std::flat_set
    نگه‌دارنده‌های شگفت‌انگیز flat_* از کتابخانهٔ بوست، دیگر در استاندارد اصلی سی++ در دسترس هستند. این خاصیت‌ها در کار با داده‌‌های کم بسیار پرکاربرد هستند. در زیر ساخت‌ها، ظروف flat داده‌ها را در یک آرایه مرتب شده ذخیره‌سازی می‌کنند که به طور قابل توجهی تخصیص حافظهٔ پویا را کاهش داده و موقعیت داده‌ها را بهبود می‌بخشد. علیرغم پیچیدگی جستجوی O(log N) و پیچیدگی درجO(N) در بدترین حالت، ظروف مسطح هنگام کار با مقدار کمی از عناصر بهتر از std:unordered_map عمل می‌کنند. در واقع، در طی فرآیند استانداردسازی، ظروف flat_* به عنوان آداپتور ساخته شده‌اند. به این ترتیب، برنامه‌نویسان می‌توانند از نگه‌دارنده‌های خود برای پیاده‌سازی اساسی استفاده کنند:
    template <std::size_t N> using MyMap = std::flat_map< std::string, int, std::less<>, mylib::stack_vector<std::string, N>, mylib::stack_vector<int, N> >; static MyMap<3> kCoolestyMapping = { {"C", -200}, {"userver", -273}, {"C++", -273}, }; assert( kCoolestyMapping["userver"] == -273 ); const auto& keys = kCoolestyMapping.keys(); // Inspired by Python :) assert( keys.back() == "userver" ); یک نکتهٔ جالب این است که استاندارد STL برخلاف پیاده‌سازی Boost، کلیدها و مقادیر را در نگه‌دارنده‌ها جداگانه ذخیره می‌کند. این مکانِ کلیدیِ بهبود یافته، جستجوی ظرفِ flat را سریع‌تر می‌کند.
    رابط کاملstd::flat_set در سند P1222 توضیح داده شده است، در حالی که شرح رابط std:flat_map در سند P0429 موجود است.
     
    مستقل (Freestanding)
    استاندارد ++C می‌گوید که امکان پیاده‌سازی کتابخانهٔ استاندارد به صورت میزبان (hosted) یا مستقل (freestanding) وجود دارد. پیاده‌سازی میزبان نیاز به پشتیبانی سیستم‌عامل دارد و باید تمام روش‌ها و کلاس‌ها را از کتابخانهٔ استاندارد پیاده‌سازی کند. مستقل (freestanding) می‌تواند بدون سیستم‌عامل کار کند، سخت‌افزار مهم نیست، و برخی از کلاس‌ها و توابع را شامل نمی‌شود. تا همین اواخر، هیچ توضیحی برای ایستادن آزاد وجود نداشت و سازندگان سخت‌افزارهای مختلف بخش‌های مختلفی از کتابخانهٔ استاندارد را ارائه می‌کردند. این کارِ پورت کردن کد را سخت‌تر کرد و محبوبیت ++C را در محیط‌های تعبیه‌شده (امبد‌ها) تضعیف کرد.
    بنابراین، زمان تغییر آن فرا رسیده است! سند P1642 مشخص کرده است که کدام بخش از کتابخانهٔ استاندارد برای freestanding اجباری است.
     
    ویژگی std::print
    روش‌هایی از کتابخانهء محبوب fmt در C++20 اضافه شد. این کتابخانه آنقدر راحت و سریع بود که برنامه‌نویسان شروع به استفاده از آن کرده و تقریباً در همه‌جای کد خود به کار برده‌اند، از جمله برای خروجی قالب‌بندی شده:
    std::cout << std::format(“Hello, {}! You have {} mails”, username, email_count); اما کدی مانند آن به دلایل زیر کامل نیست:
    تخصیص پویا اضافی. نیاز به std::cout جهت قالب‌بندی خطوط از قبل قالب بندی شده. عدم پشتیبانی از یونیکد. کدی که اندازهٔ فایل باینری حاصل را افزایش می‌دهد. ظاهری نه چندان جذاب. بنابراین، تمام این مشکلات با اضافه کردن متدهایstd::print حل شد:
    std::print(“سلام, {}! به جامعهٔ {} خوش آمدید!”, name, community); می‌توانید جزئیات، معیارها و گزینه‌های استفاده ازstd::print باFILE* و استریم‌ها را در سند P2093 بیابید.
     
    خروجی قالب‌بندی شده محدوده‌های مقدار
    به لطف سند P2286 و، std::format (و std::print) اکنون می‌توانند محدوده‌هایی از مقادیر را بدون در نظر گرفتن اینکه در یک ظرف هستند یا توسط std::ranges::views::* ارائه شده‌اند خروجی بگیرند.
    std::print("{}", std::vector<int>{1, 2, 3}); // Output: [1, 2, 3] std::print("{}", std::set<int>{1, 2, 3}); // Output: {1, 2, 3} std::print("{}", std::pair{42, 16}); // Output: (42, 16) std::vector v1 = {1, 2}; std::vector v2 = {'a', 'b', 'c'}; auto val = std::format("{}", std::views::zip(v1, v2)); // [(1, 'a'), (2, 'b')]  
    ویژگی constexpr
    اخبار تجزیه و تحلیل عالی برای توسعه‌دهندگانی که با کتابخانه‌های مختلف کار می‌کنند وجود دارد:
    خاصیت‌هایstd::to_chars/std::from_chars اکنون می‌توانند در مرحله کامپایل برای تبدیل مقادیر صحیح از متن به باینری استفاده شوند. این نیز باید هنگام توسعه DSL مفید باشد. به نظر می‌رسد توسعه‌دهنده‌های روسی Yandex Go (به نقل از عضو کمیته) قصد دارند از آن در چارچوب کاربر برای بررسی پرس و جوهای SQL در مرحله کامپایل استفاده کنند. گزینهٔ std::bitset نیز تبدیل به constexpr شده است، بنابراین کار با بیت‌ها در مرحلهٔ کامپایل اکنون بسیار آسان‌تر از قبل است. دانیل گوچاروف روی std::bitset در سند P2417 کار کرد و الکساندر کارائف در سند std::to_chars/std::from_chars P2291 به او پیوست. با تشکر فراوان از آنها برای این کار خوب انجام شده!
    ویژگی import std;
    با توجه به این‌که، اولین ماژول کامل(تمام‌عیار) به کتابخانهٔ استاندارد (STL) اضافه شد. اکنون می‌توان کل کتابخانه را با یک خط بر سند وارد کرد: import std;. اگر کل ماژول کتابخانهٔ استاندارد به جای گنجاندن فایل‌های هدر وارد شود، ساخت‌ها می‌توانند تا ۱۱ برابر (گاهی اوقات حتی ۴۰ بار!) سریع‌تر شوند. می‌توانید بنچمارک ها را در P2412 مشاهده کنید. اگر به ترکیب ++C و C و همچنین استفاده از توابع C از فضای نام جهانی عادت دارید، ماژول std.compat برای شما مناسب است. وارد کردن آن همهٔ توابع فایل‌های سرآیند C مانند ::fopen و ::isblank و همچنین محتویات کتابخانهٔ استاندارد را در اختیار شما قرار می‌دهد.
    با وجود همهٔ اینها، سند P2465 که ماژول‌های جدید را پوشش می‌‌دهد، در واقع آنقدر‌ها هم طولانی نیست.
    ویژگی std::start_lifetime_as
    تیمور داملر و ریچارد اسمیت یک هدیهٔ فوق‌العاده برای همهٔ توسعه‌دهندگانی که روی برنامه‌های تعبیه شده (امبد) و پر‌بار کار می‌کنند گرد هم آورده‌اند. اکنون تنها چیزی که برای کار کردن همه چیز نیاز دارید این است:
    struct ProtocolHeader { unsigned char version; unsigned char msg_type; unsigned char chunks_count; }; void ReceiveData(std::span<std::byte> data_from_net) { if (data_from_net.size() < sizeof(ProtocolHeader)) throw SomeException(); const auto* header = std::start_lifetime_as<ProtocolHeader>( data_from_net.data() ); switch (header->type) {> // ... } } به عبارت دیگر، می‌توانید بافرهای مختلف را به ساختارها تبدیل کنید و با آنها بدون reinterpret_cast، کپی کردن داده‌ها یا خطر عملکرد برنامه‌تان کار کنید. همه چیز در سند P2590 شرح و مستند شده است.
    ویژگی‌های شناورهای (اعشاری) 16 و 128 بیتی
    استاندارد ++C اکنون شامل std::float16_t، std::bfloat16_t، std::float128_t و نام مستعار برای اعداد موجود با ممیز شناور است: std::float32_t، std::float16_t. شناورهای 16 بیتی در هنگام کار با کارت‌های ویدئویی یا یادگیری ماشین کمک می‌کنند. به عنوان مثال، float16.h می‌تواند از انواع جدید شناور کوتاه بهره‌مند شود. شناورهای 128 بیتی برای محاسبات علمی شامل اعداد بزرگ بهترین هستند. سندِ P1467 ماکروها را برای بررسی پشتیبانی کامپایلر برای اعداد جدید توصیف می‌کند، و حتی خاصیتِ stdfloat.properties، در جدول مقایسه با توصیف اندازه‌های مانتیس و توان در بیت‌ها وجود دارد.
     
    ویژگی std::generator
    زمانی که کروتین‌ها در استاندارد C++20 پذیرفته شدند، ایده این بود که می‌توان از آن‌ها برای ایجاد «مولد» استفاده کرد: توابعی که وضعیت خود را بین تماس‌ها به خاطر می‌آورد و مقادیر جدید را بر اساس آن حالت برمی‌گرداند. در استاندارد C++23 با اشاره به، std::generator به عنوان یک کلاس جدید یاد می‌شود که به شما امکان می‌دهد به راحتی ژنراتورهای خود را ایجاد کنید:
    std::generator<int> fib() { auto a = 0, b = 1; while (true) { co_yield std::exchange(a, std::exchange(b, a + b)); } } int answer_to_the_universe() { auto rng = fib() | std::views::drop(6) | std::views::take(3); return std::ranges::fold_left(std::move(rng), 0, std::plus{}); } در مثال فوق می‌توانید ببینید که ژنراتورها با std::ranges چقدر خوب کار می‌کنند. std::generator کارآمد و ایمن است. کدی که به نظر می‌رسد یک پیوند معلق ایجاد می‌کند در واقع کاملاً معتبر است و هیچ مشکلی ایجاد نمی‌کند:
    std::generator<const std::string&=""> greeter() { std::size_t i = 0; while (true) { co_await promise::yield_value("hello" + std::to_string(++i)); // Everything is ok! } } می‌توانید مثال‌ها و توضیحاتی دربارهٔ نحوه کارکرد و استدلال پشت این رابط را در سند P2502 بیابید.
     
    سورپرایزهای دلپذیر
    کلاس string استاندارد برای متد substr() برای ارجاعات rvalue یک بازنگری اساسی (بهبود) دریافت کرده‌ است: std::string::substr() &&. مانند مثال زیر:
    std::string StripSchema(std::string url) { if (url.starts_with("http://")) return std::move(url).substr(5); if (url.starts_with("https://")) return std::move(url).substr(6); return url; } این روش اکنون بدون تخصیص پویا اضافی کار می‌کند. اطلاعات بیشتر را می‌توانید در سند P2438 بیابید.
    به لطف سند P1169، اکنون می‌توانیدoperator() را ثابت اعلام کنید، که برای ایجاد CPO برای محدوده‌ها در کتابخانه استاندارد عالی است:
    namespace detail { struct begin_cpo { template <typename T> requires is_array_v<remove_reference_t<T>> || member_begin<T> || adl_begin<T> static auto operator()(T&& val); }; void begin() = delete; // poison pill } // namespace detail namespace ranges { inline constexpr detail::begin_cpo begin{}; // ranges::begin(container) } // namespace ranges علاوه بر std::start_lifetime_as، تیمور داملر یک راهنمایی عالی برای بهینه‌ساز ارائه کرد[[assume (x > 0)]]. اکنون می‌توانید در مورد مقادیر احتمالی اعداد و سایر متغیرهای ثابت به کامپایلر نکاتی بدهید. برخی از مثال‌ها و معیارها در سند P1774 کاهش پنج برابری در تعداد دستورالعمل‌های اسمبلی را نشان می‌دهند.
    این استاندارد همچنین دارای بسیاری از ویرایش‌های جزئی، رفع اشکال و پیشرفت‌ها بوده است، در اینجا منظور استاندارد ۲۳ است. در برخی مکان‌ها، از سازنده‌های حرکتی (move constructors) به جای سازنده‌های کپی (copy constructors) استفاده شد (P2266). خوشبختانه برای توسعه‌دهندگان درایور، برخی از عملیات فرار دیگر منسوخ نمی‌شوند (P2327 با رفع اشکال در C++20). عملگر<=> کدهای قدیمی را کمتر می‌شکند (P2468)، کاراکترهای یونیکد اکنون می‌توانند با نام استفاده شوند (P2071)، و کامپایلرها عموماً برای پشتیبانی از یونیکد (P2295) مورد نیاز هستند. الگوریتم‌های جدید برای محدوده‌ها (ranges::contains P2302, views::as_rvalue P2446, views::repeat P2474, views::stride P1899, و ranges::fold P2322) و std::format_string برای بررسی‌های زمان کامپایل اضافه شد. std::format (P2508) و ماکروی #warning در (P2437). محدوده‌ها (Ranges) یاد گرفت‌اند که چگونه با انواع فقط حرکت کار کنند (P2494). و در نهایت std::forward_like برای ارسال متغیرها بر اساس نوع متغیر دیگری اضافه شد (P2445).
    برای مدت طولانی، به نظر می‌رسید مهم‌ترین نوآوری C++23 اضافه کردن std::stacktrace از RG21 بود، اگرچه در آخرین جلسه ویژگی‌های مورد انتظار بسیاری اضافه شد. نوآوری‌هایی برای توسعه‌دهندگان تعبیه شده، شیمیدانان/فیزیکدانان/ریاضیدانان/...، توسعه‌دهندگان کتابخانه‌های یادگیری ماشین، و حتی توسعه‌دهندگانی که روی برنامه‌های کاربردی با بار بالا کار می‌کنند، وجود دارد.
     
  9. کامبیز اسدزاده
    در سالی که گذشت (۲۰۲۲)، سی‌پلاس‌پلاس محبوب‌ترین زبان برنامه‌نویسی با رشد شاخص محبوبیت ۴.۶۲٪ انتخاب شد!
    جایزه زبان برنامه‌نویسی سال TIOBE به ++C تعلق گرفت! این جایزه به زبان برنامه‌نویسی تعلق می‌گیرد که بیشترین افزایش محبوبیت را در یک سال تجربه کرده است.

    شاخص TIOBE میزان محبوبیت زبان‌های برنامه‌نویسی را اندازه‌گیری می‌کند. با این حال، قبل از نتیجه‌گیری، توجه به این نکته مهم است که Index (شاخص) نه چیزی در مورد کیفیت یک زبان برنامه‌نویسی می‌گوید و نه ادعا می‌کند. این رتبه‌بندی با تجزیه و تحلیل تعداد مهندسان ماهر در یک زبان خاص، تعداد دوره‌های آموزشی در آن زبان و تعداد فروشندگان شخص ثالثی که محصولات یا خدمات مرتبط با آن زبان را ارائه می‌دهند، محاسبه می‌شود. این فهرست ماهانه به‌روز می‌شود و بر اساس داده‌های موتورهای جستجوی محبوب مانند گوگل، بینگ و یاهو است. جایزهٔ زبان برنامه‌نویسی سال TIOBE در ژانویه هر سال بر اساس رتبه‌بندی سال قبل اعلام می‌شود.
    سی‌پلاس‌پلاس یک زبان برنامه‌نویسی در سال ۲۰۲۲ انتخاب شد که با محبوبیت رشد ۴.۶۲ درصد و بیشترین رشد انتخاب شده است. این زبان برنامه‌نویسی سطح بالا با کارایی بالا و چندمنظوره برای توسعهٔ نرم‌افزار‌های سیستمی، برنامه‌های کاربردی و بازی‌های ویدیویی با انعطاف‌پذیری و قابلیت کنترل سطوح پایین است. این زبان در نوامبر ۲۰۲۲ جاوا را پشت‌سر گذاشت و به رتبهٔ سوم شاخص رسید و محبوبیت آن به طور پیوسته در حال افزایش است. نایب قهرمان در سال ۲۰۲۲ به ترتیب C با رشد ۳.۸۲ و پایتون با ۲.۷۸ درصد رشد بوده‌اند.
  10. کامبیز اسدزاده
    یک سوأل بسیار مهم و پر مخاطب در بارهٔ زبان‌برنامه‌نویسی سی‌پلاس‌پلاس در سال‌های اخیر این است که «آیا جایگزینی برای این زبان وجود دارد و یا قابل جایگزین است»؟
    در بسیاری از پاسخ‌ها نشان از گزینه‌هایی مانند Go، Rust و D دیده می‌شود که بهتر است نسبت به نظرات متخصص‌های برنامه‌نویسی به این موضوع پرداخته شود، ابتدا باید در نظر گرفت که هر ابزاری می‌تواند جایگزینی داشته باشد اما شرایط و نحوهٔ استفادهٔ آن در رابطه با نیاز متفاوت است.

    اخیراً سوألات زیادی در این موضوع دیده شده است که می‌گویند، Rust یک زبان برنامه‌نویسی ایمن، سریع و سیستمیِ جایگزین برای سی‌پلاس‌پلاس است! اما آیا واقعاً اینگونه است یا صرفاً ما بر اساس احساسات و اشتیاق به به‌روز شدن به این موضوع می‌پردازیم؟
    پاسخ برای این سوأل به صورت زیر در مدل‌های مختلف می‌تواند مطرح شود که نتیجه‌گیری و تصمیم از خلاصهٔ آن به عهدهٔ خودِ شماست.
    من بر این باورم که زبان‌های برنامه‌نویسی همه و همه در حال به‌روز رسانی و بهتر شدن نسبت به نسخه‌ها، استاندارد‌ها، و نسل‌های گذشتهٔ خودشان هستند و به هیچ عنوان هیچ زبانی تا به امروز به طور جدی منسوخ شده اعلام نشده است.
    برای درک این مطلب بهتر است ابتدا به واژهٔ «منسوخ شده» یا «Deprecated» بپردازیم، این واژه زمانی مورد استفاده قرار می‌گیرد که شرایط زیر بر آن حاکم باشد:
    گزینهٔ مورد نظر به طور رسمی از طرف سازنده، پشتیبان یا صاحب آن بد دانسته شده و رسماً کنار گذاشته شود. گزینهٔ مورد نظر به‌روز رسانی نشود و آخرین به‌روز رسانی آن نیز شامل مشکلاتی باشد که بعد از مدت‌ها نیز حل نشده باشد. گزینهٔ مورد نظر دیگر مورد استفاده قرار نگیرد و کاربردی هم در بین رقبای خود نداشته باشد. گزینهٔ مورد نظر دیگر پشتیبانی نشود و به قولی مُرده باشد. گزینهٔ مورد نظر به علاوهٔ این که شامل این موارد می‌شود، باید دارای یک جایگزین مناسب و عالی باشد. با توجه به این معیار‌ها و با در نظر گرفتن رسالت هر یک ابزار‌ها باید به آن توجه کرد که هر زبان یا ابزار برنامه‌نویسی خارج از این، در مرحلهٔ پیشرفت قرار گرفته است که آن نشان دهندهٔ زنده بودن و کاربردی بودن آن است.
    از طرفی، زبانی مثل سی‌پلاس‌پلاس جایگزین نمی‌شود چرا که هیچ یک از دلایل و معیار‌های بالا شامل حال آن نمی‌شود، اتفاقاً برعکس این زبان دارای ویژگی‌های معیاری زیر است:
    این زبان به طور رسمی توسط کمیتهٔ استاندارد‌سازی که متعلق به هیچ یک از شرکت‌های غول صنعتی و یا خصوصی نمی‌باشد پشتیبانی می‌شود. این زبان به طور مداوم در حال به‌روز رسانی است و کاربرد‌های چند-منظوره و همه جانبهٔ خود را داراست. این زبان از ویژگی‌های از ویژگی‌های بسیار خوب به همراه سریع‌ترین بازدهی‌ها را داراست. این زبان رقیب‌های بسیاری دارد، اما هیچ کدام از آن‌ها هنوز در عمل و دامنهٔ وسیعی موفق به نمایش عملکرد بهتری نبوده‌اند. این زبان همانند دیگر ابزار‌ها دارای مشکلاتی است، اما با توجه به پوشش و پشتیبانی از ویژگی BC در روند استاندارد‌سازی و به‌روز رسانی به خوبی از پس آن‌ها بر آمده است. برای مثال، زبان جاوا یکی از بهترین زبان‌های برنامه‌نویسی است و خیلی از شرکت‌ها مانند گوگل در سیستم‌های توزیع شده از آن استفاده می‌کنند. اما به معنای این نیست که به سرعت سی++ می‌رسد و در حد مقایسه با آن است. این زبان می‌تواند ده‌ها و صد‌ها برابر کند‌تر از سی++ باشد و این مربوط به طراحی، ساختار و مسائل مربوط به زبان است. از طرفی سی‌پلاس‌پلاس محبوب است زیرا که ویژگی‌های زیر را دارد و طی سال‌های بسیاری آن را ثابت کرده است:
    کارآیی (پرفرمنس) و سرعت فوق‌العادهٔ این زبان، البته خیلی از زبان‌ها ادعا می‌کنند که همچین ویژگی‌ای را دارند که در عمل نتیجهٔ جالبی مشاهده نمی‌شود. ذاتِ چند-سکویی و چند-منظوره بودن آن، حداقل همهٔ سیستم‌ها می‌توانند کد‌های سی++ را کامپایل و اجرا کنند. این زبان به راحتی می‌تواند با زبان‌ها و فناوری‌های دیگری ارتباط برقرار کرده و با آن‌ها تعامل داشته باشد. این زبان به عنوان یکی از کم‌مصرف‌ترین زبان‌های برنامه‌نویسی از نظر مصرف انرژی محسوب می‌شود. بسیاری از مهندسین این زبان‌ها را به صورت مقطعی و بار‌ها دیده و با آن آشنا هستند. کتابخانه‌های پیشفرض استاندارد STL و دیگر کتابخانه‌های سی‌++ بسیار قدرتمند و گسترده هستند. کتابخانه‌های نوع سوم (Third-Party) بسیار قدرتمند و به‌روز هستند. اولویت‌های سیستم‌های یونیکس و حتی ویندوز اکثراً بر روی C و ++C است و بازنویسی آن‌ها با زبان‌های دیگر هزینهٔ بسیاری را به ارمغان می‌آورد. بسیاری از وابستگی‌های ایجاد شده در سال‌های بسیار طولانی بر اساس سی و سی++ بوده و باز‌نگری و بازنویسی آن‌ها مشروط بر این که رابط‌ها باید باز‌نویسی شود بسیار سخت و کاری مشابه اختراع دوبارهٔ چرخ است. عملکرد تا حدی قابل پیش‌بینی است و می‌تواند آن را درک کرد، چیزی که در زبان‌هایی مانند جاوا، سی‌شارپ و گو نمی‌تواند پیش‌بینی کرد چرا که پیش‌بینی چرخهٔ GC دشوار است، هیچ رقیب جدی‌ای در این باره در سطح سی++ وجود ندارد که مدیریت حافظه را برای شما در قالب یک RAII ارائه کند، هرچند در مورد Objective-C و Rust می‌توان آن‌ها را به صورت جداگانه مورد بررسی قرار داد و نه عین آن. پشتیبانی از پارادایم (سبک)‌های طراحی را سی++ به خوبی پشتیبانی می‌کند، برای مثال برنامه‌نویسی عمومی در زمان کامپایل را به خوبی ارائه می‌کند. پشتیبانی از برنامه‌نویسی سیستمی و سطح پایین در این زبان یک مزیتی دیگری است که در کنار تمامی ویژگی‌های سطح بالای خود ارائه می‌کند. اما در این میان زبان‌هایی مثل Rust، Go، Swift و غیره ادعای جایگزینی را دارند اما ادعا‌های فنی به تنهایی کافی نیستند، در دسترس بودن گسترده از جامعه به اندازهٔ کافی به همراه جامعهٔ معتمد به آن مهم است. علاوه بر ویژگی‌های فنی زبان سی++، یک نقطه قوت بسیار مهم این زبان در بحث غیر فنی آن است، در واقع در پشت این زبان نه یک پیاده‌سازی محدودی وجود دارد و نه یک سازمان که در آینده در مورد آن تصمیم بگیرد و آن را کنترل کند. در حالی که تمامی زبان‌های مطرح و ادعا کننده داخل یک چهارچوبی کنترل می‌شوند که به شدت آیندهٔ آن‌ها را تیره و تار می‌کند. به طور کلی آزاد بودن یک ابزار و قدرت یک جامعه فارغ از جغرافیا، سازمان، نژاد و زبان یک قدرت بسیار خارق‌العاده‌ای را برای یک ابزار به ارمغان می‌آورد که به تنهایی بسیار اهمیت دارد. در این اواخر بسیاری از مهندسین به فکر باز‌نویسی بسیاری از موارد شدن و تحقیقات نشان می‌دهد ابزار‌هایی گرافیکی بسیار قدرتمند و سریع که اخیراً طراحی شده‌اند، مانند وُلکان که با سی++ نوشته شده‌ است زمانی می‌توانند با راست و زبان‌های دیگر امروزی باز‌نویسی شوند که یک سیستم‌عامل جدید با زبان‌های جدید ساخته شود! بنابراین صرفاً می‌توان یک نسخهٔ Wrapper یا همان (پوشنده) چرا که تقریباً همهٔ سیستم‌عامل‌های مدرن امروزی با زبان‌های سی و سی++ نوشته شده‌اند. از طرفی تولید یک سیستم‌عامل بسیار پر خطر است و سرمایه‌گذاری کلان، زمان و هزینه‌های بسیاری را می‌طلبد و تا زمانی که چنین نرم‌افزار‌هایی تحت سلطهٔ زبان‌هایی مانند سی++ قرار گرفته باشند پادشاهی سی‌پلاس‌پلاس ادامه خواهد داشت. نکتهٔ پایانی
    من معتقدم هر ابزار و زبان‌های برنامه‌نویسی جایگاه و شرایط استفادهٔ خودشان را شامل می‌شوند، دقیقاً مانند ابزار‌های موجود در یک جعبه‌ابزار بهتر است ابزار‌های خود را طوری بچینید که در جای لازم از مناسب‌ترین آن‌ها استفاده کنید. با این حال زبان‌ها و ابزار‌های مانند سی‌ یا سی++ طی سال‌ها ثابت کرده‌اند که معمولاً در همهٔ حوزه‌ها غالب هستند و می‌تواند هر کاری را که بخواهید با آن‌ها انجام دهید و یا با یک جایگرین مناسب آن را مدیریت کنید و این بستگی به مهارت و انتخاب شخصی شما دارد.
    همچنین صحبت‌های اخیر کمیتهٔ استاندارد‌سازی در رابطه با نحو ۲ از سی‌پلاس‌پلاس می‌تواند مفهوم خوبی در آیندهٔ این زبان باشد.
    مقالات مرتبط با این موضوع که می‌تواند به عنوان مکملی از پیش تعریف شده برای شما مفید باشد:
     
  11. کامبیز اسدزاده
    ما ایرانی‌ها به خصوص توسعه‌دهنده‌ها در حوزهٔ فناوری همیشه با مشکلاتی دست و پنجه نرم می‌کنیم، قطعاً می‌توان در این باره توضیحات بسیار جامعی ارائه کرد، اما یکی از این مسائل بحث محدودیت‌های شدید در پرداخت به شیوهٔ ارزی و بین‌المللی است و به همین خاطر به سختی می‌شود به مشتریان خارج از کشور خدمات ارائه و هزینه‌ای در قبال آن دریافت کرد بنابراین، معمولاً دسترسی به ارائهٔ خدمات در خارج از کشور امکان‌پذیر نیست.
    با تفکرِ به این که، روزی خواهد رسید درگاه‌های پرداختیِ فعلی به شیوه‌های کاملاً مردمی بدون در نظر گرفتن موقعیت، قومیت و سیاست‌های خارجی در اختیار همگان قرار خواهند گرفت و این یعنی آزادی در دنیای تجارت، به گونه‌ای که با اهداف و شعار این بستر و ارز‌های دیجیتالی هم‌خوانی داشته و به نظر می‌رسد پیش‌بینی‌ها در رابطه با شکل و قالب پول‌های نسل جدید واقعاً به این سمت سوق پیدا کند.
    این تفکر اگر به واقعیت تبدیل بشه فشار‌های کاری در این حوزه به شدت کاهش پیدا خواهد کرد و ما می‌تونیم شاهد این باشیم که برای دریافت خدمات می‌تونیم بدون محدودیت‌های مربوط به بحث سیاسی و تحریم‌ها، آن‌ها را در اختیار داشته باشیم و این خبر خوبی هست برای من، شما و هر کسی که در زمینهٔ فناوری و علم مرتبط با آن در حال پیشرفت است.
    بایننس، یکی از بزرگترین صرافی‌های دنیا، ساعاتی پیش در حاشیه رویداد «هفته بلاک چین بایننس» اعلام کرد که روز جمعه نسخه بتای درگاه پرداخت مخصوص خود با نام بایننس پی (Binance Pay) را راه‌اندازی کرده است. این درگاه به کسب‌وکارهای مختلف امکان می‌دهد تا بدون نگرانی از نوسانات قیمت ارزهای دیجیتال، محصولات خود را با این ارزها بفروشند.

    به گزارش دیکریپت، این اقدام بایننس نشان می‌دهد که این صرافی قصد دارد تا کسب‌وکار خود را فراتر از خریدوفروش ارزهای دیجیتال پیش ببرد و در نظر دارد تا مردم را به استفاده بیش از پیش از ارزهای دیجیتال سوق دهد. گفته می‌شود که بایننس پی پاسخ این صرافی به پی پل است.
    بایننس در اطلاعیه خود می‌نویسد:
    چانگ‌پنگ ژائو (Changpeng Zhao)،‌ مدیرعامل این صرفی، در رویداد هفته بلاک چین بایننس گفت:
    به‌گفته ژائو، مهمترین چالش بر سر راه این سیستم، استفاده کسب‌وکارها از ارزهایی است که اکثریت مردم از آنها استفاده نمی‌کنند. او معتقد است که پذیرش ارزهای رایج به‌مراتب راحت‌تر است؛ چراکه مردم مدام از آنها استفاده می‌کنند.
    سیستم تازه بایننس به کاربران این امکان را می‌دهد که پرداخت خود را با ارزهای دیجیتال انجام دهند. از سوی دیگر، کسب‌وکارها استیبل کوین‌هایی با پشتوانه ارزهای رایج دریافت می‌کنند و می‌توانند هر لحظه که بخواهند آنها را به ارز رایج تبدیل کنند. صد البته در حال تنها ارز رایج پشتیبانی‌شده در سیستم پرداخت بایننس یورو است. ژائو در این باره گفت:
    طبق اعلام بایننس، بایننس پی سبدی از محصولات است. از جمله محصولات دیگری که در این سبد قرار دارد بایننس کارت است. بایننس کارت یک کارت اعتباری است که به کاربران امکان خرید لحظه‌ای را می‌دهد. سیستم بایننس پی هم مانند بایننس کارت از ۵ ارز دیجیتال بیت کوین، اتریوم، بایننس کوین، استیبل کوین BUSD‌ و سوایپ (SXP) پشتیبانی می‌کند. بایننس سال گذشته شرکت سوایپ را خرید.
    بر خلاف بایننس کارت، در خدمات بایننس پی خبری از کارت‌های فیزیکی نیست و تراکنش‌ها با استفاده از اسکنر کیوآرکد در داخل اپلیکیشن انجام می‌شود. چانگ‌پنگ ژائو در ارتباط با راه‌اندازی بی سر و صدای سرویس بایننس پی گفت:
    منابع
    آی‌او‌استریم  ارز‌ دیجیتال
  12. کامبیز اسدزاده
    این چشم‌انداز احتمالاً برای دوست‌‌داران کتابخانهٔ قدرتمند Qt و طرفدارانش جذاب باشد! بنابراین من سعی کرده‌ام تا نتایج پست رسمی کیوت را در رابطه با چشم‌انداز فنی برای آیندهٔ کیوت نسخهٔ ۶ است در اختیار شما قرار دهم. تقریباً ۷ سال پیش کیوت نسخهٔ ۵.۰ منتشر شد! از آن زمان بسیاری از چیز‌ها در دنیای اطراف ما تغییر پیدا کرده است. و اکنون وقت آن رسیده است که چشم‌انداز جدیدی را از نسخهٔ جدید‌تر تعریف کنیم. بنابراین در این پست ما به معرفی مهمترین مواردی که به کیوت ۶ مرتبط است را می‌پردازیم.

    به نقل از مدیر فنی کیوت Lars Knoll، کیوت ۶ دقیقاً ادامهٔ کارهایی است که در نسخهٔ ۵ انجام داده شده است. بنابراین توسعه باید به گونه‌ای باشد که کاربران نباید اذیت شوند. اما نسخهٔ جدید می‌تواند یک آزادی بالاتر را در اجرای ویژگی‌های جدید، عملکرد و پشتیبانی بهتر از شرایط امروز و فردا از آنچه در حال حاضر می‌توان در سری ۵ داشته باشیم را به ما خواهد داد. همانطور که جزئیات بیشتر در زیر شرح داده شده است، کیوت ۶ هدف زیادی از سازگاری با نسخهٔ قبلی خود یعنی کیوت ۵ را خواهد داشت. همچنین ما در حال توسعه روی نسخهٔ ۵ نیز هستیم که قصد داریم برخی از ویژگی‌های کیوت ۶ را در نسخه‌های کیوت ۵.۱۴ و کیوت ۵.۱۵ LTS معرفی کنیم.
    بنابراین با ثابت نگه‌داشتن ویژگی‌ها در کیوت ۵.۱۴، بیشترِ تمرکزِ تحقیق و توسعه به سمت کیوت ۶ تغییر خواهد یافت. بنابراین انتظار می‌رود کیوت ۶ تا پایان سال ۲۰۲۰ آماده شود. قبل از اینکه همه به چیز‌های جدید بپردازیم، بیایید برخی از ارزش‌های پایه از هستهٔ اصلی کیوت را برای کاربران خود یادآوری کنیم تا چیز‌هایی که نمی‌خواهیم تغییر کنند را تعریف کنیم.
    چه چیزی Qt را برای کاربران ما ارزشمند می‌کند؟
    کیوت محصولی است که در بازار‌های مختلفی مورد استفاده قرار می‌گیرد، ارزش‌های اصلی در هستهٔ کیوت برای مشتریان و کاربران ما عبارتند از:
    ماهیت چند-سکویی آن، به کاربران این امکان را می‌دهد تا برنامه‌های خود را با استفاده از این فناوری به تمامی سیستم‌عامل‌های رو میزی، موبایل و سیستم‌های تعبیه شده (اِمبِد‌ها) مستقر کنند. مقایس پذیری آن از دستگاه‌های کم مصرف و یک منظوره تا برنامه‌های دسکتاپ پیچیده و یا سیستم‌های متصل شده. رابط‌های برنامه‌نویسی و ابزار‌ها و مستندات در سطح جهانی، ایجاد برنامه‌ها را ساده‌تر می‌کند. حفظ، ثبات (پایداری) و سازگاری، امکان حفظ بانک بزرگی از کد‌ها با حداقل تلاش برای نگه‌داری آن‌ها. یک اکو سیستم بزرگ توسعه‌دهنده با بیش از ۱ میلیون کاربر. یک نسخهٔ جدید از کیوت باید خواسته‌های محصول ما را مطابق با نیاز‌های بازار تنظیم کند، و در عین حال پنج ویژگیِ بالا را به خوبی حفظ کند. بازار دسکتاپ، ریشهٔ پیشنهادات و یک بازار قوی و مهم برای کیوت است؛ در این مرحله است که بیشترین تماس‌ها با ما و در انجمن‌های کیوت از طرف کاربران صورت می‌گیرد که باید سالم نگه‌ داشتن و رشد آن مهم باشد. بزرگترین بخش از رشد کیوت نیز مربوط به دستگاه‌های تعبیه شده و متصل شده می‌باشد؛ صفحات نمایش لمسی به تعداد تصاعدی در حال افزایش است که در کنار آن افزایش قیمت سخت‌افزار برای این دستگاه‌ها وجود دارد. چیپست‌های کم مصرف، میکرو‌کنترلر‌ها، همراه با صفحه نمایش لمسی به اندازه‌های کوچک در همه جا استفاده می‌شوند.
    بسیاری از این دستگاه‌ها عملکردی نسبتاً ساده‌ای دارند، اما به رابط کاربری صیقلی و صافی نیاز دارند. بنابراین حجم زیادی از این دستگاه‌ها ایجاد می‌شود و ما باید اطمینان حاصل کنیم که می‌توانیم با ارائهٔ خود آن فضا را هدف قرار دهیم تا بتوانیم قوبل مقیاس پذیری خود را عملی کنیم.
    در عین حال، رابط‌های کاربری در طیف دستگاه‌‌ها همچنان به افزایش پیچیدگی ادامه می‌دهند که شامل هزاران صفحه مختلف و برنامه‌های بسیاری است. ادغام عناصر سه بعدی و دو بعدی در یک رابط کاربری مشترک خواهد بود که در کنار آن استفاده از واقعیت افزوده و مجازی نیز وجود خواهد داشت.
    عناصر هوش مصنوعی بیشتر در حوزهٔ برنامه‌ها و دستگاه‌ها مورد استفاده قرار می‌گیرد و ما نیاز به روش‌های آنسان برای ادغام با آن‌ها داریم.
    رشد شدید تعداد دستگاه‌های متصل به هم و همچنین الزامات بسیار بالاتر در تجربه‌کاربر باعث می‌شود تا برای ساده سازی ایجاد برنامه‌ها و دستگاه‌ها، روی ابزار‌های کلاس جهانی تمرکز کنیم. هماهنگ سازی و ادغام طراحان UX در گردش کار توسعه یکی از اهداف است؛ اما بسیاری از زمینه‌های دیگر وجود خواهد داشت که ما باید برای ساده سازی زندگی کاربران تلاش کنیم.
    کیوت ۶ یک نسخهٔ اصلی و جدید برای Qt خواهد بود؛ هدف اصلی با چنین نسخهٔ اصلی و جدید، آماده سازی کیوت برای شرایط مورد نیاز در سال ۲۰۲۰ و بعد از آن، تمیز کردن کد‌های پایهٔ ما و حفظ آسان‌تر است. به همین ترتیب تمرکز روی آن مواردی خواهد بود که نیاز به تغییرات معماری در کیوت دارند و بدون شکستن برخی از سازگاری‌ها با سری‌های کیوت ۵ قابل انجام نیست.
    در زیر برخی از تغییرات اساسی که ما باید در کیوت ایجاد کنیم برای مناسب‌تر کردن آن برای سال‌های آینده ارائه شده است.
    نسل بعدی کیو‌اِم‌اِل (QML)
    زبان QML و فناوری Qt Quick فناوری‌های اصلی رشد سال‌های گذشتهٔ ما بوده است. روش‌های بصری ایجاد واسط‌های کاربری با استفاده از آن فناوری‌ها نقطه فروش بی نظیری از پیشنهاد ما است. اما QML، همانطور که برای کیوت ۵ ایجاد شده است، دارای تعداد زیادی تغییرات ناگهانی و محدودیت است. این به نوبهٔ خود به این معنا است که، امکان پیشرفت‌های چشم‌گیری وجود دارد که ما قصد داریم با کیوت ۶ آن‌ها را پیاده سازی کنیم.
    معرفی وابستگی زیاد به نوع (strong typing)، وابستگی کم به نوع (weak typing) امکان ایجاد تغییر در کدها را برای کاربران ما سخت می‌کند. سیستمی از مدل وابستگی زیاد به نوع امکان پشتیبانی از این تغییرات را در محیط‌های یکپارچهٔ توسعهٔ نرم افزار و سایر ابزارها به کاربران می‌دهد و به طور چشمگیری حفظ و نگهداری از آن‌ها را راحت می‌کند. همچنین، قادر به تولید کدهای اجرایی هرچه بهتر و با سربار کمتر خواهیم بود.
    اعمال JavaScript به عنوان یک ویژگی اختیاری، با توجه به این موضوع، داشتن یک موتور کامل جاوا اسکریپت هنگام استفاده از QML می‌تواند مشکلات را پیچیده‌تر کند و به خصوص هنگام هدف قرار دادن سخت‌افزار کم مصرف مانند میکرو کنترلرها یک مشکل اصلی محسوب می‌شود. اما در بسیاری از موارد استفاده از آن بسیار مفید است.
    حذف نسخه سازی QML، با ساده کردن برخی از قوانین بررسی و جستجو و تغییرات در برخی از خواص می‌توانیم نیاز به نسخه را در QML حذف کنیم. این به نوبهٔ خود منجر به ساده سازی‌های زیاد در موتور کیو‌ام‌اِل می‌شود. حجم کار در حفظ فناوری کیوت کوئیک و ساده‌تر کردن استفاده از QML و Qt Quick را برای کاربران بسیار ساده‌تر خواهد کرد.
    حذف ساختار داده‌های تکراری بین QObject و QML
    در حال حاضر،  برخی از ساختار داده‌ها بین meta-object و QML  کپی و تکرار می‌شوند و عملکرد (کارایی و پرفرمنس) را در استارتاپ برنامه کاهش می‌دهد و باعث افزایش مصرف حافظه نیز می‌گردد. بنابراین با متحد کردن ساختار‌های داده‌ها، ما قادر خواهیم بود بخشی اعظمی از آن را حذف کنیم.
    خودداری کردن از ساختار‌های داده تولید شده
    این مربوط به نکتهٔ قبل است، جایی که در حال حاضر بسیاری از ساختار‌های داده تکراری در زمان اجرا تولید می‌شوند. باید تولید اکثر آن‌ها در زمان کامپایل کاملاً امکان‌پذیر باشد.
    پشتیبانی از کامپایل QML برای بهره‌وری از کد‌های بومی C++، با وابستگی زیاد به نوع و قوانین جستجوی ساده‌تر، می‌توانیم QML را به کد‌های بومی C++ تبدیل کنیم که نتیجهٔ آن به طور قابل توجهی عملکرد زمان اجرا را افزایش می‌دهد.
    پشتیبانی از پنهان کردن جزئیات اجرا، روش و خصوصیات «خصوصی» یک نیاز طولانی مدت است تا بتوانید داده‌ها و عملکرد‌ها را در اجزای QML پنهاد کنید.
    هماهنگ‌سازی و ادغام بهتر ابزار‌ها، مدل کد‌های ما غالباً برای QML ناقص است و باعث می‌شود که تغییر مکان و خطاها را در زمان کامپایل غیر ممکن کند. با تغییرات فوق، می‌توان تشخیص کامپایلر را ارائه داد که بتواند با C++ و همچنین پشتیبانی از آن پالایشِ کد‌ها را بهبود بخشد.
    نسل بعدی گرافیک‌ها
    بسیاری از موارد در حوزهٔ گرافیک در نسخهٔ کیوت ۵ تغییر یافته‌اند. این باعث می‌شود که برای حفظ رقابت و توسعه در پُشته انجام شود. با کیوت ۵، ما از رابط‌های برنامه‌نویسی OpenGL را برای گرافیک‌های ۳ بعدی استفاده کردیم. از آن زمان به بعد، میزبانی از رابط‌‌های برنامه‌نویسی جدید نیز تعریف شده است. بنابراین وُلکان (Vulkan) جانشین مشخصی برای OpenGL در لینوکس است، اپل نیز مِتال (Metal) را تحت فشار قرار داد تا آن را جایگزین کند و مایکروسافت DirectX را دارد. این بدان معنی است که کیوت در آینده مجبور است به صورت یکپارچه با تمام رابط‌های برنامه‌نویسی کار کند. برای اینکه این ویژگی امکان‌پذیر باشد، باید یک لایهٔ جدید که رابط‌های برنامه‌نویسی گرافیکی را انتزاع می‌کند مانند (QPA برای ادغام سکو) به نام رابط سخت‌افزاری RHering تعریف شود. ما نیز باید زیر ساخت‌های ارائه شدهٔ خود (Qt Quick Scenegraph، QPainter و پشتیبانی ۳ بعدی) را در بالای آن لایه قرار دهیم.
    مجموعهٔ رابط‌های برنامه‌نویسی گرافیکی مختلف باعث می‌شود که ما از زبان‌های مختلف سایه‌زنی پشتیبانی کنیم. ابزار Qt Shader به عنوان یک ماژول به ما کمک می‌کند تا سیستمِ سایه‌زنی را به صورت هم‌زمان (کراس‌-کامپایل) و در زمان اجرا کامپایل کنیم. بحث ۳ بعدی نقش مهم و مهمتری را ایفا می‌کند، و پشتیبانی فعلی ما یک راه حل یکپارچه برای ایجاد رابط کاربری (UI) ‌هایی که حاوی هر دو عنصر ۲ و ۳ بعدی باشد را ندارد. ادغام QML با محتوا از Qt3D و یا Qt 3D Studio در حال حاضر کار دشواری است و باعث سر‌ریز شدن برخی از کارایی‌ها و عناصر نمایشی می‌شود. علاوه بر این همگام سازی انیمیشن‌ها و انتقال‌ها بر روی یک فریم با سطح فریم بین محتوای ۲ و ۳ بعدی غیر ممکن است.
    ادغام جدید محتوای ۳ بعدی با فناوری کیوت کوئیک با هدف حل این مشکل ایجاد شده است. در این حالت، یک سیستم ساخت (رندر) کامل و جدید به شما امکان می‌دهد تا محتوای ۲ و ۳ بعدی را با هم ظبط کنید. با این کار QML به زبان UI تعریف و تبدیل می‌شود که سه بعدی هستند و نیاز به فرمت UIP برطرف می‌شود. ما یک پیش‌نمایش از کیوت کوئیک جدید با پشتیبانی سه بعدی در حال حاضر با کیوت ۵.۱۴ ارائه می‌دهیم که اطلاعات بیشتر در یک پست جداگانه ارائه خواهد شد.
    سرانجام پشتهٔ گرافیکی جدید نیاز به پشتیبانی از خط لولهٔ برای چیز‌های گرافیکی هستند که این امکان را می‌دهد تا آن‌هایی که در زمان کامپایل برای سخت افزار مورد نظر تهیه شده‌اند آماده کرده و از موارد مورد نظر استفاده کند. برای مثال، فایل‌های PNG را به بافت‌های فشرده تبدیل می‌کند و بسیاری از آن‌ها را به بافت (Texture) تبدیل کند. سایه‌ها و مِش‌ها را به قالب‌های باینری بهینه شده و موارد دیگر تبدیل خواهد کرد.
    همچنین هدف ما این است که یک موتور متحد برای پوسته/ظاهر در کیوت ۶ ارائه دهیم که به ما این امکان را می‌دهد تا از نظر ظاهری و احساسات بر روی دسکتاپ و موبایل آن را بر روی هر دو فناوری کیوت‌ ویجت و کیوت‌ کوئیک ارائه کنیم.
    ابزار یکپارچه و سازگار
    ابزار‌های گرافیکی ما برای ساخت رابط‌های کاربری به دو بخش با استودیو کیوت ۳ بعدی (Qt 3D Studio) و استودیو طراحی کیوت (Qt Design Studio) تقسیم بندی شده‌اند. علاوه بر آن، استودیو ۳ بعدی اند;ی از بقیه کیوت جدا شده است که باعث می‌شود کمی بیشتر سعی بر آن شود!
    ابزار‌های طراحی نیز به ایجاد محتوا مانند، محتوای ساخته شده در Photoshop، Sketch، Illustrator، Maya، 3DsMax و دیگر موارد ادغام شده است. ابزار‌های توسعه به توجه زیادی برای تمرکز دارد تا بتوانیم بهترین‌ها را در پشتیبانی کلاس برای QML، C++ و پایتون ارائه دهیم. یک ابزار متحد و یکپارچه این اجازه را می‌دهد که یک طراح UX بتواند از قابلیت‌های طراحی در کیوت کریتور استفاده کند و طراحان می‌توانند از ویژگی‌های ابزار‌های توسعه‌دهنده مانند تهیه یک پروژه یا آزمایش روی یک دستگاه بهره‌مند شوند.
    ابزار ساخت QMake به عنوان ابزار ساخت در کیوت ۵ مورد استفاده قرار می‌گیرد که تعداد زیادی تغییرات ناگهانی و محدودیت‌ها خواهد دارد. برای کیوت ۶، هدف ما این است که CMake را به عنوان سیستم ساخت ثالث و استاندارد برای ساخت خود کیوت استفاده کنیم. چرا که سی‌میک تاکنون پرکاربرد‌ترین سیستم ساخت در جهان برای سی‌پلاس‌پلاس بوده است و ادغام هرچه‌بهتر آن کاملاً مورد نیاز است. البته پشتیبانی از QMake ادامه خواهد داشت، اما آن را توسعه نخواهیم داد یا از آن برای ساخت فریم‌ورک کیوت استفاده نخواهیم کرد.
    بهبود رابط‌های برنامه‌نویسیC++
    سی‌پلاس‌پلاس طی سال‌های گذشته تغییرات بسیار زیادی کرده است؛ در حالی که ما مجبور بودیم کیوت ۵.۰ را روی سی‌پلاس‌پلاس ۹۸ پایه‌گذاری کنیم. اما اکنون می‌توانیم به سی‌پلاس‌پلاس ۱۷ برای پایه‌گذاری کیوت ۶ اطمینان کنیم. این بدان معنی است که C++ عملکرد بسیار بیشتری را نسبت به زمان توسعه و اجرای کیوت ۵ که در دسترس نبود ارائه خواهد کرد. هدف ما با کیوت ۶ بهتر شدن با یکپارچه‌سازی و ادغام قابلیت‌ها  بدون از دست دادن پشتیبانی و سازگاری از روش‌های پیشین (رو به عقب یا همان backward compatibility) است.
    برای کیوت ۶، هدف ما این است که برخی از قابلیت‌های معرفی شده با QML و فناوری Qt Quick را از طرف C++ در دسترس قرار دهیم. بنابراین ما در تلاش برای معرفی یک سیستم خاص برای QObject و کلاس‌های مرتبط هستیم. موتور اتصال دهنده را از QML در هستهٔ کیوت ادغام می‌کنیم و آن را از سی‌پلاس‌پلاس در دسترس قرار می‌دهیم. این سیستم خاص از موتور اتصال به کاهش قابل توجهی در سربار زمان کار و مصرفه حافظه در اتصال منجر می‌شود و آن‌ها را برای همهٔ قسمت‌های Qt، نه تنها Qt Quick قابل دسترس می‌کند.
    پشتیبانی از زبان
    با کیوت ۵.۱۲، پشتیبانی از پایتون معرفی شده است. همچنین مرورگر را به عنوان پلتفرم جدید از طریق کیوت برای وِب اسمبلی اضافه کرده‌ایم. پس از انتشار کیوت ۶.۰ نگه‌داشتن و گسترش بیشتر بر روی سطح چند‌-سکویی بخش مهمی از اهداف و مسیر توسعهٔ سری‌های کیوت ۶ خواهد بود.
    سازگاری با کیوت ۵ و افزایش سازگاری‌ها و بهبود‌ها
    سازگاری با نسخه‌های قدیمی‌تر بسیار مهم است، بنابراین وقتی کیوت ۶ را توسعه می‌دهیم یک نیاز اساسی محسوب می‌شود. توسط چهارچوب کیوت میلیون‌ها خط کد نوشته شده است و هرگونه تغییرات در ناسازگاری که انجام شود هزینه‌ای را برای کاربران خواهد داشت. علاوه‌ بر این، کار بیشتری برای تغییرات در کیوت ۶ نیاز است تا کاربران کم کم با آن سازگار شوند که منجر به هزینه‌های بیشتر از طرف تیم توسعهٔ کیوت برای حفظ آخرین نسخه کیوت ۵ خواهد بود.
    به این ترتیب، ما باید به فکر جلوگیری از ساطع شدن خطاهای احتمالی در زمان کامپایل و یا زمان اجرا برای کاربران می‌شود باشیم. در حالی که ما نیاز به حذف بخش‌هایی از کیوت خواهیم داشت، باید اطمینان حاصل کنیم که کاربران ما از عملکرد مورد نیاز خود برخوردار هستند. این بدان معنا است که کلید‌هایی مانند Qt Widgets و سایر قسمت‌هایی که توسط بخش بزرگی از کاربران ما مورد استفاده قرار می‌گیرد، در دسترس باشد.
    ما در حال برنامه‌ریزی برای افزایش بسیاری از پیشرفت‌ها در کلاس‌های اصلی و عملکردی هستیم که در سری کیوت ۵ نتوانستیم انجام دهیم. هدف این است که سازگاری کامل منبع را حفظ کنیم، اما از آنجا که می‌توانیم سازگاری باینری را با کیوت ۶ بشکنیم، می‌توانیم پاک‌سازی‌ها و اصطلاحات کاملاً زیادی را انجام دهیم که در کیوت ۵ نمی‌توانستیم آن را عملی کنیم.
    با این وجود، ما باید به جلو پیش برویم و برخی از پاک‌سازی‌ها که در کیوت ۵ در مورد کلاس‌ها، توابع و یا ماژول‌ها عنوان شده بود را در کیوت ۶ به طور کامل اعمال کنیم. این کار باعث می‌شود ما روی مبنای کد‌گذاری شدهٔ فعلی تمرکز بیشتر و بهتری داشته باشیم.
    با این حال، انتقال به دور از قسمت‌های منسوخ شده باید تا حد امکان ساده باشد و کاربران ما می‌توانند با استفاده از کیوت ۵.۱۵ «پشتیبانی بلند مدت» به صورت ایده‌آل این کار را انجام دهند. هدف ما باید این باشد که کیوت ۶ به اندازهٔ کافی با نسخهٔ ۵.۱۵ سازگار باشد تا فرد بتواند به راحتی یک بخش اعظمی از کد خود را حفظ کند، به طوری که کد آن در هر دو نسخهٔ ۵ و ۶ قابل کامپایل باشد.
    بازار و ساختار فنی محصول
    علاوه بر بهبود چهارچوب و ابزار‌های کیوت، هدف ما ایجاد بازار جدیدی برای قطعات و ابزار‌های توسعه است. این بازار بر روی کاربران مستقیم ما متمرکز خواهد شد که برنامه‌های کاربردی و دستگاه‌های تعبیه شده را طراحی و توسعه می‌دهند؛ به این ترتیب این یک مرکز تجمع اصلی برای اکو سیستم کیوت خواهد بود که این امکان را به شخص ثالث می‌دهد تا نسخه‌های اضافی خود را در کیوت منتشر کنند و هم محتوای رایگان و تجاری را که برای آن هزینه پرداخت می‌کنند.
    کیوت طی سال‌های گذشته رشد بسیار زیادی داشته است، تا جایی که ارائهٔ نسخهٔ جدید آن یک کار مهم است. با استفاده از کیوت ۶ فرصتی برای باز‌سازی محصولات ارائه شده ما وجود دارد و یک محصول اصلی و کوچکتر که شامل چهارچوب‌ها و ابزار‌های اساسی است. ما از بازار استفاده خواهیم کرد تا چهارچوب و ابزار‌های اضافی خود را ارائه دهیم، نه به عنوان یک بسته‌نرم‌افزاری وابسته به کیوت!
    چشم‌انداز فنی تا اولین نسخهٔ کیوت ۶ تکامی خواهد یافت. اگرچه معتقد هستیم که این سند بسیاری از مهمترین نکات را برای نسخهٔ بعدی کیوت معرفی می‌کند اما مطمئناً کامل نیست. اگر شما هم ایدهٔ دیگری دارید می‌توانید آن را با ما در میان بگذارید.
  13. کامبیز اسدزاده
    خالق لینوکس از اینتل به خاطر پشتیبانی نکردن از حافظه‌های ECC انتقاد کرده است. او به پشتیبانی غیررسمی از ECC در پردازنده‌های AMD به‌عنوان اتفاقی مثبت نگاه می‌کند. این ماجرا برای توسعه‌دهدنگان قطعاً بسیار مهم و کاربردی است، بنابراین به عنوان نماینده‌ای از جامعهٔ برنامه‌نویسان و یک فرد با تجربه در بحث برنامه‌نویسی و مشکلات آن در مدیریت حافظه نظرات توروالدز برای جامعهٔ ما اهمیت دارد.

    لینوس توروالدز، خالق لینوکس، به‌تازگی پست جدیدی در انجمن آنلاین Real World Tech با محوریت حافظهٔ کد تصحیح خطا (ECC) منتشر کرده است تا از اینتل انتقاد و از ای‌ام‌دی (AMD) تمجید کند. بر اساس گزارش تامز هاردور، توروالدز می‌گوید اینتل باید حافظه‌های ECC را به قطعاتی مین‌استریم تبدیل کند و پشتیبانی از این حافظه در پردازنده‌های سری رایزن ای‌ام‌دی اتفاق بسیار خوبی است.
    توروالدز با بیان اینکه «ECC کاملا پراهمیت است» اعلام کرد اینتل تأثیر به‌سزایی روی رونق نداشتن بازار حافظه‌ی ECC گذاشته است. خالق لینوکس می‌گوید: «بروید و به‌دنبال DIMM-های ECC بگردید؛ پیدا کردن آن‌ها واقعا سخت است. بله، احتمالا به لطف ای‌ام‌دی، وضعیت DIMM-های ECC اخیرا کمی بهتر شده و این دقیقا همان نکته‌ای است که می‌خواهم به آن اشاره کنم.»
    توروالدز بارها به ضررهایی که اینتل به صنعت ECC و حتی کاربران وارد کرده است اشاره می‌کند و صحبت‌هایش را با کلماتی توهین‌آمیز خطاب ‌به اینتل ادامه می‌دهد. توروالدز می‌گوید تیم آبی با پشتیبانی نکردن از ECC در مادربردها و پردازنده‌هایی که برای کاربران عادی عرضه می‌کند، باعث شده است استفاده از حافظه‌های ECC زیاد نباشد.
    خالق لینوکس به مشکلاتی با محوریت آسیب‌پذیری روهمر (Rowhammer) اشاره می‌کند و می‌گوید این دسته از مشکلات امنیتی جدی، از طریق حافظه‌های ECC به‌راحتی رفع می‌شوند. سلول‌های حافظه‌ی DRAM می‌توانند انرژی خود را به دیگر سلول‌های حافظه منتقل کنند. به‌طور معمول این اتفاق صرفا به خاطر نقص در حافظهٔ اصلی سیستم رخ می‌دهد و نهایتاً به بروز خطا در حافظه منتهی می‌شود؛ اما حملات مبتنی بر آسیب‌پذیری روهمر از این نقص به‌عنوان مکانیسمی برای دسترسی به سیستم بهره می‌گیرند. 
    توروالدز می‌گوید هنگام توسعه دادن کد برای کرنل سیستم‌ عامل، دست‌و‌پنجه نرم کردن با حافظهٔ استاندارد بسیار سخت است. او به‌طور دقیق‌تر به این موضوع اشاره می‌کند که در اکثر اوقات نمی‌توان به‌طور دقیق فهمید خطای غیر قابل توضیح کرنل در کجا رخ داده است. در واقع این خطاها در اغلب اوقات ممکن است سخت‌افزاری باشند، نه نرم‌افزاری؛ خطاهایی که به‌راحتی توسط ECC قابل رفع هستند.
    توروالدز از ای‌ام‌دی به خاطر پشتیبانی غیررسمی از ECC تمجید می‌کند. او خوشحال است که ای‌ام‌دی تصمیم گرفته این پشتیبانی را به پردازنده‌های سری رایزن که در دسترس مشتریان عادی قرار می‌گیرند گسترش دهد. بدین ترتیب ای‌ام‌دی کاربران را قادر می‌سازد بدون پرداخت هزینه‌ی گزاف تهیهٔ قطعات سخت‌افزاری در سطح سرور، به ECC دسترسی داشته باشند.
    اینکه پشتیبانی غیررسمی از ECC به گسترش استفاده از آن کمک می‌کند، موضوعی است که نیاز به بحث دارد؛ زیرا در اغلب اوقات ECC به‌درستی کار نمی‌کند. اما خالق لینوکس می‌گوید حتی پشتیبانی غیررسمی، قدمی روبه‌جلو در جهت درست محسوب می‌شود.
  14. کامبیز اسدزاده
    شما برنامه نویس هستید یا توسعه‌دهنده؟ آیا تا به حال فکر کرده‌اید که چه نوع عنوانی متناسب با مهارت‌های شماست؟
    من یک (توسعه دهنده فول-استک هستم)
    من یک (برنامه‌نویس هستم)
    من یک (توسعه‌دهندهٔ وب هستم)
    من یک (توسعه‌دهندهٔ فرانت اند هستم)
    من یک (توسعه دهندهٔ iOS هستم)
    و عناوین بسیار زیاد من در آوردی دیگر که ممکن است منظور دقیق از مهارت‌های شما را به درستی مطرح نکنند!
    من می‌خوام در رابطه با اصطلاحاتی صحبت کنم که شاید بسیاری از علاقه‌مندان از استفادهٔ به جا از آن‌ها بی‌خبر هستند. داستان این مقاله از اینجا شروع می‌شه که امروزه عناوین متعددی در رشتهٔ مهندسی کامپیوتر به خصوص گرایش نرم‌افزار و (برنامه‌نویسی) به چشم می‌خوره که ممکنه باعث سردرگمی بشه. نکته اصلی اینجاست که ما به عنوان صاحب عنوان تخصصی خود باید بدانیم که دارای چه مهارت‌هایی هستیم و در دنیای فناوری تحت چه عنوانی باید خود را در زمینه تخصصی معرفی کنیم. 

    تفاوت بین کدنویس، برنامه‌نویس و توسعه‌دهنده
    در این پست قصد داریم با اصطلاحاتی آشنا شویم که ممکن برای اکثر افراد غیرمتخصص و گاه متخصص نیز سوال باشد که این عنوان‌ها (کدنویس، برنامه نویس و توسعه‌دهنده) به چه کسانی با چه تخصص‌های گفته می‌شود. ما به عنوان صاحب “عنوان تخصص” خود باید بدانیم که دارای چه مهارت‌هایی هستیم و در دنیای فناوری تحت چه عنوانی باید خود را در زمینه تخصصی معرفی کنیم.
    در این مقاله تصمیم گرفتم تفاوت‌های بین کدنویس (Coder)، برنامه‌نویس (Programmer) و توسعه‌دهنده (Developer) را مشخص کنم. بنابراین به ترتیب عناوین هر یک از آن‌ها را توضیح و در رابطه با نکات مهم متمایز کنندهٔ آن‌ها اشاره خواهیم کرد.
    1.کدنویس (Coder)
    کد نویس به کسی گفته می‌شود که می‌تواند بدون داشتن مهارت خاص یا حتی رشته مرتبط کدنویسی کند و نیاز به دانش تخصصی و واقعی علوم کامپیوتری ندارد. معمولاً کسانی که دارای تخصص دیگری هستند اما آشنا به منطق برنامه‌نویسی نیستند کُدِر می‌گویند. برای مثال تغییر دادن و یا ویرایش کد‌های از قبل نوشته شده و حتی ایجاد نمونه‌ای از کدهایی موجود به صورت (کپی) که می‌تواند نتیجه‌ای به صورت کار بر روی یک سیستم نرم‌افزاری بر روی وب مانند WordPress یا غیره شود که با کمی تغییرات بر اساس نیاز پروژه خود را به صورت نه چندان حرفه‌ای ایجاد و توسعه نمایند. اصطلاح درست این نوع اشخاص کُدر می‌باشد.
    2.برنامه‌نویس (Programmer)
    برنامه‌نویس به کسی گفته می‌شود که توانایی و تخصص مرتبط با برنامه‌نویسی و علوم کامپیوتری را دارد. به عنوان مثال یک مهندس نرم‌افزار از شاخه مهندسی کامپیوتر که با منطق برنامه نویسی آشنا است برنامه نویس محسوب می‌شود. برنامه‌نویس می‌تواند برنامه‌ای را تحت یکی از زبان‌های برنامه‌نویسی که خود آن را ترجیح می‌دهد برنامه نویسی کند. برای مثال، کلاسی را طراحی و پیاده سازی کرده و توابع مورد نیاز خود را در آن ایجاد و توسعه دهد.
    برنامه‌نویس می‌داند در کجا باید از چه نوع دستورات و توابعی استفاده کند تا کدِ نهایی او نتیجه‌ای ایجاد کند که از آن انتظار می‌رود. یک برنامه‌نویس توانایی این را دارد که کُدهای نوشته شده توسط دیگر برنامه‌نویسان را بخواند، درک کند و حتی آن‌ها را ویرایش کند.
    توجه داشته باشید که یک برنامه‌نویس توانایی کنترل و مدیریت کردن بخش‌های بسیار پیچیدهٔ یک محصول را ندارد. برای مثال اگر قرار است پروژه‌ای را طراحی و توسعه نمایید برنامه‌نویس بخش بَک-اِند توانایی مدیریت بخش فرانت-اند (رابط‌کاربری) را ندارد و برعکس! بنابراین برنامه‌نویسان تنها کُدهایی را می‌نویسند که قرار است در بخش مورد نیاز عملیاتی را انجام دهند و کاری به این ندارند که طراحی رابط‌کاربری تحت چه نوع فناوری و زبانی در حل توسعه است و یا ارتباط با پایگاه داده چگونه صورت می‌گیرد چرا که برنامه‌نویسان مرتبط با آن بخش‌ها با استفاده از مهارت های تخصصی خود در آن بخش آن را هندل خواهند کرد. برنامه‌نویسان معمولاً تیم‌های توسعه یک محصول را ایجاد می‌کنند و همگی آن‌ها وابسته یکدیگر هستند بنابراین اگر برنامه‌نویس واحد بک اند شما نتواند به موقع کدهای مورد نیاز بخش فرانت‌اند شما را آماده و تحویل دهد پروژه شما در زمان تعیین شده به نتیجه مطلوبی نخواهد رسید.
    3.توسعه دهنده (Developer)
    در رابطه با توسعه‌دهنده باید به این توجه داشته باشید که توسعه‌دهنده به تنهایی عنوان نمی‌شود. بنابراین توسعه‌دهنده به صورت‌های مختلفی وجود دارند (توسعه‌دهنده وب، توسعه‌دهندهٔ نرم‌افزار، توسعه‌دهندهٔ موبایل که در رابطه با نوع پلتفرم باز متفاوت هستند؛ توسعه دهنده رابط کاربری، توسعه‌دهندهٔ تجربه کاربری و در نهایت توسعه دهنده فول-استک).
    توسعه‌دهنده کسی است که علاوه بر برنامه‌نویس بودن مهارت و دانش کافی در لایه‌های مختلف پروژه در اختیار داشته باشد که متناسب با نوع تخصص نیز متفاوت است. توسعه‌دهنده کسی است که می‌تواند بر اساس نوع پروژه وظایف خاصی را در اختیار بگیرد به عنوان مثال اگر به صورت تیمی بر روی یک پروژه کار می‌کنید که شامل برنامه نویس هایی است که هر کدام بخشی از پروژه را برنامه‌نویسی می‌کنند کافی است یک توسعه‌دهنده داشته باشید تا تمامی کد‌های شما را آنالیز، اشکال زدائی و بررسی کند و در نهایت آن‌ها را با یکدیگر ارتباط داده و تبدیل به یک پروژه قابل استفاده نماید. چرا که توسعه‌دهنده دانش مورد نیاز در لایه‌های مختلف را دارد و می‌داند بخش‌های مختلف یک محصول نرم‌افزاری یا غیره را که چگونه است و چطور باید برنامه‌نویسی شوند به آن‌ها تسلط دارد.
    توسعه‌دهنده شخصی است که نباید فقط به یک زبان‌ یا ابزار برنامه‌نویسی اکتفا کند چرا که برای توسعه محصول حتما باید از چند زبان برنامه‌نویسی مورد نیاز در پروژه اطلاعات کاملی داشته و بتواند هر جا که نیاز بود کد‌ای مورد نیاز را توسعه و به نتیجه نهایی تبدیل کند. توجه داشته باشید که یک تیم شامل چندین توسعه دهنده به عنوان یک تیم کاملا حرفه‌ای و زبان زد محسوب می‌شوند برای مثال شرکت‌های بسیار بزرگ نه تنها برنامه‌نویسان حرفه‌ای در تیم خود استخدام می‌کنند بلکه توسعه دهندگانی را از نوع (Full-Stack) در اختیار دارند که مدیریت حساس پروژه را به عهده گرفته و پروژه را با دانشی که دارد به خوبی مدیریت می‌کند و زمانی که جایی پروژه به نکته‌ای برسد که برنامه‌نویسان توانایی حل آن را ندارند توسعه دهنده فول-استک می‌تواند با مهارت‌ها و تجربیات خود آن را حل کند. در رابطه با برنامه‌نویسان فول‌استک و ویژگی‌های این دسته از برنامه‌نویسان را در ادامه آورده شده است.
    4.توسعه دهندگان فرانت-اند (UI/UX)
    این نوع توسعه‌دهندگان برنامه‌نویسانی هستند که مهارت کاملی در رابطه با لایه‌های مختلف و چندین زبان و فناوری‌های مورد نیاز در بخش User Interface و User Experience را دارند و می‌توانند طراحی مناسبی را متناسب با نوع پروژه و تجریبات مشتری ایجاد و توسعه دهند. این نوع برنامه‌نویسان یکی از مهمترین بخش‌های توسعه‌دهندگان در تیم محسوب می‌شوند که شاید تجربیات و بازخورد‌های مشتری را به سمت این نوع توسعه دهنده ارسال کنند. این نوع توسعه دهندگان علاوه بر داشتن دانش طراحی و تجربه کاربری دانش مرتبط با روانشناسی رنگ‌ها و جلوه‌های بصری دارند که آن‌ها را می‌توانند در قالب برنامه نویسی پیاده سازی کنند.
    5.توسعه دهندگان بک-اند
    این نوع توسعه‌ دهندگان برنامه‌نویسان بسیار ماهری در بخش لایه‌های زیرین پروژه یعنی (منطقی) دارند که تمامی اطلاعات لازم را در رابطه با لایه‌های زیرین در اختیار دارند و می‌دانند چطور باید با دیتابیس ارتباط برقرار کنند، می‌دانند چطور باید با API‌های سیستم عامل کار کنند و می‌دانند کد‌های خود را بر اساس نوع ABI‌ و API‌ها چگونه باید مدیریت کنند؛ موارد بسیار زیادی که نیاز است در بخش منطقی یک پروژه ایجاد شود را به تنهایی حل و توسعه می‌دهند تا نتایج آن در اختیار توسعه دهنده فرانت اند قرار بگیرد. اما وظیفه‌ای در رابطه با طراحی تجربه‌کاربری و یا رابط کاربری نداشته و نمی‌توانند در این بخش مانور دهند. از این نوع توسعه دهندگان تنها می‌توان انتظار نوشتن کُدهای بی نقص و عالی در لایه‌های پایین را داشت.
    6.توسعه دهندگان فول-استک
    این نوع توسعه‌‌دهندگان علاوه بر داشتن مهارت‌های مربو به برنامه‌نویسی، توسعه‌دهنده در فرانت‌اند و بک‌اند نیز هستند تجربیات و مهارت‌های بسیار زیادی در شاخه‌های دیگر علوم مهندسی کامپیوتری را دارند که نکته بسیار مهمی است! رسیدن به این درجه از برنامه‌نویسی یعنی یک مهندس کامل کامپیوتر که می‌تواند در تمامی بخش‌های یک پروژه در لایه‌های مختلف نرم‌افزار، سخت‌افزار، شبکه، پلتفرم‌ها و … صاحب نظر باشند و آن را توسعه دهند. یک فول استک به تنهایی می‌تواند رهبری یک پروژه را بر عهده بگیرد و درصورتی که نیاز باشد به تنهایی یک پروژه را از صفر تا صد تولید توسعه و اجرا نماید.
    این نوع توسعه‌دهنده‌ها یک مهندس واقعی کامپیوتر (نرم‌افزار) هستند که به خوبی می‌دانند یک محصول نهایی باید تحت چه شرایطی توسعه و اجرا شود. البته به این نکته توجه کنید توسعه‌دهنده‌های فول‌استک هم می‌توانند از لحاض محدودیت دسته‌بندی شوند، بعضی از آن‌ها صرفاً در یک حوزه تسلط کافی دارند، مانند Full Stack Web Developer یا Full Stack Android Developer به معنای این است که این گونه توسعه‌دهنده‌ها می‌توانند یک محصول را در سطح وب به طور کامل طراحی و پیاده سازی کند و یا در حوزهٔ ساخت و ساز اپلیکیشن‌های اندروید یک محصول را به طور کامل طراحی و برنامه‌نویسی کند. در غیر این صورت تنها واژهٔ Full Stack Developer می‌تواند پوشش کاملی بر تسلط کامل یک فرد با تخصص‌های بسیار بالا در ساخت و ساز یک محصول در پلتفرم‌های متنوع  را بدهد که در یک پست جداگانه قبلاً به آن اشاره کرده‌ام:
    با توجه به تعاریف مرتبط با عناوین باید سعی کنیم که از اصطلاحات صحیح و عناوین مرتبط با خود استفاده کنیم چرا که در صورتی که شما یک برنامه‌نویس هستید نباید بگویید من یک توسعه‌دهندهٔ وب هستم! این کار باعث ایجاد انتظار از شما خواهد شد که به احتمال بسیار زیاد توانایی انجام آن را نخواهید داشت. حتی برعکس آن ممکن است شما یک توسعه‌دهنده باشید اما بگویید یک کُدر حرفه‌ای هستم! این واقعاً اشتباه است! در این صورت درجه تخصصی خود را به شدت تنزل داده‌اید.
    در فرصت مناسب‌تری در بارهٔ این موضوع، در قالب یک اینفوگرافیک اطلاعاتی نشر خواهم کرد.
  15. کامبیز اسدزاده
    همانطور که می‌دانید امضاء و انتشار اپلیکیشن‌های اندرویدی در قالب فایل apk به شما اجازه می‌دهد تا مستقل از فروشگاه گوگل، نرم‌افزار مورد نظر خودتان را در اختیار مشتریان خود قرار دهید؛ از طرفی ارسال آن برای فروشگاه‌های داخلی مانند کافه‌بازار نیز مراحلی را دربر دارد که یکی از آن‌ها بررسی مشکل مربوط به Google Play Protect است. با توجه به تجربیات من، خیلی از مشتری‌ها و کاربران علم کافی در توجه به پیام مربوط به آن را ندارند و نمی‌دانند با رد کردن پیغام می‌توانند نرم‌افزار را با پذیرش ریسک نصب کنند. اما این روش می‌تواند فرصتی برای کسانی باشد که به فکر سو‌ء استفاده از شرایط هستند. طبق گزارشاتی که دریافت کرده‌ایم، مشاهدهٔ پیام مربوط به عدم قابل اعتماد بودن نرم‌افزار شما و خطای نصبی بیشتر از قبل به چشم می‌خورد! برای اینکه ثابت کنید اپلیکیشن شما یک محصول قابل اعتماد است، تنها باید آن را به روش قانونیِ خودِ گوگل حل کنید که چندان سخت نیست ?
    توجه داشته باشید که، این پیام در شرایط متعددی می‌تواند رخ دهد. برای مثال، شما از خدماتی که مورد نیاز نیستند به اجبار در نرم‌افزار استفاده می‌کنید. اما حتی با اعمال تنظیمات مربوطه به نظر می‌رسد زمانی که شما یک برنامهٔ جدیدی را ایجاد و برای نشر ارسال می‌کنید باید ابتدا نسخهٔ مربوطه، به بانک اطلاعاتی موجود در Google Play Protection ارسال شود و سپس برای نصب آماده شود. بنابراین، خطای مربوط به آن را به روشی که در ادامه توضیح می‌دهیم می‌توانید حل کنید.

    قبل از هر چیز دقت کنید که نرم‌افزار شما امضاء شده باشد، در واقع از نوع نسخهٔ signed ریلیز شود. برای این کار باید حتماً یک گواهی مشخصی بسازید که همراه رمز عبور و اطلاعات توسعه‌دهنده به صورت اختصاصی برای هر محصول قابل ساخت است.
    در ادامه مهمترین موردی که باید در نظر گرفته شود این است که فایل مربوطه را باید قبل از نشر در کافه‌بازار یا تحویل آن به مشتری خود، به مرکز Play Protect Appeals ارسال کنید تا برای بررسی جهتِ تجدید نظر شدن از لحاظ گیر دادن‌های بی‌خودی به برنامه‌ٔ شما مورد بررسی قرار گیرد.
    معمولاً این کار خارج از ایران ساده‌تر است، چرا که بحث تحریم و شناسایی شناسه‌های ایرانی برای کارشناسان راحت‌تر بوده و به آن حساسیت نشان می‌دهند که ممکن است پیام زیر را دریافت کنید:
    بنابراین، توصیه می‌کنیم از روش‌های مطمئن‌تری برای ارسال فایل استفاده کنید.
    توصیهٔ ما استفاده از خدماتِ دراپ‌باکس خواهد بود که با ارسال فایل به آن و ساخت یک لینک اشتراکی می‌توانید مطمئن شوید که دسترسی به فایل شما در سراسر جهان میسر خواهد شد. اما توجه داشته باشید که لینک آن را برای سهولت در بررسی و ارسال در فیلد فرمِ آن، از طریق سایت http://bit.ly کوتاه سازید.
    دقت کنید که لینک دریافتی از دراپ‌باکس باید شامل قالبی به صورت زیر است:
    https://www.dropbox.com/s/example/app.apk?dl=0 آدرس زیر را بعد از پارامتر dl=0 به dl=1 تغییر دهید و سپس لینک مربوطه را کوتاه کرده و آن را در فرم ثبت اطلاعات نرم‌افزار برای گوگل در این لینک ارسال کنید.

    در فرم مربوطه فیلد‌های مورد نظر باید دقیقاً شامل واقعیت باشند، به عنوان مثال نام و نام‌خانوادگی توسعه‌دهنده، آدرس پست‌الکترونیکی، نام بستهٔ اپلیکیشن و لینک کوتاه شدهٔ قابل دریافت؛ در نهایت می‌توانید توضیحاتی برای آن در نظر بگیرید.
    اگر همه چیز به خوبی پیش رفته باشد پیامی مانند زیر را به همان آدرس پست‌الکترونیکی خود دریافت خواهید کرد.
    در نظر داشته باشید که این فرایند ممکن است زمان متغیری را در صف بررسی باشد که در حالت عادی و خاص ۱ الی ۳۰ روز زمان خواهد برد که من به شخصه بین حدقل ۲۴ تا ۴۸ ساعت نتیجهٔ مثبت گرفتم.
    صرفاً دقت کنید که در صورت بررسی و تأیید شدن برنامهٔ شما، هیچ پیام خاصی ارسال نخواهد شد، بنابراین تنها با بررسی و نصب برنامه می‌توانید متوجه آن شوید که برنامهٔ ارسال شدهٔ شما در لیست بانک اطلاعاتی امنیتی اپلیکیشن‌های گوگل قرار گرفته است یا خیر.
    امیدوارم که این تجربهٔ پیشنهادی برای شما نیز مفید واقع شود ?
  16. کامبیز اسدزاده
    همانطور که می‌دانید پلی‌استیشن ۵ به عنوان یک نسل جدیدی از کنسول بازی سونی معرفی شده است که رابط‌کاربری آن به شدت تغییر و بهبود یافته است.

    هر چیزی که در این محیط از پلی‌استیشن ۵ دیده می‌شود خط به خط و ریز به ریز آن، به لُطفِ کامپایلر Clang که اتفاقاً امروز هم نسخهٔ ۱۱ اون منتشر شد، و استاندارد ۱۷ از سی++ و به خصوص بحث نرم‌افزاری آن بر پایهٔ سیستم‌عامل FreeBSD ارائه شده است که متخصص‌ها در این باره خوب می‌دانند فری‌بی‌اِس‌دی به عنوان سریع‌ترین و پایدارترین نوع سیستم‌عامل‌های یونیکسی مطرح هستند.
    اگه شما کاربر عادی هستید، مثالی بزنیم تا بیشتر در جریان باشید: 
    - سیستم‌عامل macOS و iOS بر پایهٔ سیستم‌عامل یونیکس (داروین) ساخته شده‌اند.
    - سیستم‌عامل اندروید بر پایهٔ لینوکس ساخته شده‌اند.
    از طرفی سیستم‌عامل کنسول مایکروسافت اِکس‌باکس بر پایهٔ هستهٔ ویندوز ۱۰ طراحی شده و در مقابل سیستم‌عامل پلی‌استیشن ۴ و همچنین ۵ از هستهٔ یونیکس فری‌بی‌اِس‌دی استفاده کرده که حرف‌های زیادی برای گفتن دارند.
    در بحث طراحی نسبت به نسخه‌های پیشین یک بهبود اساسی داشته چون تغییرات رابط‌کاربری در زمان PS4 نسبت به PS3 چنان چشم‌گیر نبوده است! اما الآن دیگر سونی واقعاً بر روی آن کار کرده است و دیگر خبری از آن ظاهر تکراری و حوصله بر وجود ندارد!

    پلی‌استیشن ۵ رابط کاربری کاملاً بازسازی شده‌ای نسبت به پلی‌استیشن ۴ دارد که با هدف دسترسی آسان به اطلاعات طراحی شده. یکی از ویژگی‌های این رابط کاربری گرفتن آپدیت‌های زنده است که کاربران مجبور به جستجو و صبر کردن برای مشاهده فعالیت‌های دوستان خود و مشاهده فعالیت‌های در دسترس در بازی‌ها نباشند. مارک سرنی دربارهٔ این موضوع گفته‌است «ما نمی‌خواهیم یک کاربر بازی را باز کند، ببیند که چه‌خبراست، و دوباره بازی را باز کند که ببیند چه خبر است!»! این ویژگی در همان داشبورد رابط کاربری اصلی پلی‌استیشن فراهم شده است و نیازی به ورود به داخل بازی جهت بررسی خبر‌های اخیر از آن ندارد!
    همچنین دیگر مواردی مانند پشتیبانی از ویژگی عقب‌گرد (یعنی پشتیبانی از اجرای بازی‌های پی‌اس ۴) در این سیستم ارائه شده است.
    رابط کاربری پلی استیشن 5 همواره با وضوح تصویر 4K واقعی و پشتیبانی کامل از HDR به نمایش درمی‌آید. سونی تلاش زیادی کرده است که بازیکنان در کمترین زمان ممکن بتوانند برنامه یا بازی مورد نظر خود را در رابط کاربری بیابند و اجرا کنند. همه‌ی برنامه‌ها نیز حالا بخشی از UI هستند و دیگر مثلا موقع وارد شدن به پلی استیشن استور احساس نمی‌کنید که تازه یک برنامه‌ی جدید باید از ابتدا اجرا شود. از طرفی SSD بسیار سریع و پردازندهٔ مرکزی دستگاه کاری می‌کنند که رابط کاربری همواره با سرعت قابل ‌توجه و به شکل روان مقابل بازیکن قرار بگیرد.
  17. کامبیز اسدزاده
    مدتی است در مورد مسدود شدن اپلیکیشن‌های ایرانی برای iOS از طرف شرکت اپل خبر‌هایی به گوش می‌رسد که در سایت‌ها و پایگاه‌های خبری از سمت نویسندگان و افراد غیرفنی تجزیه تحلیل و روش‌های دور زدن آن‌ها ارائه می‌شود. واقعیت بر دلیل نوشتن این مقاله این است که این فرصت و مشکلات کنونی آبی گل‌آلود برای سود‌جویانی شده است که کاربران از آن بی‌خبرند! هر روز یک توسعه‌دهنده یک سایت جدید راه‌اندازی می‌کند و با ادعای ارائه بستری نامحدود اقدام به تبلیغات می‌کند. بنده نیز به عنوان توسعه‌دهنده وظیفهٔ خودم می‌دانم که یک بار برای همیشه توضیحات شفاف و روشنی را در اختیار کاربران iOS قرار دهم تا متوجه اصلِ موضوع باشند (بعد از آن تصمیم با خود شما)!

    اول از خودمان شروع کنیم، آیا واقعاً حرکت‌هایی که ما داشته‌ایم درست بوده است؟ به گونه‌ای که انگار اقدامات ما ایرانی‌ها بدون عیب و ایراد بوده و اپل بدون دلایل منطقی اقدام به تحریم ما کرده است! (هدف از این مقاله به هیچ عنوان طرفداری از اقدامات شرکت اپل نیست، چرا که این شرکت به عنوان فروشندهٔ محصولات خود وظیفه دارد به پشتیبانی و ارائهٔ خدمات به کاربرانش باشد نه اینکه هم سود کند و هم به خاطر مسائل سیاسی برخی از مشتریان خود را محدود کند.
    بنابراین ما اپل را هم محکوم به آن می‌کنیم که هیچ ارزشی به کاربران و توسعه‌دهندگان ایرانی به خاطر مسائل سیاسی قائل نیست)، و در مقابل مشترکین و حتی شرکت‌ها و فروشگاه‌های اپلیکیشن موظف هستند به جای توجیح کار‌های غیر قانونی و ناعادلانهٔ خود (و استفاده از چنین فرصت‌ها)، اقدامات به شفاف سازی روش‌های انتشار و توسعه کنند که مسلماً کاربران عادی و غیر حرفه‌ای از این امر بی خبرند! به گونه‌ای که انگار ما عادت کرده‌ایم هر زمان که مشکلی گریبان گیر ملت ما می‌شود به جای حل آن از روش صحیح و قانونی، اقدام به فشار بیشتر و سوء استفاده از آن فرصت کنیم که اصلاً روش انسان‌ دوستانه‌ای نیست (حداقل از فرهنگ اصیل ایرانی چنین انتظاراتی نداریم).
    اما واقعیت امر در چیست و دلایل مسدود سازی نرم‌افزار‌ها بر روی iOS در چیست؟
    اینطور که به گوش می‌رسد و به گفتهٔ پایگاه‌های خبری و سایت‌های فناوری خبر‌ها اینگونه است که، اپل تا کنون چندین بار برخی اپلیکیشن‌های ایرانی را مسدود یا رَد اعتبار کرده است ولی این بار، اپلیکیشن‌های پرداخت الکترونیکی و موبایلی مانند آسان پرداخت و نرم‌افزار‌ بانک‌های معروف ایرانی تحریم شدند. افزون بر این، اپ‌های محبوب و پر کاربردی مانند اسنپ، تپسی، فون‌پی، دیجی‌کالا، فیدیبو، سیب‌اپ نیز جزو تحریم شده‌ها هستند.
    در قدم اول ممکن است دلایل این کار را به خاطر مسائل سیاسی بدانیم، این مسئله تا حدی ممکن است درست باشد، اما با بازنگری و یادآوری حریم خصوصی و حقوق مشتری در جامعهٔ بشری از سمت اپل نیز حکم می‌کند که جوابگوی خدمات پس از فروش خودش باشد. بنابراین بهانه‌ تراشی بخشی از اقدامات می‌تواند باشد اما مسئلهٔ اصلی این نیست!
    اجازه دهید جایگاه خودمان را برعکس در نظر بگیریم، با این حساب که ما به عنوان خدمات دهنده‌های ایرانی بستری را فراهم کرده‌ باشیم که به جامعهٔ بزرگی از دنیا خدمات ارائه می‌دهیم. بنابراین قوانین و چهارچوب‌های شفاف و مشخصی را عنوان خواهیم کرد که خارج از آن باید اقدام به یادآوری و گوشزد، تذکر و در نهایت برخورد قانونی و تحریم را در برنامه‌ داشته باشیم که یک روند قانونی و طبیعی است.
    این قوانین در صورتی اجرا می‌شوند که حقوق توسعه، تولید، نشر و پشتیبانی رسمی محصولات نادیده گرفته شود. بنابراین فرض کنید شما صاحب فروشگاهی هستید که نویسندگان (توسعه‌دهندگان) و ارائه‌دهندگان خدمات آن همگی ساعت‌ها، ماه‌ها و سال‌ها زمان بر توسعه و تولید محصولات خود گذاشته‌اند. حال ممکن است آن را رایگان و یا حتی با دیدگاه تجاری در اختیار کاربران قرار دهند. بنابراین عقل و منطق اجازه می‌دهد که شما نرم‌افزار رایگان را به صورت رایگان و نرم‌افزار‌های تجاری را در قبال پرداخت هزینهٔ آن مورد استفاده قرار دهید. در غیر این صورت اگر محصولی که شما ارائه داده‌اید با نقض این موارد مواجه شود (بدون شک اولین تصمیمی که خواهید گرفت حذف خدمات پس‌ از فروش، پشتیبانی و ... خواهد بود).
    اما واقعیت این مسئله چیست؟ آیا اپل اقدام به تحریم بی دلیل بر روی اپلیکیشن‌های ایرانی داشته است؟
    اگر منطقی به قضیه فکر کنیم، به راحتی می‌توان این مسائل را بررسی و دلایل تحریم را درک کرد؛ من در این مقاله ابتدا به دلایل تحریم اپل می‌پردازم که پاسخ روشن و صریح این اقدامات اخیر را در این باره به شما خواهد داد. هرچند من به عنوان یک برنامه‌نویس باید به دنبال توسعه و تولید محصولات و حتی دور زدن تحریم‌های ناشیانه در این حوزه باید باشم، اما اینکه هم نوعان و همکاران خودم هم در این باره خبر‌ها و اطلاعات دروغ را به مشتریان این حوزه می‌دهند قابل تحمل نیست! چرا که اول باید از خودمان شروع کنیم!
    بهتر است در نظر داشته باشیم قوانینی که در اپل نیز ذکر شده‌اند به این اشاره دارد که در صورت خروج از این چهارچوب که ممکن است امنیت و حقوق مادی و معنوی توسعه‌دهنده و ناشر را پایمال کند، هیچ گونه تعهدی در رابطه با ادامهٔ همکاری و یا پشتیبانی از آن خدمات را نخواهند داشت. بنابراین شخصاً ندیدم حتی در یکی از فروشگاه‌های ایرانی اشاره‌ای به این حقوق شده باشه (حتی برعکس و شدیداً بر خلاف مواردی هستند که ذکر شده‌اند که با دلیل و اسناد معتبر خود مرجع اپل آن‌ها را شفاف سازی خواهم کرد).
    به عنوان مثال، اگر شما یک کاربر عادی یا حتی تازه کار باشید، یا اگر شما یک توسعه‌دهندهٔ تازه‌کار و حتی حرفه‌ای باشید بهتر است به این بخش از قوانین اپل (App Store Review Guidelines) توجه جدی کنید! این بخشی از قوانین صریح و شفاف اپل در حوزهٔ اپلیکیشن‌های iOS و فروشگاه خودش است که در زیر آمده است:
    App Store Review Guidelines Introduction Apps are changing the world, enriching people’s lives, and enabling developers like you to innovate like never before. As a result, the App Store has grown into an exciting and vibrant ecosystem for millions of developers and more than a billion users. Whether you are a first time developer or a large team of experienced programmers, we are excited that you are creating apps for the App Store and want to help you understand our guidelines so you can be confident your app will get through the review process quickly. The guiding principle of the App Store is simple - we want to provide a safe experience for users to get apps and a great opportunity for all developers to be successful. We do this by offering a highly curated App Store where every app is reviewed by experts and an editorial team helps users discover new apps every day. For everything else there is always the open Internet. If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too. On the following pages you will find our latest guidelines arranged into five clear sections: Safety, Performance, Business, Design, and Legal. The App Store is always changing and improving to keep up with the needs of our customers and our products. Your apps should change and improve as well in order to stay on the App Store. A few other points to keep in mind: We have lots of kids downloading lots of apps. Parental controls work great to protect kids, but you have to do your part too. So know that we’re keeping an eye out for the kids. The App Store is a great way to reach hundreds of millions of people around the world. If you build an app that you just want to show to family and friends, the App Store isn’t the best way to do that. Consider using Xcode to install your app on a device for free or use Ad Hoc distribution available to Apple Developer Program members. If you’re just getting started, learn more about the Apple Developer Program. We strongly support all points of view being represented on the App Store, as long as the apps are respectful to users with differing opinions and the quality of the app experience is great. We will reject apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, “I’ll know it when I see it”. And we think that you will also know it when you cross it. If you attempt to cheat the system (for example, by trying to trick the review process, steal user data, copy another developer’s work, manipulate ratings or App Store discovery) your apps will be removed from the store and you will be expelled from the Developer Program. You are responsible for making sure everything in your app complies with these guidelines, including ad networks, analytics services, and third-party SDKs, so review and choose them carefully. Some features and technologies that are not generally available to developers may be offered as an entitlement for limited use cases. For example, we offer entitlements for CarPlay Audio, HyperVisor, and Privileged File Operations. Review our documentation on developer.apple.com to learn more about entitlements. We hope these guidelines help you sail through the App Review process, and that approvals and rejections remain consistent across the board. This is a living document; new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this. We love this stuff too, and honor what you do. We’re really trying our best to create the best platform in the world for you to express your talents and make a living, too. در قوانین ذکر شده به صراحت عنوان شده است که اگر به فکر برنامه‌های آزمایشی هستید بهتر است از محیط Xcode با همان حساب توسعه‌دهندگی استفاده کنید که تنها بر روی دستگاه‌ خودتان می‌تواند اجرا شود. در صورتی که به فکر بحث تجاری آن هستید باید تمامی حقوق مربوطه را رعایت کنید و حتی نباید به فکر کپی کردن، درز اطلاعات، به خطر اندازی حریم خصوصی و دیگر مسائل بپردازید که در این صورت اپل محصول شما را رَد خواهد کرد.
    فشار دو طرفه، بهانه تشدید بهانه... بهانه و باز هم بهانه!!!
    مسلماً برای همه روشن است که سیاست‌های آمریکایی و شرکت‌های آن منتظر بهانه‌هایی هستند که سریعاً فشار‌ها را به سمت ملت ایران وارد کنند، بنابراین مانند اقدامات اخیر Github که متأسفانه مجبور هستند بر اساس سیاست‌های دولتی خود اقدام به محدود سازی خدمات خود به ایرانی‌ها باشند (اپل بسیار مشتاقانه‌تر به دنبال بهانه و ایجاد فشار به ملت ما می‌شتابد). بنابراین باز هم یادآوری کنیم محصولی که بابت آن پول پرداخت می‌شود اعمال محدودیت و فشار بر آن دیگر جایز و انسان‌دوستانه نیست!
    جالبتر از این موارد یادآوری این موضوع است که دوستان داخلی به جای حل مشکلات با فرصت طلبی‌ها و سوء استفاده‌‌ها و بی‌انصافی‌ها هم فشار وارده را بر کاربران iOS بیشتر کرده‌اند و هم وضعیت و بهانه‌های بیشتری به دست شرکت اپل می‌دهند! این واقعیتی است که باید پذیرفت (به گونه‌ای که در شرایط اقتصادی کنونی هم فشار از خارج هم داخل بر ملت ما وارد است). کاش منصفانه به فکر راه حل‌های مشکلات کنونی باشیم... ملت ما در چنین شرایطی هر جا که به کمک هم شتاب کرده‌اند موفق‌تر بوده‌اند و خواهند بود (اما به روش درست نه غلط!!!).
    حال با در نظر گرفتن نقض قوانین صریح از سمت فروشگاه‌های ایرانی که به آن‌ هم افتخار می‌کنند، آیا نباید انتظار داشت تا روزی اپل یا هر شرکت دیگری صبرش به پایان برسد و خیس و خُشک را باهم بسوزاند؟!
    بخشی از ادعاهایی که بزرگترین مرجع ایرانی (سیب‌اپ) اپلیکیشن‌های iOS ارائه شده است به صورت زیر می‌باشد:
    زمانی که دسترسی به هزاران اپلیکیشن خارجی با ارزش ۵۰،۰۰۰ دلار در کشور ما با افتخار حقوق توسعه‌دهنده و ناشر را زیر سوأل می‌برد نباید انتظار داشت چنین تحریم‌هایی حق ماست؟
    حال آنکه چنین فروشگاه‌هایی جدیداً از محدودیت‌های اخیر سوء استفاده کرده و حتی با وعده‌های دروغین اقدام به فروش اشتراک ویژه می‌کنند که در ازای آن هیچ تضمینی از امنیت، حقوق مادی و معنوی و حتی اجرا شدن نرم‌افزار‌های موجود در آن فروشگاه وجود ندارد! متأسفانه دروغ‌ها و فرصت‌ طلبی‌ها از چنین فرصت‌ها به جای حل مسائل و اختلاف‌های سیاسی و تجاری چیزی به جز بدتر کردن وضعیت کنونی نخواهد داشت. حتی هیچ شانسی برای بهتر شدن وضعیت کنونی باقی نخواهد ماند.
    نقل قول زیر از طرف سیب‌اپ است که ادعا کرده است با پرداخت اشتراک شما قادر به دانلود بدون مشکل اپلیکیشن‌ها خواهید بود.
    راه حل‌های ناشیانه و واقعا مسخره که از طرف فروشگاه‌ها و نویسندگان خبری اخیر به دستمان رسیده است به صورت زیر هستند:
    استفاده از نسخه وب اپلیکیشن حقیقت نفهته در پشت این راه حل‌ها به این صورت است که یک فناوری به عنوان PWA یا همان (Progressive web applications) وجود دارد که همان نسخهٔ وب به شمار می‌آید! در واقع اپلیکیشن‌های نوشته شده به این روش بسیار بدتر از حتی یک وب‌سایت کامل هستند و تنها به روش‌های غیر بومی و خارج از محیط Xcode تحت فناوری‌های وب مانند HTML, CSS و JavaScript توسعه داده می‌شوند. در نهایت هیچ ربطی به نسخهٔ اصلی و نوشته شده‌ به روش طبیعی نرم‌افزار‌های iOS ندارد و تنها نسخهٔ محدود شده‌ای از وب‌سایت خدماتی است که با حقه‌های فریبنده و کاملاً ناشیانه اقدام به ساخت میان‌بر و ایجاد آیکون بر روی صفحه گوشی شما می‌کنند که اینطور برداشت کنید نسخهٔ واقعی اپلیکیشن را نصب کرده اید!!! در حالی که بهتر است به جای آن از همان وب‌سایت استفاده کنید. مسخره است نه؟! دسترسی به برنامه‌هایی که پیش‌تر از اپ استور دانلود کرده‌اید دسترسی به برنامه‌هایی که پیش‌تر از اپ‌استور دانلود شده است روشی کاملاً مسخره‌تر است که به شما پیشنهاد می‌دهد تا نسخه‌های قدیمی اپلیکیشن‌هایی که اپل آن‌ها را نگه‌داشته است اما توسعه‌دهنده‌گان آن‌ها هم نمی‌توانند آن را به‌روز رسانی کنند استفاده کنید! این کار چه فایده‌ای دارد دقیقاً؟ تعداد اپلیکیشن‌هایی این چنینی بسیار محدود هستند مانند دیوار ... که آخرین به‌روز رسانی آن به ۲ سال پیش مربوط است!!! جیلبریک کردن این روش ممکن است کارایی داشته باشد، اما تمامی مسائل امنیتی و خدماتی که اپل آن‌ها را ارائه می‌کند را از بین برده و در واقع در این روش هیچ تضمینی برای حفظ اطلاعات و صحت عملکرد دستگاه شما وجود ندارد (در واقع شما از روش بسیار خطرناک از بین هزاران حفره‌های شکافته شدهٔ امنیتی عبور کرده و از برنامهٔ مورد نظرتان که شاید آن یک اپلیکیشن بانکی و ... باشد استفاده می‌کنید). راه حل سیب اپ (بزرگ‌ترین فروشگاه ایرانی برای برنامه های iOS) این پیشنهاد زمانی معتبر است که فروشگاه و یا فروشگاه‌های مربوطه با شفافیت کامل بیان کنند که راه‌حل‌های فعلی هیچکدام نهایی نیست و اصلاً مخصوص کاربر نیست!!! چرا که مشتری نه توسعه‌دهنده است و و نه شرکت! بنابراین زمانی که با حرکت‌های ظاهراً حرفه‌ای اما در حقیقاً کاملاً غیر حرفه‌ای از هر کاربر یک توسعه‌دهنده یا شرکت و یا سازمان می‌سازند طبیعی است که باید هزینه‌هایی مانند ۹۹ تا ۲۹۹ دلار در سال را بپردازند که مسلماً منجر به پولی شدن حق نصب اپلیکیشن خواهد بود که از بیخ غلط است! بنابراین انتظار می‌رود تحت هیچ شرایطی مردم را نَفَهم فرض نکنیم! مطمئنان هر عقل سلیمی می‌تواند تشخیص دهد که این روش دقیقاً همان مثال معروف (ماهی گرفتن از آب گل‌آلود است) در واقع شما باید پول به چیزی بپردازید که خودش روش غیرقانونی و نامناسب است!!! برخی از توسعه‌دهندگان و سایت‌های خبری و حتی استور‌ها چنین ادعا می‌کنند که هیچ محدودیتی در توسعه و انتشار برنامه‌های iOS وجود ندارد، آیا این حقیقت است؟
    طبق توضیحاتی که در بالا اشاره کردم، هیچ روش منطقی در داخل کشور وجود ندارد که قانونی باشد، اگر کسی مدعی به انتشار است مطمئنان از همین روش‌هایی که اشاره شد استفاده می‌کند که خارج از این نیست.
    فروشگاه‌های جدید و مدعی بدون محدودیت چگونه کار می‌کنند؟
    متأسفانه با وجود شرایط کنونی و محدودیت‌های اپل افراد و فروشگاه‌های زیادی در چندین ماه اخیر ایجاد شده‌اند که از این فرصت برای ارائه خدمات به شیوهٔ PWA و دو روش دیگر که ذکر شد استفاده می‌کنند که هیچ یک از آن‌ها ارائه دهندهٔ خدمات واقعی نیستند. (اگر شما فروشگاهی را می‌شناسید که از روش‌های قانونی برای نشر برنامه‌ها استفاده می‌کند که نیاز نباشد هر چند وقت یک بار برنامه‌ را حذف و دوباره نصب کنند و یا در بهترین حالت شما را به عنوان توسعه‌دهندهٔ اپل معرفی نکنند به ما معرفی کنید تا به گوش همگان برسانیم!).
    روش‌های پیشنهادی و رسمی اپل چیست؟
    طبق اسناد رسمی، اپل می‌گوید اگر شما برنامهٔ خودتان را به صورت استاندارد توسعه‌ داده‌اید می‌توانید به دو روش آن را منتشر کنید؛ روش اول این است که آن را در فروشگاه اپل منتشر کنید (که در این روش بنابر اساس سیاست‌هایی که دارند مسلماً تحریم ما خواهد بود که شاهدش بودیم - حذف اپلیکیشن‌های ایرانی از فروشگاه اپل). روش دوم آن است که شما اپلیکیشن خود را در قالب روش‌های Ad-Hoc ایجاد کنید که محدود بر ۱۰۰ دستگاه (کاربر) خواهد بود. این روش نیز به گونه‌ای قابل استفاده است اما محدود بر تعداد کاربران خواهد بود و برای اهداف داخلی و سازمانی خودمان طراحی شده است و بدون شک امضاء و مدیریت آن همراه با تولید آمار بسیار زیادی از تأییدیه‌ها سرسام آور خواهد بود. درواقع اپل می‌گوید اگر می‌خواهید در دامنهٔ بزرگتر یعنی جهان، استفاده کنندهٔ اپلیکیشن شما باشد باید در فروشگاه من آن را منتشر کنید تا هم امنیت و هم پشتیبانی آن را تضمین کنم. روش‌های دیگر نیز با عنوان (Enterprise Program) مطرح هستند که مخصوص تیم‌های توسعه‌ای که در برنامه Enterprise یا همان تجاری ثبت نام کرده‌اند نیز می‌توانند از توزیع داخلی استفاده کنند. این روش همان روشی است که اپل برای عموم اکثراً محدود کرده است و مختص تحریم‌های ایران نیست. درواقع همان روشی که بعضی از شرکت‌های ایرانی هر روز می‌گویند اپلیکیشن را از لینک جدید دریافت کنید!!! که البته همراه با هزینهٔ سالانه ۲۹۹ دلار است! روش‌های محدود‌تر دیگری وجود دارد که کاربران با محدودیت بیشتری با آن می‌توانند برنامه‌ها را صرفاً برای مصارف ازمایشی و خودمانی استفاده کنند که این دسته با عنوان University Program شناخته شده اند و توانایی نشر برنامه به جامعهٔ هدف بزرگتری را نخواهند داشت. با توجه به این تعاریف مشخص است که دو روش پیش‌فرض استاندارد و Ad-Hoc باقی مانده است. تکلیف روش اول مشخص است که تا زمانی که تحریم‌ها وجود دارد نباید انتظار داشت که در اپ‌استور بتوان اپلیکیشن‌های ایرانی را بارگذاری کرد. اما روش اد‌هاک همان روشی است که اجازه می‌دهد با خرید و ثبت دستگاه در بانک گواهی‌های معتبر اپل اپلیکیشن‌های خود را به مدت ۱ سال یا بیشتر امضا کنید (این روش برای توسعه‌دهندگان) پیشنهاد شده است که احتمالاً روش‌های فعلی استور‌ها این باشد! مسلماً این روش هزینهٔ شارژ و امضای توسعه‌دهنده را خواهد داشت. البته لازم به ذکر است این روش قطعی نیست و اگر اپل بداند که به زودی هم خواهد دانست میلیون‌ها کاربر توسعه‌دهنده پیدا کرده است! مسلماً طی اقداماتی روش‌هایی برای حل آن ارائه خواهد داد.
    خب راه حل منطقی چیست؟
    با توجه به مستندات و منابع رسمی که اعلام کرده‌اند، از اولین ساعت‌های مسدود شدن نرم‌افزار‌های بانکی و پرداختی، شرکت‌هایی که در این مجموعه اپ یا اپ‌هایی داشتند؛ راه‌حل موقت خود را ارایه کردند، عمده‌ترین راه‌حل استفاده از اپ‌های مسدود شده روی گوشی‌های آیفون، مراجعه به نسخه وب اپلیکیشن یا استفاده از پلتفرم‌های دیگری مانند اندروید است. مدیران اسنپ و دیجی‌کالا از کاربران‌شان درخواست کردند به طور موقت نسخه وب آن‌ها را استفاده کنند تا مشکل حل شود. برخی شرکت‌ها مانند سیب‌اپ و تپسی، نسخه جدید و مجزایی از اپ‌استور ارایه داده و از کاربران‌شان درخواست کردند این اپلیکیشن را از روی سایت آن‌ها دریافت و نصب کنند. سیب‌اپ در پیام‌های ویدیویی و اطلاعیه رسمی، به کاربران خود وعده داده است به‌زودی نسخه جدیدی از اپلیکیشن سیب‌اپ ارایه خواهد شد که دیگر مشکل مسدود بودن یا عدم اعتبارسنجی توسط اپل را ندارد (که این روش زمانی قابل تأیید خواهد بود که به روش‌هایی غلطی که در بالا اشاره شد عمل نشود و رسالت و شعار‌های فریبانهٔ خود را تغییر دهند) که مسلماً باید اول حقوق مادی و معنوی و حریم خصوصی مصرف کننده را تضمین کنند و در نهایت به روش‌های قانونی مجوز‌های لازم را از اپل دریافت کنند که با توجه به شرایط حاکم کمی غیر ممکن و دور از انتظار است!!! روش‌های بهتری جهت نصب و راه‌اندازی اپلیکیشن‌های ایرانی وجود دارد که با نام‌های Add-Hoc نیز معروف هستند که محدود به نوع توسعه‌دهنده و تجاری معرفی می‌شوند. البته روش‌های تجاری همان روش‌هایی است که سیب‌اپ و دیگر شرکت‌ها مورد استفاده قرار داده‌اند. اما روش روش نوع توسعه‌دهنده می‌تواند با در نظر گرفتن ثبت دستگاه شما در پروفایل این مشکل را تا حدی برطرف کند که فروشگاه‌هایی مانند اناردونی با در نظر گرفتن هزینهٔ ثبت دستگاه آن را تا به مدت ۱ سال تضمین می‌کنند. روش درست و صحیح‌تر آن است که دقیقاً طبق قوانین اپل عمل شود، در واقع تمامی ماده‌ها و تبصره‌های عنوان شده توسط شرکت اپل در اپ‌استور را باید پذیرفت. اما مشکل اصلی و اساس این مشکلات این است که اپل قبلاً هم گفته است حاضر به ارائهٔ خدمات به ایران نیست. (یاد شعار استیو جابز مرحوم افتادم که ما خواهیم گفت کاربر از چه چیزی باید استفاده کنند نه آن‌ها) در واقع اپل با این اقدامات و فشار‌های خود رسماً می‌گوید شما بهتر است از محصولات دیگر استفاده کنید که عمل زشت و بسیار نژاد‌پرستانه است. آیا فروشگاه‌های داخلی به داد مردم می‌رسند یا از آب گل‌آلود ماهی می‌گیرند؟ قضیه این است!!!
    خوشبختانه در حالت عادی خدمات فروشگاه‌های داخلی خوب به نظر می‌رسد، اما وقتی به واقعیت‌های آن‌ها می‌پردازیم می‌بینیم که فرصت‌های خوبی برای پول به جیب زدن‌های خیلی خوشگل فراهم شده است که هرچند برای فراهم سازی بستر آن باید زحمت کشید و پول خرج کرد... اما در ازای چه خدماتی چه چیزی به دست می‌آورند؟
    وقتی به خدماتی قرار است پولی پرداخت شود، آن سرویس باید بدون هیچ دغدغه و مشکلات مادی و معنوی قابل استفاده باشد. با توجه به عدم شفاف سازی کاربران که دلیل آن را نداشتن دانش فنی می‌دانند. از جانب بعضی از توسعه‌دهندگان و فروشگاه‌های ایرانی ترجیح داده‌شده است که، خدمات ارائه شود اما با دریافت هزینه! کافی است یک حساب کتاب ساده انجام دهید، وقتی شما قرار است توسعه‌دهندهٔ اپل باشید باید هزینهٔ سالیانه آن را پرداخت کنید که چیزی حدود ۹۰ تا ۱۲۰ دلار بسته به مالیات متغیر است. و اگر قرار است امضاء از نوع سازمانی داشته باشید باید هزینه‌ای معادل ۲۹۹ دلار برای آن بپردازید که در نهایت هر ۱۰ الی ۲۰ روز یک بار هزینه نزدیک به ۳ میلیون تومان برای خرید اکانت تجاری باید تقدیم کنید! در قبال آن به دست آوردن برخی از فروشگاه‌ها مانند سیب‌اپ هزینه‌‌ی حداقل ۳۰،۰۰۰ تومان را بابت آن دریافت می‌کنند. به گفتهٔ خودشان تعداد کاربران میلیونی... با پرداخت چنین هزینه‌هایی معادل صد‌ها شاید هم هزاران و میلیون‌ها برابر آن را به دست خواهند آورد!!! فرصت خوبی برای راه‌اندازی کسب‌و‌کار و به قول قدیمی‌ها (ماهی گرفتن از آب گل‌آلود) است نه! البته فروشگاه‌هایی هم وجود دارند که با روش‌های PWA ادعای به اشتراک گذاری اپلیکیشن‌ها را دارند که از اشاره به نسخه وب بودن و محدودیت‌های آن دریغ می‌کنند.
    اخیراً هم که با حقه‌بازی‌های هرچه تمام هزینه‌های چند برابری با وعده‌های دروغین به مردم خدمات می‌دهند که شخصاً با خرید حساب ۱ ساله بعد از ۳ ماه دوباره از ما پول خواستن!
    حالا که در جریان واقعیت قرار گرفته‌اید، بهتر است خودتان قضاوت کنید (چرا که به عنوان یک برنامه‌نویس این ننگ است که بدانیم اما به زبان نیاوریم که چه چیزی به خُرد ملت می‌دهیم). آیندهٔ نرم‌افزار‌های iOS ایرانی چطور خواهد شد؟
    شما کاربران عزیز باید در نظر داشته باشید که هیچ روش رسمی و قانونی به جز مواردی که اشاره شده است وجود ندارد، مشخص نیست با این وضعیت چه بلایی به بازار اپلیکیشن‌های ایرانی در پلتفرم iOS خواهد آمد، اما با توجه به مسائل سیاسی که دولت ایالات متحدهٔ آمریکا اعمال کرده است و تمامی تحریم‌های بانکی و ... از قبل گریبان گیر ما شده است کمی بعید است بدون حل مسائل سیاسی این دو کشور به این راحتی ها بتوان راه حل‌های دائمی و مطمئن معرفی کرد. بنابراین، باید منتظر ماند تا دید آیا نظر اپل در این بهانه تراشی‌ها تغییر خواهد کرد یا خیر! البته بر اساس نظرات کارشناسی برخی از حقوق‌دان‌ها و سیاست‌مداران اینطور عنوان می‌شود که شرکت‌ها بعضاً مجبور هستند بر خلاف میل خود طبق دستورات دولت خودشان اقدام کنند. در نهایت، باید منتظر ماند و دید که آیا حتی با پذیرفتن هزینه‌های بسیار بالا و رعایت قوانین کامل اپل باز هم اقدام به مسدود کردن برنامه‌های ایرانی خواهد کرد یا خیر.
    هدف از این مقاله این است که با چشمان باز حقیقت پنهاد در پشت این مسائل را بدانید.
  18. کامبیز اسدزاده
    مدتی قبل بود که من در رابطه با شاخص‌های در حال رشد زبان‌های برنامه‌نویسی در کانال‌های شخصی نظری داده بودم که با توجه به وضعیت شاخص، زبان‌ برنامه‌نویسی ++C سریع‌ترین رشد را بعد از مدت‌ها به خود اختصاص داده است.

    این تغییرات و بیداری زبان طبق انتظاری که داشتم بعد از ظاهر شدن زبان برنامه‌نویسی Rust در بین ۲۰ زبان برنامه‌نویسی برتر و همچنین نهایی شدن استاندارد‌های 2a و پیشرفت‌های اخیر به خصوص رضایت‌بخشی کاربران از استاندارد 17 زبان ++C رخ داده است که دور از انتظار هم نبود.

    طبق شاخص محبوبیت طی چند سال گذشته، ++C با توجه به شاخص TIOBE در سپتامبر، سریع‌ترین زبان در حال رشد در بسته برنامه‌نویسی است. این زبان در سال‌های گذشته، محبوبیت سهم خود را در فراز و نشیب‌ها داشته است. اما با مقیاسه با سال‌های گذشته در حال حاضر رسماً سریع‌ترین رشد را در بین تمامی زبان‌های تحت پوشش اتوماسیون QA در شرکت Tobie را دارد.

    با این حال مدیرعامل Tobie جناب Paul Jansen گفته است، من فکر می‌کنم که استاندارد جدید سی++ یکی از دلایل این رشد اصلی باشد. به خصوص ویژگی‌های جدید module که قرار است جایگزین مکانیزم وحشتاک قبلی شود. با این روند سی++ بیشترین رشد‌ها که متعلق به #C با ۱.۱۸+ و R با ۱.۳۳+ را شکست می‌دهد.
  19. کامبیز اسدزاده
    با توجه به محبوبیت صنعت وِب، سال‌هاست زبان‌های برنامه‌نویسی در این زمینه پیشرفت‌ها و کاربرد‌های چشم‌گیری را داشته‌اند، از جمله جاوا‌اسکریپت (JS) به عنوان یک زبان قابل اجرا در داخل مرورگر شناخته می‌شود. هرچند بسیار محبوب و کاربردی است، اما این زبان قطعاً مشکلات خودش را دارد که برخی از آن‌ها عدم انعطاف‌پذیر بودن، سرعت پایین اجرا و همچنین انواع غیر ایمن آن است که این باعث می‌شود برای محاسبات و کارهای پیچیده جوابگو نباشد.

    هرچند گزینه‌هایی مانند CoffeeScript و TypeScript وجود دارند و نسبتاً ایرادات خام جاوا‌اسکریپتی را پوشش می‌دهند، اما در نهایت کد‌های نوشته شده به جاوا‌اسکریپت تبدیل می‌شود. در این میان می‌توان گفت وب‌اسمبلی (WebAssembly) برای حل و مرتب سازی مشکلات جاوا‌اسکریپت معرفی شده است و شدیداً در حال اثبات آن است که یک انقلاب در صنعت وِب را رقم می‌زند.
    با این تفاسیر، آیا وب‌اسمبلی زبان برنامه‌نویسی است؟
    این فناوری به خودی خود، یک زبان برنامه‌نویسی نیست، در واقع برنامه‌نویسان برنامه‌های خود را توسط زبان‌های سطح‌بالا مانند C یا ++C و حتی Rust می‌نویسند و آن را کامپایل و در قالب باینری با پسوند فایل .wasm وارد می‌کنند. توجه داشته باشید که وب‌اسمبلی جایگزینی برای جاوا‌اسکریپت نیست، درواقع قرار است در کنار جاوا‌اسکریپت اجرا شود. به عنوان مثال شما می‌توانید فقط یک کد محاسباتی بالا را در WebAssembly بسازید و آن را در کنار سایر کد‌های جاوا‌اسکریپت با وزن سبک‌تر استفاده کنید. همچنین شما برای بارگذاری ماژول wasm در مرورگر به جاوا‌اسکریپت نیاز دارید.

    فناوری وب‌اسمبلی (WebAssembly) و یا WA چیست؟
    وب‌اسمبلی یا وَسم (Wasm، اغلب به طور مخفف) استانداردی باز است که یک قالب جدید دستورالعمل‌های باینری را معرفی می‌کند. این فناوری نوید این را می‌دهد که برنامه‌ها با کارآیی (پرفرمنس) بومیِ خود در بستر وِب اجرا شوند. به عبارت ساده‌تر می‌توان گفت، این فناوری امکان این را می‌دهد که کد‌های نوشته شده با زبان‌های سطح بالا‌تر مانند C و ++C یا Rust به ماژول Wasm کامپایل شوند که مستقیماً در مرورگر‌های مدرن قابل اجرا هستند.

    معماری وب‌اسمبلی
    وب‌اسمبلی به گونه‌ای طراحی شده است که بر روی دستگاه‌های مجازی مبتنی بر پشته (stack-based) اجرا شود. بر خلاف ماشین‌های رجیستری که عملوند‌های آن‌ها بر روی پردازندهٔ مرکزی قرار دارند و محاسبات در آن بخش اتفاق می‌افتد، در یک ماشین مبتنی بر پشته، بیشتر دستورالعمل‌ها به جای اینکه بر روی رجیستر اعمال شوند، بر روی پشته می‌نشینند.
    برای افزودن دو عدد بر روی ماشین مبتنی بر پشته، شماره‌های مربوطه را در پشته ارسال می‌کنید. سپس دستور ADD را فشار می‌دهید. سپس دو عملگر و دستورالعمل از بالای صفحه ظاهر می‌شود و نتیجهٔ اضافی در جای خود قرار می‌گیرد. برخی از این نوع ماشین‌ها عبارتند از .Net، JVM Runtime و غیره.
     
    وب‌اسمبلی به معنای سنتی، پشته‌ای ندارد. درواقع هیچ مفهومی از اپراتور‌های جدید ندارد. حتی خبری از GC در آن وجود ندارد. در عوض وب‌اسمبلی دارای یک حافظهٔ خطی است، یعنی حافظه به عنوان طیف پیوسته از بایت‌های بدون نوع نمایش داده می‌شود. در صورت نیاز به فضای بیشتر، ماژول وب‌اسمبلیِ شما می‌تواند بلوک حافظهٔ خطی را افزایش دهد.
    نکته: WebAssemble فقط چهار نوع داده دارد: i32، i64، f32، f64 برای اعداد صحیح 32 و 64 بیتی و انواع شماره‌های شناور
    آیندهٔ توسعهٔ وب چگونه می‌شود؟
    اگرچه ممکن است وب‌اسمبلی، جاوا اسکریپت را از بین نبرد، اما قطعاً قصد این را دارد که چهرهٔ front-end توسعهٔ وب را تغییر دهد. البته راه بسیاری در پیش است تا همهٔ تغییرات را تجربه کنیم. اما به اندازهٔ کافی می‌توان آیندهٔ وب را پیش‌بینی کنیم:
    تنوع از نظر زبانی خیلی سریع موازی تنوع زبانی
    این فناوری به طور چشم‌گیری تنوع در استفاده از زبان‌های برنامه‌نویسی را برای ساخت برنامه‌های تحت وب افزایش می‌دهد. در حال حاضر لیست زیر زبان‌هایی است که وب‌اسمبلی از آن‌ها پشتیبانی می‌کند:
    C/C++ Rust C#/.Net Java Python Elixir Go
    سرعت و کارآیی بسیار بالا
    فناوری WASM باعث می‌شود عملکرد برنامه‌ها شگفت‌انگیز شود. در این زمینه مستنداتی وجود دارد که فایرفاکس در یک سری از نمونه‌های اولیه آن را ثابت می‌کند. همچنین طبق تجزیه و تحلیل برنامه‌های کاربردی توسط فیگما منتشر شده است که نشان می‌دهد پیاده‌سازی‌های صورت گرفت در قالب asm.js که خود از سرعت بسیاربالای به خاطر پشتیبانی از سی++ دارد، با این وجود با فعال بودن ماژول WebAssembly چیزی حدود ۳ برابر بهبود زمان اجرا گرفته است. در این موارد ثابت شده است که با استفاده از ++C و کامپایلر کلنگ (LLVM) سرعت اجرای برنامه‌ها با فعال بودن وب‌اسمبلی بسیار چشم‌گیر است.
    موازی سازی
    طبیعتاً این مورد بسیار قابل بررسی و توجه است، چرا که این مبحث به طور کامل در وِب پیاده‌سازی نشده است. از آنجایی که تغییر به سمت پردازنده‌های چند هسته‌ای حدوداً از سال ۲۰۰۵ آغاز شد، این امر به طور فزاینده‌ای اتفاق می‌افتد که برای دستیابی به عملکرد بیشتر، نرم‌افزار‌ها به موازی سازی نیاز دارند. با توجه به اینکه جاوا‌اسکریپت از سیستم موازی پشتیبانی نمی‌کند، تصور کنید که با فعال‌سازی WASM امکان استفاده از تمامی هسته‌های پردازنده فراهم شود.
     
    من به عنوان نویسندهٔ این مقاله، تصور شما را از این فناوری نمی‌دانم. اما قطعاً با این تفاسیر این فناوری به عنوان یک انقلاب بزرگ در حوزهٔ وِب محسوب می‌شود. با توجه به ساختار برنامه‌های نوشته شده توسط زبان‌های قدرتمندی چون ++C می‌توان تصور کرد که برنامه‌های بسیار بهینه و قدرتمندی را در حوزهٔ اجرایی مرورگر‌ها پشتیبانی کند.
    در حال حاضر ممکن استد شما فکر کنید که چرا کسی باید زبان ساده‌ای مثل جاوا‌اسکریپت را خدشه‌دار کند و یا به سمت زبان‌های پیچیده‌ای مانند Rust، C و ++C برود. اکنون وب‌اسمبلی کاملاً جدید است و جامعهٔ کافی در اطراف خود ندارد. اما باید توجه داشت وقتی از طریق این فناوری می‌توان به ویدئو‌ها، تصاویر و کتابخانه‌های رمزنگاری، یا استفاده از موتور‌های گرافیکی و فیزیکی که از OpenGL استفاده می‌کنند، و یا حتی کتابخانه‌‌ها و فریم‌ورک‌های قدرتمندی مانند Qt و غیره را می‌توان در حوزهٔ وب مورد استفاده قرار داد. بنابراین فناوری وب‌اسمبلی می‌تواند مسیری را برای رشد صنایع مختلف به خصوص شرکت‌های بازی‌سازی و غیره باز کند.
    افزایش کارآیی (پرفرمنس) بسیار شدید که توسط وب‌اسمبلی فراهم می‌شود، همانند اجرای برنامه‌های دسکتاپی است که می‌توان آن را بر روی وب نیز مشاهده کرد. با این روال ممکن است وب‌اسمبلی در سال‌های آینده، با نرم‌افزار‌های رومیزیِ بومی برابری کند.
  20. کامبیز اسدزاده
    معرفی نسخه‌بندی معنایی ویرایش ۲.۰
    در دنیای مدیریت نرم‌افزار مکان مخوفی به نام «جهنم وابستگی» (dependency hell) وجود دارد. هر چه سیستم شما بزرگتر باشد و بسته‌های (package) بیشتری با نرم‌افزار شما یکپارچه شده باشند، احتمال بیشتری وجود دارد که روزی خود را دراین گودال ناامیدی بیابید.
    در سیستم‌هایی با وابستگی‌های زیاد، انتشار بستهٔ جدید به زودی می‌تواند تبدیل به یک کابوس شود. اگر ویژگی‌های وابستگی‌ها بسیار جزئی‌نگرانه باشد، در خطر قفل نسخه (version lock) خواهید بود (ناتوانی برای بروزرسانی یک بسته، بدون اجبار جهت انتشار نسخه‌های جدید همهٔ بسته‌های وابسته). اگر وابستگی‌ها بسیار ضعیف مشخص شده باشند، به ناچار زخم بی‌قاعدگی نسخه را خواهید خورد (به فرض سازگاری بیش از حد معقول با نسخه‌های آتی‌تر). جهنم وابستگی آنجایی است که قفل نسخه و یا بی‌قاعدگی نسخه از پیشرفت رو به جلوی آسان و امن پروژهٔ شما جلوگیری می‌کند.
    برای پاسخگویی به این مشکل، من یکسری قوانین و پیش‌نیازهای ساده را پیشنهاد میدهم که نحوهٔ تخصیص و افزایش شماره‌های نسخه را دیکته می‌کند. این قوانین برپایهٔ شیوه‌های موجود رایج و گستردهٔ در حال استفاده، هم در نرم‌افزارهای متن‌باز و غیر متن‌باز است، اگرچه لزوماً محدود به آن نیست. برای آنکه این سیستم کار کند نخست لازم است یک API عمومی (public) تعریف کنید. این امر ممکن است شامل مستندسازی، یا بوسیلهٔ خود کد مقید شده باشد. صرف نظر از این موضوع، مهم است که این API دقیق و واضح باشد. زمانیکه API عمومی خود را مشخص کردید، تغییرات آن را با افزایش معین شمارهٔ نسخهٔ خود مرتبط می‌سازید. قالب نسخهای به صورت X.Y.Z را در نظر بگیرید. خطاهایی که تاثیری بر API ندارند، نسخهٔ وصله (Patch) را افزایش می‌دهند، افزایش یا تغییر API که با نسخه‌های قبلی سازگار است، نسخهٔ جزئی (Minor) را افزایش می‌دهند، و تغییرات API که با نسخه‌های قبل ناسازگار هستند، نسخهٔ اصلی (Major) را افزایش می‌دهند.

    این سیستم را «نسخه‌بندی معنایی» می‌نامیم. بر اساس این طرح، شماره‌های نسخه و روشی که تغییر می‌کنند، معنی و مفهومی را دربارهٔ کد تحت آن نسخه، و آنچه که از یک نسخه تا نسخه‌ای دیگر ویرایش شده است، انتقال می‌دهد.
    به فرض اینکه نسخهٔ MAJOR.MINOR.PATCH یا اصلی.جزیی.وصله داده شده است:
    شمارهٔ نسخهٔ اصلی (MAJOR) را زمانی افزایش دهید که تغییرات API ناسازگار اعمال کرده‌اید، شمارهٔ نسخهٔ جزئی (MINOR) را زمانی افزایش دهید که قابلیت‌هایی اضافه کرده‌اید که با نسخه‌های قبل سازگار هستند، شمارهٔ نسخهٔ وصله (PATCH) را زمانی افزایش دهید که تصحیح خطاهایی (bug) اعمال کرده‌اید که با نسخه‌های قبل سازگار هستند. برچسب‌های اضافی برای پیش‌نشر و ساختن فراداده به صورت پسوندهایی برای قالب MAJOR.MINOR.PATCH فراهم است.
    ویژگی‌های نسخه‌بندی معنایی (SemVer)
    کلمات کلیدی «باید»، «نباید»، «نیاز است»، «می‌بایست»، «نمی‌بایست»، «توصیه شده است»، «ممکن است» و «اختیاری» در این مستند می‌بایست بر مبنای آنچه در RFC 2119 تعریف شده است، معنا شوند.
    نرم‌افزارهایی که از نسخه‌بندی معنایی استفاده می‌کنند باید یک API عمومی اعلام کنند. این API می‌تواند در خود کد اعلام شود، یا به طور واضح در مستندسازی وجود داشته باشد. هر طور که انجام شود، می‌بایست دقیق و جامع باشد.
    یک شمارهٔ نسخهٔ عادی باید قالب X.Y.Z را داشته باشه طوری که در آن X ،Y و Z اعداد صحیح غیرمنفی هستند و نباید صفر اضافه (leading zero) داشته باشند. X نسخهٔ اصلی، Y نسخه جزیی، و Z نسخهٔ وصله است. هر عنصر باید به صورت شمارشی افزایش یابد. به عنوان مثال 1.9.0 -> 1.10.0 -> 1.11.0.
    زمانی‌که یک بستهٔ نسخه‌بندی شده منتشر شد، محتوای آن نسخه نباید دستکاری شود. هرگونه تغییری باید به عنوان نسخهٔ جدید منتشر شود.
    نسخهٔ اصلی شمارهٔ صفر (0.y.z) برای توسعه‌های ابتدایی است. هرچیزی در هر زمانی ممکن است تغییر کند. API عمومی نمی‌بایست ماندگار در نظر گرفته شود.
    نسخهٔ 1.0.0 API عمومی را تعریف می‌کند. روشی که شمارهٔ نسخهٔ بعد از این انتشار افزوده می‌شود، به این API عمومی و نحوهٔ تغییر آن وابسته است.
    نسخهٔ وصله Z (x.y.Z | x > 0) باید در صورتی افزوده شود که تصحیح‌های خطای سازگار با نسخهٔ قبلی معرفی شده باشند. یک تصحیح خطا به عنوان یک تغییر داخلی تعریف می‌شود که رفتارهای نادرست را اصلاح می‌کند.
    نسخهٔ جزیی Y (x.Y.z | x > 0) باید در صورتی افزوده شود که عملکرد سازگار با نسخه‌های قبل جدیدی به API عمومی معرفی شده باشد. همچنین اگر هرگونه عملکرد API عمومی به عنوان منسوخ‌شده برچسب خورده باشد، این شماره باید افزوده شود. اگر عملکرد جدید یا بهبود قابل توجهی در کدهای داخلی معرفی شده باشد، ممکن است نسخهٔ جزیی افزوده شود. ممکن است که شامل تغییرات سطح وصله هم باشد. زمانیکه نسخه جزیی افزوده شود، نسخهٔ وصله باید به 0 بازنشانده شود.
    نسخهٔ اصلی X (X.y.z | X > 0) باید در صورتی افزوده شود که هرگونه تغییرات ناسازگار با نسخه‌های قبل به API عمومی معرفی شده باشد. ممکن است این تغییرات شامل سطوح جزیی و وصله نیز باشد. نسخهٔ جزئی و وصله زمانیکه نسخهٔ اصلی افزوده می‌شود باید به 0 بازنشانی شوند.
    یک نسخهٔ پیش‌انتشار ممکن است با اضافه کردن یک خط تیره و یک سری شناسه‌هایی که به وسیلهٔ نقطه از هم جدا ‌شده‌اند و بلافاصله به دنبال نسخهٔ وصله می‌آیند، نشانه‌گذاری شود. شناسه‌ها باید تنها شامل اعداد و حروف الفبای اَسکی (ASCII) و خط تیره [A-Za-z0-9] باشند. شناسه‌ها نباید تهی باشند. شناسه‌های عددی نباید با صفر اضافه آغاز شوند. نسخهٔ پیش‌انتشار از اولویت پایین‌تری نسبت به نسخهٔ عادی مرتبط برخوردار است. یک نسخهٔ پیش‌انتشار حاکی از آن است که نسخهٔ ناپایدار است و ممکن است نیازمندی‌های سازگاری مورد نظر را آنگونه که در نسخهٔ عادی مرتبط نشان داده شده است، برآورده نکند. مثال: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
    متادیتای ساخت (build metadata) ممکن است با افزودن یک علامت جمع (+) و یک سری شناسه‌هایی که به وسیلهٔ نقطه ازهم جدا شده‌اند، و بلافاصله به دنبال نسخهٔ وصله یا پیش‌انتشار می‌آیند، نشانه‌گذاری شود. شناسه‌ها باید تنها شامل اعداد و حروف الفبای اَسکی (ASCII) و خط تیره [A-Za-z0-9] باشند. شناسه‌ها نباید تهی باشند. متادیتای ساخت می‌بایست در زمان تعیین اولویت نسخه درنظر گرفته نشود. بنابراین دو نسخه که تنها در متادیتای ساخت با یکدیگر متفاوت هستند، اولویت یکسان دارند. مثال: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f8
    اولویت اشاره دارد به اینکه چگونه نسخه‌ها زمانی‌که مرتب شده‌اند با یکدیگر مقایسه می‌شوند. اولویت باید به وسیلهٔ جداسازی نسخه به اصلی، جزیی، وصله و شناسه‌های پیش‌انتشار به همین ترتیب، محاسبه شود (متادیتای ساخت در اولویت نمایان نمی‌شود). اولویت، به وسیلهٔ اولین تفاوت تعیین می‌شود هنگامی که این مشخصه‌ها از چپ به راست مقایسه شوند، بدین صورت: نسخه‌های اصلی، جزیی و وصله همیشه به صورت عددی مقایسه می‌شوند. مثال: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. زمانی که اصلی و جزیی و وصله برابر هستند، یک نسخهٔ پیش‌انتشار از اولویت کمتری نسبت به نسخهٔ عادی برخوردار است. مثال: 1.0.0- alpha < 1.0.0 اولویت برای دو نسخهٔ پیش‌انتشار با نسخهٔ اصلی، جزیی و وصلهٔ مشابه باید به وسیلهٔ مقایسهٔ هر مشخصه‌ای که با نقطه جدا شده، از چپ به راست مشخص شود تا زمانی که یک تفاوت به شرح زیر یافت شود: شناسه‌هایی که تنها شامل اعداد صحیح هستند به صورت عددی و شناسه‌هایی که با حروف یا خط‌های تیره به صورت الفبایی به ترتیب ASCII مقایسه می شوند. مشخصه‌های عددی همیشه از اولویت کمتری نسبت به مشخصه‌های غیرعددی برخوردار هستند. مجموعه‌های بزرگتری از بخشهای پیش‌انتشار اولویت بیشتری نسبت به مجموعه‌های کوچکتر دارند، اگر همه مشخصه‌های اولویت برابر باشند. مثال: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
    چرا از نسخه‌بندی معنایی استفاده شود؟
    این ایده‌ای جدید یا انقلابی نیست. در واقع، احتمالاً شما چیزی مشابه به این را پیش از این انجام داده‌اید. مشکل اینجاست که «مشابه» به اندازهٔ کافی خوب نیست. بدون انطباق با نوعی تعریف رسمی، شماره‌های نسخه ضرورتاً برای مدیریت وابستگی (dependency) بلااستفاده هستند. بوسیلهٔ اختصاص اعداد و تعاریف واضح به ایده‌های بالا، برقراری ارتباط میان کاربران نرم‌افزار شما و اهدافتان آسان‌تر می‌شود. به‌مجرد اینکه این اهداف واضح شود، مشخصات وابستگی انعطاف‌پذیر (نه آن‌چنان انعطاف‌پذیر) می‌تواند نهایتاً ایجاد شود.
    یک مثال ساده می‌تواند نشان دهد که چگونه نسخه‌بندی معنایی می‌تواند جهنم وابستگی را به خاطره‌ای از گذشته تبدیل کند. کتابخانه‌ای به نام «Firetruck» را در نظر بگیرید. این کتابخانه به یک بسته به نام «Ladder» که به صورت معنایی نسخه‌بندی شده، احتیاج دارد. در زمانی که firetruck ساخته شده، Ladder در نسخهٔ 3.1.0 است، شما می‌توانید وابستگی Ladder را با آسودگی به عنوان بزرگتر یا برابر با 3.1.0 و نه کمتر از 4.0.0 تعیین کنید. شما می‌توانید آن‌ها را در سیستم مدیریت بستهٔ خود منتشر کنید و بدانید که آن‌ها با نرم‌افزار وابسته موجود سازگار هستند.
    بدون شک به عنوان یک توسعه‌دهندهٔ مسئولیت‌پذیر شما خواهید خواست که هر بسته همان‌طورکه اعلان شده ارتقاء یابد. دنیای واقعی مکان به هم ریخته ایست، ما جز اینکه هشیار باشیم نمی‌توانیم کاری دربارهٔ آن انجام دهیم. آنچه شما می‌توانید انجام دهید این است که بگذارید نسخه‌بندی معنایی به شما یک راه عاقلانه ارائه دهد، تا بسته‌ها را منتشر کرده و ارتقاء دهد بدون آنکه نسخه‌های جدیدی از بسته‌های مستقل را راه اندازی کند و شما را عذاب نداده، در وقت شما صرفه‌جویی کند..
    اگر همهٔ این‌ها مطلوب به نظر می‌رسد، همهٔ آنچه شما برای شروع استفاده از نسخه‌بندی معنایی احتیاج دارید این است که اعلام کنید که در حال انجام این کار هستید و از قوانین پیروی کنید. به این وب‌سایت از طریق صفحه README خود لینک بزنید، در نتیجه دیگران دربارهٔ قوانین خواهند دانست و از آن نفع خواهند برد.
     
    سوالات متداول
    چگونه باید با نسخه‌ها در فاز توسعهٔ ابتدایی 0.y.z کنار بیایم؟
    ساده‌ترین کار برای انجام دادن این است که توسعهٔ ابتدایی خود را از انتشار 0.1.0 آغاز کنید و سپس نسخهٔ جزیی را برای هر انتشار آتی افزایش دهید.
    چگونه بدانم چه زمانی باید 1.0.0 را منتشر کنم؟
    اگر نرم‌افزار شما در طول تولید مورد استفاده قرار گرفته است، احتمالاً می‌بایست هم‌اکنون 1.0.0 باشد. اگر یک API ماندگار دارید که کاربران روی آن حساب می‌کنند، شما باید 1.0.0 باشید. اگر در مورد سازگاری با نسخه‌های قبل خیلی نگران هستید، احتمالاً می‌بایست هم‌اکنون 1.0.0 باشید.
    آیا این روش، توسعه و تکرار سریع را کند نمی کند؟
    نسخهٔ اصلی صفر تماماً در مورد توسعهٔ سریع است. اگر شما API را هر روز تغییر می‌دهید، یا باید هنوز در نسخهٔ 0.y.z باشید یا در یک شاخهٔ توسعهٔ جداگانه که بر نسخهٔ اصلی بعدی کار می‌کند هستید.
    اگر حتی کوچکترین تغییرات ناسازگار با نسخه‌های قبل در API عمومی نیازمند یک نسخهٔ اصلی باشد، آیا من خیلی سریع به نسخه 42.0.0 نخواهم رسید؟
    این سوال یک توسعه‌دهندهٔ مسئولیت‌پذیر و آینده‌نگر است. تغییرات ناسازگار نمی‌بایست به راحتی در نرم‌افزاری که کدهای وابستهٔ زیادی دارد معرفی شود. هزینه‌ای که برای ارتقاء باید متحمل شد می‌تواند قابل توجه باشد. اجبار برای ایجاد نسخه‌های اصلی برای انتشار تغییرات ناسازگار، یعنی شما به تأثیر تغییراتتان فکر خواهید کرد و نرخ هزینه/سود مورد نظر را خواهید سنجید.
    مستندسازی تمامی API عمومی کار بسیار زیاد می‌برد!
    این مسئولیت شما به عنوان یک توسعه‌دهندهٔ حرفه‌ای است تا به طور مناسب نرم‌افزار که می‌بایست توسط دیگران مورد استفاده قرار گیرد را مستندسازی کنید. مدیریت پیچیدگی نرم‌افزار یک بخش فوق‌العاده مهم ازکارآمد نگه‌داشتن پروژه است، و انجام آن سخت است اگر کسی نداند که چگونه نرم‌افزار شما را استفاده کند یا چه متدهایی برای صدا زدن امن است. در دراز مدت، نسخه‌بندی معنایی و پافشاری بر یک API عمومی خوش‌تعریف می‌تواند همه چیز و همه کس را در اجرا کردن راحت در موقعیت مناسبی نگه دارد.
    چه کار می‌توانم بکنم اگر تصادفاً یک تغییر ناسازگار با نسخه‌های قبل را به عنوان نسخهٔ جزئی منتشر کردم؟
    به مجرد اینکه متوجه این مورد بشوید، تنظیمات نسخه‌بندی معنایی را به هم زده‌اید، مشکل را حل کنید و یک نسخهٔ جزیی جدید که مشکل را تصحیح کند و سازگاری با نسخه‌های قبل را بازگرداند، منتشر سازید. حتی تحت این شرایط، این پذیرفته شده نیست که انتشارهای نسخه‌بندی شده را دستکاری کنید. اگر مناسب است نسخهٔ متخلف را مستند‌سازی کنید و کاربران خود را از مشکل مطلع سازید تا آن ها نیز از نسخهٔ متخلف آگاه باشند.
    چه کار باید بکنم اگر وابستگی‌های خودم را بدون تغییر دادن API عمومی به‌روزرسانی کردم؟
    این مورد تا زمانی که API عمومی را متأثر نسازد سازگار تلقی خواهد شد. نرم‌افزاری که صریحاً به همان وابستگی‌هایی که بستهٔ شما وابسته است، وابسته باشد، باید مشخصات وابستگی خود را داشته باشد و نویسنده باید هرگونه مغایرت را ذکر کند. تشخیص اینکه آیا تغییر ازنوع دستکاری در سطح جزیی است یا سطح وصله، به این بستگی دارد که آیا شما وابستگی‌های خود را جهت تصحیح یک خطا یا برای یک کاربرد جدید به‌روزرسانی کرده‌اید. من معمولاً کد اضافی برای موارد آتی در نظر می‌گیرم، که بدون شک این موارد افزایش سطح جزیی می‌باشد.
    چه می شود اگر من بدون اعلام قبلی API عمومی را به صورتی تغییر دهم که با تغییر عدد نسخه سازگار نباشد؟ (یعنی کد به نادرست تغییر اصلی‌ای را در انتشار وصله معرفی می‌کند)
    از بهترین قضاوت خود استفاده کنید. اگر شما مخاطبان زیادی دارید که به شدت به وسیلهٔ تغییر رفتار به آنچه قبلاً برای API عمومی در نظر گرفته شده، متأثر خواهند شد، پس بهترین کار انجام یک انتشار نسخهٔ اصلی است، حتی اگر اصلاح اعمال شده مؤکداً یک انتشار وصله محسوب شود. به یاد داشته باشید، نسخه‌بندی معنایی تماماً دربارهٔ انتقال معنا بوسیله چگونگی تغییر عدد نسخه می‌باشد. اگر این تغییرات برای کاربران شما مهم است، از عدد نسخه برای آگاه‌سازی آن‌ها استفاده کنید.
    چگونه باید با منسوخ کردن عملکرد (deprecating functionality) کنار بیایم؟
    منسوخ کردن عملکرد موجود بخشی عادی از توسعهٔ نرم‌افزار است و معمولاً برای این‌که پیشرفت رو به جلو حاصل شود مورد نیاز است. زمانی‌که بخشی از API عمومی خود را منسوخ می‌کنید، باید دو کار انجام دهید: ۱) مستندسازی خود را به‌روزرسانی کنید تا به کاربر اجازه دهید از تغییرات باخبر شود. ۲) یک انتشار جزیی که در آن قسمت منسوخ شده در جایگاه خود باشد منتشر کنید. قبل از آنکه عملکرد را به طورکامل در یک انتشار اصلی حذف کنید حتماً باید حداقل یک انتشار جزیی که شامل قسمت منسوخ شده است وجود داشته باشد تا کاربران به راحتی بتوانند به API جدید منتقل شوند.
    آیا SemVer محدودیت اندازه بر روی رشتهٔ نسخه دارد؟
    خیر، اما از قضاوت مناسبی استفاده کنید. به عنوان مثال یک نسخهٔ ۲۵۵ نویسه‌ای احتمالاً مفید نخواهد بود! همچنین، سیستم‌های خاص ممکن است محدودیت‌های خود برای اندازهٔ رشته اعمال کنند.
    - منبع
  21. کامبیز اسدزاده
    معرفی سیاههٔ تغییرات (Change Log)
    سیاههٔ تغییرات (changelog یا CHANGELOG) اشاره به یک سیاهه یا تاریخچهٔ تغییراتی دارد که در یک پروژه همانند یک وب‌سایت اینترنتی یا یک پروژه نرم‌افزاری اعمال می‌شوند. یک پروندهٔ سیاههٔ تغییرات شامل یک لیستی است از تغییرات قابل توجه برای هر نسخه از یک پروژه. این تغییرات عموماً به عنوان اصلاحات باگ‌ها، قابلیت‌های جدید و ... در این سیاهه نوشته می‌شوند. برخی از پروژه‌های متن‌باز فایل سیاههٔ تغییرات را در دایرکتوری سطح بالای کدهای منبع پروژه خود قرار می‌دهند. هرچند که قرارداد متعارف نام‌گذاری این فایل ChangeLog است، این فایل گاهی اوقات به صورت CHANGES یا HISTORY هم نام‌گذاری می‌شود (باید توجه داشت که NEWS فایل متفاوتی است که تغییرات بوقوع پیوسته از یک نسخه به نسخه دیگر در آن نوشته می‌شود، نه تغییراتی که از یک کامیت به کامیتی دیگر اتفاق افتاده‌اند). برخی از نگه‌دارنده‌های پروژه‌ها پسوند ‎.txt را هم به انتهای این فایل اضافه می‌کنند. برخی از سیستم‌های نسخه‌بندی قادر به تولید کردن اطلاعاتی هستند که مناسب قرارگرفتن در یک فایل سیاههٔ تغییرات است.

    چرا باید از سیاههٔ تغییرات جهت حفظ تغییرات استفاده شود؟
    برای اینکه کاربران و مشارکت کنندگان به راحتی بدانند که دقیقاً چه تغییرات قابل توجهی بین هر نسخهٔ انتشار یافته و دیگر نسخه‌ها ایجاد شده است، بهتر است از این اصول پیروی شود.
    چه کسانی به سیاههٔ تغییرات نیاز دارند؟
    چه مصرف‌‌کنندگان و چه توسعه‌دهندگان، کاربران نهایی نرم‌افزار، انسان‌هایی هستند که به آنچه در نرم‌افزار تغییر پیدا می‌کند اهمیت می‌دهند؛ هنگامی که نرم‌افزار تغییر پیدا می‌کند، مردم می‌خواهند بدانند که چرا و چطور این تغییرات اعمال شده است. بنابراین استفاده از این قالب علاوه بر ارائهٔ ارزشی در بحث تجربه‌کاربری، در روند توسعه اهمیت بسیاری دارد.
     
    چطور می‌توانم یک سیاههٔ تغییرات خوب ایجاد کنم؟
    راهنمای اصول
    سیاههٔ تغییرات برای انسان‌ها هستند نه ماشین.  برای هر کدام از نسخه‌ها باید یک مدخل وجود داشته باشد.  انواع مشابه تغییرات باید دسته‌بندی شوند.  نسخه‌ها و بخش‌ها باید پیوند پذیر باشند.  آخرین نسخه اول می‌آید.  تاریخ عرضهٔ هر کدام از نسخه‌ها، نمایش داده می‌شود. از استاندارد و اصول نسخه‌بندی معنایی استفاده و آن را رعایت کنید. انواع تغییرات
    Added برای امکانات جدید. Changed برای تغییر در عملکرد موجود. Deprecated برای امکاناتی که به زودی حذف می‌شوند. Removed برای امکانات حذف شده. Fixed برای هر نوع رفع خطا. Security در صورت وجود هرگونه آسیب‌پذیری امنیتی. برای ردیابی تغییرات آتی یک بخش با عنوان Unreleased در بالا نگه‌دارید، این کار دو هدف دارد:
    مردم می‌توانند ببیند که در نسخه‌های آینده چه تغییراتی را می‌توان انتظار داشت. در زمان انتشار، می‌توانید تغییرات بخش Unreleased را به بخش نسخهٔ جدید منتقل کنید. آیا استانداردی برای سیاههٔ تغییرات وجود دارد؟
    حقیقتاً خیر، هرچند سبکی از گنو و همچنین بخشی از فایل خبر گنو به این مورد اشاره دارند، اما این‌ها ناکافی می‌باشند.
    نام فایل سیاههٔ تغییرات چه باید باشد؟
    می‌توانید آن را CHANGELOG.md بنامید. برخی از پروژه‌ها از HISTORY، NEWS و یا RELEASES استفاده می‌کنند. هرچند مهم نیست که نام فایل نهایی این روند چه چیزی باشد، اما طوری باید باشد که کاربر متوجه هدف فایل تغییرات باشد.
    یک مثال از قالب صحیح از سیاههٔ تغییرات
    # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ## [1.0.0] - 2017-06-20 ### Added - New visual identity by [@tylerfortune8](https://github.com/tylerfortune8). - Version navigation. - Links to latest released version in previous versions. - "Why keep a changelog?" section. - "Who needs a changelog?" section. - "How do I make a changelog?" section. - "Frequently Asked Questions" section. - New "Guiding Principles" sub-section to "How do I make a changelog?". - Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo). - German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4). - Italian translation from [@azkidenz](https://github.com/azkidenz). - Swedish translation from [@magol](https://github.com/magol). - Turkish translation from [@karalamalar](https://github.com/karalamalar). - French translation from [@zapashcanon](https://github.com/zapashcanon). - Brazilian Portugese translation from [@Webysther](https://github.com/Webysther). - Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek). - Russian translation from [@aishek](https://github.com/aishek). - Czech translation from [@h4vry](https://github.com/h4vry). - Slovak translation from [@jkostolansky](https://github.com/jkostolansky). - Korean translation from [@pierceh89](https://github.com/pierceh89). - Croatian translation from [@porx](https://github.com/porx). - Persian translation from [@Hameds](https://github.com/Hameds). - Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s). ### Changed - Start using "changelog" over "change log" since it's the common usage. - Start versioning based on the current English version at 0.3.0 to help translation authors keep things up-to-date. - Rewrite "What makes unicorns cry?" section. - Rewrite "Ignoring Deprecations" sub-section to clarify the ideal scenario. - Improve "Commit log diffs" sub-section to further argument against them. - Merge "Why can’t people just use a git log diff?" with "Commit log diffs" - Fix typos in Simplified Chinese and Traditional Chinese translations. - Fix typos in Brazilian Portuguese translation. - Fix typos in Turkish translation. - Fix typos in Czech translation. - Fix typos in Swedish translation. - Improve phrasing in French translation. - Fix phrasing and spelling in German translation. ### Removed - Section about "changelog" vs "CHANGELOG". ## [0.3.0] - 2015-12-03 ### Added - RU translation from [@aishek](https://github.com/aishek). - pt-BR translation from [@tallesl](https://github.com/tallesl). - es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex). ## [0.2.0] - 2015-10-06 ### Changed - Remove exclusionary mentions of "open source" since this project can benefit both "open" and "closed" source projects equally. ## [0.1.0] - 2015-10-06 ### Added - Answer "Should you ever rewrite a change log?". ### Changed - Improve argument against commit logs. - Start following [SemVer](https://semver.org) properly. ## [0.0.8] - 2015-02-17 ### Changed - Update year to match in every README example. - Reluctantly stop making fun of Brits only, since most of the world writes dates in a strange way. ### Fixed - Fix typos in recent README changes. - Update outdated unreleased diff link. ## [0.0.7] - 2015-02-16 ### Added - Link, and make it obvious that date format is ISO 8601. ### Changed - Clarified the section on "Is there a standard change log format?". ### Fixed - Fix Markdown links to tag comparison URL with footnote-style links. ## [0.0.6] - 2014-12-12 ### Added - README section on "yanked" releases. ## [0.0.5] - 2014-08-09 ### Added - Markdown links to version tags on release headings. - Unreleased section to gather unreleased changes and encourage note keeping prior to releases. ## [0.0.4] - 2014-08-09 ### Added - Better explanation of the difference between the file ("CHANGELOG") and its function "the change log". ### Changed - Refer to a "change log" instead of a "CHANGELOG" throughout the site to differentiate between the file and the purpose of the file — the logging of changes. ### Removed - Remove empty sections from CHANGELOG, they occupy too much space and create too much noise in the file. People will have to assume that the missing sections were intentionally left out because they contained no notable changes. ## [0.0.3] - 2014-08-09 ### Added - "Why should I care?" section mentioning The Changelog podcast. ## [0.0.2] - 2014-07-10 ### Added - Explanation of the recommended reverse chronological release ordering. ## [0.0.1] - 2014-05-31 ### Added - This CHANGELOG file to hopefully serve as an evolving example of a standardized open source project CHANGELOG. - CNAME file to enable GitHub Pages custom domain - README now contains answers to common questions about CHANGELOGs - Good examples and basic guidelines, including proper date formatting. - Counter-examples: "What makes unicorns cry?" [Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.0.0...HEAD [1.0.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.3.0...v1.0.0 [0.3.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...v0.3.0 [0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0 [0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.8...v0.1.0 [0.0.8]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.7...v0.0.8 [0.0.7]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.6...v0.0.7 [0.0.6]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...v0.0.6 [0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5 [0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4 [0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3 [0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2 [0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1  
     
     
     
  22. کامبیز اسدزاده
    وب‌اسمبلی (WebAssembly) یا wasm یک فناوری برنامه‌نویسی سطح‌پایین برای استفاده در مرورگر است. هدف اولیهٔ آن پشتیبانی از کامپایل کد‌ها به سی و سی++ است هرچند که قرار است از سایر زبان‌ها نیز حمایت شود. حال کتابخانهٔ Qt این امکان را تحت ماژول Qt WebAssembly فراهم می‌کند تا برنامه‌‌ی نوشته شده توسط سی++ و کیوت در محیط مرورگر قابل اجرا باشند. این ویژگی در حال حاضر به عنوان پیش‌نمایش برای نسخهٔ Qt 5.11 برنامه‌ریزی شده است.
    کیوت برای ساخت وب اسمبلی دستور‌العمل‌هایی را در اینجا آورده است. قبل از هرچیز شما نیاز دارید تا ابزار کامپایلر emsdk را آماده و نصب نمایید. بنابراین دستورات زیر را به ترتیب اجرا کنید.
    # Get the emsdk repo git clone https://github.com/juj/emsdk.git # Enter that directory cd emsdk # Fetch the latest registry of available tools. ./emsdk update # Download and install the latest SDK tools. ./emsdk install latest # Make the "latest" SDK "active" for the current user. (writes ~/.emscripten file) ./emsdk activate latest # Activate PATH and other environment variables in the current terminal source ./emsdk_env.sh در صورتی که در پیکربندی نیاز به راهنمایی دارید از راهنمای اصلی آن استفاده کنید و یا در همین مرجع در تالار‌های گفتمان از ما بپرسید. ما به این ابزار به عنوان ابزار کامپایل-چند‌منظوره استفاده خواهیم کرد.
    برخی از اسکرین شات‌ها از نتایج خروجی این ماژول به صورت زیر آمده‌اند:
    یک بازی ساده به نام Colliding mice

    ویژگی پنجره‌های گفتگو

    به نظر می‌رسد پنجره‌های ساخته شده توسط QOpenGLWindow با فریم ریت ۶۰ به خوبی عمل می‌کنند. البته به نظر می‌رسد QOpenGLWidget فعلاً شامل برخی از مشکلات است که حل خواهند شد. کامپایلر Emscripten که به عنوان یک کامپایلر منبع‌باز که بک اند آن بر روی LLVM اجرا می‌شود کُد‌های OpenGL را به WebGL ترجمه می‌کند. بنابراین محدودیت‌هایی در نسخه‌های دسکتاپ و اِمبد‌ها وجود خواهد داشت.
     
    نمونه مثال پنجره تحت OpenGL

    در کنار این‌ها QtBases و QtDeclarative که از شاخهٔ Wip/Web Assembly استقاده می‌کنند، ماژول‌های شناخته شدهٔ کیوت به صورت زیر به کار گرفته می‌شوند:
    QtCharts QtGraphicalEffects QtQuickControls QtQuickControls2 QtWebSockets QtMqtt (با استفاده از وب سوکت) برای استفاده از QtMqtt، شما باید کلاس WebSocketIODevice از نمونه مثالی با نام (websocketsubscription) وارد برنامهٔ خود کنید.
    نمونه مثال‌های ساعت در QML

    نکته: از آن‌جا که جاوا‌اسکریپت و وب‌اسمبلی تنها یک نخ (Thread) دارند، QtDeclarative تنها برای یک نَخ (ترد) کار خواهد کرد. در نظر داشته باشید که ماژول‌های QtCharts QtGraphicalEffects، QtQuickcontrols، QtQuickControls2 بدون هیچ تغییراتی کار می‌کنند.
    ماژول QtChart از نمونه مثال oscilloscope

    این پروژه به عنوان یک رویکرد جدید و ویژگی‌ای که در آینده می‌تواند مفید باشد در حال توسعه است. بخش ویکی رسمی آن در این لینک آورده شده است.
  23. کامبیز اسدزاده
    برنامه‌نویس تنها در این عنوان خلاصه نمی‌شود و لازم است بدانید که برنامه‌نویسان در چند دسته متفاوت وجود دارند که برخی از آن ها به صورت Back-End و برخی Front-End فعالیت می‌کنند. در کل به کسانی که توانایی برنامه‌نویس در بخش Back-End را دارند به آن‌ها Back-End Developer می‌گویند. همچنین برنامه‌نویسانی که توانایی توسعه در بخش طراحی رابط‌کاربری و تجربه‌کاربری را با عنوان Front-End دارند Front-End Developer می‌گویند.
    در نظر داشته باشید که توسعه‌دهندگان و طراحان بخش تجربه‌‌کاربری (UX) و رابط‌کاربری (UI) خود وظایفی در سمت طراحی یک محصول را دارند که به خودی خود می‌توانند به عنوان توسعه‌دهندهٔ فرانت‌اِند محسوب شوند اما ممکن است زمینهٔ اجرایی آن‌ها با محیط‌های توسعه که شامل کد‌نویسی هستند نباشد! بنابراین شاخه‌ای از حوزهٔ توسعه در نرم‌افزار کامپیوتر وجود دارد که می‌تواند با ترکیب دانش طراحی و کد‌نویسی و تسلط کامل بر این دو حوزه به صورت ترکیبی با دانش و توانایی بسیار بالا عنوان شود که به آن فول‌اِستک می‌گویند.
    البته فول‌اِستک ابعاد مختلفِ خود را دارد، برای مثال ممکن است یک توسعه‌دهندهٔ فول‌اِستک تنها در پلتفرم اندروید توانایی طراحی و کد‌نویسی را به صورت همزمان و بدون نیاز به یار تیمی خود داشته باشد. اما در اصل توسعه‌دهنده‌های با تجربه با سابقهٔ بالا که توانایی مدیریتی پروژه و توسعهٔ آن‌ها را دارند از نوع فول‌اِستک تمام عیار محسوب می‌شوند که در ادامه به ویژگی‌های آن‌ها اشاره شده است.
    یک برنامه‌نویس حرفه‌ای یا همان فول‌اِستک می‌بایست مهارت‌های زیر را داشته باشد:
    مسلط به زبان‌های برنامه‌نویسی پایه آشنایی با UX و UI و مباحث مرتبط با هر یک از آن‌ها مدیریت پروژه بر روی پلتفرم‌های مختلف توانایی کنترل کیفیت محصول توانایی کار با انواع فناوری‌ها و کتابخانه‌ها توانایی کار با انواع دیتابیس و مدیریت آن‌ها هک و امنیت بهینه سازی موتور‌های جستجو آشنایی و توانایی درک و مدیریت کامپایلر‌ها و مفسر‌ها درک نیاز‌های کاربران در محصول (UX) آشنایی با سیستم عامل‌های مختلف آشنایی و توانایی تولید محصول به صورت چند-سکویی (Cross-Platform) آشنایی با شبکه و پیکربندی آن برای محصول آشنایی با مدیریت سرور و هاستینگ آشنایی با سیستم‌های مدیریتی و مجازی مانند VM آشنایی با سخت افزار آشنایی با رابط های برنامه نویسی API‌ها آشنایی با انواع محیط‌های توسعه و موارد دیگر که در یک پروژه از صفر تا صد می‌توان به آن‌ها نیاز پیدا کرد.  برنامه‌نویسان Full-Stack Developer به تنهایی می‌تواند درتولید و توسعه یک محصول موثر باشد و زمانی که با مشکلی مواجه شوند نمی‌گوید من آن را بلد نیستم، بلکه حتماً آن را حل خواهند کرد. به طور کلی کسب مهارت در سطح بالا در حد یک توسعه‌‌ دهنده فول‌اِستک بسیار سخت است اما نباید بگوییم که غیر ممکن است، در صورتی که چنین تعریفی برای یک توسعه‌دهندهٔ فول‌استک در نظر بگیریم، بدون اغراق باید گفت تعداد اندکی از این برنامه‌نویسان موجود است که بتوانیم چنین لقبی را به آن‌ها اختصاص بدهیم بنابراین چنین برنامه‌نویسانی بسیار ارزشمند هستند لذا به خوبی می‌دانند یک نرم افزار چگونه طراحی‌ می‌شود و توانایی این را دارند از صفر تا صد یک نرم‌افزار را طراحی و روانه بازار کنند. علاوه بر این توسعه دهنده Full-Stack کسی است که واژگانی مانند نبود، نمی‌شه، امکان نداره، نمی‌توم، کار من نیست و ... را بر زبان نمی‌آورند و اگر هم چیزی را ندانند تمام تلاش خود را می‌کنند تا بدون نیاز به کمک شخصی دیگر آن را حل کنند. این نوع توسعه‌‌دهنده‌ها بسیار با ارزش و مهم هستند، و نکته جالب اینجاست که آن‌ها سال‌ها تلاش کرده‌اند و مسلماً به تنهایی صاحب کسب‌و‌کار خود بوده و در انتخاب اول برای کسی کار نمی‌کنند.
    برای توسعه دهندهٔ فول‌اِستک فرقی نمی‌کند محصول تحت چه پلتفرمی باشد، او می‌تواند تحت دسکتاپ، وب، موبایل و دیگر پلتفرم ها آن را تولید کند.
  24. کامبیز اسدزاده
    مایکروسافت قصد دارد با اعمال فناوری گرافیکی سایه‌زنی با نرخ متغیر در DirectX 12 ضمن افزایش نرخ فریم همگام با افزایش کیفیت بصری، از الزامات سخت‌افزاری اجرای بازی‌ها بکاهد.

    مایکروسافت فناوری سایه‌زنی با نرخ متغیر (Variable Rate Shading) را به DirectX 12 وارد کرده است. بدین ترتیب توسعه‌دهندگان با اتکا بر این نوع سایه‌زنی قادر خواهند بود سطح عملکرد در محیط‌های گرافیکی نظیر بازی‌ها را بهبود ببخشند، کیفیت بصری بازی را افزایش داده و منابع مورد نیاز سیستم برای اجرای بازی را کاهش دهند.
    مایکروسافت از توسعه‌دهندهٔ بازی‌های ویدئویی Firaxis خواسته است که این نوع سایه‌زنی را در یکی از بازی‌های خود پیاده‌سازی کند تا نشان دهد که کاربرد روش VRS تا چه اندازه ساده و تأثیر آن برعملکرد عناوین مختلف تا چه اندازه چشمگیر خواهد بود. در قسمت سمت چپ تصویر زیر، تأثیر VRS در عمل دیده می‌شود. گرچه دو سمت تصویر یکسان به نظر می‌رسد، بنا به گزارش Firaxis در نقشهٔ زیر و در چنین سطحی از بزرگنمایی، با اعمال VRS شاهد ۱۴ درصد افزایش در خروجی فریم خواهیم بود.
    البته باید به سطح عملکرد گزارش شده توسط Firaxis با جانب احتیاط نگریست. ما از شرایط انجام آزمایش بی‌خبریم، قابلیت VRS را هنوز نیازموده‌ایم و حتی ممکن است تصاویر و آمار منتشرشده راهی برای تبلیغ فناوری گرافیکی جدید مایکروسافت باشد. بنابراین قضاوت در مورد میزان تأثیر سایه‌زنی با توان متغیر را باید به زمانی پس از آزمایش عمومی این قابلیت موکول کرد.
    در هر صورت، فناوری «سایه‌زنی با نرخ متغیر» مایکروسافت در دسترس توسعه‌دهندگان قرار دارد و بسیاری از شرکت‌های صاحب‌نام قصد استفاده از آن را در محصولات بعدی خود دارند. توسعه‌دهندگانی مانند 343 Industries، شرکت Playground Games و Massive Entertainment در کنار ناشرانی مثل Ubisoft و Activision و سازندگان موتورهای بازی نظیر Unity و Epic Games در فهرست شرکت‌هایی قرار دارند که بناست از این قابلیت در عناوین آیندهٔ خود استفاده کنند.
    طرز کار فناوری VRS
    همان‌طور که از نام «سایه‌زنی با نرخ متغیر» پیدا است، در این روش به‌جای تمرکز بر رندر شیدرها با رزولوشن و جزییات یکسان (که مفهومی متمایز از رزولوشن کلی است)، توان سایه‌زنی (قدرت پردازشی یا به عبارتی نرخ کلاک هسته‌های سایه‌زن) متغیری را در ترسیم بافت‌های گرافیکی بخش‌های مختلف هر فریم می‌توان به‌کار گرفت. این فناوری با تغییر تعداد پیکسل‌هایی کار می‌کند که در یک عملیات سایه‌زنی پیکسل واحد پردازش‌پذیر هستند.
    براساس اعلام مایکروسافت، توسعه‌دهندگان می‌توانند به‌صورت گزینشی توان سایه‌زنی را در مناطقی از فریم که تأثیر چندانی بر کیفیت بصری نداشته باشد، کاهش دهند و حداکثر قدرت واحدهای سایه‌زن را معطوف به مناطقی کنند که جزئیات تصویری بالاتری در آن‌ها موردنیاز است. بنابراین توسعه‌دهندگان خواهند توانست در مناطقی که در آن شیدرها اهمیت بیشتری دارند، توان سایه‌زنی را افزایش دهند تا کیفیت تصویر بهتری در خروجی بازی‌های خود دریافت کنند.
    در پایان سطح عملکرد بالاتر و کیفیت تصویری بهتری را می‌توان به دست آورد؛ درحالیکه منابع سخت‌افزاری مورد نیاز کمتری برای اجرای بهتر بازی‌ها نسبت به قبل لازم خواهد شد.API سایه‌زنی با نرخ متغیر به توسعه‌دهندگان اجازه خواهد داد توان سایه‌زنی را به سه روش تنظیم کنند: روش‌های per-draw، روش within-draw با استفاده از یک تصویر screenspace و روش within-draw به حالت per-primitive. همچنین دو ردهٔ پشتیبانی از VRS وجود دارد. در ردهٔ نخست از VRS در حالت per-draw و در ردهٔ دوم از VRS هم در حالت per-draw و هم در حالت within-draw پشتیبانی می‌شود. همچنین حالت ترکیبی سایه‌زنی با توان متغیر (VRS Combiners) پیش‌بینی شده است که امکان استفادهٔ همزمان از VRS به روش per-draw و per-permitive را ممکن می‌سازد.
    براساس ادعای مایکروسافت، قابلیت سایه‌زنی با نرخ متغیر با سخت‌افزارهای موجود شرکت انویدیا برخوردار از معماری تورینگ و نیز سخت‌افزارهایی که در آینده توسط اینتل ارائه خواهد شد، پشتیبانی می‌شود. اینتل هم‌اکنون در حال آزمایش سایه‌زنی با نرخ متغیر روی تراشه‌های اولیهٔ گرافیکی نسل ۱۱ خود است که برنامه‌ریزی برای عرضهٔ آن‌ها در سال جاری وجود دارد. احتمالا پردازنده‌های گرافیکی مجزای اینتل (نسخه‌های دسکتاپ آینده) نیز از این فناوری گرافیکی پشتیبانی کند.
  25. کامبیز اسدزاده
    پس از انتشار مقاله اختصاصی Intel در زمینه گرافیک مجتمع نسل جدید آن با نام Gen 11 و پس از آن جنجالی که با اولین بنچمارک در رزولوشن 1080p ادامه یافت، در تعطیلات نوروزی حسابی سر و صدایی به پا کرده است؛ این تراشه گرافیکی مجتمع در چند پلتفرم پردازشی CPU محور اینتل نصب خواهد شد و بد نیست بدانید که اولین نسل با نام Ice Lake شناخته خواهند شد.

    اینتل به تازگی یک درایور جدید برای تراشه های گرافیکی خود در ویندوز 10 را منتشر کرده است که به همراه داشبورد و برنامه نرم افزاری جدیدی است که به تازگی اخبار آن را برای شما عزیزان پوشش داده بودیم؛ اما نکته ای که در این درایور به چشم می خورد، لو رفتن عمدی یا سهوی اسامی برخی از CPU و تراشه های گرافیکی داخلی است که اینتل به زودی معرفی خواهد کرد.
    در این لیست 13 نوع تراشه با معماری جدید گرافیکی Gen11 به چشم می خورند که از نسل Ice Lake خواهند بود. گرافیک مجتمع Iris Plus Graphics 950 قوی ترین پردازشگر این نسل است که دارای 64 واحد EU خواهد بود. این تراشه گرافیکی در پردازنده های Core i7 و Core i9 نیز نصب خواهد شد. گرافیک دوم با نام Iris Plus Graphics 940 شناخته می شود که در پردازنده های Core i5 نیز مورد استفاده قرار می گیرند. Iris Plus Graphics 940 ها با همین تعداد واحد EU دارای فرکانس پایین تری هستند.
    سپس Iris Plus 930 و Iris Plus 920 را شاهد هستیم که تعداد واحد های EU آنها نیز 48 و 32 عدد است. iGPUهای Gen11 همچنان در مدل های کلیدی GT1 و GT2 معرفی می شوند. برای اطلاعات بیشتر به زمان بیشتری نیاز داریم. شایان ذکر است که لیتوگرافی تولید در این نسل به 10 نانومتری کاهش یافته است.
×
×
  • جدید...

اطلاعات مهم

شرایط استفاده

  قبول میکنم