وبلاگ‌های سایت ما

1. 

   طراحی و توسعه

   یک وبلاگ گروهی توسط طراحی و توسعه

   • 15
     نوشته‌
   • 1
     دیدگاه
   • 3309
     مشاهده

   نوشته‌های اخیر

   • اصول طراحی: ثبات و سازگاری
   • معرفی مناسب‌ترین فونت‌ها و اصول استفاده در طراحی U…
   • ۸ مهارتی که هر تیم تجربه‌ کاربری شرکتی نیاز دارد
   • کدام میزبانی وب مناسب است؟
   • ۱۵ اصول راهبردی برای محققان UX

   

   آخرین نوشته
   

   اصول طراحی: ثبات و سازگاری

   توسط الهه انصاری، 20 شهریور 1399

   

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

   اصل ثبات در طراحی چیست؟

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

   مزایای ثبات و یکپارچگی

   کاربران، نحوهٔ استفاده از طرح شما را سریع‌تر یاد می‌گیرند. فرض کنید که عناصر سازگار در طراحی شما همان حروف الفبا هستند. وقتی کاربر الفبای شما را یاد گرفت، می‌تواند به هر قسمتی از محصول برود و بتواند بدون هیچ مشکلی با رابط ارتباط برقرار کند.
   داشتن رابط متناقض همانند تلاش برای برقراری ارتباط با کاربر به چندین زبان است. در این حالت فقط کاربران پیشرفته و حرفه‌ای قادر به انجام کارهای خود خواهند بود؛ بنابراین باید رابط ساده و سازگاری داشته باشید.
   ثبات و سازگاری، سردرگمی را از بین می‌برد! وقتی کاربر احساس سردرگمی کند، مرحلهٔ بعدی احساس ناامیدی است. ما نمی‌خواهیم کاربر عزیز ما این گونه احساس کند، نه؟
   ثبات باعث صرفه جویی در هزینه و زمان می‌شود! طراحی سازگار اغلب توسط اجزای از پیش تعریف شده ساخته می‌شود. این امر به طراحان و ذینفعان اجازه می‌دهد تا بدون صرف وقت با ارزش برای استدلال، سریع تصمیم بگیرند. این مورد باعث صرفه جویی در وقت میشود که میتواند برای ساخت محصول و پیشرفتهای چشمگیر و افزایشی به کار گرفته شود.

    

   چهار نوع مختلف ثبات و سازگاری

   بیایید چهار نوع سازگاری را بررسی کنیم که مهم است که هنگام طراحی از آن آگاه باشید.

   سازگاری بصری
   عناصر مشابه که به همان شیوه درک می شوند ، قوام بصری را تشکیل می دهند. این باعث افزایش یادگیری محصول می شود. برای حفظ قوام بینایی ، قلم ها ، اندازه ها ، دکمه ها ، برچسب زدن و موارد مشابه باید در سراسر محصول باشند.

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

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

   سازگاری خارجی
   این نوع سازگاری زمانی حاصل میشود که ثبات طراحی در چندین سیستم یا محصول وجود داشته باشد. به این ترتیب میتوان از دانش کاربر برای یک محصول در محصول دیگر استفاده مجدد کرد. بله، این به از بین بردن بسیاری از اصطکاکها کمک می کند و تجربه‌ٔ کاربری خوبی را ارائه میدهد. مثال خوب سازگاری خارجی رابط کاربری محصولات Adobe است. هنگامی که کار با فتوشاپ را میدانید استفاده‌ٔ‌ مجدد از همان دانش برای استفاده از Illustrator و غیره بسیار سادهتر است.

   دستیابی به این چهار نوع سازگاری به طراحی شما کمک میکند تا از قابلیت استفادهٔ بهتر و استفاده کنندگان خوشحالتری برخوردار شود.

    

   چگونه سازگاری را فراهم کنیم؟ 

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

   عوامل بصری

   تایپوگرافی، رنگ‌ها، فضا، شبکه (grid)، اندازه و موقعیت‌ها؛ این عناصر باید در یک مکان مرکزی تعریف شده و سپس در کل سیستمی که طراحی می‌کنید استفاده شوند. سلسله مراتب بصری قوی تعریف کنید؛ به طوری که مهم‌ترین موارد، بزرگ‌تر از موارد کم اهمیت‌تر باشند. از همان پالت رنگی در سراسر محصول استفاده کنید. حاشیه‌ٔ داخلی (padding) و حاشیه‌ٔ خارجی (margin) باید در تمام عناصر مشابه (دکمه‌ها، کارت‌ها و غیره) سازگار باشند. همه چیز را باید در یک شبکه به انتخاب خود مرتب کنید که امکان چیدمان همه‌ٔ اجزا را به روشی زیبا و ظریف فراهم کند. داشتن عوامل بصری سازگار به کاربر این امکان را می‌دهد تا سیستم را سریع یاد بگیرد و تجربه‌ای روان و دلنشین داشته باشد. وقتی از عوامل بصری سازگار استفاده می‌کنید، طراحی شما از فنگ شویی خوبی بهره خواهد برد. در این لینک نمونه‌های مناسبی با دستورالعمل‌هایی از این سبک آورده شده است.

   صدا و لحن

   زبان و لحنی که شما در کل جریان کاربر استفاده می‌کنید، بر نحوه‌ٔ درک کاربر از محصول تاثیر می‌گذارد. صدا و لحن را در حالت ثبات و سازگاری حفظ کنید تا ارتباط گیرا، مختصر و مفیدی با کاربر شکل بگیرد. ما نمی‌خواهیم ذهن کاربر خیلی درگیر و شلوغ شود، مگر نه؟
   اگر می‌خواهید صدایی بامزه و دوستانه در طراحی محصول خود داشته باشید، این کار را تا دریافت پیام‌های خطا ادامه دهید. MailChimp نمونه‌ی خوبی از صدا و لحن سازگار است.

   

    

   از الگوهای آشنا استفاده کنید

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

   

   http://www.mobile-patterns.com

   ما باید از این مورد استفاده کنیم و الگوهای آشنا را در طراحی‌های خود بگنجانیم. در این صورت سفر کاربر بسیار روان‌تر خواهد بود و افراد حتی فکر نمی‌کنند که «هوم، چگونه از این استفاده کنم؟»؛ آن‌ها مستقیما بدون درنگ از آن بهره می‌برند.
   در این دو منبع، موارد خوبی برای بررسی الگوهای مختلف وجود دارد: Mobile Patterns و Design Patterns.

    

   ثبات را به دست آورید، آن‌ها را بر هم نزنید

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

   

   این مسئله هم برای کاربر و هم برای سازمان یک درد است. روند طراحی کند می‌شود. کلی سرمایه‌ٔ اضافی صرف می‌شود تا افراد در اتاق جلسات بر سر این که بهترین رنگ برای آن دکمه چیست، بحث کنند. هر کسی زمان ارزشمند خود را از دست می‌دهد تا تصمیماتی بگیرد که پیش از این باید اتخاذ شده و اکنون دوباره مورد استفادهٔ مجدد قرار گیرد. طراحان باید تا حد امکان ثبات را حفظ و ایجاد کنند.
   ثابت نگه داشتن امور به معنای کند شدن تغییر است. ما هنوز هم نیاز داریم که محصولمان لذت بخش و جذاب باشد. ما به آن‌ها نیاز داریم تا به نسخه‌ی بهتری تبدیل شوند.
   بنابراین، چگونه باید ثابت قدم بمانیم و همچنان به موقعیتی که می‌خواهیم برسیم و تغییر کنیم؟
   «راز» این کار در درک کاربران است. تمام تصمیمات طراحی شما باید از همین درک حاصل شود. فقط درصورتی که سیستم مورد نظر شما از نیاز کاربر مطلع شده باشد، تنظیمات را اعمال کنید. انجام این تغییرات کوچک، محصول را به نسخهٔ بهتری مبدل ساخته و ثبات آن را حفظ می‌کند.

    

   افکار نهایی

   طراحی خود را با انتظارات کاربران هماهنگ کنید. کاربران خود را بشناسید دقیقا همان طور که شریک زندگی خود را می‌شناسید. قادر باشید از زاویه‌ٔ دید آن‌ها نگاه کنید و از طریق قلب آن‌ها احساس کنید. با آن‌ها یکی شوید.
   آن را با درک کامل از اصول طراحی مانند سلسله مراتب بصری، تایپوگرافی، الگوهای کاربردی و غیره ترکیب کنید. به یاد داشته باشید که تغییرات اندک خوب است اما تغییر بیشتر لزوما بهتر نیست! ثبات را ایجاد کنید تا قابلیت استفاده را بهبود بخشید و با کاهش اجزای غیر منتظره، لذت وصف ناپذیری در تجربه‌ٔ کاربر ایجاد نمایید.

   منبع

   امیدوارم مطالب برای شما همراهان عزیز مفید واقع شوند. با نظرات ارزنده‌ٔ خود ما را در این مسیر یاری کنید

   • ادامه مطلب...
   • 0 دیدگاه
