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

1. 

   برنامه نویسی

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

   • 21
     نوشته‌
   • 14
     دیدگاه
   • 2914
     مشاهده

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

   • معرفی و راهنمای استفاده از نسخه‌بندی معنایی
   • شبیه سازی تکنیک Template در زبان C
   • کتابخانه‌های استاتیک و داینامیک (پویا)
   • چشم‌انداز فنی برای کیوت ۶
   • استفاده از کانتینر Doubly Linked List و Iteration …

   

   آخرین نوشته
   

   معرفی و راهنمای استفاده از نسخه‌بندی معنایی

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

   معرفی نسخه‌بندی معنایی ویرایش ۲.۰

   در دنیای مدیریت نرم‌افزار مکان مخوفی به نام «جهنم وابستگی» (dependency hell) وجود دارد. هر چه سیستم شما بزرگتر باشد و بسته‌های (package) بیشتری با نرم‌افزار شما یکپارچه شده باشند، احتمال بیشتری وجود دارد که روزی خود را دراین گودال ناامیدی بیابید.

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

   برای پاسخگویی به این مشکل، من یکسری قوانین و پیش‌نیازهای ساده را پیشنهاد میدهم که نحوهٔ تخصیص و افزایش شماره‌های نسخه را دیکته می‌کند. این قوانین برپایه‌ی شیوه‌های موجود رایج و گسترده‌ی در حال استفاده، هم در نرم‌افزارهای متن‌باز و غیر متن‌باز است، اگرچه لزوماً محدود به آن نیست. برای آنکه این سیستم کار کند نخست لازم است یک API عمومی (public) تعریف کنید. این امر ممکن است شامل مستندسازی، یا بوسیله‌ی خود کد مقید شده باشد. صرف نظر از این موضوع، مهم است که این API دقیق و واضح باشد. زمانیکه API عمومی خود را مشخص کردید، تغییرات آن را با افزایش معین شماره‌ی نسخه‌ی خود مرتبط می‌سازید. قالب نسخهای به صورت X.Y.Z را در نظر بگیرید. خطاهایی که تاثیری بر API ندارند، نسخه‌ی وصله (Patch) را افزایش می‌دهند، افزایش یا تغییر API که با نسخه‌های قبلی سازگار است، نسخه‌ی جزئی (Minor) را افزایش می‌دهند، و تغییرات API که با نسخه‌های قبل ناسازگار هستند، نسخه‌ی اصلی (Major) را افزایش می‌دهند.

   

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

   به فرض اینکه نسخه‌ی MAJOR.MINOR.PATCH یا اصلی.جزیی.وصله داده شده است:

   1. شماره‌ی نسخه‌ی اصلی (MAJOR) را زمانی افزایش دهید که تغییرات API ناسازگار اعمال کرده‌اید،
   2. شماره‌ی نسخه‌ی جزئی (MINOR) را زمانی افزایش دهید که قابلیت‌هایی اضافه کرده‌اید که با نسخه‌های قبل سازگار هستند،
   3. شماره‌ی نسخه‌ی وصله (PATCH) را زمانی افزایش دهید که تصحیح خطاهایی (bug) اعمال کرده‌اید که با نسخه‌های قبل سازگار هستند.

   برچسب‌های اضافی برای پیش‌نشر و ساختن فراداده به صورت پسوندهایی برای قالب MAJOR.MINOR.PATCH فراهم است.

   ویژگی‌های نسخه‌بندی معنایی (SemVer)

   کلمات کلیدی «باید»، «نباید»، «نیاز است»، «می‌بایست»، «نمی‌بایست»، «توصیه شده است»، «ممکن است» و «اختیاری» در این مستند می‌بایست بر مبنای آنچه در RFC 2119 تعریف شده است، معنا شوند.

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

   2. یک شماره‌ی نسخه‌ی عادی باید قالب X.Y.Z را داشته باشه طوری که در آن X ،Y و Z اعداد صحیح غیرمنفی هستند و نباید صفر اضافه (leading zero) داشته باشند. X نسخه‌ی اصلی، Y نسخه جزیی، و Z نسخهٔ وصله است. هر عنصر باید به صورت شمارشی افزایش یابد. به عنوان مثال 1.9.0 -> 1.10.0 -> 1.11.0.

   3. زمانی‌که یک بسته‌ی نسخه‌بندی شده منتشر شد، محتوای آن نسخه نباید دستکاری شود. هرگونه تغییری باید به عنوان نسخه‌ی جدید منتشر شود.

   4. نسخه‌ی اصلی شمارهٔ صفر (0.y.z) برای توسعه‌های ابتدایی است. هرچیزی در هر زمانی ممکن است تغییر کند. API عمومی نمی‌بایست ماندگار در نظر گرفته شود.

   5. نسخهٔ 1.0.0 API عمومی را تعریف می‌کند. روشی که شمارهٔ نسخه‌ی بعد از این انتشار افزوده می‌شود، به این API عمومی و نحوهٔ تغییر آن وابسته است.

   6. نسخه‌ی وصله Z (x.y.Z | x > 0) باید در صورتی افزوده شود که تصحیح‌های خطای سازگار با نسخهٔ قبلی معرفی شده باشند. یک تصحیح خطا به عنوان یک تغییر داخلی تعریف می‌شود که رفتارهای نادرست را اصلاح می‌کند.

   7. نسخهٔ جزیی Y (x.Y.z | x > 0) باید در صورتی افزوده شود که عملکرد سازگار با نسخه‌های قبل جدیدی به API عمومی معرفی شده باشد. همچنین اگر هرگونه عملکرد API عمومی به عنوان منسوخ‌شده برچسب خورده باشد، این شماره باید افزوده شود. اگر عملکرد جدید یا بهبود قابل توجهی در کدهای داخلی معرفی شده باشد، ممکن است نسخهٔ جزیی افزوده شود. ممکن است که شامل تغییرات سطح وصله هم باشد. زمانیکه نسخه جزیی افزوده شود، نسخهٔ وصله باید به 0 بازنشانده شود.

   8. نسخه‌ی اصلی X (X.y.z | X > 0) باید در صورتی افزوده شود که هرگونه تغییرات ناسازگار با نسخه‌های قبل به API عمومی معرفی شده باشد. ممکن است این تغییرات شامل سطوح جزیی و وصله نیز باشد. نسخه‌ی جزئی و وصله زمانیکه نسخه‌ی اصلی افزوده می‌شود باید به 0 بازنشانی شوند.

   9. یک نسخه‌ی پیش‌انتشار ممکن است با اضافه کردن یک خط تیره و یک سری شناسه‌هایی که به وسیله‌ی نقطه از هم جدا ‌شده‌اند و بلافاصله به دنبال نسخه‌ی وصله می‌آیند، نشانه‌گذاری شود. شناسه‌ها باید تنها شامل اعداد و حروف الفبای اَسکی (ASCII) و خط تیره [A-Za-z0-9] باشند. شناسه‌ها نباید تهی باشند. شناسه‌های عددی نباید با صفر اضافه آغاز شوند. نسخه‌ی پیش‌انتشار از اولویت پایین‌تری نسبت به نسخه‌ی عادی مرتبط برخوردار است. یک نسخه‌ی پیش‌انتشار حاکی از آن است که نسخه‌ی ناپایدار است و ممکن است نیازمندی‌های سازگاری مورد نظر را آنگونه که در نسخه‌ی عادی مرتبط نشان داده شده است، برآورده نکند. مثال: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

   10. متادیتای ساخت (build metadata) ممکن است با افزودن یک علامت جمع (+) و یک سری شناسه‌هایی که به وسیلهٔ نقطه ازهم جدا شده‌اند، و بلافاصله به دنبال نسخه‌ی وصله یا پیش‌انتشار می‌آیند، نشانه‌گذاری شود. شناسه‌ها باید تنها شامل اعداد و حروف الفبای اَسکی (ASCII) و خط تیره [A-Za-z0-9] باشند. شناسه‌ها نباید تهی باشند. متادیتای ساخت می‌بایست در زمان تعیین اولویت نسخه درنظر گرفته نشود. بنابراین دو نسخه که تنها در متادیتای ساخت با یکدیگر متفاوت هستند، اولویت یکسان دارند. مثال: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f8

   11. اولویت اشاره دارد به اینکه چگونه نسخه‌ها زمانی‌که مرتب شده‌اند با یکدیگر مقایسه می‌شوند. اولویت باید به وسیله‌ی جداسازی نسخه به اصلی، جزیی، وصله و شناسه‌های پیش‌انتشار به همین ترتیب، محاسبه شود (متادیتای ساخت در اولویت نمایان نمی‌شود). اولویت، به وسیلهٔ اولین تفاوت تعیین می‌شود هنگامی که این مشخصه‌ها از چپ به راست مقایسه شوند، بدین صورت: نسخه‌های اصلی، جزیی و وصله همیشه به صورت عددی مقایسه می‌شوند. مثال: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. زمانی که اصلی و جزیی و وصله برابر هستند، یک نسخهٔ پیش‌انتشار از اولویت کمتری نسبت به نسخهٔ عادی برخوردار است. مثال: 1.0.0- alpha < 1.0.0 اولویت برای دو نسخه‌ی پیش‌انتشار با نسخه‌ی اصلی، جزیی و وصله‌ی مشابه باید به وسیله‌ی مقایسه‌ی هر مشخصه‌ای که با نقطه جدا شده، از چپ به راست مشخص شود تا زمانی که یک تفاوت به شرح زیر یافت شود: شناسه‌هایی که تنها شامل اعداد صحیح هستند به صورت عددی و شناسه‌هایی که با حروف یا خط‌های تیره به صورت الفبایی به ترتیب ASCII مقایسه می شوند. مشخصه‌های عددی همیشه از اولویت کمتری نسبت به مشخصه‌های غیرعددی برخوردار هستند. مجموعه‌های بزرگتری از بخشهای پیش‌انتشار اولویت بیشتری نسبت به مجموعه‌های کوچکتر دارند، اگر همه مشخصه‌های اولویت برابر باشند. مثال: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

   چرا از نسخه‌بندی معنایی استفاده شود؟

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

   یک مثال ساده می‌تواند نشان دهد که چگونه نسخه‌بندی معنایی می‌تواند جهنم وابستگی را به خاطره‌ای از گذشته تبدیل کند. کتابخانه‌ای به نام «Firetruck» را در نظر بگیرید. این کتابخانه به یک بسته به نام «Ladder» که به صورت معنایی نسخه‌بندی شده، احتیاج دارد. در زمانی که firetruck ساخته شده، Ladder در نسخه‌ی 3.1.0 است، شما می‌توانید وابستگی Ladder را با آسودگی به عنوان بزرگتر یا برابر با 3.1.0 و نه کمتر از 4.0.0 تعیین کنید. شما می‌توانید آن‌ها را در سیستم مدیریت بستهٔ خود منتشر کنید و بدانید که آن‌ها با نرم‌افزار وابسته موجود سازگار هستند.

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

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

    

   سوالات متداول

   چگونه باید با نسخه‌ها در فاز توسعه‌ی ابتدایی 0.y.z کنار بیایم؟

   ساده‌ترین کار برای انجام دادن این است که توسعهٔ ابتدایی خود را از انتشار 0.1.0 آغاز کنید و سپس نسخهٔ جزیی را برای هر انتشار آتی افزایش دهید.

   چگونه بدانم چه زمانی باید 1.0.0 را منتشر کنم؟

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

   آیا این روش، توسعه و تکرار سریع را کند نمی کند؟

   نسخه‌ی اصلی صفر تماماً در مورد توسعهٔ سریع است. اگر شما API را هر روز تغییر می‌دهید، یا باید هنوز در نسخه‌ی 0.y.z باشید یا در یک شاخه‌ی توسعه‌ی جداگانه که بر نسخه‌ی اصلی بعدی کار می‌کند هستید.

   اگر حتی کوچکترین تغییرات ناسازگار با نسخه‌های قبل در API عمومی نیازمند یک نسخهٔ اصلی باشد، آیا من خیلی سریع به نسخه 42.0.0 نخواهم رسید؟

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

   مستندسازی تمامی API عمومی کار بسیار زیاد می‌برد!

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

   چه کار می‌توانم بکنم اگر تصادفاً یک تغییر ناسازگار با نسخه‌های قبل را به عنوان نسخه‌ی جزئی منتشر کردم؟

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

   چه کار باید بکنم اگر وابستگی‌های خودم را بدون تغییر دادن API عمومی به‌روزرسانی کردم؟

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

   چه می شود اگر من بدون اعلام قبلی API عمومی را به صورتی تغییر دهم که با تغییر عدد نسخه سازگار نباشد؟ (یعنی کد به نادرست تغییر اصلی‌ای را در انتشار وصله معرفی می‌کند)

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

   چگونه باید با منسوخ کردن عملکرد (deprecating functionality) کنار بیایم؟

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

   آیا SemVer محدودیت اندازه بر روی رشته‌ی نسخه دارد؟

   خیر، اما از قضاوت مناسبی استفاده کنید. به عنوان مثال یک نسخه‌ی ۲۵۵ نویسه‌ای احتمالاً مفید نخواهد بود! همچنین، سیستم‌های خاص ممکن است محدودیت‌های خود برای اندازه‌ی رشته اعمال کنند.

   - منبع

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

   ابزار‌ها

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

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

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

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

   فناوری

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

   • 11
     نوشته‌
   • 1
     دیدگاه
   • 2143
     مشاهده

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

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

   

   آخرین نوشته
   

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

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

   زبانی را انتخاب کنید که پاسخگوی برنامه‌ی تحت بلاک‌چین شما باشد!

    

   فناوری بلاک‌چین به سرعت در حال تبدیل شدن به یکی از مهمترین پیشرفت‌های فناوری در چند دهه‌ی گذشته است. این سیستم، معاملات ناشناس و همتا را بین کاربران امکان‌پذیر می‌کند که اساساً بر پایه‌ی انقلاب رمزنگاری است. بازار جهانی بلاک‌چین در حال حاضر حدود ۱.۲ میلیارد دلار تخمین زده می‌شود و کارشناسان پیش‌بینی می‌کنند که تا سال ۲۰۲۵ به ارزش ۵۷ میلیارد دلار برسد که در سال بیش از ۶۹ درصد رشد خواهد داشت.

   

   عمده‌ی شرکت‌ها و سرمایه‌دارانِ سرمایه‌گذار در توسعه‌ی فناوری جدید رمزنگاری، قرارداد‌های هوشمند دفترچه‌های توزیع‌شده برای بانک‌های سنتی، توکن‌های بازی و سیستم‌های مدیریت زنجیره تأمین با شرکت‌های مشاوره بلاک‌چین همکاری می‌کنند. توسعه‌دهندگان در حال حاضر از زبان‌های برنامه‌نویسی محبوبی مانند C++ و JavaScript برای ساختن برنامه‌های سفارشی بلاک‌چین استفاده می‌کنند. علاوه بر این، مهندسان رمزنگاری زبان‌هایی مانند Simplicty و Solidity را برای این کار طراحی کرده‌اند. اما، آن‌ها آیا این‌ها بهترین زبان‌های برنامه‌نویسی برای فناوری بلاک‌چین هستند؟

   بلاک‌چین چیست؟

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

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

   نقل قول

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

   زبان برنامه‌نویسی JavaScript (جاوااسکریپت)

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

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

   زبان برنامه‌نویسی C++ (سی‌پلاس‌پلاس)

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

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

   همچنین C++ به دلیل پشتیبانی و مدیریت وظایف موازی و نخی به طور گسترده در بلاک‌چین مورد استفاده قرار می‌گیرد. این زبان قادر به مدیریت هردو ویژگی موازی و غیرموازی در وظایف است، در واقع می‌تواند به خوبی انجام وظایف تک-نخی/تک رشته‌ای (single-thread) را بهبود دهد. نمونه‌ی فوق‌العاده‌ای از برنامه‌های اساسی از بلاک‌چین که با C++ نوشته شده است EOS نام دارد. این نرم‌افزار به صورت منبع‌باز در سال ۲۰۱۸ توسط بلاک منتشر شد و به گونه‌ای طراحی شده است که معاملات را سریع‌تر از گزینه‌های دیگر پردازش می‌کند. این نرم‌افزار اجازه می‌دهد تا در کمتر از یک ثانیه معامل را تأیید کرده و فقط در دو دقیقه آن را نهایی کنید.

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

   این زبان یک نمونه‌ی هوشمند است که با همکاری توسعه‌دهندگان Ethereum و بلاک‌چین توسعه یافته است. این زبان به صورت اختصاصی دامنه‌های بسیاری از اصول و اصطلاحات مشابه به جاوا‌اسکریپت را برای ایجاد برنامه‌های با کیفیت بالا و غیر متمرکز فراهم می‌کند. توسعه‌دهندگان، این زبان را برای این ترجیح می‌دهد که به شما این امکان را فراهم می‌کند تا یک کد سطح بالا را برای شبکه‌ی بلاک‌چینی Ethereum، دومین بلاک‌چین رمزنگاری محبوب، که می‌تواند به زبان سطح پایین و کد ماشین کامپایل شود. در حال حاضر Solidity در طیف گسترده‌ای از سکو‌ها (پلتفرم‌های) بلاک‌چینی از جمله، Ethereum، Tendermint، Ethereum Classic و Counterparty موجود است.

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

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

   خلاصه

   بلاک‌چین اینجاست تا بماند! فناوری محبوب (Record-Keeping) چیزی است که تبادلات رمزنگاری را ممکن می‌سازد و بطور گسترده توسط شرکت‌ها، افراد و خدمات مشاوره‌ای بلاک‌چین، برای توسعه‌ی نرم‌افزار مورد استفاده قرار می‌گیرد. توسعه دهندگان می‌توانند به راحتی از زبان‌های محبوب مانند C++ و JavaScript برای توسعه‌ی بلاک‌چین استفاده کنند. از طرفی این انجمن اخیراً زبان‌هایی به عنوان Solidity و Simplicity را ایجاد کرده است که باعث می‌شود تا فرآیند توسعه‌ی رمزنگاری روان‌تر شود.

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

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

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

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

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

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

   

   آخرین نوشته
   

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

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

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

   

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

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

   اما واقعیت امر در چیست و دلایل مسدود سازی نرم‌افزار‌ها بر روی iOS در چیست؟

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

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

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

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

   اما واقعیت این مسئله چیست؟ آیا اپل اقدام به تحریم بی دلیل بر روی اپلیکیشن‌های ایرانی داشته است؟

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

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

   به عنوان مثال، اگر شما یک کاربر عادی یا حتی تازه کار باشید، یا اگر شما یک توسعه‌دهنده‌ی تازه‌کار و حتی حرفه‌ای باشید بهتر است به این بخش از قوانین اپل (App Store Review Guidelines) توجه جدی کنید! این بخشی از قوانین صریح و شفاف اپل در حوزه‌ی اپلیکیشن‌های iOS و فروشگاه خودش است که در زیر آمده است:

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

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

   فشار دو طرفه، بهانه تشدید بهانه... بهانه و باز هم بهانه!!!

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

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

   حال با در نظر گرفتن نقض قوانین صریح از سمت فروشگاه‌های ایرانی که به آن‌ هم افتخار می‌کنند، آیا نباید انتظار داشت تا روزی اپل یا هر شرکت دیگری صبرش به پایان برسد و خیس و خُشک را باهم بسوزاند؟!

   بخشی از ادعاهایی که بزرگترین مرجع ایرانی (سیب‌اپ) اپلیکیشن‌های iOS ارائه شده است به صورت زیر می‌باشد:

   نقل قول

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

   نقل قول

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

   زمانی که دسترسی به هزاران اپلیکیشن خارجی با ارزش ۵۰،۰۰۰ دلار در کشور ما با افتخار حقوق توسعه‌دهنده و ناشر را زیر سوأل می‌برد نباید انتظار داشت چنین تحریم‌هایی حق ماست؟

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

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

   نقل قول

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

   راه حل‌های ناشیانه و واقعا مسخره که از طرف فروشگاه‌ها و نویسندگان خبری اخیر به دستمان رسیده است به صورت زیر هستند:

   • استفاده از نسخه وب اپلیکیشن
     • حقیقت نفهته در پشت این راه حل‌ها به این صورت است که یک فناوری به عنوان PWA یا همان (Progressive web applications) وجود دارد که همان نسخه‌ی وب به شمار می‌آید! در واقع اپلیکیشن‌های نوشته شده به این روش بسیار بدتر از حتی یک وب‌سایت کامل هستند و تنها به روش‌های غیر بومی و خارج از محیط Xcode تحت فناوری‌های وب مانند HTML, CSS و JavaScript توسعه داده می‌شوند. در نهایت هیچ ربطی به نسخه‌ی اصلی و نوشته شده‌ به روش طبیعی نرم‌افزار‌های iOS ندارد و تنها نسخه‌ی محدود شده‌ای از وب‌سایت خدماتی است که با حقه‌های فریبنده و کاملاً ناشیانه اقدام به ساخت میان‌بر و ایجاد آیکون بر روی صفحه گوشی شما می‌کنند که اینطور برداشت کنید نسخه‌ی واقعی اپلیکیشن را نصب کرده اید!!! در حالی که بهتر است به جای آن از همان وب‌سایت استفاده کنید. مسخره است نه؟!
   • دسترسی به برنامه‌هایی که پیش‌تر از اپ استور دانلود کرده‌اید
     • دسترسی به برنامه‌هایی که پیش‌تر از اپ‌استور دانلود شده است روشی کاملاً مسخره‌تر است که به شما پیشنهاد می‌دهد تا نسخه‌های قدیمی اپلیکیشن‌هایی که اپل آن‌ها را نگه‌داشته است اما توسعه‌دهنده‌گان آن‌ها هم نمی‌توانند آن را به‌روز رسانی کنند استفاده کنید! این کار چه فایده‌ای دارد دقیقاً؟ تعداد اپلیکیشن‌هایی این چنینی بسیار محدود هستند مانند دیوار ... که آخرین به‌روز رسانی آن به ۲ سال پیش مربوط است!!!
   • جیلبریک کردن
     • این روش ممکن است کارایی داشته باشد، اما تمامی مسائل امنیتی و خدماتی که اپل آن‌ها را ارائه می‌کند را از بین برده و در واقع در این روش هیچ تضمینی برای حفظ اطلاعات و صحت عملکرد دستگاه شما وجود ندارد (در واقع شما از روش بسیار خطرناک از بین هزاران حفره‌های شکافته شده‌ی امنیتی عبور کرده و از برنامه‌ی مورد نظرتان که شاید آن یک اپلیکیشن بانکی و ... باشد استفاده می‌کنید).
   • راه حل سیب اپ (بزرگ‌ترین فروشگاه ایرانی برای برنامه های iOS)
     • این پیشنهاد زمانی معتبر است که فروشگاه و یا فروشگاه‌های مربوطه با شفافیت کامل بیان کنند که راه‌حل‌های فعلی هیچکدام نهایی نیست و اصلاً مخصوص کاربر نیست!!! چرا که مشتری نه توسعه‌دهنده است و و نه شرکت! بنابراین زمانی که با حرکت‌های ظاهراً حرفه‌ای اما در حقیقاً کاملاً غیر حرفه‌ای از هر کاربر یک توسعه‌دهنده یا شرکت و یا سازمان می‌سازند طبیعی است که باید هزینه‌هایی مانند ۹۹ تا ۲۹۹ دلار در سال را بپردازند که مسلماً منجر به پولی شدن حق نصب اپلیکیشن خواهد بود که از بیخ غلط است! بنابراین انتظار می‌رود تحت هیچ شرایطی مردم را نَفَهم فرض نکنیم! مطمئنان هر عقل سلیمی می‌تواند تشخیص دهد که این روش دقیقاً همان مثال معروف (ماهی گرفتن از آب گل‌آلود است) در واقع شما باید پول به چیزی بپردازید که خودش روش غیرقانونی و نامناسب است!!!

   برخی از توسعه‌دهندگان و سایت‌های خبری و حتی استور‌ها چنین ادعا می‌کنند که هیچ محدودیتی در توسعه و انتشار برنامه‌های iOS وجود ندارد، آیا این حقیقت است؟

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

   فروشگاه‌های جدید و مدعی بدون محدودیت چگونه کار می‌کنند؟

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

   روش‌های پیشنهادی و رسمی اپل چیست؟

   • طبق اسناد رسمی، اپل می‌گوید اگر شما برنامه‌ی خودتان را به صورت استاندارد توسعه‌ داده‌اید می‌توانید به دو روش آن را منتشر کنید؛ روش اول این است که آن را در فروشگاه اپل منتشر کنید (که در این روش بنابر اساس سیاست‌هایی که دارند مسلماً تحریم ما خواهد بود که شاهدش بودیم - حذف اپلیکیشن‌های ایرانی از فروشگاه اپل). روش دوم آن است که شما اپلیکیشن خود را در قالب روش‌های Ad-Hoc ایجاد کنید که محدود بر ۱۰۰ دستگاه (کاربر) خواهد بود. این روش نیز به گونه‌ای قابل استفاده است اما محدود بر تعداد کاربران خواهد بود و برای اهداف داخلی و سازمانی خودمان طراحی شده است و بدون شک امضاء و مدیریت آن همراه با تولید آمار بسیار زیادی از تأییدیه‌ها سرسام آور خواهد بود. درواقع اپل می‌گوید اگر می‌خواهید در دامنه‌ی بزرگتر یعنی جهان، استفاده کننده‌ی اپلیکیشن شما باشد باید در فروشگاه من آن را منتشر کنید تا هم امنیت و هم پشتیبانی آن را تضمین کنم.
   • روش‌های دیگر نیز با عنوان (Enterprise Program) مطرح هستند که مخصوص تیم‌های توسعه‌ای که در برنامه Enterprise یا همان تجاری ثبت نام کرده‌اند نیز می‌توانند از توزیع داخلی استفاده کنند. این روش همان روشی است که اپل برای عموم اکثراً محدود کرده است و مختص تحریم‌های ایران نیست. درواقع همان روشی که بعضی از شرکت‌های ایرانی هر روز می‌گویند اپلیکیشن را از لینک جدید دریافت کنید!!! که البته همراه با هزینه‌ی سالانه ۲۹۹ دلار است!
   • روش‌های محدود‌تر دیگری وجود دارد که کاربران با محدودیت بیشتری با آن می‌توانند برنامه‌ها را صرفاً برای مصارف ازمایشی و خودمانی استفاده کنند که این دسته با عنوان University Program شناخته شده اند و توانایی نشر برنامه به جامعه‌ی هدف بزرگتری را نخواهند داشت.

   با توجه به این تعاریف مشخص است که دو روش پیش‌فرض استاندارد و Ad-Hoc باقی مانده است. تکلیف روش اول مشخص است که تا زمانی که تحریم‌ها وجود دارد نباید انتظار داشت که در اپ‌استور بتوان اپلیکیشن‌های ایرانی را بارگذاری کرد. اما روش اد‌هاک همان روشی است که اجازه می‌دهد با خرید و ثبت دستگاه در بانک گواهی‌های معتبر اپل اپلیکیشن‌های خود را به مدت ۱ سال یا بیشتر امضا کنید (این روش برای توسعه‌دهندگان) پیشنهاد شده است که احتمالاً روش‌های فعلی استور‌ها این باشد! مسلماً این روش هزینه‌ی شارژ و امضای توسعه‌دهنده را خواهد داشت. البته لازم به ذکر است این روش قطعی نیست و اگر اپل بداند که به زودی هم خواهد دانست میلیون‌ها کاربر توسعه‌دهنده پیدا کرده است مسلماً طی اقداماتی روش‌هایی برای حل آن ارائه خواهد داد.

   خب راه حل منطقی چیست؟

   • با توجه به مستندات و منابع رسمی که اعلام کرده‌اند، از اولین ساعت‌های مسدود شدن نرم‌افزار‌های بانکی و پرداختی، شرکت‌هایی که در این مجموعه اپ یا اپ‌هایی داشتند؛ راه‌حل موقت خود را ارایه کردند، عمده‌ترین راه‌حل استفاده از اپ‌های مسدود شده روی گوشی‌های آیفون، مراجعه به نسخه وب اپلیکیشن یا استفاده از پلتفرم‌های دیگری مانند اندروید است.
   • مدیران اسنپ و دیجی‌کالا از کاربران‌شان درخواست کردند به طور موقت نسخه وب آن‌ها را استفاده کنند تا مشکل حل شود.
   • برخی شرکت‌ها مانند سیب‌اپ و تپسی، نسخه جدید و مجزایی از اپ‌استور ارایه داده و از کاربران‌شان درخواست کردند این اپلیکیشن را از روی سایت آن‌ها دریافت و نصب کنند.
   • سیب‌اپ در پیام‌های ویدیویی و اطلاعیه رسمی، به کاربران خود وعده داده است به‌زودی نسخه جدیدی از اپلیکیشن سیب‌اپ ارایه خواهد شد که دیگر مشکل مسدود بودن یا عدم اعتبارسنجی توسط اپل را ندارد (که این روش زمانی قابل تأیید خواهد بود که به روش‌هایی غلطی که در بالا اشاره شد عمل نشود و رسالت و شعار‌های فریبانه‌ی خود را تغییر دهند) که مسلماً باید اول حقوق مادی و معنوی و حریم خصوصی مصرف کننده را تضمین کنند و در نهایت به روش‌های قانونی مجوز‌های لازم را از اپل دریافت کنند که با توجه به شرایط حاکم کمی غیر ممکن و دور از انتظار است!!!
   • روش‌های بهتری جهت نصب و راه‌اندازی اپلیکیشن‌های ایرانی وجود دارد که با نام‌های Add-Hoc نیز معروف هستند که محدود به نوع توسعه‌دهنده و تجاری معرفی می‌شوند. البته روش‌های تجاری همان روش‌هایی است که سیب‌اپ و دیگر شرکت‌ها مورد استفاده قرار داده‌اند. اما روش روش نوع توسعه‌دهنده می‌تواند با در نظر گرفتن ثبت دستگاه شما در پروفایل این مشکل را تا حدی برطرف کند که فروشگاه‌هایی مانند اناردونی با در نظر گرفتن هزینه‌ی ثبت دستگاه آن را تا به مدت ۱ سال تضمین می‌کنند.
   • روش درست و صحیح‌تر آن است که دقیقاً طبق قوانین اپل عمل شود، در واقع تمامی ماده‌ها و تبصره‌های عنوان شده توسط شرکت اپل در اپ‌استور را باید پذیرفت. اما مشکل اصلی و اساس این مشکلات این است که اپل قبلاً هم گفته است حاضر به ارائه‌ی خدمات به ایران نیست. (یاد شعار استیو جابز مرحوم افتادم که ما خواهیم گفت کاربر از چه چیزی باید استفاده کنند نه آن‌ها) در واقع اپل با این اقدامات و فشار‌های خود رسماً می‌گوید شما بهتر است از محصولات دیگر استفاده کنید که عمل زشت و بسیار نژاد‌پرستانه است.

   آیا فروشگاه‌های داخلی به داد مردم می‌رسند یا از آب گل‌آلود ماهی می‌گیرند؟ قضیه این است!!!

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

   وقتی به خدماتی قرار است پولی پرداخت شود، آن سرویس باید بدون هیچ دغدغه و مشکلات مادی و معنوی قابل استفاده باشد. با توجه به عدم شفاف سازی کاربران که دلیل آن را نداشتن دانش فنی می‌دانند. از جانب بعضی از توسعه‌دهندگان و فروشگاه‌های ایرانی ترجیح داده‌شده است که، خدمات ارائه شود اما با دریافت هزینه! کافی است یک حساب کتاب ساده انجام دهید، وقتی شما قرار است توسعه‌دهنده‌ی اپل باشید باید هزینه‌ی سالیانه آن را پرداخت کنید که چیزی حدود ۹۰ تا ۱۲۰ دلار بسته به مالیات متغیر است. و اگر قرار است امضاء از نوع سازمانی داشته باشید باید هزینه‌ای معادل ۲۹۹ دلار برای آن بپردازید که در نهایت هر ۱۰ الی ۲۰ روز یک بار هزینه نزدیک به ۳ میلیون تومان برای خرید اکانت تجاری باید تقدیم کنید! در قبال آن به دست آوردن برخی از فروشگاه‌ها مانند سیب‌اپ هزینه‌‌ی حداقل ۳۰،۰۰۰ تومان را بابت آن دریافت می‌کنند. به گفته‌ی خودشان تعداد کاربران میلیونی... با پرداخت چنین هزینه‌هایی معادل صد‌ها شاید هم هزاران و میلیون‌ها برابر آن را به دست خواهند آورد!!! فرصت خوبی برای راه‌اندازی کسب‌و‌کار و به قول قدیمی‌ها (ماهی گرفتن از آب گل‌آلود) است نه ؟ البته فروشگاه‌هایی هم وجود دارند که با روش‌های PWA ادعای به اشتراک گذاری اپلیکیشن‌ها را دارند که از اشاره به نسخه وب بودن و محدودیت‌های آن دریغ می‌کنند.

   • حالا که در جریان واقعیت قرار گرفته‌اید، بهتر است خودتان قضاوت کنید (چرا که به عنوان یک برنامه‌نویس این ننگ است که بدانیم اما به زبان نیاوریم که چه چیزی به خُرد ملت می‌دهیم).

   آینده‌ی نرم‌افزار‌های iOS ایرانی چطور خواهد شد؟

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

   هدف از این مقاله این است که با چشمان باز حقیقت پنهاد در پشت این مسائل را بدانید.

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

   استارتاپی

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

   • 27
     نوشته‌
   • 8
     دیدگاه
   • 2481
     مشاهده

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

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

   طراحی و توسعه

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

   • 9
     نوشته‌
   • 5
     دیدگاه
   • 2100
     مشاهده

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

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

   

   آخرین نوشته
   

   اصول طراحی: تضاد

   توسط الهه انصاری، 21 خرداد 1398

   تا کنون در مجموعه‌ی مقالات اصول طراحی، در مورد تعادل و رنگ صحبت کردیم. در این بخش این روند را با موضوع تضاد (Contrast) ادامه می‌دهیم. 

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

   ۱. تضاد از نظر چشمان ما جذاب است.

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

   

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

   

   ۲. تضاد به سازماندهی اطلاعات کمک می‌کند.

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

   

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

   

   ۳. تضاد سبب ایجاد تمرکز می‌شود.

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

   

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

   

   مواردی که هنگام افزودن تضاد به طرح‌های خود باید به آن‌ها فکر کنید:

   ۱. چگونه تضاد را ایجاد میکنید؟ از طریق بافت، تایپوگرافی، رنگ یا شکل؟

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

   ۳. آیا تضاد به کار رفته، ایده‌ی طراحی شما را تقویت می‌کند؟

   پی‌نوشت: مقالات و دوره‌های سایت Sitepoint پیشنهاد می‌شوند. با ایجاد حساب کاربری امکانات جذابی در اختیارتان قرار خواهد گرفت.

    

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

   سخت افزار

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

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

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

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

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

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

   

   آخرین نوشته
   

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

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

   

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

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

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

   

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

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

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

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

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

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

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

   رویداد‌ها

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

   • 4
     نوشته‌
   • 0
     دیدگاه
   • 1548
     مشاهده

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

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