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

1. 

   طراحی و توسعه

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

   • 10
     نوشته‌
   • 1
     دیدگاه
   • 2486
     مشاهده

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

   • ۱۵ اصول راهبردی برای محققان UX
   • اصول طراحی: تضاد
   • اصول طراحی: رنگ
   • فرایند UX: این فرایند چیست و چرا مهم است؟
   • تکنولوژی REST

   

   آخرین نوشته
   

   ۱۵ اصول راهبردی برای محققان UX

   توسط الهه انصاری، 5 بهمن 1398

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

   ترکیب کنید

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

   فهمیدن این که اشتباه کرده‌اید آسان‌تر است

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

   شما نمی‌توانید اندازه‌ی کلیه‌ی تحقیقات خود را استاندارد کنید

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

   انجام آزمایش و تست فقط با یک کاربر همیشه بی معنی نیست

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

   

   اندازه‌های نمونه را برای دقت بیشتر افزایش دهید

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

   تصادفی سازی می تواند بر نقایص طراحی تحقیق غلبه کند

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

   نتایج تحقیقات متعلق به هیچ کس نیست

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

   درجه‌بندی مقیاس در سوالات مهم نیست

   مطمئناً بحث‌های زیادی در مورد این که آیا مقیاس x دقیق‌تر از مقیاس y است یا نه وجود دارد و این که آیا شما باید یک رتبه بی‌طرف داشته باشید یا خیر. هیچ یک از آن‌ها به اندازه‌ی کافی مهم نیستند که بیش از ۵ دقیقه را صرف نگرانی کنید. یک مقیاس را انتخاب کرده و شروع به انجام تحقیق کنید.

   شرکت کنندگان نیاز به بازتاب پرسوناها دارند

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

    

   آنچه می‌گویند در مقابل آنچه انجام می‌دهند

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

   جعبه‌ی ابزار خود را توسعه دهید

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

   قابلیت استفاده - یک تخیل معقول؟

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

   گزارش ها را کوتاه تهیه کنید

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

   آگاه باشید که ناظران به طور متفاوتی بررسی می‌کنند

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

   کیش شخصیت (Cult of Personality) به کارتان نخواهد آمد

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

    

   پی‌نوشت: منبع اصلی

    

    

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

   برنامه نویسی

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

   • 17
     نوشته‌
   • 12
     دیدگاه
   • 3471
     مشاهده

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

   • قسمت اول معماری 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 چه منطق کلی وجود دارد. امیدوارم این مقاله برای شما مفید بوده باشد. نمونه انگلیسی این مقاله را می توانید در این آدرس (لینک) مطالعه کنید.

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

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

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

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

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

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

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

   

   آخرین نوشته
   

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

   توسط 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 دیدگاه
4. 

   فناوری

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

   • 12
     نوشته‌
   • 0
     دیدگاه
   • 2595
     مشاهده

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

   • آینده‌ی توسعه‌ی وب تحت فناوری WebAssembly
   • چهار زبان برتر برنامه‌نویسی برای بلاک‌چین
   • ویندوز 10 در به‌روز‌رسانی بعدی خود مرورگر Edge را …
   • مایکروسافت سایه‌زنی با نرخ متغیر را به DirectX 12 …
   • چند سايت ارزشمند جهانی

   

   آخرین نوشته
   

   آینده‌ی توسعه‌ی وب تحت فناوری WebAssembly

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

   با توجه به محبوبیت صنعت وِب، سال‌هاست زبان‌های برنامه‌نویسی در این زمینه پیشرفت‌ها و کاربرد‌های چشم‌گیری را داشته‌اند، از جمله جاوا‌اسکریپت (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 و غیره را می‌توان در حوزه‌ی وب مورد استفاده قرار داد. بنابراین فناوری وب‌اسمبلی می‌تواند مسیری را برای رشد صنایع مختلف به خصوص شرکت‌های بازی‌سازی و غیره باز کند.

   افزایش کارآیی (پرفرمنس) بسیار شدید که توسط وب‌اسمبلی فراهم می‌شود، همانند اجرای برنامه‌های دسکتاپی است که می‌توان آن را بر روی وب نیز مشاهده کرد. با این روال ممکن است وب‌اسمبلی در سال‌های آینده، با نرم‌افزار‌های رومیزیِ بومی برابری کند.

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

   ابزار‌ها

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

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

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

   • معرفی سیاهه تغییرات و راهنمای استفاده از آن
   • کاربران 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
     دیدگاه
   • 2939
     مشاهده

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

   • معرفی استارتاپ فانوکس (شیوه‌ای جدید برای بی‌نهایت …
   • استارت‌آپ چیست و چگونه راه‌اندازی می‌شود؟
   • اینفوگرافی: مراحل مختلف یک استارتاپ چیست و چه زمان…
   • معرفی استارت‌اپ شکست خورده ترانوس
   • شاخص عملکرد کلیدی (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
     دیدگاه
   • 1940
     مشاهده

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

   • آخرین اطلاعات از گرافیک مجتمع جنجالی اینتل منتشر ش…
   • پردازنده‌ها چگونه طی ۴۰ سال گذشته تغییر کرده‌اند؟
   • چیپست های 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
     دیدگاه
   • 1967
     مشاهده

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

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

   

   آخرین نوشته
   

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

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

   

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

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

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

   

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

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

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

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

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

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

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

   رویداد‌ها

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

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

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

   • خلاصه‌‌ای از رویداد نشست 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 دیدگاه