2. 

   فناوری

   یک وبلاگ گروهی توسط فناوری

   • 14
     نوشته‌
   • 2
     دیدگاه
   • 3339
     مشاهده

   نوشته‌های اخیر

   • اکنون ++C سریع‌ترین رشد را بین زبان‌های برنامه‌نوی…
   • سریع‌ترین فریم‌ورک‌های وب!
   • آیندهٔ توسعهٔ وب تحت فناوری WebAssembly
   • چهار زبان برتر برنامه‌نویسی برای بلاک‌چین
   • ویندوز 10 در به‌روز‌رسانی بعدی خود مرورگر Edge را …

   

   آخرین نوشته
   

   اکنون ++C سریع‌ترین رشد را بین زبان‌های برنامه‌نویسی دارد

   توسط کامبیز اسدزاده، 20 شهریور 1399

   مدتی قبل بود که من در رابطه با شاخص‌های در حال رشد زبان‌های برنامه‌نویسی در کانال‌های شخصی نظری داده بودم که با توجه به وضعیت شاخص، زبان‌ برنامه‌نویسی ++C سریع‌ترین رشد را بعد از مدت‌ها به خود اختصاص داده است.

   

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

   

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

   

   با این حال مدیرعامل Tobie جناب Paul Jansen گفته است، من فکر می‌کنم که استاندارد جدید سی++ یکی از دلایل این رشد اصلی باشد. به خصوص ویژگی‌های جدید module که قرار است جایگزین مکانیزم وحشتاک قبلی شود. با این روند سی++ بیشترین رشد‌ها که متعلق به #C با ۱.۱۸+ و R با ۱.۳۳+ را شکست می‌دهد.

   • ادامه مطلب...
   • 0 دیدگاه
3. 

   برنامه نویسی

   یک وبلاگ گروهی توسط برنامه نویسی

   • 17
     نوشته‌
   • 13
     دیدگاه
   • 4475
     مشاهده

   نوشته‌های اخیر

   • قسمت اول معماری CPP: مبحث Overloading و Name Mangl…
   • معرفی و راهنمای استفاده از نسخه‌بندی معنایی
   • کتابخانه‌های استاتیک و داینامیک (پویا)
   • چشم‌انداز فنی برای کیوت ۶
   • آشنایی با سرویس میزبانی صفحات گیت هاب (Github Page…

   

   آخرین نوشته
   

   قسمت اول معماری CPP: مبحث Overloading و Name Mangling و Template و Auto

   توسط clightning، 5 دی 1398

    

   هنگامیکه شما برای اولین بار از C به CPP مهاجرت می کنید، یا اصلا برنامه نویسی را قصد دارید با CPP شروع کنید، با مفاهیم متعددی روبرو خواهید شد که شاید برای شما جالب باشند که بدانید، این ایده ها چطور شکل گرفتند، چطور به CPP افزوده شدند و اهمیت آن ها در عمل (هنگام برنامه نویسی و توسعه نرم افزار) چیست. در این پست وبلاگی IOStream، به این خواهیم پرداخت که ایده Overloading و Template و Auto Deduction چطور از CPP سر در آوردند. 

   همانطور که شما ممکن است تجربه کرده باشید، هنگامیکه برنامه نویسی و توسعه نرم افزاری را با C شروع می کنید، برنامه شما چیزی بیش از یک مجموعه بی انتها از توابع و استراکچرها و متغیرها و اشاره گرها و ... نخواهند بود.

   از همین روی شما مجبور هستید مبتنی بر ایده مهندسی نرم افزار و پارادیم برنامه نویسی ساخت یافته، برای هر کاری یک تابع منحصربفرد پیاده سازی کنید. این تابع باید از هر لحاظی از قبیل نام، نوع ورودی ها، نوع خروجی و حتی نوع عملکرد منحصربفرد باشد تا بتواند یک کار را به شکل صحیح کنترل کند که همین مسئله می تواند در پیاده سازی برخی نرم افزارها، انسان را در جهنم داغ و سوزان قرار بدهد. مثلا پیاده سازی یک برنامه محاسباتی مانند ماشین حساب که ممکن است با انواع داده های محاسباتی مانند عدد صحیح (Integer) و عدد اعشاری (Float) رو به رو شود. 

   از همین روی فرض کنید، ما قرار است یک عمل محاسباتی مانند جمع از برنامه ماشین حساب را پیاده سازی کنیم. برای اینکه برنامه به شکل صحیحی کار کند، باید عمل جمع یا همان Add برای انواع داده های موجود از قبیل عدد صحیح و اعشاری پیاده سازی شود. اگر شما این کار را انجام ندهید، برنامه شما به شکل صحیحی کار نخواهد کرد (یعنی نتایج اشتباه ممکن است برای ما تولید کند). در تصویر زیر، نمونه این برنامه و توابع مرتبط با آن پیاده سازی شده است:

   #include <stdio.h>
   
   int AddInt(int arg_a, int arg_b)
   {
   	return arg_a + arg_b;
   }
   
   float AddFloat(float arg_a, float arg_b)
   {
   	return arg_a + arg_b;
   }
   
   double AddDouble(double arg_a, double arg_b)
   {
   	return arg_a + arg_b;
   }
   
   int main(int argc, const char* argv[])
   {
   	int result_int = AddInt(1, 2);
   	float result_float = AddFloat(10.02f, 21.23f);
   	double result_double = AddDouble(9.0, 24.3);
   
   	printf("Result Integer: %d", result_int);
   	printf("Result Float: %f", result_float);
   	printf("Result Double: %lf", result_double);
   
   	return 0;
   
   }

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

   ولی به هر صورت، اگر به خروجی دیزاسمبلی برنامه مشاهده کنید، دلیل این مسئله را متوجه خواهید شد که چرا هنگام برنامه نویسی با زبان C، به نام های منحصربفرد نیاز است، چون اگر توابع نام های مشابه با هم داشته باشند، لینکر نمی تواند به دلیل تداخل نام (Name Conflict)، آدرس آن ها را محاسبه یا اصطلاحا Resolve کند.

   

   همانطور که در تصویر بالا خروجی دیزاسمبلی برنامه Add را مشاهده می کنید، اگر توابع نام مشابه داشتند، در هنگام فراخوانی (Call) تابع Add تداخل رخ می داد، چون دینامیک لودر سیستم عامل دقیقا نمی داند که کدام تابع را باید فراخوانی کند. برای همین نیاز است وقتی برنامه نوشته می شود، نام توابع در سطح کدهای اسمبلی و ماشین منحصر بفرد باشد.

   به هر صورت، به نظر شما آیا راهی وجود دارد که ما پیاده سازی این نوع توابع را ساده تر کنیم یا حداقل بار نامگذاری آن ها را از روی دوش توسعه دهنده و برنامه نویس برداریم؟ بله امکان این کار وجود دارد. مهندسان CPP با افزودن ویژگی Overloading و Name Mangling یا همان بحث Decoration مشکل برنامه نویسان در پیاده سازی توابع با نام های منحصربفرد را حل کردند (البته کاربردهای دیگر هم دارد که فعلا برای بحث ما اهمیت ندارند).

   ویژگی اورلودینگ در CPP به ما اجازه خواهد داد یک تابع با عنوان Add پیاده سازی کنیم که تفاوت آن ها فقط در نوع ورودی و نوع خروجی است. به عنوان مثال، در قسمت زیر، کد برنامه Add را مشاهده می کنید که با قواعد CPP بازنویسی شده است.

   #include <iostream>
   
   int Add(int arg_a, int arg_b)
   {
   	return arg_a + arg_b;
   }
   
   float Add(float arg_a, float arg_b)
   {
   	return arg_a + arg_b;
   }
   
   double Add(double arg_a, double arg_b)
   {
   	return arg_a + arg_b;
   }
   
   int main(int argc, const char* argv[])
   {
   	int result_int = Add(1, 2);
   	float result_float = Add(10.02f, 21.23f);
   	double result_double = Add(9.0, 24.3);
   
   	std::cout << "Result Integer: " << result_int << std::endl;
   	std::cout << "Result Float: " << result_float << std::endl;
   	std::cout << "Result Double: " << result_double << std::endl;
   
   	return 0;
   
   }

   همانطور که مشاهده می کنید، ما اکنون سه تابع با نام Add داریم. ولی شاید سوال پرسیده شود که چطور لینکر متوجه تفاوت این توابع با یکدیگر می شود درحالیکه هر سه دارای یک نام واحد هستند. اینجاست که مسئله Name Mangling یا همان Decoration نام آبجکت ها در CPP مطرح می شود. اگر شما برنامه مذکور را دیزاسمبل کنید، متوجه تفاوت کد منبع (Source-code) و کد ماشین/اسمبلی (Machine/Assembly-code) خواهید شد. 

   

   همانطور که در خروجی دیزاسمبلی برنامه اکنون مشاهده می کنید، توابع اگرچه در سطح کد منبع دارای نام مشابه با یکدیگر بودند، اما بعد کامپایل نام آن ها به شکل بالا تبدیل می شود. به این شیوه نام گذاری Name Mangling یا Decoration گویند که قواعد خاصی در هر کامپایلر برای آن وجود دارد.

   این ویژگی موجب می شود در ادامه لینکر بتواند تمیز بین انواع توابع Add شود. به عنوان مثال، تابع نامگذاری شده با عنوان  j__?Add@YAHH@Z تابعی است که به نوعی از تابع Add اشاره دارد که ورودی هایی از نوع عدد صحیح دریافت می کند. این شیوه نامگذاری خلاصه موجب خواهد شد لینکر بتواند به سادگی بین توابع تمایز قائل شود.

   با این حال هنوز یک مشکل باقی است، و آن هم تکرار مجدد یک پیاده سازی برای هر تابع است. به نظر شما آیا راهی وجود دارد که ما از پیاده سازی مجدد توابعی که ساختار مشابه برای انواع ورودی ها دارند، جلوگیری کنیم؟ باید بگوییم، بله. این امکان برای شما به عنوان توسعه دهنده CPP در نظر گرفته شده است.

   ویژگی که اکنون به عنوان Templateها در مباحث Metaprogramming یا Generic Programming استفاده می شود، ایجاد شده است تا این مشکل را اساساً برای ما رفع کند. با استفاده از این ویژگی کافی است، طرح یا الگوی یک تابع را پیاده سازی کنید، تا در ادامه خود کامپایلر مبتنی بر ورودی هایی که به الگو عبور می دهید، در Backend، یک نمونه تابع Overload شده مبتنی بر آن الگو برای نوع داده شما ایجاد کند. 

   #include <iostream>
   
   template <typename Type>
   Type Add(Type arg_a, Type arg_b)
   {
   	return arg_a + arg_b;
   }
   
   int main(int argc, const char* argv[])
   {
   	int result_int = Add(1, 2);
   	float result_float = Add(10.02f, 21.23f);
   	double result_double = Add(9.0, 24.3);
   
   	std::cout << "Result Integer: " << result_int << std::endl;
   	std::cout << "Result Float: " << result_float << std::endl;
   	std::cout << "Result Double: " << result_double << std::endl;
   
   	return 0;
   
   }

   به عنوان مثال، در بالا تابع Add را مشاهده می کنید که نوع داده ورودی این تابع و حتی نوع خروجی آن مشخص نشده است و در قالب Typename به کامپایلر معرفی شده است. این یک الگو برای تابع Add است. کامپایلر اکنون می تواند مبتنی بر ورودی هایی که به تابع هنگام فراخوانی یا اصطلاحا Initialization عبور می دهیم، یک نمونه تابع Overload شده از آن الگو ایجاد کند و در ادامه آن را برای استفاده در محیط Runtime فراخوانی کند. حال اگر برنامه بالا را دیزاسمبل کنید، مشاهده خواهید کرد که کامپایلر از همان قاعده Overloading استفاده کرده است تا نمونه ای از تابع Add متناسب با نوع ورودی هایش ایجاد کند.

   

   هنوز می توان برنامه نویسی با CPP را جذاب تر و البته ساده تر کرد، اما چطور؟ همانطور که در قطعه کد بالا مشاهده می کنید، هنوز ما باید خود تشخیص دهیم که نوع خروجی تابع قرار است به چه شکل باشد. این مورد خیلی مواقع مشکل ساز خواهد بود.

   برای حل این مسئله، در CPP مبحثی در نظر گرفته شده است که آن را به عنوان Auto Deduction می شناسیم که سطح هوشمندی کامپایلر CPP را بالاتر می برد. در این ویژگی خود کامپایلر است که مشخص می کند نوع یک متغیر مبتنی بر خروجی که به آن تخصیص داده می شود، چیست. به عنوان مثال، شما می توانید برنامه بالا را به شکل زیر بازنویسی کنید:

   #include <iostream>
   
   template <typename Type>
   auto Add(Type arg_a, Type arg_b)
   {
   	return arg_a + arg_b;
   }
   
   int main(int argc, const char* argv[])
   {
   	auto result_int = Add(1, 2);
   	auto result_float = Add(10.02f, 21.23f);
   	auto result_double = Add(9.0, 24.3);
   
   	std::cout << "Result Integer: " << result_int << std::endl;
   	std::cout << "Result Float: " << result_float << std::endl;
   	std::cout << "Result Double: " << result_double << std::endl;
   
   	return 0;
   
   }

   با استفاده از ویژگی Auto Deduction و کلیدواژه Auto در برنامه، خود کامپایلر در ادامه مشخص خواهد کرد که تابع Add چه نوع خروجی دارد و همچنین نوع متغیرها برای ذخیره سازی خروجی Add چه باید باشد. به عبارتی اکنون تابع Add هم Value و هم Data type را مشخص می کند که این موجب می شود برنامه نویسی با CPP خیلی ساده تر از گذشته شود. حال اگر به نمونه برنامه آخر نگاه کنید و آن را با نمونه C مقایسه کنید، متوجه خواهید شد که CPP چقدر کار را برای ما ساده تر کرده است.

   در این پست به هر صورت، قصد داشتم به شما نشان دهم که نحوه تحول CPP به صورت گام به گام چطور بوده است و البته اینکه پشت هر ویژگی در CPP چه منطق کلی وجود دارد. امیدوارم این مقاله برای شما مفید بوده باشد. نمونه انگلیسی این مقاله را می توانید در این آدرس (لینک) مطالعه کنید.

   میلاد کهساری الهادی

   • ادامه مطلب...
   • 3 دیدگاه
4. 

   نرم‌افزار و اپلیکیشن

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

   • 5
     نوشته‌
   • 2
     دیدگاه
   • 2552
     مشاهده

   نوشته‌های اخیر

   • از تلفن همراه تا سکوی گیت هاب!
   • پشت پردهٔ تحریم‌های اپل و وضعیت کنونی اپلیکیشن‌های…
   • محدودیت‌های اپل گریبان شرکت‌های ایرانی را گرفت!
   • مرورگر گوگل کروم بازطراحی شد
   • زبان فارسی به گوگل مپ اضافه شد

   

   آخرین نوشته
   

   از تلفن همراه تا سکوی گیت هاب!

   توسط Max Base، 28 آذر 1398

   سلام.

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

   چک کردن حساب ایمیل در تلفن همراه می توانست تا حدودی به این موضوع کمک کند. اما یک اپلیکیشن اختصاصی برای این مورد می تواند این امر را به بهترین شکل پوشش دهد.

   بعد از کارهایی که برروی اپلیکیشن رسمی شرکت گیت هاب برای پلتفرم iOS انجام شد و خوشبختانه بدون هیچ مشکلی در بزرگ رویداد و کنفرانس شرکت و مایکروسافت - GitHub Universe 2019 در تاریخ November 13-14, 2019 رونمایی شد. به عنوان یکی از اعضای شرکت این نوید را می دهم که نوبت به آن رسید تا اپلیکیشن برای اندروید نیز پیاده شود.

   در حال حاضر این اپلیکیشن در حال توسعه است و هنوز رونمایی نشده است.

   برای این اپلیکیشن میزان پشتیبانی API 21+ Android device در نظر گرفته شده است و خواهد توانست از نسخه Android 5.0 به بالا را پشتیبانی کند.

   می توانید پیشنهادات و نظرات خود را نیز ایمیل کنید. Max [@] Asrez {.DOR.} com

   Hi, I'm Max Base.

   GitHub team did work on the official GitHub application for the iOS platform and fortunately unveiled at the big event and conference(GitHub Universe 2019 on November 13-14, 2019). As a member of the company, I have the promise that the app will launch for Android.

   This app is currently under development and has not been unveiled yet.

   This app is designed to support Android 21+ API and will support Android 5.0 or later.

   You can also email your suggestions and comments. Max [@] Asrez {.DOR.} com

   Best,

   Max Base

   

    

   

   

    

   

   

   

   

   با تشکر

   Max Base / مکس بیس

   • ادامه مطلب...
   • 0 دیدگاه
5. 

   ابزار‌ها

   یک وبلاگ گروهی توسط ابزار‌ها

   • 11
     نوشته‌
   • 3
     دیدگاه
   • 2623
     مشاهده

   نوشته‌های اخیر

   • معرفی سیاهه تغییرات و راهنمای استفاده از آن
   • کاربران GitHub اکنون مخازن خصوصی را به صورت رایگان…
   • چگونه کد خود را زیبا کنیم؟
   • اسلک تمام ایرانی‌ها در همه نقاط جهان را تحریم کرد
   • انتشار SoNebuntu Light: نسخه سبک توزیع لینوکس مخصو…

   

   آخرین نوشته
   

   معرفی سیاهه تغییرات و راهنمای استفاده از آن

   توسط کامبیز اسدزاده، 7 آبان 1398

   معرفی سیاههٔ تغییرات (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
   

    

    

    

    

   • ادامه مطلب...
   • 0 دیدگاه
6. 

   استارتاپی

   یک وبلاگ گروهی توسط استارتاپی

   • 27
     نوشته‌
   • 4
     دیدگاه
   • 3802
     مشاهده

   نوشته‌های اخیر

   • معرفی استارتاپ فانوکس (شیوه‌ای جدید برای بی‌نهایت …
   • استارت‌آپ چیست و چگونه راه‌اندازی می‌شود؟
   • اینفوگرافی: مراحل مختلف یک استارتاپ چیست و چه زمان…
   • معرفی استارت‌اپ شکست خورده ترانوس
   • شاخص عملکرد کلیدی (KPI)

   

   آخرین نوشته
   

   معرفی استارتاپ فانوکس (شیوه‌ای جدید برای بی‌نهایت شدن)

   توسط کامبیز اسدزاده، 30 تیر 1398

   اولین پلتفرم آموزشی چند منظورهٔ بومی

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

   هدف :  آموزش و یادگیری هوشمند در هر زمان و هر جا برای بهبود زندگی و کسب و کار

   • زبان برنامه‌نویسی : ++C
   • انجین : سِل Cell
   • رابط کاربری: JavaScript، QML و فناوری Qt Quick
   • کتابخانه‌ها : STL, OpenSSL, Curl و Qt
   • سمت سرور: Php7.2 و  MySQLi MariaDB (در آینده همین بخش رو هم احتمالاً با ++C توسعه بدم).
   • رابط‌های برنامه‌نویسی: Restful Api v.1.0 در قالب JSon
   • نسخهٔ فعلی: ۰.۵ آلفا
   • پلتفرم‌های پشتیبانی دسکتاپ : Windows, macOS, Linux
   • پلتفرم‌های پشتیبانی موبایل و تبلت : iOS, Android, iPadOS

   

   ویژگی‌های فانوکس چیست و چگونه آن را متمایز می‌کند؟

   نصب و اجرای آسان

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

   حساب کاربری هماهنگ شده

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

    

   علائم نظارتی

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

   سیستم حفظ محتوای آموزشی و حقوق چاپ و نشر

   یکی از دغدغه‌های تولید کنندگان محتوای ویدیویی دانلود ویدیو‌ها توسط افراد سودجویی است که با قرار دادن این ویدیوها در کانال‌های تلگرامی و ... باعث هدر رفتن زحمات شما می‌شود، زحماتی که ساعت‌ها و هفته وقت صرف تولید یک محتوای آموزشی شده و منبع درآمد شماست به راحتی با چند کلیک به هدر می‌رود. مطمئنن بارها در انجمن‌ها و گوگل مواردی همچون «عدم دانلود محتوای آموزشی، عدم دانلود ویدیو، عدم دانلود ویدئو، جلوگیری از دانلود ویدیو در سایت، جلوگیری از دانلود فیلم» را مطرح و سرچ کرده‌اید و هر بار به در بسته خورده‌اید. به همین خاطر فانوکس بعنوان یک بستر آموزشی با توجه به اهمیت این موضوع سیستم عدم دانلود ویدئو را بر روی پلتفرم پیاده سازی کرده است تا دغدغه شما را به عنوان یک تولید کننده محتوای ویدیویی که منابع درآمدی‌تان از این راه است را به حداقل برساند.
   
   معمولاً در پلتفرم‌های رایج به دلیل میزبانی داده و پخش آن بر روی صفحات وِب دسترسی به لینک‌ها و دانلود آن توسط ابزار‌های دانلود راحت است. اما در فانوکس به دلیل عدم وابستگی به مرورگر امکان دریافت فایل‌های شما را به شکل خیره کننده‌ای مخفی و حفظ کرده است. البته این ویژگی در فاز‌های اول از امنیت بسیار بالایی برخوردار نیست اما تدارکاتی در دست توسعه می‌باشد که بتوانیم به طور کامل حتی بدون استفاده از روش‌های معکوس و هک حفظ اطلاعات را به حداکثر خود برسانیم.
   
   البته با توجه به رسالت فانوکس سیستم ترغیب کننده‌ٔ کاربر برای جمع‌آوری امتیاز و کسب اعتبار مصرف کننده را ترغیب به استفاده از پلتفرم می‌کند چرا که بدون استفاده‌ٔ آنلاین از پلتفرم نه سیستم امتیاز‌دهی و باشگاه مشتریانی وجود دارد و نه کسب اعتبار، دریافت تخفیف و تشکیل شبکه‌ٔ اجتماعی آموزشی!

   مرکز به‌روز رسانی

   هر سیستم نرم‌افزاری در یک چرخه‌ٔ تولید و توسعه قرار می‌گیرد که بعد از انتشار نسخه‌های اولیه مُدام در حال تازه‌سازی (به‌روز‌ رسانی) و حل مشکلات و یا بازخورد‌های کاربری است. در فانوکس سیستم به‌روز رسانی به گونه‌ای طراحی شده است که در صورت وجود هر گونه تغییرات نهایی شده از طرف تیم توسعه آن را به صورت مستقیم از سمت سرور‌های فانوکس به نرم‌افزار اطلاع می‌دهد. در صورتی که نرم‌افزار نصب شده فاقد بسته‌های جدید باشد آن را به طور خودکار با جزئیات کامل به شما اطلاع می‌دهد تا آن را دریافت و به‌روز رسانی کنید. یک ویژگی خاص در این بخش از فانوکس این است که به‌روز رسانی‌های احتمالی مستقیماً به تمامی نسخه‌های مربوطه اعمال می‌شود. در واقع در صورتی که در هسته‌ٔ نرم‌افزار یا بخش رابط کاربری آن تغییراتی اعمال شود سیستم به صورت خودکار نوع پلتفرم آن را تشخیص و بسته‌های مربوط به آن پلتفرم و معماری سخت‌افزاری را اعمال می‌کند. جالب است بدانید، به‌روز رسانی‌های عمیق سریعاً و بدون تاخیر در تمامی پلتفرم‌ها اتفاق خواهد افتاد و این ویژگی را مدیون انجین سِل هستیم.

    

   امتیاز‌ها و نظرات

   طبیعی است که کاربر باید بتواند نسبت به آموزش‌ و حتی اساتید انتقادات و پیشنهاداتی را داشته باشد. بر اساس رسالت فانوکس این حق مسلم کاربر است که نسبت به مطالب آموزشی نظرات و امتیازات مشخصی را ارائه دهد. بنابراین افزایش سطح کیفیت آموزشی و تغییر در رتبه‌ٔ یک پکیج یا استاد تاثیر مستقیم در نظرات و امتیازاتی دارد که از طرف هنرجویان اعمال می‌شود. سیستم نظرات و امتیازات فانوکس این امکان را فراهم می‌سازد تا شما در صورتی که وارد حساب کاربری خود شده‌اید، بتوانید نظرات و امتیازات مربوط به پکیج آموزشی را ارائه دهید.

    

   باشگاه مشتریان هوشمند

   فانوکس به گونه‌ای طراحی شده است که مجهز به سیستم هوشمند باشگاه مشتریان است. در این باشگاه بر خلاف پلتفرم‌های رایج آموزشی، کاربران و اساتید نسبت به هر واکنش امتیازاتی را دریافت می‌کنند که منجر به دریافت اعتبار به عنوان تخفیف و یا ویژگی‌های دیگر می‌شود. در سیستم باشگاه مشتریان فانوکس قواعدی پیاده سازی شده است که به هنرجو اجازه می‌دهد تا با پیگیری و ادامه‌ٔ روند آموزشی به مراتب امتیازاتی را جمع‌آوری کند که در نتیجه‌ٔ نهایی آن موثر باشد.
   
   اهداف باشگاه مشتریان فانوکس

   • - افزایش تعامل و ارتباط با کاربران و مشتریان
   • - حفظ و وفادارسازی و قدردانی از مشتریان
   • - ایجاد یک تجربه متمایز و لذت بخش نمودن تجربه مشتری
   • - ارائه پاسخی شایسته در مقابل اعتماد مشتریان
   • - دادن جوایز مختلف به مشتریان در ازای خرید آنها در فانوکس و نوشتن نظرات و معرفی دوستان
   • - برگزاری قرعه‌کشی هر چند ماه یکبار
   • - ارائه کالاهای متنوع با تخفیف به مشتریان

   فانوکس پلاس

   فانوکس پلاس با هدف خرید لذت بخش و جلب رضایت مشتری ایجاد شده است. در همین راستا "باشگاه مشتریان فانوکس" با ترکیب و هماهنگی خود با ویژگی فانوکس پلاس به عنوان سیستم امتیازدهی به مشتریان عمل می‌کند. بنابراین امتیاز خرید بعد از اولین ورود به فانوکس تحت سیستم فانوکس‌ پلاس محاسبه می‌شود.
   
   قوانین فانوکس‌پلاس
   پس از عوضیت در فانوکس به ازای ثبت نام اولیه مقدار ۳ امتیاز دریافت خواهید کرد که توسط سیستم امتیاز‌دهی هوشمند محاسبه می‌شود.
   - امتیاز ثبت نظر: برای هر نظر تائید شده ۵ امتیاز تعلق خواهد گرفت. محصولی که ثبت نظر در خصوص آن صورت می‌گیرد می‌بایست توسط مشتری خریداری شده باشد. نظر ثبت شده باید با قوانین "ثبت نظر" فانوکس منطبق بوده و پس از تایید نظر توسط فانوکس امتیاز در حساب کاربر منظور می‌شود. سقف امتیاز ثبت نظر ۲۴۰ امتیاز در هر سال می‌باشد.
   - امتیاز دعوت از دوستان: به ازای اولین خرید موفق و قطعی دوست دعوت شده ۱۵ امتیاز به دعوت‌کننده تعلق می‌گیرد. سقف امتیازات دعوت از دوستان ۵۰۰۰ امتیاز در سال می‌باشد.برای دعوت از دوستان می‌بایست با استفاده از لینک مربوط به دعوت از دوستان که مختص هر کاربر می باشد نسبت به دعوت از دوستان اقدام به عمل آید.
   امتیاز مربوطه در صورتی به مشتری دعوت‌کننده تعلق می‌گیرد که دعوت‌شونده قبلا عضو فانوکس نبوده باشد و بعد از دریافت لینک دعوت با کلیک روی آن ثبت‌نام نموده و سپس مبادرت به اولین خرید از فانوکس نماید. لازم به ذکر است پس از ثبت‌نام از طریق لینک دعوت یاد شده، یک کد تخفیف ۱۰ هزار تومانی به شخص دعوت‌شده برای اولین خرید ایشان از فانوکس که بیشتر از ۱۰۰ هزار تومان باشد، تعلق خواهد گرفت.

   سیستم تخفیف

   سیستم تخفیف فانوکس برای کمک به تهیه کنندگان آموزش با هزینه‌ٔ مقرون به صرفه می‌باشد. بنابراین با توجه به وضعیت اقتصادی و معیشتی مردم عزیزمان سعی شده است تا با بیشترین میزان کمک به کاهش هزینه‌ها از طریق کمک‌های سیستم باشگاه مشتریان هوشمند و همچنین سیاست‌های تخفیف‌های قابل اعمال از طرف اساتید میسر شود. بنابراین مجموع امتیاز‌های کسب شده به علاوهٔ تخفیف‌های اعمال شده توسط اساتید ممکن است در برخی از مواقع موجب شود تا یک پکیج آموزشی به صورت کاملاً رایگان در اختیار عزیزان قرار بگیرد (با توجه به یادگیری حق همه‌ٔ ماست) این سیاست با در نظر گرفتن هزینه‌های مصرفی پلتفرم مدیریت خواهد شد.

   درگاه بانکی ایمن

   بخشی از صداقت و رسالت فانوکس در این است که تمامی جزئیات مالی و تراکنش‌ها را برای کاربر (هنرجویان) و تولید کننده‌های محتوا (اساتید) شفاف‌سازی کند. بنابراین درگاه‌های بانکی به کار گرفته شده در این پلتفرم مستقیماً با بانك ملت (و درگاه شاپرک به‌پرداخت ملت، به عنوان بزرگترین درگاه مجازی کشور است). تمامی تراکنش‌های موفق و نا موفق در سیستم به طور کامل تحت کُد تراکنشی مشخص و انحصاری F A N O O X و اطلاعات سمت بانکی ثبت می‌شوند که به کاربر اجازه می‌دهد تا در مواقع لزوم از میزان تراکنش‌های پرداختی با جزئیات دقیق مطلع باشد.

    

   دستیار هوشمند

   دستیار هوشمند فانوکس هماهنگ با هسته‌ٔ مرکزی نرم‌افزار و توسع‌یافته به سبک هوش مصنوعی کار می‌کند و به عنوان یک استاد مجازی در کنار دنبال کننده‌ٔ آموزش‌ها فعال خواهد بود تا در مواقع لزوم اطلاعات و یا رسیدگی‌های مورد نیاز را نسبت به دوره‌های آموزشی و تکالیف و وظایف کاربران اقدام کند. این ویژگی در نسخه‌های آینده امکان سفارشی سازی و شخصیت سازی ویژه خواهد داشت.

   کتابخانهٔ هوشمند

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

    

   پخش کنندهٔ چند‌رسانه‌ای اختصاصی

   یکی از ویژگی‌های خاص فانوکس پخش‌کنندهٔ چندرسانه‌ای اختصاصی آن است که با قابلیت‌های خود با تمام سادگی امکان پخش فایل‌های چند-رسانه‌ای تولید شده توسط واحد استودیو فانوکس را فراهم می‌کند. این سیستم امکان پخش با کیفیت بالا تا 4K را ارائه می‌دهد.

   یادداشت برداری

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

   تهیه و خرید گروهی

   معمولاً به خاطر عدم توانایی فردی برای خرید و استفاده از آموزش‌ها، نیاز به این است که آموزش مربوطه به صورت مشترک تهیه شود. فانوکس به کمک شبکه‌ٔ اجتماعی اختصاصی خودش بین گروه‌ها این امکان را فراهم می‌کند تا شما با ایجاد گروه بین دوستان و آشنایان خود بتوانید به کمک هم یک آموزش را به صورت اشتراکی تهیه و به صورت جداگانه استفاده کنید.

   سیستم پیش‌خرید (پیش‌فروش)

   معمولاً اساتید به دنبال این هستند که برخی از محصولات خود را به صورت پیش‌فروش تا قبل از آماده شدن محتوای آن ارائه دهند. این امکان در فانوکس با در نظر گرفتن حساب کاربری ویژه تعبیه می‌شود که به اساتید اجازه می‌دهد تا پکیج مورد نظر خود را به صورت ویژه پیش‌فروش کنند. کاربران و علاقه‌مندان برای تهیه آن می‌توانند هر فصلی که آماده می‌شود را مرحله به مرحله خرید نمایند که روش پرداخت آن به صورت خودکار نسبت به مراحل ساخت محتوا صورت می‌گیرد.

   

    

   • ادامه مطلب...
   • 0 دیدگاه
7. 

   سخت افزار

   یک وبلاگ گروهی توسط سخت افزار

   • 5
     نوشته‌
   • 1
     دیدگاه
   • 2634
     مشاهده

   نوشته‌های اخیر

   • آخرین اطلاعات از گرافیک مجتمع جنجالی اینتل منتشر ش…
   • پردازنده‌ها چگونه طی ۴۰ سال گذشته تغییر کرده‌اند؟
   • چیپست های Intel X599 و Z399 کار را برای پردازنده ه…
   • برخی جزئیات چیپست Z390 از سوی اینتل اعلام شد
   • اینتل تراشه جدیدی با هسته‌های زئون و FPGA یکپارچه …

   

   آخرین نوشته
   

   آخرین اطلاعات از گرافیک مجتمع جنجالی اینتل منتشر شد

   توسط کامبیز اسدزاده، 4 فروردین 1398

   پس از انتشار مقاله اختصاصی 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 نانومتری کاهش یافته است.

   • ادامه مطلب...
   • 0 دیدگاه
8. 

   علم و دانش

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

   • 6
     نوشته‌
   • 0
     دیدگاه
   • 2598
     مشاهده

   نوشته‌های اخیر

   • فضانورد سابق ناسا: سفر انسان به سیاره مریخ احمقانه…
   • نوع جدیدی از کامپیوترهای کوانتومی رکوردهای قبلی را…
   • لپ‌تاپ شیمیایی ناسا که به یافتن سیاره دیگر کمک می‌…
   • اهمیت یادگیری ماشین
   • هوش مصنوعی واتسون با پیش‌بینی عملکرد آینده

   

   آخرین نوشته
   

   فضانورد سابق ناسا: سفر انسان به سیاره مریخ احمقانه است

   توسط کامبیز اسدزاده، 6 دی 1397

   

   پس از فرود انسان روی کره ماه در قرن بیستم، سیاره مریخ همواره به عنوان مقصد بعدی در منظومه شمسی شناخته شده؛ اما یکی از فضانوردان سابق ناساانجام چنین کاری را احمقانه می داند.

   بیل اندرس فضانورد سابق ناسا که در مأموریت آپولو 8 سال 1968 نیز شرکت داشته، معتقد است سفر به سیاره مریخ در حال حاضر صرفاً یک نمایش تبلیغاتی از سوی ناسا بوده و هیچ نفعی برای جامعه علمی دنیا نخواهد داشت.

   به گفته اندرس، بودجه لازم برای سفر به مریخ می تواند صرف پروژه های مفیدتری مانند ارسال ربات های کاوشگر به سیارات مختلف شود و از این طریق، سطح آگاهی ما از جهان اطراف را افزایش دهد.

   

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

   سفر انسان به مریخ در حال حاضر توجیه علمی ندارد

   به گفته فضانورد سابق ناسا، حضور انسان روی سیاره مریخ مسلماً یک موج رسانه ای عظیم و قدرتمند را به راه خواهد انداخت اما هیچ کمکی به گسترش مرزهای دانش بشری نخواهد کرد. جالب است بدانید که چنین دیدگاهی تنها مختص به بیل اندرس نبوده و بسیاری از مدیران ناسا، اسپیس اکس و بلو اوریجین (هر سه به دنبال فرود انسان روی مریخ هستند) نیز با نظر وی موافقند.

   البته نظر اندرس مخالفانی هم دارد؛ به عنوان مثال فرانک بورمن (یکی دیگر از سرنشینان آپولو معتقد است جست و جوی عمیق در منظومه شمسی یکی از مهم ترین مأموریت های ناسا بوده که حضور انسان بخش جدایی ناپذیر چنین پروژه هایی خواهد بود.

   گفتنی است آقای بورمن از سوی دیگر هیجان موجود در زمینه سفر به سیاره مریخ را هم تأیید نکرده و اظهار داشته: «ماسک و بزوس (صاحبان اسپیس اکس و بلو اوریجین) درباره تشکیل جوامع انسانی در مریخ صحبت می کنند؛ چنین چیزی مسخره است.»

   به هرحال باید منتظر بود و دید که آیا در سال های آتی ناسا و دیگر سازمان های فضایی بودجه خود را صرف امور علمی خواهند کرد یا بر شکستن محدودیت های حضور انسان در سایر سیارات تمرکز خواهند داشت.

   • ادامه مطلب...
   • 0 دیدگاه
9. 

   رویداد‌ها

   یک وبلاگ گروهی توسط رویداد‌ها

   • 5
     نوشته‌
   • 0
     دیدگاه
   • 2497
     مشاهده

   نوشته‌های اخیر

   • خلاصه‌‌ای از رویداد نشست 2018 زبان ++C
   • ششمین ماراتون برنامه‌نویسی تلفن همراه کشور
   • بیست و چهارمین نمایشگاه بین المللی ایران الکامپ
   • سونی در رویداد TGS 2018 اسپانسر سازندگان مستقل می‌…

   

   آخرین نوشته
   

   خلاصه‌‌ای از رویداد نشست 2018 زبان ++C

   توسط کامبیز اسدزاده، 14 آذر 1397

   دو هفته پیش، نشست ۲۰۱۸ سی‌پلاس‌پلاس آغاز شد. شرکت کننده‌ها مدال‌های خودشان را دریافت کردند چرا که همه‌ چیز با هماهنگی بسیار خوبی به پایان رسید. این رویداد به عنوان یکی از چندین رویداد مهمC++ بشمار می‌رود که هرساله توسط حامیان و علاقه‌مندانش برگزار می‌شود.

    

   سخنان کلیدی

   امسال در این رویداد سه یادداشت کلیدی وجود داشت، که با حضور Andrei Alexandrescu ،Lisa Lippincott و Nicolai Josuttis ارائه شد.

   

   اولین سخنران Andrei Alexandrescu بود، او این کنفرانس را با افکار و اندیشه‌های خودش برای شروع آغاز کرد عنوان موضوع آن به بَد بودنِ کپی constexpr از static if اشاره می‌کرد. او یک سخنران سرگرم کننده است، بنابراین سخنرانی او بسیار طبیعی در مورد یادداشت‌های خودش منعکس می‌شد. همچنین او به عنوان یک توسعه‌دهندهٔ ++C به نقاط بسیاری اشاره کرد که کمیتهٔ استاندارد سازی زبان حرف‌های او را تایید می‌کرد.

   

   سخنران دوم Lisa Lippincott روز دوم را با یک سخنرانی آغاز کرد که دیدگاه‌های مختلفی در مورد محاسبات و منطق که در آن به کار می‌رود ارائه داد. زمانی که مُجری لیزا را دعوت کرد، می‌دانست که این موضوع به عنوان یک نکته مهم برای فکر کردن است، چیزی که همه نمی‌توانند به طور مستقیم آن را درک کنند و به آن دسترسی پیدا کنند. اما این تلنگری برای نحوهٔ درک کُد از دیدگاه ریاضی و دیدگاه جدیدی بود.

   

   سخنران سوم و آخر Nicolai Josuttis بود که در مورد، او اولین سخنران در نشست Hartmut Kaiser در سال ۲۰۱۴ بود. در آن سخنرانی بسیار خوب درخشیده، بنابراین در قسمت سوم نقص‌هایی را با جزئیات در مورد نقاط خشن ++C نشان داد. این سخنرانی بسیار صادقانه بود! چرا که بسیاری از جزئیات خشن بودن سی‌پلاس‌پلاس را عنوان کرد که همگی با آن موافق بودند.

    

   مذاکرات، مسابقه و گفتگوها‌ی چند دقیقه‌ای

   جلسات و رویداد‌های مرتبط با ++C همیشه گفتگو‌های بسیار خوبی دارد، و با یک مسیر مشخص که هدفش آوردن سخنرانان جدید با دیدگاه‌های جدید است برگزار می‌شود. بازخورد سخنران‌ها در این رویداد خوب بود چرا که به برخی از نکات در مورد چگونگی بهبود‌ها اشاره کردند.

   

   

   تصویر بالا مربوط به Hana Dusíková است که می‌توان به آن بهترین نمره را داد. بهترین سخنرانی هم مربوط به  Andrei Alexandrescu بود که دنبال شد. در اولین عصر این رویداد، امتحان (Quiz) برجسته‌ترین مورد رویداد در آن روز بود. سازماندهی آن توسط Diego  و اسپانسری آن توسط Conan است که برای چند سال اخیر حمایت شده است. به نظر می‌رسید که سوالات امتحانی این سال سخت‌تر از سوالات رویداد قبلی در سال گذشته بوده است. اما بار دیگر این سرگرمی ترکیب بسیار خوبی با ترس از سی‌++ را داشت.

   هر یک از سوالات امتحانی یک خروجی از کُد را تولید می‌کردند، که هر گروه باید برای کسب امتیاز آن را می‌نوشتند. ده نوع کُد امتحانی وجود داشت که تهیه کنندهٔ گزارش برای به تصویر کشیدن آن‌ها زیاد خوب عمل نکرده است. بنابراین تصویر زیر مربوط به سوالات چالشی در مورد سی‌پلاس‌پلاس است:

   

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

   • نقل قول

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

   نکته: شما می‌توانید تصاویر ویدیویی مربوط به این رویداد را از کانال رسمی آن در یوتیوب دریافت کنید.

    

   • ادامه مطلب...
   • 0 دیدگاه