Здравствуйте! Друзья, в этот раз мы подготовили для вас подборку лучших вебинаров от ITVDN по направлению .NET. В рейтинг вошли как познавательные вебинары с актуальной информацией, так и вебинары, ориентированные на прокачку ваших навыков создания кода. Давайте приступим к их рассмотрению. Как стать C# разработчиком в 2021 году? .NET или .NET Core? Автор — Дмитрий Охрименко, сертифицированный специалист Microsoft (MCTS, MCPD, MCT). Тренер-консультант, эксперт по построению распределенных и веб-ориентированных приложений. Автор курсов по .NET и FrontEnd разработке на ITVDN C#/.NET разработка — это очень перспективное направление в IT, жизнь которому дала всемирно известная компания MIcrosoft. Если вам интересна данная сфера и вы хотите сделать в ней профессиональный старт, этот вебинар будет для вас как нельзя кстати! Цель вебинара — помочь вам разобраться с главными аспектами данной специальности, опираясь на тенденции развития IT рынка, правильно расставить приоритеты и помочь спланировать ваше обучение и карьеру по направлению C# / .NET.  На мероприятии рассмотрены следующие важные вопросы: Есть ли смысл начинать учить C# в 2021 году? Что такое .NET Framework и что такое .NET Core? Что учить и в какой последовательности? Карта специальности Сравнение веб приложения на .NET и на .NET Core Полезные ресурсы для обучения и развития Вопросы и ответы Как стать Full-Stack разработчиком? Автор — Виталий Емец, FullStack Developer, Microsoft Certified Specialist Full-stack разработчик (произносится “фулл стек”) — это мастер на все руки в мире веб-разработки. Ему под силу реализовать как клиентскую, так и серверную сторону приложения, которыми обычно занимаются FrontEnd и BackEnd разработчики раздельно друг от друга. Таким образом, в некоторых случаях Full-Stack специалист может даже в одиночку вести проект от начала до конца. Какими навыками необходимо обладать, чтобы достичь такого уровня мастерства, и какой инструментарий должен быть у истинного Full-Stack разработчика? В чем преимущества данной профессии и какие у нее подводные камни? Каким образом Full-Stack разработка связана с технологиями C#/.NET? Все ответы на ваши вопросы вы получите на вебинаре Виталия Емца. Что нового в C# 8, 9? Автор — Алексей Никифоров, Software Engineer & Business Analyst at HYS-Enterprise C# — это универсальный объектно-ориентированный язык, который является мощным инструментом создания программного обеспечения с широкой областью применения. При столь высокой функциональности он является достаточно несложным в изучении и отлично подходит тем, кто собирается сделать первый шаг навстречу программированию. Данный вебинар предусматривает погружение в последние нововведения языка С#. Основной упор будет сделан на коммуникацию и обсуждение, предполагая, что участники вебинара — разработчики C#, которые следят за новинками данного языка. Автор пройдется по новым возможностям языка и обсудит, как эти изменения могут быть использованы с целью написания более выразительного и чистого кода. Алгоритмы и структуры данных в .NET Автор — Ярослав Кучук, .NET Developer На вебинаре рассматривается вопрос фундаментальной алгоритмической подготовки – от математического обоснования мощности алгоритма до стандартных алгоритмов и структур данных. Базовые алгоритмы реализованы на C#; автор анализирует их с точки зрения их мощности. На вебинаре рассматриваются следующие темы: Понятие алгоритма Сложность алгоритма и способы ее измерения Основные структуры данных Стек Очередь Связанный список Хеш-таблица Бинарные деревья поиска Красно-черные деревья Базовые сортировочные алгоритмы Базовые поисковые алгоритмы 5. Безопасность .NET веб-приложений: частые ошибки и методы борьбы с ними Автор — Алексей Голубев, Lead Software Engineer в компании SoftServe Цель вебинара — обратить внимание разработчиков на проблемы в сфере безопасности веб приложений, которые можно устранить еще на этапе разработки. На вебинаре автор рассказывает о наиболее частых ошибках в приложениях, уязвимостях, связанных со сторонними библиотеками, и то, как их можно избежать. Содержание вебинара: Авторизация. Кражи сессий и стойкости паролей. Человеческий фактор. Что разработчик может сделать не так и на что обращать внимание. Инъекции. Какие встречаются чаще и чем опасны WYSIWYG редакторы. Рандомизация. Случайности не случайны. Вебинар подойдет .NET разработчикам — приветствуются специалисты любого уровня. Будет много практической информации которую можно применить как на этапе разработки, так и на этапе проектирования систем. 6. Техники тестирования для C# разработчиков. Уровень Advanced Автор — Юрий Науринский, Senior Fullstack .NET Software Developer На вебинаре будет рассмотрено 3 «продвинутые» техники тестирования, которыми должен владеть опытный разработчик. Будет немного теории, примеры и ответы на вопросы. Все примеры на языке С#. Ниже перечислены техники, которые рассматриваются на встрече. Property based testing — техника тестирования, применяемая для проверки свойств функции, программы, системы. Ключевая идея в том, что описываются не заранее заданные ожидаемые значения, а свойства, которым должны удовлетворять тестовые примеры. Дальше, тестовые примеры генерируются случайным образом, постоянно проверяя, удовлетворяют ли они вышеописанным свойствам. Performance testing — одна из самых важных техник тестирования, которую желательно знать каждому разработчику, применяемая для ответа на вопрос, насколько быстро работает функция, программа, система, а также отдельные её компоненты. Также, может отвечать на вопрос, сколько памяти потребляет функция, программа, система. Load testing — техника тестирования, о которой желательно иметь представление каждому веб-разработчику; применяется для измерения поведения системы под различной нагрузкой, в частности нормальной и пиковой. Могут измеряться время ответа, пропускная способность, прочие бизнес-ориентированные метрики. 7. Docker для .NET разработчиков Автор — Алексей Никифоров, Software Engineer & Business Analyst at HYS-Enterprise Docker — это популярная платформа, которая используется при разработке, тестировании и развертывании программного обеспечения. Она позволяет сократить время между написанием кода и поставкой его на “production”. За последние годы популярность Docker’a сильно возросла и данная технология стала индустриальным стандартом в сфере контейнеризации программных решений. Docker может быть полезен очень широкому спектру специалистов: разработчик, тестировщик, администратор, релиз-менеджер и т. д. Несмотря на то, что Docker написан на Go и использует особенности ядра Linux, .NET разработчики, которые традиционно ведут разработку под Windows, могут получить огромную пользу от использования Docker’a на самых разных уровнях. Знание данного инструмента повысит вашу продуктивность и даст конкурентное преимущество на рынке труда. Вебинар будет полезен специалистам начального уровня, которые всегда хотели попробовать Docker. Ознакомление будет основано на .NET Core приложении. По завершению, вы смело будете ориентироваться в основных концепциях и инструментах и сможете успешно начать свою путь изучения Docker’а. 8. F# и функциональное программирование для C# разработчиков Автор — Альберт Ташу, .NET Developer, тренер-консультант учебного центра CyberBionic Systematics, а также сертифицированный специалист Microsoft С# — это мультипарадигменный язык, и с каждым релизом он приобретает всё больше возможностей, направленных на применение функционального программирования, которое является одной из самых востребованных парадигм в современной разработке программного обеспечения. Для того, чтобы легче было разобраться в этой парадигме, будет рассмотрен очень интересный язык платформы .NET — F#. Помимо этого, будут затронуты основные принципы функционального программирования и их применение при разработке на языке C#. Содержание вебинара: Введение в язык F# Основы функционального программирования Применение функциональных подходов при разработке на C# Рефакторинг проекта на С# 9. Создание игры “Space Invaders” на C# с нуля Автор — Армен Маилян, C#/.NET Developer, тренер-консультант CyberBionic Systematics Какой самый лучший способ изучить что-то новое? Конечно же, превратить это в игру! Этот способ хорош и в обучении программированию. Начните изучение языка C# путем создания консольной компьютерной игры. Обещаем минимум скучной теории и максимум практики. Будет интересно! Кому это будет полезно? Новичкам. Никогда не программировали? Это не повод отказываться от нового крутого опыта. У вас есть шанс сделать свою собственную игру на C# и получить опыт практического применения данного языка программирования, а также попробовать себя в роли разработчика игр. Начинающим C# разработчикам. Вы сможете углубить и применить на практике свои знания языка C# вместе с наставником. Чему вы научитесь: Разрабатывать простую игру на языке C#. Разбивать большую задачу на отдельные этапы и последовательно их реализовывать. Применять на практике процедурный и объектно-ориентированный подход для написания программ на С#. Понимать и применять основы алгоритмирования. Применять знания основ ООП для создания полноценной программы. Использовать функционал .NET Framework. 10. Создание эволюционной игры Conway's Game Of Life на C# + WPF Автор — Юрий Науринский, Senior Fullstack .NET Software Developer На вебинаре будет рассмотрен Game Of Life — клеточный автомат, придуманный английским математиком Джоном Конвеем в 1970 году — и его реализация с помощью языка программирования C# и фреймворка WPF. Прежде чем реализовывать игру, необходимо чётко определить задачу и постановку правил самой игры. Дальше будет рассмотрено, как реализовать саму логику игры без привязки к какому-либо фреймворку. Следующий логичный шаг после того, как была реализована основная логика игры — это рассмотрение привязки логики к фреймворку WPF и придание «жизни» игре. В конце вебинара автор расскажет, какие техники тестирования можно применить для гарантии корректности получаемого результата логики игры. Данный вебинар будет интересен C# разработчикам, которые желают углубиться в разработку приложений с использованием технологии WPF, а также хотят рассмотреть с практической точки зрения достаточно интересную и известную математическую игру.   Изучайте .NET разработку на ITVDN!

Добридень, дорогі читачі блогу ITVDN! Тема комп'ютерних ігор часто опиняється в епіцентрі багатьох обговорень. На сьогоднішній день ігри є свого роду видом мистецтва, який має гіллясту класифікацію та різні горизонтальні і вертикальні поглиблення, подібно до інших видів творчої діяльності. Як живопис, скульптура, фотомистецтво – ігри також мають свій жанр, котрий викликає у нас різні емоції та відчуття. Одні підносять сюжети, які захоплюють дух, інші змушують вирішувати головоломки, треті спрямовані на те, щоб полоскотати нерви. Кожна людина незалежно від віку та особистих переваг може знайти собі відповідний ігровий екземпляр. Для того, щоб реалізувати свої ідеї та концепції у відеогрі, розробники використовують безліч інструментів: мови програмування, знання математики, фізики та англійської мови, системи контролю версій, а також ігровий рушій – фундамент будь-якої гри. Саме на останньому ми робимо акцент в даній статті. Більш детально тему розробки ігор було розкрито в статті “Як стати розробником ігор”. Якщо вам цікаво дізнатися, в чому специфіка роботи гейм девелоперів, як вони сходять на ігровий Олімп і яким набором технологій при цьому озброєні, переходьте за посиланням вище – ви отримаєте відповіді на свої запитання. Отже, ігровий рушій – це водночас інструментарій для створення гри та її базове програмне забезпечення; кілька підсистем, які мають працювати разом, щоб на виході отримати гру. У ці підсистеми входять рушії рендерингу, анімації, фізики, звуку, система скриптів, штучний інтелект, мережевий код та багато інших складових. Одним із найпопулярніших рушіїв є Unity (читається як "юніті") – кросплатформний продукт компанії Unity Technologies, що дозволяє створювати додатки більш ніж на 25 різних платформах. Цей перелік включає персональні комп'ютери (Windows, macOS, Linux), мобільні пристрої (Android, iOS), консолі (PlayStation, Xbox, Switch тощо), VR (Virtual Reality) та інші пристрої. Unity можна назвати найбільш щедрим ігровим рушієм. І не лише тому, що на ньому випущено справді багато ігор різних жанрів під безліч платформ, а й за його безкоштовну базову версію. Unity значно зменшує трудові та грошові витрати розробників. Рушій порівняно простий у використанні для будь-якого девелопера-початківця, але при цьому не відстає від технологій поточного часу. Ця якість принесла Unity велику популярність серед інді-розробників. Однак і у колі великих студій його також використовують. Давайте розглянемо ТОП-7 найкращих ігор на Unity, щоб переконатися в силі та здібностях даного рушія. Hearthstone: Heroes of Warcraft Карткова онлайн-гра за мотивами всесвіту Warcraft. Її суть полягає у віртуальних битвах один з одним за допомогою колод карт з покроковою системою передачі ходів між опонентами протягом матчу. До виходу Hearthstone поняття “карткова гра” у цифровому середовищі сприймалося досить холодно. Багатосторінковий перелік правил, маса перевантажених механік, загальна недружелюбність до гравця – це спадщина попередніх екземплярів жанру, стикатися з яким середньостатистичному користувачеві не дуже й хотілося. Саме тому реліз альфа-версії Hearthstone сколихнув ігрову спільноту, викликавши велику увагу до гейм-продукту. Його відносна простота та захоплюючий ігровий процес не лише повернули надію гравцям-ветеранам, а й привели нову аудиторію. Можна сказати, що в жанрі карткових ігор відкрилося друге дихання. Hearthstone: Heroes of Warcraft неодноразово нагороджувалася преміями в різних номінаціях, у тому числі: “найкраща мобільна гра”, “найкраща стратегічна гра”, “найкраща багатокористувацька онлайн-гра”. Більше того, вона стала однією з провідних кіберспортивних дисциплін у своєму жанрі. Cities Skylines Містобудівний симулятор, який спрямований на забудову та розвиток власного міста. Гра примітна тим, що крім архітектури необхідно займатися оподаткуванням, організовувати роботу міських служб та громадського транспорту, підтримувати рівень бюджету міста, населення, здоров'я, щастя, зайнятості, стежити за забрудненням довкілля, автотрафіком та іншими елементами гри. Підтримати розповсюдження парків, заборонити куріння, ввести закон про економію електроенергії — вам доступна безліч важелів управління вашим містом. Також у гру вбудований API для створення модифікацій мовою програмування C#, що дозволяє гравцям додавати нові моделі будівель та транспорту, вносити свої корективи у процес гри. Наприклад, можна збільшити допустиму ігрову зону, змінити ігрову перспективу на перспективу від першої особи, автоматизувати деякі елементи гри. Cuphead Комп'ютерна гра, яка поєднує в собі жанри run and gun та shoot 'em up. Її головною особливістю є візуальна складова. Працюючи над стилістикою Cuphead, канадські інді-розробники надихалися роботами аніматорів 1930-х років, внаслідок чого графічно гра дуже відрізняється від будь-яких інших. Cuphead анімована повністю на папері як справжній мультфільм тих часів. Комп'ютер був використаний лише для розмальовки ескізів, в той час як саме життя намальованим героям дали руки аніматора, які за допомогою олівця змалювали велику кількість аркушів паперу. Однак Cuphead сподобалася гравцям не лише завдяки мальованій анімації. За мультяшною естетикою ховається шалений хардкор — платформер просто створений для того, щоб перетворювати голови геймерів на киплячий чайник. Невелика кількість життів та різноманітність випробувань/босів розставлять усі крапки над “i”. Навіть запросивши у гру свого друга, не сподівайтеся на поступки з боку гри. Pillars of Eternity Ізометрична партійна рольова гра, яка сповідує принципи "старої школи" і є духовною спадкоємицею гучних рольових ігор минулого: Baldur's Gate, Planescape: Torment та Icewind Dale. Pillars of Eternity не тільки нічим не поступається своїм попередникам із двохтисячних, а й привносить зручну сучасну механіку. Розроблена компанією Obsidian Entertainment, на рахунку якої такі відомі проєкти, як: Fallout: New Vegas, Neverwinter Nights 2, Star Wars: Knights of the Old Republic II, The Outer Worlds та інші. Всі необхідні грошові витрати на створення гри були покриті за допомогою краудфандингової платформи Kickstarter — в концепцію гри повірили вірні шанувальники творчості Обсидіан та фанати рольових ігор. За допомогою Unity розробникам вдалося створити деталізований та пропрацьований світ, який високо оцінили як критики, так і геймери. Рушій дозволив дбайливо перенести старі механіки на нову платформу, при цьому відшліфувавши всі гострі кути, які були присутні в іграх-побратимах кінця дев'яностих та початку нульових. Звичайно, Pillars of Eternity не ідеальна, проте вона довела, що класні рольові ігри зі старим духом і водночас сучасною оболонкою можуть існувати та бути гарним прикладом для наступних екземплярів цього жанру. Pokemon Go Мобільна гра, яка у 2016 році прогриміла на весь світ. Їй присвячувалися репортажі новин у багатьох країнах, включаючи США, Росію, Україну тощо. Платформа Unity забезпечила вихід Pokemon Go як під Андроїд, так і під iOS. Грі вистачило лише одного тижня, щоб стати всесвітньо відомою. Pokemon Go – це рольова багатокористувацька гра для мобільних пристроїв, що використовує технологію доповненої реальності, яка "викликає" віртуальних покемонів на певні ділянки реальної місцевості. Щоб побачити дане створіння і спіймати його, необхідно зайти в гру і направити камеру свого смартфона/планшета на місце присутності істоти. Самі покемони переміщуються ігровою картою в той час, як ви рухаєтеся у реальному світі. Таким чином, гра не тільки демонструє досягнення сучасних технологій доповненої реальності, а й мотивує своїх гравців на підтримку фізичної активності. Subnautica Гра на рушії Unity, розроблена інді-студією Unknown Worlds Entertainment у жанрі пригодницької гри та симулятора виживання з відкритим світом. Дуже тепло прийнята як критиками, так і гравцями. На Metacritic – популярному сервісі, який збирає рецензії до різних музичних альбомів, ігор, фільмів, ТВ-шоу, DVD-дисків та мобільних ігор – середня оцінка ПК-версії від критиків – 87 із 100 (39 видань висловили свою думку), а від користувачів – 8.5 із 10 (806 гравців висловили свою думку). Геймплей гри побудований навколо виживання на барвистій океанічній планеті серед безлічі недружніх істот, куди герой потрапив у результаті аварії космічного корабля. Для різноманітності контенту та надання йому більшої кількості механік, в гру було введено зручну систему крафту. Не забули розробники і про сюжетну складову, яка здатна якщо не здивувати, то утримувати гравця в інтризі до самої розв'язки. Проте головною особливістю Subnautica було саме дослідження підводного світу, сповненого таємниць та небезпек. Перегляньте огляди на неї і ви дізнаєтеся, наскільки комплексну, багатогранну і при цьому красиву гру можна створити з використанням Unity. Kerbal Space Program Цікавий проєкт на Unity, котрий являє собою космічний симулятор. Жанр гри – пісочниця, в якій вам слід спорудити свій космодром, побудувати ракету і запустити її в космос. Обираєте цілі, збираєте літаючий апарат необхідної конфігурації, злітаєте, вирушаєте в якусь цікаву точку космосу, здійснюєте свої дослідження – і назад додому. Звісно, ​​не все так просто. Щоб здійснити задумане, вам потрібні хоча б поверхневі знання в області фізики, інакше ваша конструкція навіть на сантиметр не підніметься. Також не обійтися і без кмітливості. Конструювання ракети, вирішення питань паливного постачання, акумуляція електроенергії в космічному просторі та інше — іграшка для тих, хто не боїться експериментувати та кидати собі виклики. Створюючи її, розробники хотіли зробити не лише головоломку для аерокосмічних любителів, а й популяризувати наукову та інженерну діяльність у широкого загалу. Чудовий вибір для тих, хто бажає підвищити свою ерудованість. Підсумки Як ви помітили, ігровий рушій Unity демонструє чудові показники у створенні абсолютно різнополярних гейм-продуктів. Містобудівні симулятори, доповнена реальність на вашому смартфоні/планшеті, хардкорні ігри в стилі ретро-мультиків, підводні пригодницькі пісочниці, симулятори з великим акцентом на фізику та кмітливість, карткові ігри та ізометричні рольові стратегії... Це далеко не повний перелік жанрів, в яких Unity себе чудово зарекомендував. Щоб створювати захоплюючі і затягуючі ігри, необов'язково мати знання С/С++. Якщо вас цікавить гейм індустрія і ви хочете пов'язати свою професійну діяльність з розробкою ігор, пропонуємо вам опанувати спеціальність Unity/Game Developer, яка доступна на ITVDN у форматі записаних відео уроків. Обов'язкова програма навчання включає наступні відео курси: Unity Starter Unity Essential Unity Advanced Основи використання Git Unity User Interface Крім цього, програма містить прикладні відео курси, в яких автор демонструє створення ігор, аналогічних таким загальновідомим, як: Need For Speed, Pokemon Go, Counter Strike, Agar.io тощо. Також в курсі приділяється увага створенню ігор VR (віртуальна реальність) та модифікації вже існуючих (як, наприклад, GTA V). Для того, щоб створювати унікальні відеоігри з добре пропрацьованим геймплеєм, необхідно вивчити мову програмування C#. Безумовно, розробляти ігри можна, знаючи лише Unity, проте щоб внести щось своє до гри, потрібна C#. Ця мова є однією з найлегших та найзручніших у вивченні для новачків. ITVDN має невеликий “чит” для тих, хто хоче її опанувати – відео курси від Олександра Шевчука, експерта у галузі побудови архітектури інформаційних систем, бізнес-аналізу та управління IT-проєктами. Цей автор є одним із найулюбленіших серед наших студентів. Його манері викладання складно знайти рівних, як і рівню зрозумілості записаних ним уроків. Нещодавно Олександр Шевчук випустив новий відео курс "Процедурне програмування мовою C#", який є оновленням курсу "С# Стартовий". Обираючи навчання у даного автора, ви досягнете дзену C# у максимально зрозумілій та мотивуючій формі, котру складно відшукати в інтернет-просторі. Поєднайте отримані знання з відео курсами спеціальності Unity/Game Developer та отримайте солідний інструментарій розробки відеоігор, з яким зможете підкорювати будь-які вершини ігробудівництва. Якщо у вас виникли зауваження або побажання до статті, сміливо залишайте їх у коментарях. Бажаємо успіхів та невичерпної мотивації на шляху до ваших цілей! Залишайтеся з ITVDN!

Верстка сайтов и веб-программирование привлекают большое количество новичков в мир IT. Это связано с достаточно низким порогом вхождения. Количество желающих стать фронтендщиком с каждым годом увеличивается, вследствии чего растут и требования к кандидатам.  Какие технологии необходимо изучить, чтобы стать FrontEnd разработчиком в 2019 году? Давайте разберемся.    HTML5 & CSS3 HTML5 и CSS3 - это фундаментальные технологии, без знания которых не обойтись любому веб-разработчику. С помощью языка гипертекстовой разметки HTML создается разметка (каркас) каждой интернет-страницы. Затем язык стилей CSS преображает сайт и придает ему привлекательный и эффектный внешний вид.  Также необходимо владеть: кроссбраузерной адаптивной версткой, чтобы уметь создавать сайты под мобильные устройства, планшеты и широкоформатные экраны и для различных браузеров; семантической версткой для повышения качества разметки и улучшения поисковой индексации сайта. Хорошее владение HTML и CSS уже позволяет заниматься версткой сайтов и начать зарабатывать деньги. Именно с этих двух базовых технологий начинается путь к профессии FrontEnd разработчика.   Bootstrap 4 Популярная HTML/CSS платформа для разработки адаптивных веб-приложений, которую применяют при создании сайтов и интерфейсов администраторских панелей. Основные преимущества Bootstrap: высокая скорость верстки; кроссбраузерность и кроссплатформенность; наличие хорошей документации, большого сообщества и огромного количества разнообразных обучающих материалов; низкий порог вхождения (необходимо знать лишь основы HTML, CSS, JavaScript и jQuery).      JavaScript Язык программирования, который используется как при разработке клиентской стороны веб-приложения, так и серверной. При помощи JavaScript (сокращенно - JS) можно писать даже десктопные (настольные) и мобильные приложения, используя определенные программные платформы и библиотеки. Этот язык позволяет:  динамически изменять разметку; осуществлять интерактивное взаимодействие с пользователем; анимировать изображения; совершать валидацию форм; управлять мультимедиа и т. д.  Другими словами, JavaScript “оживляет” страницу и добавляет ей функциональности. Хорошее владение данным языком программирования является обязательным для каждого FrontEnd разработчика. Сергей Росоха, Software Architect с 11-летним опыта во FrontEnd/JS, отмечает важность изучения алгоритмов и структур данных на JavaScript:  “JavaScript давно уже используется не только для разработки динамических интерфейсов пользователя, но и для написания достаточно сложной бизнес-логики. Поэтому знание алгоритмов и структур данных становится критичным для JS-разработчиков. ” (источник) JavaScript использует официальный стандарт ECMAScript (сокращенно - ES), который подразумевает определенное формальное описание синтаксиса, базовых объектов и алгоритмов. На данный момент существует множество различных версий ES. Работодатели чаще всего требуют знание ES6.  Однако, вначале необходимо изучить чистый JavaScript и лишь потом вникать в новые стандарты. Как ни крути, а классику надо знать. Благодаря хорошему владению JS можно быстро разобраться в любой версии ES и затем освоить любой фреймворк или библиотеку.    Фреймворки JavaScript Это инструменты, с помощью которых создаются динамические веб/мобильные/десктопные приложения на языке JavaScript. Они ускоряют разработку веб-приложений и предусматривают четко структурированную организацию кода, повышая его качество и чистоту.  Самыми популярными фреймворками для фронтенд-разработки можно назвать Vue.js, React и Angular. Каждый из них предназначен для решения своего спектра задач и имеет различную степень сложности: Vue.js - самый легкий (но и с наименьшим сообществом), React - средней сложности, Angular - высокой сложности. Стоит сконцентрироваться на глубоком изучении одного фреймворка, но в то же время очень рекомендуется знать особенности и сферу применения всех вышеперечисленных технологий. Какой фреймворк все же выбрать? Мнения на этот счет расходятся. Инструментарий выбирается индивидуально под проект и трудно предугадать, какие задачи вам нужно будет решать. Мы рекомендуем Angular.       CSS препроцессоры  CSS препроцессор - это программа, которая имеет свой собственный синтаксис, но может сгенерировать из него CSS код. Самыми популярными считаются SASS, Stylus, LESS и PostCSS, однако, наибольшее комьюнити имеет именно SASS. Препроцессоры предназначены для: ускорения процесса написания кода; упрощения чтения кода и дальнейшей его поддержки; минимизации рутинной работы при написании кода. Для повышения эффективности написания CSS кода вполне достаточным будет изучение лишь одного препроцессора.   Git Самая популярная распределенная система управления версиями, которая позволяет вести историю разработки проекта с возможностью доступа к каждой сохраненной версии. Таким образом, если в процессе создания программный продукт стал неправильно функционировать, есть возможность вернуться к предыдущей рабочей версии вместо длительных поисков ошибок.  Также системы управления версиями являются неотъемлемым инструментом командной разработки, который дает возможность девелоперам работать над одним проектом одновременно, сохраняя внесенные изменения. Заодно удобно отслеживать выполнение задач каждым членом команды. Очень важный инструмент для любого IT-разработчика.     jQuery Небольшая, быстрая и многофункциональная JavaScript-библиотека, для работы с которой необходимо владеть HTML, CSS и JavaScript на базовом уровне. Она призвана упростить программирование на JS. Данная библиотека представляет объемные решения распространенных задач в виде методов, которые вызываются одной строчкой кода.  Несмотря на то, что jQuery теряет популярность, уступая место фреймворкам JS, большое количество сайтов все еще используют эту библиотеку. FrontEnd разработчик, работающий в офисе, не всегда создает новые веб-сайты - необходимо поддерживать и обновлять уже существующие. Тут без знания jQuery никак не обойтись.   JavaScript Core (DOM, AJAX, JSON) DOM (Document Object Model) - объектное представление исходного HTML-документа. Ключевым является понятие DOM-дерева, которое описывает структуру страницы. С помощью объектной модели JavaScript получает полную власть над HTML-документом: возможность редактировать, удалять и добавлять элементы и атрибуты HTML, менять CSS код и т. д.  AJAX (Asynchronous JavaScript And XML) - это синтез технологий JavaScript и XML, который фактически представляет собой комбинацию: встроенного в браузер XMLHttpRequest-объекта (чтоб запрашивать данные с веб-сервера); JavaScript и HTML DOM (чтобы отображать или использовать данные). AJAX позволяет веб-страницам совершать асинхронное обновление, обмениваясь данными с веб-сервером. Благодаря этой технологии страница не нуждается в перезагрузке - обновляется лишь конкретная ее часть (вспомните ленту новостей в социальных сетях). JSON (JavaScript Object Notation) - это общий формат обмена данными. Позволяет совершать обмен информацией между программными продуктами, написанными на разных языках. Таким образом, клиент, использующий JavaScript, может легко передавать данные на сервер, который реализован с помощью Ruby/Java/PHP. Все три технологии являют особую ценность для каждого веб-разработчика и раскрывают организацию работы интернет-приложения.      БЭМ “Блок, Элемент, Модификатор” - методология, предусматривающая компонентный подход к разработке веб-страниц, в основе которого лежит принцип разделения интерфейса на независимые блоки. Подход БЭМ позволяет повторно использовать существующий код в создании других страниц с сохранением всех его свойств (размеры, шрифт, цвет и т. д.).       Webpack Мощный сборщик модулей, который позволяет скомпилировать в один файл несколько разных модулей. Используется во время работы над объемными проектами. Успешно применяется как во фронтенд-разработке, так и при создании бэкенд-приложений.   Flex и Grid CSS Технологии верстки надежных адаптивных веб-страниц, которые позволяют легче создавать динамические сайты и удобнее структурировать их содержимое. Лучше всего Flex-верстку в действии показывает интерактивный сайт flexboxfroggy.com, а Grid-верстку - cssgridgarden.com.   Gulp / Grunt Системы сборки, которые автоматизируют рутинные задачи разработчиков: минификацию кода, оптимизацию изображений, тестирование, анализ качества кода и прочее. Подходят при разработке небольших проектов.    TypeScript Кроссплатформенный строго типизированный язык, который является расширением JavaScript. Строгая типизация позволяет уменьшить количество потенциальных ошибок в исходном коде, написанном на TypeScript. Также, этот язык реализует концепции, которые близки объектно-ориентированным языкам, таким как C#, Java и подобным. TypeScript повышает скорость и удобство написания сложных комплексных программ, вследствии чего их становится легче поддерживать, масштабировать и тестировать.     SVG Язык разметки масштабируемой векторной графики. Изображения на странице, сделанные с помощью SVG, корректно отображаются на экранах с различным разрешением, не теряя при этом своего качества, в отличии от традиционных растровых .jpeg, .png и других.    Английский язык Знание английского языка является одним из основных требований к фронтенд-разработчику, поскольку большое количество полезной информации находится именно на англоязычных сайтах. Уровень чтения технической документации будет достаточным для комфортного пользования иностранными ресурсами.      Итоги FrontEnd разработчик - достаточно универсальный боец в мире веб-разработки. Он должен уметь и верстать, и создавать логику работы клиентской части, и понимать работу серверной части веб-приложения. Для освоения такого обширного инструментария стоит запастись временем, терпением и упорством. Перечисленные в статье средства разработки сайтов также имеют аналоги, поскольку для решения разных задач подходят разные веб-инструменты. Однако мы выбрали самые популярные и эффективные из них.    Если у вас остались вопросы о последовательности и необходимости изучения тех или иных технологий, ответы вы можете найти в видео Как стать FrontEnd разработчиком, в котором подробно рассматриваются основные технологии создания клиентских веб-приложений.  Для тех, кто хочет стать FrontEnd разработчиком, на ITVDN создана комплексная программа обучения, которая включает в себя 35 видео курсов. Желаем вам успехов в достижении ваших целей!   Оставайтесь с ITVDN!    

Code Wars CodinGame Cyber Dojo CodeCombat CodeMonkey CSS Diner Flexbox Froggy Flexbox Defense Ruby Warrior Untrusted Robocode CheckIO Elevator Saga Вывод Когда начинали писать код многие из современных гуру программирования, их возможности в обучении были ограничены – книги, справочники, наборы технической документации и спецификаций. Со временем ситуация улучшилась. Начали появляться  различные онлайн ресурсы.  Появилось множество видеоуроков. Родилось и набрало силы новое направление в обучении – онлайн обучение. Онлайн обучение прошло долгий путь в последние несколько лет. Появились интерактивные курсы, в сети Интернет выложено множество видеоуроков, различные онлайн-уроки проводятся с квалифицированными тренерами по множеству направлений. Одним из новых и очень увлекательных способов интерактивного онлайн обучения программированию стали игры, в которых нужно выполнять задания с использованием различных языков программирования. Конечно, одно только написание кода в играх не сделают из вас профессионального разработчика, однако такие игры могут стать действительно полезным способом отработать навыки  и поддержать интерес к обучению. Игры увлекают. Вы внезапно обнаружите, что потратили несколько часов на закрепление своих навыков программирования, даже не осознавая этого. 1. Code Wars Code Wars поможет вам улучшить ваши навыки написания кода, соревнуясь с другими разработчиками. Игра предлагает большое разнообразие языков, включая JavaScript, Swift, PHP, Python, Ruby и Haskell. Сначала вам нужно будет подтвердить ваши навыки, пройдя базовый тест на понимание языка, который вы хотите практиковать. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский. Доступные языки программирования: Clojure, C, C++, C#, Crystal, Dart, Elixir, F#, Go, Haskell, Java, JavaScript, PHP, Python, Ruby, Rust, Shell, SQL, Swift, TypeScript.   2. CodinGame CodinGame предлагает набор бесплатных игр, которые помогут вам в освоении более 25 различных языков программирования, включая C#, Java, Python, JavaScript, Ruby и PHP. Вы можете выполнять игровые практические задания для проверки навыков или посмотреть примеры, объясняющие различные конструкции языка. Одна из особенностей CodinGame заключается в том, что вы можете играть с друзьями или коллегами, а также участвовать в международных соревнованиях по программированию. Материалы игр доступны на английском и французском языках. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский, Французский. Доступные языки программирования:  Bash, C, C++, C#, Clojure, Dart, F#, Java, JavaScript, Go, Groovy, Haskell, Kotlin, Lua, Objective‑C, OCaml, Pascal, Perl, PHP, Python2, Python3, Ruby, Rust, Scala, Swift, VB.NET. 3. Cyber Dojo В Cyber Dojo есть практические упражнения и задачи для десятков языков программирования, включая C#, Java, C++, Ruby, JavaScript, PHP, Python и другие. Каждое упражнение предполагает определенную задачу, чтобы дополнить имеющийся код, выполняющий определенную задачу. Несмотря на то, что это не совсем игра, а скорее большой набор интересных задач, это все же отличный способ попрактиковать свои навыки в коде. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский. Доступные языки программирования: Assembler, BCPL, Bash, C, C#, C++, Chapel, Clojure, CoffeeScript, D, Elixir, F#, Fortran, Go, Groovy, Haskell, Java, JavaScript, Kotlin, PHP, Pascal, Perl, Python, R, Ruby, Swift, VHDL, assert, VisualBasic, NUnit. 4. CodeCombat CodeCombat ориентирован на учителей и учеников, но играть может каждый. Эта достаточно яркая и увлекательная платформа подойдет для практики в таких языках как Python, JavaScript, CoffeeScript, HTML и CSS. На начальном уровне подземелий вы будете перемещать своего персонажа по различным уровням игры, используя базовые команды. Далее команды усложняются. Можно играть самому, участвовать в соревнованиях и многопользовательских вариантах игр – все это поможет вам не заскучать во время отработки в этой игре полученных ранее навыков программирования. Имеется возможность играть бесплатно, но получить доступ ко всему контенту можно только по платной подписке. Особенности игры: браузерная игра, есть платный контент. Доступные языки интерфейса: Английский, Русский, Украинский и еще 57 языков. Доступные языки программирования: Python, JavaScript, CoffeeScript, HTML и CSS. 5. CodeMonkey CodeMonkey это онлайн игра, которая обучает программированию с использованием CoffeeScript. CoffeeScript – это современный открытый язык программирования, который по своей сути является  просто надстройкой и синтаксическим сахаром для JavaScript. В основном CoffeeScript используется для веб-приложений. В игре пользователи с помощью кода контролируют поведение обезьяны и помогают ей собирать бананы. CodeMonkey предназначен скорее для обучения детей. Однако данная игра подойдет и взрослым, желающим в простой игровой манере закрепить знания языка. Несмотря на относительно детский интерфейс игры, задачи в CodeMonkey затрагивают такие темы языка программирования, как: объекты, вызовы функций, аргументы, циклы, переменные, массивы, цикл for, определение функций, булевые условия, цикл until, if и if-else условия, булевые операторы, события клавиатуры и мыши.   Имеется бесплатная триальная версия и ряд премиум подписок, позволяющих, в частности, учителям подключать учеников для обучения и контроля выполнения заданий. Особенности игры: браузерная игра, триальная версия на 14 дней и платная подписка. Доступные языки интерфейса: Английский, Русский, и еще 16 языков. Доступные языки программирования:  CoffeeScript (JavaScript). 6. CSS Diner CSS Diner - простой, но достаточно увлекательный способ изучения языка CSS. Последовательно проходя 32 уровня, вы в игровой манере сможете познакомиться с основами работы CSS-селекторов. Начиная с простых селекторов по классам  и тэгам  уровни этой бесплатной игры постепенно усложняется, основываясь на том, что вы запомнили на предыдущих уровнях. Под конец вы будете использовать сложные структурные селекторы наподобие и их комбинации. Эта игра будет полезна тем, кто ищет удобный и нескучный инструмент, чтобы попрактиковаться в верстке. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский. Доступные языки программирования: CSS. 7. Flexbox Froggy Flexbox Froggy это удобный инструмент для тех, кто уже имеет определенные навыки работы с CSS и хочет на практике, и в интересной манере, изучить основы такой технологии, как CSS Flexible Box Layout Module (или CSS Flexbox).  У Flexbox Froggy достаточно простой интерфейс, с помощью которого вы научитесь основам выравнивания во Flexbox, пока вы помогаете лягушонку Фрогги и его друзьям в их приключениях. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский, Русский, Украинский и еще 28 языков. Доступные языки программирования: CSS. 8. Flexbox Defense Flexbox Defense - еще один интересный способ попрактиковаться в навыках работы с Flexbox. Это игра по принципу Tower Defense. В этой игре вы будете с помощью CSS свойств размещать пушки в нужные места вдоль пути, чтобы победить встречные волны врагов. Вы получите нужную практику в интересной интерактивной манере, используя те же команды, что и в Flexbox Froggy. Особенности игры: браузерная игра. Доступные языки интерфейса: Английский. Доступные языки программирования: CSS. 9. Ruby Warrior Если вы хотите изучать язык Ruby, тогда Ruby Warrior - это игра для вас. Управляя персонажем рыцаря с помощью кода на Ruby, вы будете выполнять игровые задачи, сражаться с монстрами и проходить подземелья. В игре есть простые и сложные задания, подходящие вашему уровню владения языком Ruby. Играя в Ruby Warrior вы улучшите ваши знания циклических и условных конструкций, создания и вызова методов. Авторизация в игре происходит через аккаунт Facebook. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский. Доступные языки программирования: Ruby. 10. Untrusted Untrusted - это приключенческая игра, которая поможет вам проверить и закрепить ваши знания и навыки JavaScript для решения различных проблем. Вы будете использовать код на JavaScript, чтобы провести доктора Эвала по разным локациям электронной вселенной. Это увлекательная бесплатная игра поможет отработать достаточно сложные навыки применения JavaScript. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский. Языки: JavaScript 11. Robocode Robocode  подойдет вам, если вы когда-нибудь интересовались играми с противостоянием различных роботов. Играя в Robocode, вы приобретете и укрепите навыки программирования, создавая виртуальные боевые роботы-танки. Логику поведения этих роботов вы будете прописывать, используя языки Java или C# с помощью вашей IDE. Битвы с такими роботами затем разыгрываются в браузере на экране в режиме реального времени. Особенности игры: бесплатная игра; онлайн игра, но требует установки определенных модулей на ваш ПК. Доступные языки интерфейса: Английский. Языки: Java или C#. 12. CheckIO CheckIO  - это стратегическая игра, которая будет интересна как начинающим, так и уже продвинутым программистам. Вы будете выполнять  задания, которые помогут лучше изучить особенности выбранного языка программирования. Данная игра поможет вам вписать код лучше. Набирая балы за выполнение задания, вы можете также сравнивать свои ответы с ответами других игроков CheckIO. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский. Доступные языки программирования: Python, JavaScript. 13. Elevator Saga Elevator Saga поможет вам протестировать ваши знания JavaScript во время решения  проблем, связанных с перемещением лифта и транспортировкой людей наиболее эффективным способом. Начинается задача с перемещения 15 человек, затем задачи становятся сложнее. Особенности игры: браузерная игра, бесплатная игра. Доступные языки интерфейса: Английский. Доступные языки программирования: JavaScript. Для удобства подбора подходящей игры мы собрали их в таблицу: Не всегда только суровая зубрежка и толстые учебники способствуют получению знаний. Обучение в игровой форме – это также один из лучших способов запомнить что-то новое или закрепить уже существующий навык. Вывод Многие из представленных в этом обзоре игр смогут реально помочь Вам улучшить понимание основного инструмента разработчика – языка программирования. Мы включили в этот обзор как игры, полезные при изучении языков программирования, так и те из них, что помогут лучше запомнить конструкции CSS, HTML, SQL. В некоторых играх вы будете выполнять готовые задачи, зарабатывая баллы и играя «против компьютера», некоторые игры позволят вам соревноваться с другими разработчиками в поиске решений чужих задач и предложении встречных задач. Учитесь, играючи и обучайтесь во время игры! Мы надеемся, что наша подборка игр поможет вам в этом. Также всем, кто изучает программирование, мы рекомендуем использовать интерактивный тренажер навыков ITVDN. В тренажере вас ждут задания, которые нужно выполнять, используя навыки программирования. За правильные решения вы будете получать баллы. В случае ошибки, вы сможете воспользоваться подсказками, но за использование подсказок будут сниматься баллы. Итак, ваша задача – выполнить все задания на тренажере, набрав максимальное количество баллов! На ITVDN доступны интерактивные тренажеры по таким языкам программирования и технологиям: HTML5&CSS3 (уровень Starter и Essential) JavaScript (уровень Essential и Advanced) Python (уровень Starter и Essential) Java Starter C# (уровень Starter и Essential) SQL Essential C++ (уровень Starter и Essential) Перейти в Тренажер ITVDN  

10 отменных советов как стать лучшим Node.JS разработчиком 2018 года от автора Азата Мардана. Эта статья содержит в себе собранный и тщательно отфильтрованный опыт писателей и спикеров технологии всего Веб-сообщества. Заметка: первоначально заголовком статьи должно было быть «Лучшие практики Node.JS от Гуру Технологии». Эта статья охватывает не «новые» и «лучшие» практики 2017-2018 года, а тщательно выверенные и проверенные временем и практикой паттерны, которые стопроцентно приведут к успеху. И хотя многие из проверенных практик Вам определенно пригодятся в 2018, 2019 и даже более поздних годах, статья не включает в себя такие новшества, как async/await и прочее. Почему? Потому что эти фичи не включены в состав, собственно говоря, кода Node.JS-ядра или кода таких популярных проектов как npm, Express и прочие. Полноценно заниматься разработкой на Node.JS я начал в 2012 году, когда присоединился к Storify. С тех пор я никогда не жалел о принятом решении и не ощущал, как будто я многое потерял, закинув Python, Ruby, Java или PHP – языки, с которыми я работал на протяжении предыдущего десятилетия. Работа в компании Storify для мня оказалась достаточно интенсивной. В отличии от большинства компаний, все приложения Storify работают исключительно на JavaScript. Как вы понимаете, большинство компаний, особенно такие крупные как PayPal, Walmart или Capital One, используют Node.JS только для конкретных определенных задач. Как правило, это gateway API. Однако, с точки зрения программиста, ничего не может быть лучше, чем работа и погружение с головой в одну определенную технологию. Краткая сводка: Избегайте нагромождения – пытайтесь разбивать свой код на столько мелких составных частей, насколько это вообще возможно. И даже больше. Используйте асинхронный подход – избегайте синхронное программирование словно чумы. Избегайте блокировки потоков – помещайте ВСЕ требуемые утверждения в начало файла, ибо они синхронные и, следовательно, будут блокировать программу. Require должен быть закеширован – считайте, это такая фича в Вашем коде. Или баг. Как Вам угодно. Всегда проверяйте свой код – ошибки – это не вышивание, которое можно выбросить в любом момент. Никогда не упускайте обнаруженные ошибки! Используйте try…catch только в синхронном потоке – try…catch бесполезен в асинхронном коде. Кроме того, v8 никогда не оптимизирует try…catch-код. Возвращайте значения или используйте if…else – просто на всякий случай: возвращайте значения что бы остановить выполнение участка кода. Обращайте внимание на события ошибок – почти все Node.JS-классы или объекты реализуют паттерн-наблюдатель и производят события-ошибки. Не стоит пропускать их. Познайте свой npm – устанавливайте модули с ключами –S или –D вместо –save или –save-dev. Используйте текущие версии в package.json – при работе с npm он по-тупому просто добавляет верхнюю скобочку по умолчанию при использовании вместе с ключом –S. Дабы избежать этого, просто вручную блокируйте версии. Никогда не доверяйте semver в своих приложениях, но доверьтесь ему в модулях с открытым исходным кодом. Бонус – используйте разные зависимости. Помещайте то, что требует проект только в процессе разработки в devDependencies. После этого используйте npm i –production. Чем больше ненужных зависимостей используется, тем больше риск возникновения уязвимостей.   Давайте разберем некоторые из этих пунктов поподробнее: Избегайте нагромождения Взгляните на некоторые модули, написанные Исааком З. Шлейтером, создателем npm. К примеру, use-strict включает «строгий» режим написания JavaScript-модульного кода. Включается эта опция всего лишь в три строчки: Но почему-же все-таки стоит избегать нагромождения кода? Одна известная фраза американского воздушного флота гласит: «все должно быть просто до идиотизма». И на это существуют свои причины. Человеческий разум не может держать в памяти больше чем от 5 до 7 вещей одновременно. Это просто как факт. Разбивая код на небольшие составные части, Вы и другие разработчики легко сможете разобраться в нем и понять, для чего он предназначен. Так же упрощается процесс тестирования. Вот пример:   Или еще: Уверен, большинство из Вас отдадут предпочтение второму примеру, когда имена переменных сразу же делают понятной их суть. Конечно, в процессе написания кода Вы можете думать, что Вы понимаете, как он работает и так. Возможно, Вам даже захочется продемонстрировать свою смекалку и сообразительность, объединив несколько методов вместе в одну строку. Пожалуйста, пишите так, как если бы Вы были более неопытны. Как если бы Вы не смотрели в код на протяжении 6 месяцев, или очень устали и, кроме того, еще и выпили. Если Вы пишете код на пике своей ментальной активности, Вам будет труднее понимать его позже, не говоря уже о Ваших коллегах, которые даже не знакомы с ходом Ваших мыслей. Держать все в относительной простоте единственно верный метод – особенно в рамках Node.JS-технологии, где используется асинхронный подход. Другими словами, преимущества от использования подхода малых частей значительно более перевешивают недостатки. Помимо прочего, они позволяют значительно быстрее исправить различные ошибки, которые могут возникнуть по разным причинам в процессе работы с Node.JS-приложением.   Используйте асинхронный подход Синхронный код мало где используется в нынешнем Node.JS. Как правило, он находит свое применение в написании CLI-команд или скриптов, не связанных с веб-приложениями. Что же касательно веб-разработки, Node.JS программисты предпочитают использовать асинхронный подход, так как это позволяет избежать блокировки потоков. К примеру, синхронный код будет приемлем, если мы строит скрипт для работы с базой данных, не системы для обработки параллельных/конкурентных задач: Но, в случае веб-приложения, лучше использовать следующее: Отличительная особенность состоит в том, пишите ли вы долго исполняемый конкурентный код или небольшой скрипт с малым временем жизни. А вообще, лучше запомните одно хорошее правило: всегда пишите асинхронный код в Node.JS.   Избегайте блокировки require S обладает простой системой загрузки модулей, которая использует общий формат CommonJS. Самый простой способ подключить модули, разбросанные по отдельным файлам – использовать встроенную функцию require. В отличии о AMD/requirejs, Node/CommonJS синхронна. По сути, функция работает согласно следующему принципу: Вы импортируете то, что было экспортировано в виде модуля или файла. О чем большинство разработчиков даже не догадывается, так это о том, что require кэшируемая. Потому, до тех пор, пока нет заметных изменений зарезервированного имени файла (и, в случае использования npm-модулей, их нет), код модуля будет выполнен и подгружен в переменную только единожды (для обработки). Подобная методика позитивно сказывается на оптимизации. Однако, даже с кэширование, лучше сначала попробуйте обойтись без require. Попробуйте использовать axios-модули. Путь /connect в свою очередь будет медленнее чем требуется, ибо импорт модулей происходит после генерации запроса: Гораздо лучше будет загрузить модули тогда, когда сервер еще даже не определен, не в маршруте: Require должен быть закэширован Хотя я и упоминал о том, что require может быть закэширован, но что так же интересно, так это то, что мы можем поместить код вне module.exports. К примеру: Зная, что некоторые участки кода могут быть запущены только один раз, подобная реализация окажется более чем полезной.   Всегда проверяйте свой код Node.JS – это Вам не Java. В Java Вы выкидываете исключения потому как в большинстве случаев Ваше Java-приложение не должно продолжать работать в случае ошибки. В Java для этого Вы просто используете try…catch. В случае Node.JS история обстоит несколько по-иному. Так как технология выполняется в асинхронном режиме, контекст ошибки всегда будет отделен от любого перехватчика (такого как try…catch) в случае возникновения самой ошибки. Этот код в Node.JS будет просто-напросто бесполезен: Но! Привычный try…catch все еще может быть использован в синхронном режиме. Вот более действенный рефакторинг предыдущего участка кода: Если мы не можем обернуть request-вызов в блок try…catch, ошибка будет не перехвачена. Однако, это легко решается при помощи callback-аргумента error. Кроме того, Вам нужно всегда вручную отлавливать error в каждом и каждом callback`е. Проверяйте наличие ошибки (и убедитесь, что она не равна null) и затем, или демонстрируйте содержание ошибки пользователю или клиенту и потому логируйте ее, или отправляйте ее обратно в место вызова при помощи error-callback`а. В качестве небольшого фокуса Вы можете использовать библиотеку okay. Применяйте ее как наведено ниже что бы обойти ручной проверки на ошибки: Возвращайте значения или используйте if…else .JS – параллельный. Эта особенность может привести к багам, если не отнестись к ней с должной осторожностью. Что бы обезопасить себя, останавливайте выполнение участка кода при помощи ключевого слова return: Избегайте бессмысленной работы (и ошибок) из-за неостановленного вовремя исполнения: Просто убедитесь, что return всегда будет стоять на страже целесообразности работы Вашего кода.   Обращайте внимание на события ошибок Почти все классы/объекты Node.JS реализую паттерн-наблюдатель, который порождает событие-ошибку. Это прекрасная возможность для разработчика отловить особо подлые ошибки и придушить их до того, как они устроят хаос. В качестве полезной привычки было бы неплохо создавать программы-прослушиватели событий-ошибок при помощи использования .on(): Познайте свой npm Многие Node.JS и front-end событийные разработчики знают, что –save (для npm install) не только установит модуль, но так же и создаст запись в package.json с упоминанием текущей версии модуля. Для аналогичных целей существует и –save-dev, опция для модулей, которые нужны только во время разработки. Но знаете ли Вы, что вместо этого можно спокойно использовать –S и –D? Теперь да. И пока Вы в режиме установки модулей, удаляйте символ ^, который будут порождать команды –S и –D. Эти значки могут быть особенно опасными, так как они позволят npm автоматически обновить модуль к последней незначительной версии (вторая цифра в семантике версирования). К примеру, с версии 6.1.0 до версии 6.2.0. Команда NPM полагается на semver, но Вы не должны. Я хочу сказать, что они используют авто обновления к промежуточным версиям модулей с открытым исходным кодом, так как они полагают, что никаких радикальных изменений в этих самых промежуточных версиях не будет. Мой вам совет: не стоит слишком в это верить. Более того, используйте npm shrinkwrap. Команда создаст новый файл с текущими версиями зависимостей зависимостей. И в заключение В этом посте мы охватили много всего: от работы с callback'ами до работы с асинхронными потоками, проверки на ошибки и снятия блокировки зависимостей. Надеюсь, Вы нашли для себя что-то новое и познавательное здесь. Немного об авторе Азат является техническим консультантом и менеджером в Capital One. JavaScript/Node.js-эксперт, автор различных онлайн-курсов. Издатель более чем 12 книг, посвященных теме, включающие такие хиты продаж как Full Stack JavaScript, React Quickly, Practical Node.JS и Pro Express.js и другие. В свое свободное время Азат читает о технике на Webapplog.com, проводит конференции и работает над продуктами с открытым исходным кодом. До того, как стать экспертом Node.JS, работал в федеральных правительственных агентствах США, принимал участие в небольших старт-апах и больших корпорациях, имея дело с такими технологиями, как Java, SQL, PHP, Ruby и прочие. Азат обожает все, что связано с технологиями и финансами, так же увлекается инновационными способами обучения и просвещения людей. Автор перевода: Евгений Лукашук Источник

Об авторе Юрий Думов работает архитектором программного обеспечения в SAP, имеет более 10 лет опыта в разработке веб и мобильных приложений. Прежде всего, давайте введем некоторые сокращения. Internationalization - достаточно длинное слово, поэтому предлагаю его заменить в нашем контексте на “intl”. Интернационализация в общем плане может быть разделена на следующие подпункты: Определение пользовательской локали Перевод UI-элементов, заголовков, подсказок и прочего Поддержка местных специфических сервисов, таких как даты, валюты и числа На заметку: в этой статье я заострю ваше внимание лишь на front-end части. Мы разработаем несложное универсальное React-приложение с полной поддержкой интернационализации. Для начала предлагаю воспользоваться моим репозиторием. Здесь у нас есть веб-сервер Express для серверного рендеринга, вебпак для построения клиентского JS, Babel для конвертации современного JavaScript в ES5. Также мы будем использовать npm-run, nodemon для запуска веб-сервера под средой разработчика и webpak-dev-server для ассетов. Нашей точкой входа в серверное приложение будет служить server.js. Здесь мы загружаем Babel и babel-polyfill для создания прочего серверного кода в современном стандарте JavaScript. В качестве бизнес-логики сервера мы используем src/server.jsx. Тут мы устанавливаем Express-сервер для прослушки порта 3001. Для рендеринга мы используем очень простой компонент components/App.jsx, который также является частью точки входа в универсальное приложение. Точкой входа в клиентский JS нам служит src/client.jsx. Тут мы фиксируем корневой компонент - component/App.jsx - для placeholder'а react-view в HTML-разметке, предоставляемой Express-сервером. Таким образом, сейчас мы склонируем репозиторий, запустим npm-install и выполним nodemon и webpack-dev-server одновременно в двух консолях. В первой консоли: И во второй: Наш веб-сервер должен быть доступен по localhost:3001. Откройте предпочитаемый вами браузер и убедитесь в этом сами! Итак, мы готовы начать. Определение пользовательской локали Существует два возможных решения этого вопроса. По какой-то причине большинство популярных веб-сайтов, включая Skype и NBA, используют гео-IP для определения местоположения пользователя, таким образом определяя его родной язык. Подобный подход не только является дорогим в плане реализации, но и еще не совсем точным. Сейчас очень много людей путешествует, по этой причине местоположение пользователя не является надежным ориентиром при выборе подходящего языка приложения. Вместо этого мы предпочтем второй способ решить данную проблему при помощи обработки на стороне сервера заголовка Accept-Language. Этот заголовок отправляется любым более-менее современным браузером.   -Language Этот заголовок предоставляет информацию о возможных вариантах языка, принятого в качестве ответа. Каждый язык обладает своим «приоритетом», показывая, как часто пользователь может его использовать. По умолчанию уровень «приоритетности» равен 1. К примеру, «Accept-Language: da, en-gb;q=0.8, en;q=0.7» означает «я предпочитаю датский, но могу также принять британский или другие виды английского».   (Также стоит упомянуть, что сей подход так же несовершенен. К примеру, пользователь может посетить ваш веб-сайт из интернет-кафе или публичного ПК. Лучше всего разработать виджет, при помощи которого пользователь на интуитивном уровне сможет поменять язык сайта.)   Реализация определения локали пользователя Вот пример кода веб-сервера Node.js. Мы используем пакет accept-language, что извлекает локали из http-заголовков и находит наиболее предпочтительные, исходя из поддерживаемых вашим веб-сайтом. Если таковые не были найдены, тогда сайт будет использовать свою дефолтную локаль.   Приступим к установке пакетов: После чего в src/server.jsx у нас будет следующее: Здесь мы импортируем accept-language и устанавливаем поддержку английских и русских локалей. Также мы реализовываем функцию detectLocale, что извлекает значение локали из куки. Если ни одна не была обнаружена, начинается обработка Accept-Language. Наконец, мы выбираем дефолтную локаль. После обработки запроса мы добавим заголовок Set-Cookie для обнаруженной локали в ответ. Это значение будет использовано для всех последующих запросов.   Перевод UI-элементов, заголовков, подсказок и прочего Здесь я собираюсь использовать React Intl-пакет. Это наиболее популярная и, так сказать, проверенная боем реализация интернационализации для React-приложений. Впрочем все библиотеки так или иначе строятся по одному принципу: они обеспечивают нас компонентами высшего порядка, что внедряют уже готовые функции интернационализации для обработки сообщений, дат, номеров, валют посредством специальных фич React.   Во-первых, мы должны установить провайдер интернационализации. Для этого мы немного изменим src/server.jsx и src/client.jsx. src/server.jsx:          здесь src/client.jsx: Так, теперь IntlProvider-дочерний компонент получит доступ к функциям интернационализации. Давайте добавим переведенный текст в наше приложение и клавишу для изменения локали. У нас есть два способа, как это можно сделать: через FormattedMessage или через formatMessage – функцию. Разница в том, что компонент будет обернут в span-тэг, что хорошо для текстовых данных, но не хорошо для значений HTML-атрибутов, таких как alt и title. Давайте опробуем и их!   Вот src/components/App.jsx: Отметьте, что атрибут id должен быть всегда уникальным для всего приложения в целом, так что было бы не лишним установить для себя некоторые правила именования сообщений. Я предпочитаю следовать формату «имяКомпонента.некийУникальныйИдентификатор». В качестве некой дефолтной локали будет использовано сообщение defaultMessage. Атрибут description предоставит некую информацию для переводчика.   Перезапустите nodemon и обновите страницу в браузере. Вы должны увидеть «Hello World». Но если вы открываете статью при помощи инструментов разработчика, вы увидите, что текст теперь внутри тэга span. В этом случае это не ошибка, но иногда мы предпочитаем просто получить текст, без никаких дополнительных тэгов. Для этого нам нужен прямой доступ к объекту интернационализации React Intl.   Давайте вернемся назад к src/components/App.jsx: Нам нужно написать гораздо больше кода, чем раньше. Во-первых, мы используем injectIntl, который «упаковывает» наш компонент приложения и внедряет intl-объект. Чтобы получить переведенное сообщение, нам нужно вызвать formatMessage и передать в качестве параметра message. Этот message должен иметь свой уникальный идентификатор и атрибуты defineMesasges из React Intl.   Лучшее, что есть в React Intl, так это его экосистема. Давайте добавим babel-plugin-react-intl к нашему приложению и построим словарь трансляции. Мы передадим этот словарь переводчикам, которым не нужно никаких задатков программирования для выполнения своей работы. .babelrc: Перезапустите nodemon, и вы увидите, что папка build/messages была успешно создана в корневой директории проекта, вместе с некоторыми другими папками и файлами внутри. Теперь нам необходимо собрать эти файлы в один JSON. Для этого вы можете использовать мой скрипт. Сохраните его как scripts/translate.js.   Теперь нам нужно добавить новый скрипт в package.json: Что же, попробуем! В конце вы должны увидеть файл en.json в build/lang. И все работает! Теперь пришло время для кое-чего поинтересней. На стороне сервера мы можем загрузить все переводы в память и, соответственно, выдавать их в зависимости от характера запроса. Однако на клиентской стороне этот подход неприемлем. Потому вместо этого мы будем один раз принимать json-файл со всеми переводами, а клиент автоматически определит, какой из текстов ему нужен.   Скопируем результирующий файл в public/assets. На заметку: если вы пользуетесь Windows, симлинки для вас недоступны. Таким образом, вам нужно будет вручную копировать команды каждый раз, как только вы будете перестраивать ваши переводы. public/assets/ru.json применим следующее: Теперь нам нужно повязать серверный и клиентский коды. Для сервера наш src/server.jsx должен выглядеть так: Здесь мы делаем следующее: Кэшируем сообщения и специфичный для данной локали JS для валют, DateTime, Number во время запуска приложения. Расширяем метод renderHTML так, что мы можем вставить специфичный для данной локали JS прямо в разметку. Предоставляем переведенные сообщения IntlProvider (все те сообщения теперь доступны в качестве дочерних компонентов). Что же касается стороны сервера, во-первых, нам нужно установить библиотеку для выполнения AJAX-запросов. Я предпочитаю использовать изоморфное обновление, так как, скорее всего, нам предстоит запрашивать данные из сторонних API, и изоморфное обновление очень хорошо с этим справляется. Вот src/client.jsx: Также мы должны затронуть src/server.jsx, чтобы Express предоставлял json с переводом на сторону клиента. Заметьте, что на продакшине вы, скорее всего, будете использовать что-то вроде nginx. После инициализации JavaScript, client.jsx возьмет локаль из куки и запросит JSON с переводом. Во всем остальном наше приложение будет работать, как и раньше. Пришло время проверить, как все будет работать в браузере. Откройте вкладку «Network» в панели разработчика и удостоверьтесь, что JSON с переводом был успешно получен нашим клиентом. Подведя итог, давайте добавим небольшой виджет для изменения локали в src/components/LocaleButton.jsx: И так же в src/components/App.jsx: Заметьте, как только пользователь меняет свою локаль, мы перезагружаем страницу, чтобы убедиться, что новый JSON-файл с переводом был успешно извлечен. Теперь же время протестировать! Окей, мы изучили, как определять локаль пользователя и как отображать переведенные сообщения. Перед тем, как двигаться в направлении заключительной части, давайте обсудим пару также немаловажных нюансов. Плюрализация и шаблоны В английском большинство слов могут принимать одну или две возможные формы: «одно яблоко», «много яблок». В других языках все намного сложнее. К примеру, русский имеет 4 различные формы. Надеемся, React сумеет справиться и с этим. Он также поддерживает шаблоны, так что вы можете предоставить переменные, которые могут быть подставлены в шаблон во время рендеринга. Вот как это работает. В src/components/App.jsx у нас есть: Тут мы определяем шаблон с переменной count. Мы напечатаем или «одно яблоко», если значение переменной равно 1, 21 и так далее, или «два яблока» в противном случае. Нам нужно передать все переменные в formatMessage. Давайте перестроим наш файл переводов и добавим русский перевод для теста. Вот наш public/assets/ru.json файл: Теперь все случаи предусмотрены! Поддержка местных специфических сервисов, таких как даты, валюты и числа Ваша информация будет представляться по-разному в зависимости от локали. К примеру, русская локаль нам покажет $500.00 и 12/10/2016.   Intl предоставляет React-компоненты для такого типа данных, которые автоматически обновляются каждые 10 секунд, если вы за это время не перезаписывали значения. это в src/components/App.jsx: Обновите браузер и проверьте страницу. Вам необходимо будет подождать 10 секунд, чтобы увидеть, как обновится FormattedRelative.   Круто, не правда ли? Что же, теперь мы можем столкнуться еще с одной проблемой – универсального рендеринга.   В среднем между формированием разметки и инициализацией JS проходит порядка 2-х секунд. Это значит, что все DateTime`сы, сгенерированные на странице, могут иметь разные значения на стороне клиента и сервера. Что, как следствие, разрушает универсальный рендеринг.   Вот src/server.jsx: вот src/client.jsx: Перезапустите nodemon и проблема почти исчезнет! Она может, правда, остаться в случае, если вы используете Date.now() вместо показаний, записанных в базе. Чтобы сделать пример более «жизненным», заменим в app.jsx Date.now() на последний таймштамп, что-то вроде 1480187019228.   (Впрочем, вы можете столкнутся с другой проблемой – когда сервер не в состоянии отрендерить DateTime в нормальном формате. Это потому, что 4 версия Node.js по умолчанию не поддерживала Intl.) Звучит слишком хорошо, чтобы быть правдой, не так ли? Мы как истинные фронт-енд разработчики всегда были на стороже того, что касается браузеров и платформ. React Intl использует нативный браузерный API для обработки форматов DateTime и Number. И, несмотря на тот факт, что подобная функциональность была представлена в 2012 году, до сих пор есть современные браузеры, которые ее все еще не поддерживают. Даже Safari поддерживает ее только частично. Вот таблица с детальной информацией: ​ Это значит, что если вы желаете покрыть большинство браузеров, которые не поддерживают Intl API на нативном уровне, polyfill для вас просто незаменим. Хвала Всевышнему, существует Intl.js. С одной стороны, кажется, вот оно – идеальное решение, но, как показывает мой опыт, всегда существуют свои недостатки. Во-первых, вам нужно добавить Js-bundle, что несколько ресурсоемко. Также для уменьшения размера вам нужно будет передавать ваш Intl.Js только для браузеров, у которых нет своей нативной поддержки. Конечно, все эти техники уже давным-давно известны, и существует великое множество статей, посвященных им. Но все равно, Intl.js – не абсолютное решение, так как все же представления DateTime и Number на стороне сервера и на стороне клиента могут несколько отличаться, что, разумеется, влечет за собой ошибки при серверном рендеринге.   Наконец, я пришел к своему собственному решению, которое хоть и имеет свои недостатки, но мои запросы в большинстве случаев оно устраивает. Я реализовал очень поверхностный polyfill, что имеет лишь небольшую часть из требуемой функциональности. В то время, как в большинстве случаев подобное решение непригодное, оно лишь добавляет лишние 2 КБ к размеру JS-файла, так что даже нет необходимости реализовывать динамическую загрузку кода для устаревших браузеров, что значительно упрощает решение в целом.   И в заключение Возможно, сейчас вас не покидает чувство, как будто здесь написано слишком сложное решение. Также, возможно, сейчас вы подумываете о том, чтобы реализовать все самим. Я бы не советовал этого делать. В конце концов, вы все равно придете к выводам, представленным в данной статье. Или, что хуже, зайдете в тупик одного решения и не сможете увидеть остальные. Вы можете подумать, что можно легко решить проблему с Intl API, используя вместо него Moment.js (я специально не рассматривал другие библиотеки, так как они либо неподдерживаемые, либо неиспользуемые). К счастью, я уже опробовал это, так что я могу сохранить вам много времени. Moment.js монолитен и очень тяжел, так что если для кого-то он и подойдет, то остальная масса пользователей будет неудовлетворенной результатом. Разработка собственного polyfill не звучит интригующе, так как вам наверняка придется выделить определенное время для борьбы с возникающими при этом багами. Подведя итог, могу лишь сказать, что не существует идеального решения касательно проблемы на данный момент: просто выберите то, что вам подойдет лучше всего.   Надеюсь, эта статья дала вам все, что нужно знать для создания интернационализируемого React front-end приложения. Теперь вы выучили, как определять локаль пользователя, сохранять ее в куки, писать виджет для изменения локали и многое другое! Также вы ознакомились с некоторыми возможными проблема и ловушками, в которые вы можете попасть в процессе написания приложения.   Удачи в разработке! Автор перевода: Евгений Лукашук Источник

Введение Ни для кого не секрет, что в мобильных играх, в отличие от компьютерных, практически единственным “устройством ввода” является палец. То есть, все действия, которые пользователь выполняет в игре, совершаются благодаря прикосновениям к экрану, или же тачам (англ. touch – прикосновение). В этой статье мы с Вами рассмотрим, как можно правильно обработать тачи, разберем, в чем разница между глобальными и локальными тачами, а также реализуем обработку некоторых популярных жестов, которыми Вы оперируете не только в играх, но и в повседневном пользовании смартфоном – swipe и zoom. Разумеется, все это мы будем делать, используя исключительно встроенный функционал Unity3D, без внешних плагинов и ассетов. Наведем справки Перед тем, как начать, рассмотрим, какие возможности нам предоставляет библиотека для работы с тачами. В документации Unity видим, что разработчики движка рекомендуют использовать класс Input для получения доступа к данным об акселерометре и мульти-таче мобильного устройства. Это нас вполне устраивает. В обязательном порядке необходимо подключить пространство имен UnityEngine.EventSystems, ведь именно оттуда родом большинство интерфейсов и классов, которые нам сегодня понадобятся. Например, IPointerClickHandler, IDragHandler и многие другие. В конце концов, классы BaseEventData и PointerEventData, из которых мы будем доставать все необходимые данные о событиях, проживают по тому же адресу. Что ж, не стоит волноваться, если Вы видите эти имена впервые. Моя задача - сдружить вас и наставить на путь плодотворной разработки. Если у Вас уже имеется опыт работы с данными классами, надеюсь, смогу поведать о каких-либо интересных спецификах работы с ними и еще некоторыми компонентами. Ближе к делу  или “Что такое глобальные и локальные тачи?” Немного теории. Чтобы правильно реализовать все, что мы задумали, сначала разберемся, что такое глобальные и локальные тачи. Если вкратце, то глобальные тачи – это прикосновения к экрану устройства в любой точке. То есть, мы будем говорить, что необходимо обработать глобальный тач, если для игрового процесса не важно, где именно игрок ткнет пальцем в экран. Думаю, все видели в играх заставку после загрузки уровня с большими буквами “Tap to start” либо что-то в этом роде. Бывают настолько простые игры, что, по сути, все управление игроком производится исключительно такими вот глобальными тачами. Например, в Flappy Bird, 2 Cars и многих других. Разумеется, не всегда все так просто. Случается, нам необходимо обработать тач в определенной области экрана, или по какой-либо кнопке, или по объекту. Такие тачи мы с Вами будет именовать локальными, так как они должны производиться в некой локальной области. Причем принципы реализации обработки тачей по 2D объектам или же элементам UI и обработки тачей по 3D объектам на сцене немного отличаются. Эти нюансы мы также рассмотрим. То есть перед тем, как перейти к воплощению идеи в жизнь, хорошенько подумайте, где и какой вид тача будет использоваться, ведь от этого зависит, как далеко в лес мы пойдем и как много дровишек нарубим. Практика. Подготовим рабочее место, как на картинке. Также создадим новый скрипт HandleScript и прикрепим его на куб. Как же считать прикосновение к экрану? Если в случае с кликами мыши в классе Input есть методы GetMouseButton (...Up, ...Down), то для тачей соответствующие методы отсутствуют. Здесь все даже проще. Разработчики предоставляют свойство touchCount (только для чтения), в котором хранится количество тачей в текущем кадре. То есть, чтобы считать глобальный тач, нам необходима всего одна строчка в методе Update: using UnityEngine; using UnityEngine.EventSystems; public class HandleScript : MonoBehaviour { void Update () {      if (Input.touchCount > 0) Debug.Log("Global touch!"); } } Как только пользователь задумает ткнуть пальцем в экран (чего мы, по сути, и ждем), выражение в блоке условия вернет true и на консоль вылетит наше сообщение. Что может быть проще? Важно: проверить данный способ обработки на компьютере не получится, так как в свойство touchCount записывается именно кол-во тачей. Клики мыши не в счет. Примечание: К примеру, при портировании на Windows Phone сообщения консоли, разумеется, отображаться не будут. Так что стоит реакцию на тач сделать более явной. Допустим: if (Input.touchCount > 0) transform.localScale *= 1.1f; Я специально буду обращать Ваше внимание на многие нюансы (для кого-то известные и очевидные, а для кого-то - нет), чтобы избавить от мелких и неприятных ошибок и сберечь парочку нервных клеток. Попробуйте сбилдить на свой смартфон и немного потапать в разных частях экрана. Что касается локальных тачей, то здесь есть несколько вариантов обработки. Также они зависят и от типа  объекта – 2D или 3D. Начнем, пожалуй, с 2D объектов. Давайте добавим на сцену какой-либо спрайт и сразу прилепим ему компонент 2D Box Collider (о нем чуть ниже). Еще добавим к этому спрайту наш скрипт HandleScript, но немного его подкорректируем. В Unity есть перечень методов, которые являются обработчиками определенных событий. Например, метод OnCollisionEnter вызывается, когда два твердых (Rigidbody) объекта соприкасаются, если вкратце. Так вот, среди вышеупомянутого перечня методов есть такой себе OnMouseDown метод. Он вызывается, как вы уже, наверное, догадались, в момент нажатия левой кнопки мыши непосредственно на объекте. Здесь есть три важных момента: Метод вызывается непосредственно в момент нажатия кнопки, а не отпускания или полного клика. Метод реагирует только на левую кнопку мыши. Срабатывает только при клике непосредственно на объект. Так как мы с Вами обрабатываем тачи, а не клики, то справедливы для нас будут только первый и третий пункты. То есть работу с человеческими пальцами данный метод тоже поддерживает. А может, и не только человеческими... Как же будет выглядеть наш код? using UnityEngine; using UnityEngine.EventSystems; public class HandleScript : MonoBehaviour { void OnMouseDown() {      transform.localScale *= 1.1f; } } Обратите внимание на сигнатуру метода и запомните. Ведь если сделать малейшую опечатку, событие касания/клика обрабатываться не будет. Проверить работу этого способа уже проще. Учитывая, что метод OnMouseDown реагирует как на мышь, так и на пальцы, билдить проект на смартфон не обязательно. Из этой серии есть еще метод OnMouseUp, который вызывается при отпускании пальца/кнопки. Важно: все события, связанные с кликами, движок Unity считывает, неявно используя Raycast’ы (лучи). Именно поэтому мы добавили на наш спрайт компонент 2D Box Collider. Если Вы еще не знаете, в чем суть работы Raycast’ов, обязательно почитайте в документации Unity. Важно: получается, указанные методы срабатывают при тапе/клике именно по коллайдеру объекта, а не по мэшу(Mesh)/спрайту. Попробуйте сбилдить и потапать на спрайт ящика либо зеленого куба. Теперь отключите их коллайдеры и проверьте, обрабатывается ли событие. Как видите, этот способ позволяет обработать тап как по 2D, так и по 3D объекту. Просто? Следующий способ обработать локальный тач тоже работает для обоих типов объектов, но немного отличается конфигурацией компонентов. Здесь мы с Вами будем уже работать с таким пространством имен, как UnityEngine.EventSystems. Если оно у Вас еще не подключено, самое время это сделать. Там, как я уже говорил, находятся необходимые нам интерфейсы и классы. Теперь обязательно добавьте на сцену объект EventSystem. Он находится во вкладке UI контекстного меню создания объекта. Итак, чтобы считать тап по 2D объекту (не элементу UI), необходимо обязательно прикрепить к камере компонент Physics 2D Raycaster. Для данного компонента обязательным является присутствие компонента Camera. Поэтому совсем неудивительно, что мы цепляем его именно на объект Main Camera. То есть после всех наших манипуляций игровая сцена должна выглядеть, как на картинке. Теперь, пожалуй, в код. Данный метод более универсальный, чем предыдущий, так как позволяет получить множество информации о состоянии курсора. Неважно, кто им управляет – палец или мышь. Нам понадобится интерфейс IPointerDownHandler из подключенного пространства имен. После реализации единственного его метода, получаем код, не менее простой, чем раньше. using UnityEngine; using UnityEngine.EventSystems; public class HandleScript : MonoBehaviour, IPointerDownHandler { public void OnPointerDown(PointerEventData eventData) {      Debug.Log(eventData.position); } } Разумеется, ошибиться с сигнатурой метода у вас не выйдет, так как Visual Studio сразу ругнется за нереализованный интерфейс. А в параметре eventData типа PointerEventData будет храниться вся информация о курсоре на момент срабатывания метода, а это очень полезно. Что же будет происходить? Здесь тоже все просто. В момент касания движок Unity пустит луч в сцену и в случае, когда тот пройдет сквозь коллайдер нашего спрайта, сработает метод обработчик OnPointerDown и в параметр eventData запишется вся информация о курсоре. Для считывания тачей также есть следующие интерфейсы: IPointerUpHandler, IPointerClickHandler, IPointerEnterHandler и IPointerExitHandler. Мне кажется, по их именам предельно ясно, какой из них какое событие позволяет обработать. Все, что Вам необходимо – наследоваться от нужного интерфейса, реализовать единственный его абстрактный метод и удивиться, как просто это работает. Главное, когда будете работать, не забудьте о компоненте Physics 2D Raycaster и объекте EventSystem, которые упоминались выше. Как вы уже, наверное, заметили, на 3D объекты данный способ не распространяется. Как это исправить? Элементарно. На объект-камеру необходимо также прикрепить компонент Physics Raycaser. Вот и все. Остальная суть остается та же. Попробуйте запустить проект. Заметили? Движок реагирует на клики мыши тоже. Теперь портируйте на ваш смартфон и удостоверьтесь, что все работает верно. Чтобы обработать тачи по элементам UI, Вам необходим будет компонент Graphic Raycaster. Но для него обязательным является компонент Canvas. Это, думаю, тоже вполне логично. Если прикрепить его на объект Canvas, то методы рассмотренных нами интерфейсов позволят также обработать тачи по кнопкам, панелям, тогглам и т.д. Итог по разделу о глобальных и локальных тачах. Давайте немного подсуммируем все, что только что было рассмотрено. Все тачи и клики обрабатываются неявным пусканием лучей из экрана в сцену. То есть определяется касание к коллайдерам объектов. При использовании интерфейсов из пространства имен UnityEngine.EventSystems обязательно надо добавить объект EventSystem. Physics 2D Raycaster – компонент для обработки тачей/кликов по 2D объектам. Physics Raycaster – компонент для обработки тачей/кликов по 3D объектам. Graphic Raycaster – компонент для обработки тачей/кликов по элементам UI. В отличие от предыдущих присутствует на объекте Canvas по умолчанию. Обработка Swipe жестов Как же выловить эти Swipe жесты и как определить их направление? На самом деле, это совсем несложно. Есть несколько интерфейсов, которые позволят нам это сделать:    IDragHandler, IBeginDragHandler, IEndDragHandler. Причем, они отлично подходят как для работы с Drag, так и Swipe жестами. Давайте почистим нашу сцену и приведем ее примерно вот к такому виду: У нас на объекте Canvas есть красная панель размером на весь экран и внутри нее имеется еще одна небольшая панель. Мы с Вами будем считывать Swipe’ы по красной панели и в зависимости от их направления двигать зеленую. Все до безобразия просто. Аналогичные действия Вы потом сможете проделать не только с элементами UI, как в этом примере, но и с 2D и 3D объектами. Сейчас же будем использовать панели, так как это получится более наглядно. Скрипт HandlerScript прикрепляем к внешней (красной) панели. using UnityEngine; using UnityEngine.EventSystems; public class HandleScript : MonoBehaviour, IDragHandler, IBeginDragHandler { public void OnBeginDrag(PointerEventData eventData) { } public void OnDrag(PointerEventData eventData) {  } } Вот как изначально должен выглядеть наш скрипт. Мы должны наследоваться он интерфейсов IDragHandler и IBeginDragHandler. Этого будет достаточно, чтобы считать Swipe. Скажу даже больше. Мы будем использовать только метод из второго интерфейса. Важно: необходимо обязательно реализовать интерфейс IDragHandler (пусть даже методом с пустым телом), чтобы срабатывали методы из интерфейсов IBeginDragHandler и IEndDragHandler. Дабы определить направление Swipe’а, мы будет использовать свойство delta в параметре eventData метода OnBeginDrag. В это свойство записывается разница позиций курсора между текущим и предыдущим кадрами. Мы просто напросто в момент начала Swipe’а глянем, какое значение этой дельты, и из этого уже определим, какое направление жеста. Возможно, у Вас возник вопрос. Откуда возьмется эта дельта, если метод OnBeginDrag сработает сразу, как только игрок начнет вести пальцем по экрану? Дело вот в чем. Этот метод вызывается только после того, как игрок сдвинет палец на какое-то пороговое значение расстояния от начальной точки. За это время успевает накопиться некоторая информация о происшедшем событии. То есть за этот небольшой промежуток времени мы можем определить, куда пользователь собирается вести свой палец. Мы всего лишь должны построить правильную условную конструкцию для определения направления и, исходя из условия, двигать зеленую панель в соответствующем направлении. В будущем это может быть ваш игрок в раннере или что-либо иное... using UnityEngine; using UnityEngine.EventSystems; public class HandleScript : MonoBehaviour, IDragHandler, IBeginDragHandler { Transform green;   // здесь будет ссылка на компонент Transform зеленой панели. void Start() {      green = transform.GetChild(0); // получаем ссылку на Transform зеленой панели. } public void OnBeginDrag(PointerEventData eventData) {      if (Mathf.Abs(eventData.delta.x) > Mathf.Abs(eventData.delta.y))      {             if (eventData.delta.x > 0) Debug.Log("Right");             else Debug.Log("Left");             green.position += new Vector3(eventData.delta.x, 0, 0);      }      else      {             if (eventData.delta.y > 0) Debug.Log("Up");             else Debug.Log("Down");             green.position += new Vector3(0, eventData.delta.y, 0);      } } public void OnDrag(PointerEventData eventData) { } } Что мы сделали? Сначала проверили, дельта по какой оси больше – X или Y? Если по оси X, значит движение будет по горизонтали, если же по Y – значит, по вертикали. А там еще раз проверили направление. Как видите, это делается элементарно просто, а работает безотказно. Обязательно проверьте, обрабатывается ли жест Swipe у вас на смартфоне. Если же Вам необходимо получить непосредственно угол Swipe’а, можно использовать формулу , которая позволяет вычислить синус угла прямоугольного треугольника из отношения противоположной и прилегающей сторон. Обработка Zoom’а Вернем сцену к первоначальному состоянию. Чтобы считать жест zoom’а, нам необходимо обработать глобальные тачи, поэтому наш скрипт HandleScript можно прикрепить даже на камеру. А код наш будет выглядеть вот так: using UnityEngine; public class HandleScript : MonoBehaviour { public float sensitivity; Vector2 f0start; Vector2 f1start; void Update() {      if (Input.touchCount < 2)      {             f0start = Vector2.zero;             f1start = Vector2.zero;      }      if (Input.touchCount == 2) Zoom(); } void Zoom() {      if (f0start == Vector2.zero && f1start == Vector2.zero)      {             f0start = Input.GetTouch(0).position;             f1start = Input.GetTouch(1).position;      }      Vector2 f0position = Input.GetTouch(0).position;      Vector2 f1position = Input.GetTouch(1).position;      float dir = Mathf.Sign(Vector2.Distance(f1start, f0start) - Vector2.Distance(f0position, f1position));      transform.position = Vector3.MoveTowards(transform.position, transform.position + transform.forward, dir * sensitivity * Time.deltaTime * Vector3.Distance(f0position, f1position)); } } В чем суть его работы?  Если пользователь прикасается к экрану двумя пальцами, координаты двух тачей записываются в соответствующие поля f0start и f1start. Именно с ними будут сравниваться все остальные позиции тачей, пока игрок не уберет от экрана пальцы. То есть мы просто сравниваем расстояние между двумя тачами. Если текущее расстояние меньше, чем начальное, то камера будет двигаться назад, если же больше – вперед. Условная конструкция в методе Zoom для того, чтобы позиции тачей записались в свойства только один раз в момент касания к экрану. Чувствительность zoom’а вы можете регулировать значением поля sensitivity прямо в окне Inspector. Попробуйте усовершенствовать этот скрипт сами. Допустим, сделать, чтобы сравнивались позиции не текущих и начальных тачей, а позиции тачей в этом и предыдущем кадре. Сравните результат. Заключение Как видите, обработка тачей и рассмотренных нами жестов реализуется очень просто. Все, что Вам необходимо – внимательность и фантазия. Если что-то не работает, обязательно проверьте, присутствуют ли необходимые компоненты на всех объектах, вызываются ли нужные методы и так далее. Совсем не обязательно искать внешние библиотеки, плагины и ассеты для того, чтобы работать с тачами в Unity. Разработчики предоставляют, по сути, всё, что вам может понадобится. Результат же зависит от Вашей фантазии. Не забывайте заглядывать в документацию Unity, там есть много всего интересного. Хотя, среди того, что мы сегодня рассмотрели, есть  вещи, о которых там не упоминают. Благодарю за внимание и желаю всем творческих успехов!

Junior 1.1 Теория тестирования. 1.2 AQA      1.2.1 Программирование и Selenium      1.2.2 TestNG/JUnit, Git, CI              1.3 Web              1.4 Mobile              1.5 Практические задания   Middle 2.1 Теория 2.2 AQA      2.2.1 Selenium      2.2.2 Тестовая инфраструктура 2.3 Web 2.4 Mobile 2.5 Практические задания   Senior 3.1 Теория 3.2 Практические задания     Дорогие друзья! Предлагаем вашему вниманию перевод статьи, опубликованной на DOU.ua 12 января 2022 года. Оригинальная версия на украинском языке доступна по ссылке. Эту подборку вопросов, которые ставят кандидатам разных уровней на технических собеседованиях на позицию QA, составили совместными усилиями практики. Список – лишь ориентир. Кандидатам советуем пробежаться по вопросам и отметить неизвестные слова, погуглить и заодно повысить шансы пройти собеседование. Интервьюерам – пополнить свой запас интересных вопросов. Но не переборщите :) Если вы не претендуете на позицию QA, просмотрите переводы подборок вопросов по другим популярным IT-специальностям.   Junior   Теория тестирования 1. Что такое тестирование? 2. Зачем тестировать ПО? 3. Какие существуют этапы тестирования? 4. Какие типы тестирования можете назвать? 5. Какие уровни тестирования знаете? 6. Какие техники тест-дизайна знаете? 7. Что такое техника анализа классов эквивалентности? 8. Что такое техника анализа предельных значений? В чем ценность этой техники? 9. Что такое Regression и Confirmation тестирование, какая между ними разница? 10. Как часто следует проводить регрессионное тестирование продукта? 11. Какие бывают виды интеграционного тестирования? 12. Что такое Configuration Testing? 13. Что такое Exploratory Testing? 14. Какие существуют UI-стандарты? 15. Что такое Black/Grey/White Box Testing? 16. Что такое Performance Testing? 17. Что такое Smoke и Sanity тестирование и какая между ними разница? 18. Что такое Traceability Matrix? 19. Что такое Sanity Testing? 20. Что такое End-to-End тест? 21. Что такое тестирование безопасности? 22. Что такое испытание на основе рисков? 23. Что такое динамическое тестирование? 24. Что такое «парадокс пестицида»? 25. Опишите основные фазы STLC? Дайте определение Entry и Exit Criteria. 26. Что такое Bug, Error, Failure, Fault? 27. Какие есть атрибуты баг-репорта? Какие основные поля для заполнения? 28. Какова разница между приоритетом и серьезностью? 29. Приведите примеры серьезного, но не приоритетного бага. 30. В чем разница между валидацией и верификацией? 31. Зачем нужна тестовая документация? Какие её виды? 32. Что такое тест-план? Какие элементы у него есть? 33. Какую обязательную информацию должен содержать тест-план? Как правильно его использовать, поддерживать и нужен ли он вообще для большинства проектов? 34. Какая разница между чеклистом и тест-кейсами? 35. Приведите пример хорошего тест-кейса.   Ответы на некоторые из этих вопросов вы можете найти в видео курсе QA Стартовый (урок 1, урок 3, урок 4, урок 5), Основы тестирования (урок 6), Основы тестирования ПО (урок 1-5), а также в вебинаре “QA практикум. Техники тест дизайна” (часть 1 и часть 2).   AQA (Automation QA)   Программирование 36. Что такое ООП? Назовите его принципы с примерами? 37. Что такое интерфейс? Что такое абстрактный класс? Чем они отличаются? 38. Что такое SOLID? Приведите примеры. 39. Что такое DRY, KISS, YAGNI? 40. Какие паттерны GOF вам известны? Приведите примеры их использования. 41. Что такое PageObject и PageFactory? 42. Какая иерархия Collections? 43. Какая разница между Thread class и Runnable interface? 44. Какая разница между String, Stringbuffer и Stringbuilder? 45. Разница между final, finally и finalize?   Selenium 46. ​​Что такое Selenium и зачем его используют? 47. Что такое драйвер браузера? 48. Какие виды локаторов страницы существуют? Каковы их преимущества и недостатки? 49. Что такое Selenium Waits? Какие есть и чем отличаются? 50. Какие exceptions может бросить Selenium? Что они означают и как их обрабатывать? 51. Для чего используют JavaScriptExecutor? Приведите примеры. 52. Что такое Selenium Grid? 53. Какие способы click и send keys Selenium? 54. Как вы запускаете параллельное выполнение тестов? Что такое ThreadLocal? 55. Какая разница между Action и Actions? 56. Как написать метод isElementPresent? 57. Как вычитать данные из динамической веб-таблицы? 58. Можете ли вы назвать 10 интерфейсов в Selenium? 59. Назовите два способа, позволяющих автоматизировать капчу. 60. Вспомните типы навигационных команд Selenium. 61. Как найти поврежденные ссылки в Selenium WebDriver? 62. Какую технику следует рассмотреть, используя весь сценарий, если «нет ни frame id, ни frame name»?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing Automation on Java (урок 1), Автоматизация тестирования мобильных приложений (урок 5), а также в вебинаре “Selenoid или Selenium Grid — что лучше?”.   TestNG/JUnit 63. Для чего нужны TestNG/JUnit? 64. Какие инструкции используются в TestNG/JUnit? 65. Какие assertions есть в TestNG/JUnit? 66. Как выполнять тесты параллельно TestNG/JUnit?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing Automation on Java (урок 4).   Git 67. Для чего используют системы контроля версий? 68. Что такое Git? Каков принцип его работы? 69. Что такое commits, branches в Git? 70. Для чего нужны GitHub, GitLab и другие, базирующиеся на Git, вебхостинги проектов?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Основы работы с Git.   CI 71. Что такое CI? 72. Как автоматическое тестирование интегрируется в CI? 73. Как настроить Job или Pipeline на знакомом вам CI-инструменте? 74. Какие инструменты для генерации репорта после выполнения автоматических тестов вы знаете? 75. Какую информацию должен содержать отчет о выполнении автоматических тестов?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing (урок 4).   Web 76. Что такое клиент-серверная архитектура? 77. Что может выступать в роли клиента? 78. Что такое REST API, SOAP? В чем разница? 79. Какие протоколы передачи данных знаете? 80. Какие способы взаимодействия с API существуют? В чем разница между ними? 81. Как можно протестировать API, что там нужно проверять? 82. Как расшифровывается CRUD? 83. Чем отличается GET от POST? 84. Какие отличия между XML и JSON? 85. Какие знаете форматы передачи данных? 86. Как происходит шифрование? 87. Какие бывают виды баз данных? 88. Охарактеризуйте каждый класс status code (1хх; 2xx; 3xx; 4xx; 5xx). 89. Какие есть HTTP-методы? 90. Какие знаете Web elements? 91. Какие браузеры знаете? В чем их отличие? 92. Для чего необходимы инструменты разработчика в браузере (Chrome DevTools) и как они помогают в тестировании. 93. Что такое кэш? 94. Что такое сессия? 95. Зачем нужны cookies? 96. Что такое фрейм? 97. Что такое HTML/CSS/JavaScript? 98. Какую структуру имеет веб-страница? 99. Зачем чистить кэш? 100. Какие виды тестирования можно применить только к Web? 101. Для чего в веб-страницах используют JavaScript? 102. Что такое REST? 103. Что такое AJAX?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах QA Стартовый (урок 6), Web Testing, SQL Базовый.   Mobile 104. Какие мобильные платформы существуют? 105. Какие версии Android и iOS используются на рынке (минимальные и максимальные)? 106. Какие версии Android нужно тестировать, если заказчик сказал поддерживать с версии 5.0? 107. Назовите типы мобильных приложений. 108. Каков формат файлов сборок приложений для Android и iOS? 109. Что такое ADB? 110. Как снять логи с AOS/IOS? 111. Что нужно проверять при использовании сканера отпечатка/Face ID? 112. Как я могу запускать тесты Android без Appium? 113. Объясните концепцию дизайна Appium.   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Автоматизация тестирования мобильных приложений.   Практические задания 114. Написать чеклист для функционала корзины в интернет-магазине. 115. Написать тестовые наборы данных для поля ввода даты, которое отсеивает пользователей в возрасте до 18 лет. 116. Написать чеклист тестирования формы ввода данных платежной карты. 117. Протестовать «предмет» относительно различных видов тестирования. (Предмет - лифт, карандаш, калькулятор и т. д.) 118. Есть Input поле, принимающее целые значения от 18 до 99 включительно. Надо протестировать с помощью техники тест-дизайна Boundary Values ​​Analysis и Equivalence Partitioning. 119. Есть веб-страница с полями: e-mail, password и кнопкой submit. Необходимо привести примеры отрицательных тест-кейсов, которыми можно проверить эту страницу. 120. Привести примеры тест-кейсов для функционала, находящегося на нескольких страницах проекта (например, поле поиска). 121. Как протестировать процесс оплаты в интернет-магазине? 122. Как протестировать сломанный тостер? 123. Объясните для 7-летнего ребенка, что такое база данных. 124. Определите необходимое количество функциональных тест-кейсов, чтобы проверить Log in форму. 125. Есть форма регистрации в веб-приложении с полями (first name, last name, username, password, repeat password) и кнопкой Register. Какие проверки нужно провести? 126. Поле username должно быть обязательным, но оно не является обязательным. Приведите пример баг-репорта, созданного для этой ошибки. 127. Как бы вы провели smoke-testing для приложения типа Telegram? 133. Как будет выглядеть баг-репорт, если, к примеру, не работает электрический чайник? 128. Есть таблица books с полями: name, price, page_count. Следует выбрать все имена книг, в которых price более 10 единиц и количество страниц от 20 до 100. 129. У вас есть функционал калькулятора, который доступен через веб-браузер по ссылке. Он имеет только функцию делить, так сказать, MVP-версию. Диапазоны для вписывания в числитель и делитель от 0,1 до 99,9. Вывод значения происходит автоматически, потому что front-end реализован на React JS. Как вы будете тестировать этот функционал? Какие виды тестирования примените? Какие техники тест-дизайна используете?     130. Задание на работу с SQL.   извлечь номер телефона и адрес пользователя Muzik. Извлечь данные о пользователях, имеющих сумму заказа более 2000 грн. Подсчитать количество заказов в таблице и общую сумму сделанных заказов.     131. Ваша компания разрабатывает программное обеспечение для медицинских систем, и вы тестируете компонент, управляющий дефибриллятором сердца. Вы заметили, что одно решение в тестовом модуле состоит из 34 независимых атомарных условий. Какой метод тестирования белого ящика следует выбрать для этого и почему? 132. Оздоровительная программа для сотрудников совмещена с оплатой медицинского страхования и имеет следующие правила:   сотрудники, потребляющие 17 единиц или менее алкоголя в неделю, получают $28 скидки на оплату. Для сотрудников, которые заполнят «Оценку риска для здоровья», оплата уменьшается на $23. Сотрудники, участвующие в ежегодном контроле за состоянием здоровья в компании: получат скидку на $50 за то, что имеют индекс массы тела (ИМТ) 25,5 или менее, и $19 скидки при ИМТ ниже 30. Некурящие получают дополнительную скидку на $46. Курильщики, присоединившиеся к курсу отказа от курения, получают скидку в $24. Курильщики, не присоединившиеся к курсу отказа от курения, оплачивают дополнительно $75.   133. Используя технику классов эквивалентности, сколько тестов нужно написать, чтобы покрыть вышеупомянутые условия на 100%? 134. Какое минимальное количество тестов необходимо для покрытия следующих условий автогражданки:   лица до 18 лет не застраховываются. Для мужчин на красном авто прибавляется +15% к стоимости полиса. Для женщин от 18 до 64 лет страховая премия 1000 грн. Для мужчин от 18 до 64 лет страховая премия 1200 грн. Для лиц старше 64 лет страховая премия 1800 грн.   135. Напишите сценарии автоматического тестирования для сортировки по цене и добавлению товара в корзину на сайте. К вашим тестам добавьте документацию с настройками и разместите ваше решение на GitHub.   Middle   Теория 1. Назовите обязанности QA? 2. Что знаете о тестировании нагрузки? В каком случае следует проводить такое тестирование? На каком этапе готовности продукта? 3. Что такое таблица решений/decision table и как её можно использовать? 4. Что может быть критериями запуска и завершения тестирования? 5. Расскажите о вариантах интегрирования тестовой документации в проект, инструментах для работы с ней. 6. Как организовать сквозное тестирование (e2e)? 7. Какие тест-кейсы можно сдать для тестирования баз данных? 8. Приведите примеры подходов для тестирования локализации. 9. Что такое A/B тестирование? 10. Что такое mock/stub? Какие знаете инструменты для работы с ними? 11. Когда нужно использовать технику Pairwise? 12. Что такое fuzz-тестирование и где его используют? 13. Что такое REgexp? 14. Как меняется стоимость дефекта при тестировании программного обеспечения? 15. Каковы пути анализа бизнеса клиента? Как определить целесообразность того или иного функционала? 16. Назовите последовательность выполнения CI/CD процесса на проекте. 17. Какое должно быть процентное соотношение между положительным и отрицательным тестированием на проекте? 18. Какой вид тестирования целесообразнее проводить до релиза? 19. Есть ли разница между bug leakage и bug release? 20. Может ли быть ситуация, когда критерии завершения (exit criteria) не выполнены? Что должно происходить в этом случае? 21. Что мы действительно должны покрывать тест-кейсами, а что считается избыточным расходом времени и денег? Когда нецелесообразно писать тест-кейсы? 22. Для какого функционала труднее всего написать тест-кейсы? 23. Как посчитать Cyclomatic complexity? 24. В чем основная разница между defect detection percentage и defect removal efficiency? 25. Какие модели risk-based testing вы знаете? 26. Что такое тестирование API? Какими инструментами пользуются для его выполнения? 27. Что такое performance testing? Какими инструментами пользуются для его выполнения? 28. Что такое load и stress testing? Какими инструментами пользуются для их выполнения? 29. Что такое contract testing? 30. Какая разница между Scrum и Kanban? 31. Расскажите о ритуалах, ценностях и ролях в Scrum. 32. Как выбор методологии может повлиять на качество разработки? 33. Нулевой спринт в Scrum. Для тестирования есть задание под названием «Настройка среды». Что здесь нужно выполнять?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing, QA Стартовый, “Методология управления проектами. Вступление в SCRUM”.   AQA   Selenium 34. Расскажите, как вы будете строить и внедрять стратегию по автоматизации тестирования. 35. Как взаимодействуют клиентская библиотека Selenium, драйвер браузера и сам браузер? 36. Для чего используют browser capabilities, arguments и options? 37. Что такое iframe и как с ним работать в Selenium? 38. Как обрабатывать браузерные сообщения (alerts)? 39. Что такое Appium? 40. Что такое Electron-based applications? Как использовать Selenium и Appium для их тестирования? 41. Как взаимодействовать с запросами, отправляемыми из браузера? 42. Как взаимодействовать с cookies, LocalStorage и SessionStorage?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing Automation on Java (урок 1) и Автоматизация тестирования мобильных приложений.   Тестовая инфраструктура 43. Что такое и чем отличаются виртуальная машина, симулятор и эмулятор? 44. Что такое контейнер и чем он отличается от виртуальной машины? 45. Как используют виртуальные машины и контейнеры в автоматизации? 46. ​​Что такое IaaS и PaaS? Приведите примеры. 47. Что такое Configuration Management? 48. Что такое Provisioning? 49. Какие команды Linux Shell вам известны? Как с помощью команд Linux Shell найти лог-файл и строчку с ошибкой в ​​файле? 50. Какие команды Windows CMD вам известны? Как с помощью команд Windows CMD найти IP-адрес машины? 51. Что такое SSH и как им пользоваться? 52. Что такое bash и batch скрипты? Зачем их используют?   Web 53. Какая разница между авторизацией и аутентификацией? 54. Как происходит авторизация на сервере? 55. Какие статус-коды ошибок бывают? Может ли сервер отправить код 400, если проблема на его стороне? 56. Как выполнить Debug страницы в браузере? 57. Как протестировать адаптивную верстку? 58. Что такое WebSocket и как проверить обрыв соединения? 59. Каковы есть основные виды уязвимости веб-приложений? 60. Какие инструменты для тестирования Web performance client-side знаете? 61. Какова разница между методами GET и POST? 62. Какая разница между методами PUT и PATCH? 63. Какие знаете сниферы? 64. Какова разница между DROP и TRUNCATE? 65. Что такое case function? 66. Что такое collation? 67. Что такое схема GraphQL? 68. Объясните разницу между OLTP и OLAP. 69. Вспомните разные типы репликации в SQL Server? 70. Что вы понимаете под Self Join? Приведите примеры. 71. Что такое cursor и как им пользоваться?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing Automation on Java, SQL Базовый.   Mobile 72. Что основное нужно проверить при тестировании мобильного приложения? 73. Что такое Manifest.xml в .apk файле и какие данные там указывают? 74. Что такое режим разработчика Do not keep activities? 75. Как происходит перехват трафика http/https для мобильных устройств? 76. В каком виде хранятся данные в мобильных приложениях локально? 77. Как тестировать миграцию локальных данных? 78. Каковы основные компоненты Android-приложений (активити / фрагмент / сервис / интент-фильтр)? 79. Опишите жизненный цикл активити. 80. Что такое утечки памяти? Как найти? 81. Как протестировать билд на Android? 82. Что такое Testflight? Как тестировать с его помощью? 83. Как работает Android? Какая у него архитектура? 84. Как происходит деплой программ IOS/AOS?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Автоматизация тестирования мобильных приложений.   Практические задания 85. Что делать, если разработчик не соглашается, что указанный баг действительно является багом? А если в требованиях использована неоднозначная формулировка? Если бизнес-аналитик, PM и представитель клиента сейчас недоступны, чтобы подсказать? Как можно предотвратить такую ​​ситуацию? 86. Сложилась ситуация, когда команда тестирования не успевает закончить свою работу в дедлайн. Как правильно действовать в этом случае? А если релиз передвинуть нельзя? А если никакие фичи из релиза забрать нельзя? 87. Что делать, если проект уже начался, а QA-инженер там начал работать только когда начали разрабатываться бизнес-фичи? Какие этапы тестирования теперь нужно наверстать и нужно ли это? Как это сделать максимально грамотно без ущерба для загрузки по тестированию новых фич? Какие риски имеет позднее вовлечение QA-инженера в разработку? 88. Веб-страница с полями e-mail, password и кнопкой submit. Назовите отрицательные тест-кейсы, по которым можно проверить эту страницу. 89. Предположим, что после нажатия кнопки submit страница перезагружается и ранее введенные данные исчезают. Как проверить, что информация отправлена ​​в базу данных? 90. Как проверить, что данные отправились на сервер, если у нас нет доступа к бэкенду? 91. Приведите примеры улучшений для приведенной веб-страницы (любая на выбор). 92. Составить Smoke Test Suite для DOU.ua. 93. Протестовать функционал банкомата с помощью техники State Transition Diagram. 95. Написать предельные значения для ввода в форму оплаты товара на сайте. 96. Есть метод POST, который регистрирует нового пользователя на сайте, есть тело запроса, содержащее данные о почте, телефоне, имени пользователя и адресе проживания. Какие кейсы для проверки можете привести? 97. На что следует акцентировать внимание при автоматизации методов API? Что следует проверять? 98. Вы тестируете логин-форму, вводите логин и пароль, нажимаете кнопку логин и ничего не происходит. Ваши действия? 99. В течение 5 минут найдите и опишите дефекты, которые вы видите:     100. Вам нужно сделать Regression Testing за два дня. Как вы это сделаете, если Regression Run охватывает 1000 тест-кейсов? 101. Вы тестируете интернет-магазин, который продаёт карандаши. В заказе нужно указать количество карандашей (максимум для заказа – 1000 штук). В зависимости от заказанного количества карандашей отличается цена:   1–100 – 10 грн за шт. 101-200 – 9 грн за шт. 201-300 – 8 грн за шт.   С каждой новой сотней цена уменьшается на 1 гривну. Задание: используя тест-дизайн, опишите все необходимые тест-кейсы, которые будут максимально покрывать описанную функциональность.   102. Есть приложение типа мессенджера, пользователь заходит в чат и отсылает файл (видит сообщение Failed to send...) Когда это может быть баг, а когда нет? 103. Есть веб-приложение интернет-магазина (регистрация, логин, поиск товаров, корзина и покупки). Программу поддерживают следующие браузеры: Chrome, Safari, Edge. У нас есть ограниченное время на тестирование. Расскажите, как вы будете проверять приложение? 104. Напишите автоматические тестовые сценарии для проверки API операций создания и просмотра GitHub Gists. Интегрируйте ваш проект с известной вам CI-системой.   Senior   Теория 1. Как вы преодолеете трудности из-за отсутствия надлежащей документации для тестирования? 2. Какой подход является наилучшим для старта QA в проекте? 3. Какие препятствия могут возникнуть в обеспечении качества для Agile Tester? 4. Что такое Definition of Done? 5. Когда можно считать, что тестирование окончено? 6. Что такое RCA в тестировании? Нужно ли его проводить? 7. Какой подход вы используете для Test Cases Review? 8. Какие виды рисков существуют? Что такое Mitigation Plan? 9. На основе чего нужно составлять стратегию для проведения тестирования нагрузки? 10. Как часто следует ревьюировать тестовую документацию? 11. Как можно быстро сделать выборку необходимых проверок для смоук-тестирования? 12. Как запланировать загруженность команды тестировщиков? 13. Какую ценность несет анализ результатов тестирования команде и проекту в целом? 14. Как можно подкорректировать флоу разработки, чтобы получать более чистые результаты на выходе и уменьшить количество багов на проде? 15. Расскажите о метриках качества, которые вы применяли. Зачем они нужны? 16. Как провести эстимейт задачи? Каковы техники оценки объема тестирования существуют? 17. Как можно посчитать покрытие тестами функционала? 18. Какое оптимальное количество шагов в тестовом сценарии? 19. Как избежать появления регрессивных дефектов? 20. Что такое тестирование со смещением влево (Shift left testing)? 21. Как будете тестировать программу, если для продукта нет документации? 22. В чем смысл юнит-тестов? 23. Какие минусы полной автоматизации тестирования? 24. Что такое ROI и как его считать? 25. Что такое CI/CD? Какие плюсы и минусы этого подхода? 26. TOP OWASP: какие знаете уязвимости и методы защиты? 27. Что вы думаете по поводу BDD? Когда следует использовать, а когда будет только хуже? Если все же следует использовать, то для UI или API автоматизированного тестирования? 28. Что такое сокеты и как их тестировать, вручную и автоматизировано? Зачем их используют? 29. Когда следует делать стресс-тестирование на проектах? От чего отталкиваться, когда строите сценарий для такого тестирования? Что учесть при выборе инструмента? 30. Расскажите об алгоритмах шифрования трафика. 31. Что такое NIC? 32. Для чего нужен протокол RTP? 33. Что, по вашему мнению, лучше – SIP или PRI? 34. Что такое NAT?     Практические задания 35. Сформулируйте негативные сценарии для POST-запроса, который создаёт нового пользователя. 36. Как вы регулируете конфликтные ситуации между QA и разработчиками? 37. Есть проект, на котором нет тестовой документации, но проекту уже год. Мануальным QA не хватает времени на тестирование, они очень устали, есть желание уволиться. Какое решение по команде можно принять? 38. Продайте мне тестирование как клиенту, не желающему его покупать. Кратко и структурированно опишите вашу работу на каждом из этапов разработки ПО, используя профессиональные термины (не лить воду). 39. У вас есть онлайн-калькулятор. Вы вводите 1+1 и получаете 3. Расскажите, как вы будете искать причину проблемы. 40. Могут ли быть такие виды архитектур? Чего может быть недостаточно для правильной работы архитектур, приведенных ниже?   Пример 1     Пример 2     Пример 3     Пример 4   Вопросы при выполнении этого задания:   какие запросы выполняются по форме авторизации? Какой запрос выполняется, когда мы сохраняем данные в базе данных? Можно ли авторизоваться с помощью GET-запроса и нормально ли так делать? Какой код ответа мы получаем при падении ошибки на сервере, код при ошибочных credentials на форме авторизации? Можно ли заменить SSL-сертификат шифрованием данных в пакете от клиента к серверу для протокола HTTP или это будет равноценной заменой?   41. Есть веб-страница с полями e-mail, password и кнопкой submit. Предположим, что после нажатия кнопки submit страница перезагружается и ранее введенные данные исчезают. Как проверить, что данные отправлены в базу данных? 42. Какое минимальное количество тест-кейсов необходимо, чтобы убедиться в корректной работе этой веб-страницы? 43. Как проверить безопасность на веб-странице (на выбор)?   Редакция DOU.ua выражает благодарность за вопросы и рецензию: Роману Поботину, Андрею Заблоцкому, Виктору Максименко, Марьяне Батюк, Ирине Литвин, Сергею Могилевскому, Святославу Логину, Роману Маринскому, Олегу Заревичу, Олесе Паславской, Тарасу Лирке, Максиму Богуну, Вадиму Гуличу, Виталию Кашубе, Юрию Суравскому, Светлане Франковой, Владимиру Арутину, Станиславу Жупинасу, Людмиле Федчук, Иванне Черухе, Юлии Левченко, Владиславу Куличенко, Юрию Бояру.

ТОП 7 дистрибутивов Linux 7-е место - Gentoo 6-е место - Gentoo 5-е место - Linux Mint 4-е место - Fedora 3-е место - Debia 2-е место - Arch Linux 1-е место - Ubuntu Несколько не вошедших в ТОП рейтинга, но все еще интересных дистрибутивов Linux Antergos Puppy Linux Manjaro Linux   Существует большое разнообразие операционных систем, используемых на рабочих станциях как простыми пользователями, так и разработчиками ПО. Какую же операционную систему следует выбрать разработчику в 2019 году? Согласно опросу, проведенному среди более чем 76 000 разработчиков и опубликованному в ежегодном отчете Stack Overflow’s 2018 Developer Survey, лидирующее положение в качестве основной операционной системы все еще занимает OS Windows. Однако, уже почти четверть из числа разработчиков используют в качестве основной ОС – Linux, или правильнее сказать Linux-based операционную систему. Этот немалый процент пользователей не может не заставить задуматься – а какие плюсы дает использование Linux в качестве операционной системы для разработчика? Возможно, имеет смысл мигрировать на Linux с OS Windows и MacOS? Но давайте для начала уточним несколько моментов.   Что такое Linux История UNIX-подобных операционных систем начинается в 1960-х годах с совместного проекта Массачусетского Технологического Института и компаний General Electric и Bell Labs. В последствии компании прекратили финансирование проекта и его развитие продолжилось энтузиастами. Это привело к появлению в 70-х годах системы UNICS, затем сменившей название на UNIX. В 1980-х годах набор дистрибутивов UNIX был выпущен под коммерческой лицензией компанией AT&T, в которую входила Bell Labs. Однако, по политическим причинам, AT&T была вынуждена предоставить исходный код OS UNIX, под ограничивающей возможности лицензией, ряду вузов, включая университет Беркли. Так, начиная с 1978 года, появилось одно из первых ответвлений Unix-подобных систем – BSD Unix. (BSD - Berkeley Software Distribution). Работавший в начале 1980-х в MIT Ричард Столлман был недоволен коммерциализацией и закрытостью лицензий UNIX. В 1983 году он объявил о новом проекте – GNU (GNU – рекурсивный акроним GNU’s Not UNIX). В рамках этого проекта получила начало разработка Unix-подобной операционной системы под свободной лицензией GNU GPL. Стоит отметить, что данная лицензия не только дает право разработчику свободно использовать программы, выпущенные под этой лицензией, но и обязывает разработчика выпускать все производные программы также под данной лицензией. Операционная система Linux появилась на свет в 1991 году благодаря Линусу Торвальдсу, разочаровавшемуся в существующих на тот момент операционных системах, бывших либо платными, либо выпущенными под лицензией BSD – с правом применения только в образовательных целях. В новой операционной системе Линусом Торвальдсом было переписано ядро, задачей которого является, в основном, координация доступа приложений к ресурсам системы. Возникшая на основе UNIX-подобной системы MINIX, работавшей под лицензией BSD, операционная система Linux в дальнейшем претерпела значительных изменений. Так были заменены многие компоненты на те, что написаны под лицензией GNU. В последствии произошло более глубокое слияние проектов GNU и Linux с образованием операционной системы GNU/Linux или той, что сейчас зачастую называют просто - Linux. До сих пор существует путаница в том, какие дистрибутивы ОС следует относить к Linux, а какие – нет. Ряд пользователей называет Linux-ом все операционные системы, использующие ядро Linux. В число таких ОС входит, в частности – Android. Другие пользователи признают под Linux только те дистрибутивы, которые состоят как из стандартного ядра, так и из обязательно включенной части ПО GNU (в число таких Android входить, соответственно, не будет). В рамках данной статьи, мы примем за определение Linux следующее: Операционная система Linux – это продукт, состоящий из ядра Linux, и набора внешних модулей GNU. Часто многие обзорные статьи и рейтинги операционных систем под заголовками «ТОП ... лучших Linux дистрибутивов» включают в себя не только сборки из семейного дерева Linux, но и те, которые фактически относятся к другим ветвям Unix-подобных систем, в частности - FreeBSD. Такая путаница действительно существует. Но не стоит забывать – это разные «ветви» развития операционных систем, имеющих общий исторический «корень» – Unix.   Преимущества Linux, как системы для разработчиков Почему Linux хорошая альтернатива для разработчика? Рассмотрим отдельно преимущества и недостатки использования Linux как основной операционной системы.   Общие преимущества для пользователей: Выбор. Огромное разнообразие дистрибутивов Linux, с разным набором компонентов, позволяет профессиональному пользователю найти тот, который будет удовлетворять его потребности как в работе, так и в быту. Настраиваемость и гибкость системы. Являясь, вероятно, самой настраиваемой и гибкой системой, Linux позволяет подогнать операционную систему под себя буквально. Бесплатное распространение. Распространяясь под лицензией GNU GPL, сами дистрибутивы Linux являются бесплатными. Однако ряд дистрибутивов являются коммерческими и полный спектр возможностей (поддержка, доступ в ряд репозиториев и т.п.) предоставляют на платной основе. Открытое программное обеспечение – Open Source. Огромное количество разнообразных программ с отрытым исходным кодом, бесплатных и общедоступных. Значительное количество специфических программ для обучения. При этом сохраняется возможность установки проприетарных программ. Использование эмулятора Wine позволяет запускать  на Linux многие приложения операционной системы Windows. Низкие системные требования и высокая скорость работы. Благодаря глубокой кастомизации дистрибутивов, обеспечивается более высокая скорость работы операционной системы и приложений. Это позволяет с большим комфортом пользоваться относительно старым железом при правильном подборе дистрибутива ОС. Активное сообщество пользователей и разработчиков. Безопасность. Конечно безопасность операционной системы в первую очередь зависит от пользователя, но нельзя не признать, что количество вирусов под Linux на порядки меньше чем под Windows. Кроме того, благодаря доступу к публичным, контролируемым репозиториям для установки ПО, нет необходимости брать программы из непроверенных источников. Также нельзя не отметить глубокую настраиваемость механизмов, обеспечивающих безопасность в Linux.   Преимущества Linux для разработчиков: Возможность тестировать разрабатываемое ПО прямо в том же окружении, в котором оно будет работать после выхода в продакшн. Вы можете иметь на вашем персональном компьютере весь тот же самый софт, с теми же версиями и настройками, как тот, который будет «крутиться» на сервере для вашего приложения. Удобство при активном использовании механизмов командной строки, Git и текстового редактора Vim отмечают многие разработчики. Стабильность в работе без перезагрузок. Многие пользователи не перезагружают операционную систему, пока не появляется необходимость в обновлении. Параноикам от мира разработчиков будет приятно знать, что Linux не собирает статистику на пользователя, в отличие от той же Windows   Недостатки Linux, как системы для разработчиков: Отсутствие ряда профессиональных программ, сравнимых с таковыми под Windows. Несмотря на возможность запуска многих программ под Wine нехватка профессиональных приложений ощущается. Особенно это заметно при необходимости работы с графикой и моделированием. Сложность разработки под Windows. Если вы работаете под Linux, это не значит, что в ваши задачи не будет входить написание кода под Windows. К сожалению полноценная Visual Studio под Linux не работает, а эта IDE сейчас является основной для Windows-разработки. Определенная сложность в обучении работы с инструментами. Нельзя не отметить, что порог вхождения в работе под Linux заметно выше.   Мы выделили основные плюсы и минусы в работе на Linux для программиста. Теперь давайте рассмотрим наиболее приемлемые Linux дистрибутивы. Разнообразие дистрибутивов Linux и статистика История дистрибутивов Linux насчитывает уже более 28 лет. Не удивительно, что из года в год появляющиеся и отмирающие ветви дистрибутивов этой операционной системы сегодня представляют уже целый зоопарк – фигурально выражаясь. Для примера можно посмотреть на стилизованный под периодическую систему список наиболее используемых дистрибутивов Linux, отсортированных по материнским версиям операционных систем. Как видно из этой схемы, таких дистрибутивов – не мало. И это только наиболее популярные. Известный портал distrowatch.com насчитывает только активных более 260 дистрибутивов. Чтобы помочь определиться с тем, какой дистрибутив Linux лучше выбрать разработчику, рассмотрим несколько рейтингов дистрибутивов Linux. Статистика использования пользователями разных дистрибутивов Linux согласно порталу phoronix.com Согласно данным опроса, проведенного в 2017 году порталом phoronix.com среди почти 30 000 людей, использовавших Linux дистрибутивы на ноутбуках, лидером по применению  является дистрибутив Ubuntu. Этот дистрибутив линукс получил 38,9% голосов. Следом за Ubuntu по популярности идет дистрибутив Arch Linux, получивший 27,1% пользователей.  Затем идут, Debian, Fedora и Linux Mint, получившие, соответственно, 15,3%, 14,8% и 10,8% аудитории. Шестое место в этом рейтинге дистрибутивов Linux занял openSUSE с 4,2%, а седьмое – Gentoo с 3,9% аудитории. Стоит отметить, что почти три четверти этих пользователей (73,1%) использовали указанную ими операционную систему для разработки ПО. Топ дистрибутивов Linux по статистике портала gamingonlinux.com По данным опроса, проведенного порталом gamingonlinux.com среди более 2 500 своих пользователей и действительному на 01.01.2019 – большая часть их пользователей использует Arch Linux - 21,2%. Затем идут Ubuntu – 19,15%, Linux Mint – 9,37%, Manjaro – 7,36%, Debian – 6,28%, Fedora – 4,72%, Antergos – 4,61%.   Опрос для рейтинга дистрибутивов линукс на портале reddit.com Проведенный на портале reddit.com в 2017 году, опрос среди почти 2 500 человек в сообществе r/unixporn, показал наибольшую популярность таких дистрибутивов линукс: Arch Linux использовали 27.0% пользователей, Ubuntu – 17,9%, Debian – 11,8%, Fedora – 6,09%. Затем идут Rasbian – 5,52%, Manjaro – 5,43% Antergos – 4,67%, Linux Mint – 3,41% и Gentoo – 2,44%. Множество других дистрибутивов Linux, включая openSUSE, Puppy Linux, CentOS и т.п., использует значительно меньшая доля пользователей. При этом указанные дистрибутивы использовались на ноутбуках более чем в 80% случаев, а на стационарных компьютерах – более чем в 60% случаев. Данные Google Trends Данные Google Trends, по пяти наиболее популярным дистрибутивам, показывают существенный отрыв Ubuntu даже от других дистрибутивов первой пятерки.   Давайте рассмотрим непосредственно наш рейтинг Linux дистрибутивов, составленный на основе указанных выше статистических данных.   ТОП 7 дистрибутивов Linux   7-е место - Gentoo Дистрибутив Gentoo версии 1.0 увидел свет в 2002. Этот дистрибутив создавался Дэниелом Роббинсом на основе другой его разработки, начатой еще в 1999 году -  Enoch Linux. В 2004 году Роббинсом был создан некоммерческий Фонд Gentoo, которому он передал в последствии права на торговые марки и авторские права, после чего покинул пост главного архитектора проекта. Философия проекта Gentoo состоит в предоставлении пользователям линукс, желающим иметь полный контроль своей системы, возможность контролировать, что установлено и запущено на их компьютере.  У пользователей есть возможность собирать персональные системы и серверы очень эффективными, если они готовы потратить немалое время, для установки и настройки системы. Gentoo рекомендует пользователям создавать ядро Linux с учетом их конкретного оборудования. Пользователи могут полностью контролировать, установленные и запущенные службы. Возможно существенно уменьшить потребление системой памяти в сравнении с работой других дистрибутивов, исключив незадействованные пакеты и службы ядра. Соответственно, может быть увеличена и скорость работы операционной системы - благодаря отсечению лишнего. Само название дистрибутива, происходит от названия вида пингвинов - Gentoo penguin, самого быстрого в мире. Значительная часть версий Linux являются пакетными. Сам процесс установки дистрибутивов такого типа происходит из пакетов, заранее собранных с откомпилированными исполняемыми файлами. Gentoo, в свою очередь, дистрибутив не пакетный, а source-based. У такого типа дистрибутивов исходники пакетов хранятся в репозиториях, а при установке – пакеты собираются из исходников прямо на пользовательском компьютере. Официальный сайт – https://www.gentoo.org/   Особенности линукс дистрибутива Gentoo: source-based дистрибутив; системы менеджмента пакетами Portage, Pkgcore, Paludis; для ряда приложений (особенно долго компилируемых) есть готовые бинарные сборки; созданные при компиляции на одном компьютере бинарные пакеты можно переносить на другой, с таким же железом; скользящие обновления (rolling-релиз); возможность установки существует для таких платформ - x86, x86-64, ARM, PowerPC, PowerPC 970, SPARC, MIPS, DEC Alpha, PA-RISC, IBM/390, SuperH и 68k.   Плюсы дистрибутива линукс Gentoo: глубокая настройка ОС с компилированием под индивидуального пользователя с конкретным железом; очень большое число доступных для установки приложений; большое количество доступных репозиториев; очень высокая стабильность работы правильно настроенных приложений; благодаря rolling-релизам обновление становятся менее болезненным; развитое сообщество пользователей и разработчиков; хорошая документация; возможность продолжения компиляции пакетов в случае если она была прервана; возможность устанавливать одновременно несколько веток софта; ряд исследований показывает, что в Gentoo потребление PHP памяти может быть уменьшено на количество вплоть до 50%.   Минусы дистрибутива Gentoo: излишне высокий порог вхождения для обычного пользователя; первоначальная установка занимает много времени; необходимость в частых обновлениях; если систему долго не обновлять, то обновление потом будет по сложности сравнимо с установкой с нуля; основная работа только через командную строку; возможны проблемы в процессе установки (компиляции пакетов) на слабых компьютерах.   Минимальные системные требования Gentoo Linux для desktop: Фактически может работать на самых минимальных возможных конфигурациях, в зависимости от задач и сборки.   6-е место - openSUSE Начало дистрибутиву openSUSE положено в 1992 году, когда четыре «любителя Linux» - Роланд Дайрофф, Томас Фер, Хьюберт Мантел и Бурхард Стейнбилд запустили SuSE - свой проект по продаже локализованных наборов Slackware Linux. Начиная с 1996 года, SuSE Linux стала независимым дистрибутивом. В дальнейшем, в состав SuSE Linux добавили менеджер пакетов RPM и представили общественности YaST - графический инструмент управления системой. Частые выходы новых версий дистрибутива, доступность SuSE Linux в магазинах Европы и Америки, наличие полной печатной документации – все это смогло поднять популярность дистрибутива. Novell Inc приобрела SuSE Linux в конце 2003 года. Вскоре произошел ряд изменений в политике SuSE. Так широкой публике представили YaST, дистрибутив SuSE лицензировали под GPL, образы дистрибутива начали распространять свободно с общедоступных серверов загрузки, и, что наиболее важно, разработка дистрибутива стала открытой для участия общественности. С версии SuSE 10.0, благодаря сообществу openSUSE, дистрибутив начинает распространятся полностью бесплатно, с открытым исходным кодом. На основе кода openSUSE был создан коммерческий продукт, сначала под именем Novell Linux, но позже разделившийся на два и изменивший название на SUSE Linux Enterprise Desktop и, также, SUSE Linux Enterprise Server. Сейчас проект openSUSE финансируется как компанией SUSE, так и рядом других компаний, и энтузиастов. Сейчас openSUSE доступен в двух основных редакциях - Leap, которая обеспечивает стабильную платформу с многолетней поддержкой и Tumbleweed, который обеспечивает скользящий выпуск обновлений дистрибутива. openSUSE часто хвалят за простоту настройки (через YaST), расширенную поддержку файловой системы Btrfs, а также за автоматические снимки файловой системы и загрузочные среды. Официальный сайт - https://www.opensuse.org/ Особенности дистрибутива openSUSE: версия ядра Linux – 4.12; в качестве графических сред, использует - Cinnamon, Enlightenment, GNOME, IceWM, KDE Plasma, LXDE, LXQt, MATE, Xfce; частота обновления версий – 12 месяцев; в качестве менеджера пакетов применяется RPM; поддерживает x86-64. Плюсы дистрибутива openSUSE: комплексный и интуитивно понятный инструмент настройки; большой репозиторий доступных пакетов ПО; отличная документация проекта; файловая система Btrfs, по умолчанию. Минусы дистрибутива openSUSE: ресурсоемкая работа рабочего стола и графики зачастую замедляет работу системы. Минимальные системные требования openSUSE: Pentium 4 1,6 GHz – процессор; 1 GB – оперативной памяти; 3 GB – свободного места на жестком диске; CD-ROM или USB порт.   5-е место - Linux Mint Linux Mint - основанный на Ubuntu ирландский дистрибутив, впервые выпущенный в 2006 году. Mint доминировал во многих рейтингах с 2011 по 2017 год. Такую популярность он приобрёл за свою стабильность, разнообразие поддерживаемых настольных менеджеров и полноценные мультимедийные возможности. Изначально планировалось выпускать несколько версий дистрибутива Mint под каждый выпуск версии Ubuntu. Однако, со временем, цикл разработки удлинился, сейчас составляя 2 года. При этом теперь дистрибутив базируется только на LTS-версиях Ubuntu (. В настоящий момент разрабатывается и управляется сообществом. Разработчики Mint сосредоточены на стабильности, поэтому они предпочитают консервативный цикл выпуска. Вы не будете получать новейшие обновления, но все равно будете в курсе событий разработки. Вас также не привлекут к разработке в качестве непроизвольного бета-тестера. Официальный сайт - https://linuxmint.com/   Особенности дистрибутива Mint: основывается на LTS версиях дистрибутива Ubuntu; версия ядра линукс – 4.15; специально разработанная среда рабочего стола Cinnamon, также доступны MATE, Xfce; частота обновления версий – 2 года; в качестве системы менеджмента пакетов - применяется dpkg; поддерживает x86 архитектуру; в сравнении с Ubuntu, базовый дистрибутив включает более расширенный мультимедийный функционал; использует тот же программный репозиторий, что и Ubuntu; вход под суперпользователем по умолчанию запрещён, как и в Ubuntu; своя система как обновления, так и установки приложений.   Плюсы дистрибутива Mint: превосходная коллекция мультимедийных инструментов; высокая стабильность работы; открытое сообщество разработчиков.   Минусы дистрибутива Mint: в альтернативные «общественные» релизы редко добавлены последние функции; проект не выпускает рекомендации по безопасности.   Минимальные системные требования дистрибутива Linux Mint: x86 - процессор; 512 MB – доступной оперативной памяти; 9 GB - места на жёстком диске; CD-привод или USB-порт.   4-е место - Fedora Хотя официально год представления дистрибутива общественности - 2004, фактически история Fedora начинается в 1995. Дистрибутив, с именем Fedora, его авторами Бобом Янгом и Марком Юингом изначально был назван - Red Hat Linux. В последствии, Red Hat представила в 1997 году новый менеджер пакетов – RPM (RPM - рекурсивный акроним RPM Package Manager - менеджер пакетов), во многом признанный революционным. В 2003 году, после выхода 9й версии Red Hat, в продуктах компании произошел ряд изменений. Имя Red Hat (товарный знак) - сохранился для коммерческих продуктов, публике же был представлен дистрибутив Fedora Core (затем сменивший имя на Fedora), изначально ориентированный на сообщество «любителей Linux». Несмотря на неприятие изменений сообществом, Fedora уже через несколько выпусков смогла вернуть себе звание одной из наиболее востребованных версий дистрибутива Linux. В свою очередь компания Red Hat, благодаря внедрению множества инноваций, превосходной поддержке клиентов и ряду других моментов, смогла стать крупнейшей и прибыльнейшей Linux-компанией в мире. В 2015 году Fedora представила обновленную версию своего дистрибутива под названием Atomic Host. Используя те же пакеты, что и Fedora's Server edition, Atomic обеспечивает обновления базовой ОС используя технологию OSTree. Сегодня Fedora - это один из самых распространенных и инновационных дистрибутивов Linux. К началу 2019 года только загрузок дистрибутива с официального сайта было произведено около 1 500 000. Широко известен вклад проекта Fedora в код ядра системы Linux, в ряд библиотек и технологий. Однако, в дистрибутиве все еще отсутствует определенность в стратегии развития десктоп-сегмента, которая упростила бы использование этого линукс дистрибутива для всех тех, кто выходит за рамки цели «любителя Linux». Официальный сайт - https://getfedora.org/   Особенности дистрибутива Fedora 29: версия ядра Linux – 4.18; менеджер пакетов RPM; использует по умолчанию графическую среду GNOME 3.30; частота обновления – 6-8 месяцев; поддерживает x86, x86-64, ARM, i686, POWER, MIPS, IBM System/39 платформы; единый глобальный репозиторий с исключительно бесплатным ПО (есть ряд неофициальных репозиториев); проект как разрабатывается, так и поддерживается сообществом, при этом спонсором выступает компания Red Hat; Fedora Project запретила поставку дистрибутива в Крым, Сирию, Судан, Иран, Северную Корею, и Кубу.   Плюсы дистрибутива Fedora: значительная инновационность дистрибутива; встроенная поддержка Docker; впечатляющие возможности обеспечения безопасности; огромное количество поддерживаемых пакетов; философская концепция свободного ПО; устоявшееся сообщество разработчиков и пользователей дистрибутива; наличие Live-CD со многими графическими оболочками.   Минусы дистрибутива Fedora: приоритеты дистрибутива Fedora, ориентированы, чаще, на решения корпоративных задач, а не на удобство при использовании персональных компьютеров; некоторые передовые внедрения (к примеру - раннее переключение на KDE 4 и GNOME 3) отталкивают ряд устоявшихся пользователей настольных компьютеров.   Минимальные системные требования дистрибутива Fedora: 1 GHz - процессор; 1 GB – оперативная память; 10 GB – свободного места на жестком диске.   3-е место - Debia   OS Debian GNU анонсировали в 1993 году. Создателем дистрибутива Debian был Ян Мердок, который, совместно с сотнями разработчиков-добровольцев, проектировал новый, полностью некоммерческий дистрибутив. Несмотря на общий скепсис в отношении новой операционной системы, Debian выжил. Кроме того, он стал крупнейшим дистрибутивом и, вероятно, самым крупным совместным проектом ПО из когда-либо созданных! Успешность Debian можно проиллюстрировать следующими цифрами. Его разрабатывали более 1000 добровольных разработчиков. Репозитории Debian содержат около 50 000 бинарных пакетов (написанных для 8 различных процессорных архитектур) и участвуют в создании около 130 установочных дистрибутивов и систем LiveCD на основе Debian. Ни одна другая ОС семейства Linux не может похвастаться похожими достижениями. Фактическая разработка OS Debian происходит в четырех (включая экспериментальную) основных ветвях с повышающимися уровнями стабильности работы ПО: «нестабильная» - «sid», «тестовая» и «стабильная». Именно благодаря этой схеме постепенной стабилизации и интеграции компонентов, Debian на сегодня считается одним из наиболее протестированных и наиболее свободных от ошибок дистрибутивов Linux. Официальны сайт - https://www.debian.org/   Особенности stable дистрибутива Debian Linux: дистрибутив основан на ядре версии 4.9. работает на следующих архитектурах - Intel x86, Intel 64, AMD64, ARM, ARM с аппаратным FPU, 64-битные ARM, 32bit MIPS, 64bit MIPS, Power Systems, 64-битный IBM S/390.   Плюсы дистрибутива Debian: признанная очень высокая стабильность; глубокий и последовательный контроль качества разработки; огромная библиотека пакетов в репозиториях - более 30 000 пакетов ПО; Универсальность касательно применения с различными видами процессорных архитектур. Debian поддерживает на сегодня больше их видов, чем любые другие линукс дистрибутивы. Минусы: достаточно быстрое устаревание стабильных версий из-за длинного цикла разработки – 1-3 года на цикл; консервативный состав дистрибутива – новые технологии, зачастую, не включаются в состав дистрибутива из-за необходимости поддержки сразу многих процессорных архитектур; относительно старая версия ядра; демократичность руководства проектом зачастую приводит к неоднозначным решениям, вызывая конфликты в сообществе разработчиков и тормозя развитие проекта.   Системные требования Debian: 128 MB – оперативная память; 2 GB - свободного места на жестком диске.   2-е место - Arch Linux Дистрибутив Arch Linux был основан Джаддом Винетом на философии KISS (keep it simple, stupid - не усложняй, тупица) в 2002 году. Сначала развитие проекта Arch Linux проходило, как дистрибутива для достаточно продвинутых пользователей, и Arch был мало популярен. Ситуация изменилась после того, как к дистрибутиву была применена политика обновлений Rolling release (плавающий релиз).  Теперь операционную систему достаточно стало установить единожды, после чего мощный менеджер пакетов сам обновлял соответствующие пакеты согласно выходящим обновлениям, без необходимости переустановки ОС. Из-за этого мажорные выпуски Arch Linux немногочисленны и ограничиваются базовым установочным образом, который обновляется только при значительных изменениях в базовой версии системы. Официальный сайт - https://www.archlinux.org/   Особенности дистрибутива Arch Linux: быстрый и мощный менеджер пакетов Pacman предоставляет возможность легко управлять и настраивать под себя как пакеты, размещенные в официальных репозиториях Arch, так и собранные самостоятельно; возможность устанавливать пакеты ПО из исходного кода; доступны следующие варианты графических оболочек – GNOME, KDE, LXDE, MATE, Xfce, Cinnamon, Enlightenment. в своем базовом виде дистрибутив Arch Linux содержит тщательно отобранный набор ПО, необходимого для ежедневной работы. основанная на философии «не усложняй», Arch Linux предоставляет ПО в том виде, в котором оно изначально представлено разработчиками. Для обеспечения совместимости вносятся только минимально необходимые изменения. последняя версия работает с ядром 4.20.5.   Плюсы дистрибутива Arch Linux: отличная инфраструктура управления программным обеспечением; возможности глубокой настройки системы под себя; удобства системы обновлений Rolling release; доступность обширной библиотеки документации системы.   Минусы дистрибутива Arch Linux: опасности ошибок и нестабильности при обновлениях благодаря особенностям принципа обновлений «roll-release»; требовательность к относительно высокому уровню знаний пользователя; зачастую невозможность установки новой - «мажорной» версии ОС, поверх старой.   Системные требования Arch Linux: x86_64 - совместимый процессор; 512 MB - оперативная память; 800 MB – свободного места на жестком диске; подключение к Интернету.   1-е место - Ubuntu Топ 1 нашего рейтинга -  операционная система Ubuntu, является широко распространенной версией Linux, в свое время основанной на другом дистрибутиве – Debian. Впервые о выходе Ubuntu заявили в 2004 году. Несмотря на относительную новизну, развиваться он начал стремительно. Пройдя тернистый путь популяризации длинной в 15 лет, Ubuntu занимает место самой популярной версии Linux для настольных компьютеров. Этот проект сделал очень много для разработки простой и удобной в использовании, бесплатной операционной системы для настольных компьютеров. Сегодня дистрибутив Ubuntu успешно конкурирует как со свободными, так проприетарными ОС. В чем причины потрясающего успеха Ubuntu? Среди главных выделяют Марка Шаттлворта - автора проекта.  Участвовавший ранее до Ubuntu в разработке Debian, Шаттлворт является мультимиллионером, владеющим компанией Canonical Ltd, которая и финансирует проект в настоящее время. Во-вторых, проект Ubuntu извлек уроки из проблем в разработках схожих проектов и смог избежать их – разработчики смогли создать удобную веб-инфраструктуру с Wiki-документацией и креативным средством сообщения о багах системы, профессионально подходя к конечным потребителям. В-третьих – с помощью финансовых возможностей автора, участники проекта смогли разослать бесплатные образцы дистрибутива заинтересованным пользователям. Это напрямую поспособствовало скорейшему распространению Ubuntu. Фактически, Ubuntu основывается на нестабильной ветке дистрибутива Debian, включив в себя такие распространенные пакеты, как - GNOME, LibreOffice, Firefox и др., обновив их до стабильных версий. Этот дистрибутив Linux выходит с предсказуемым шестимесячным графиком, периодически выпуская версии с долгосрочной поддержкой (LTS), которые поддерживаются обновлениями безопасности на протяжении 5 лет. Выпуск без LTS, в свою очередь, поддерживается 9 месяцев. Официальный сайт - https://www.ubuntu.com/   Особенности дистрибутива линукс Ubuntu: дистрибутив основывается на Debian; вход под суперпользователем отключен. Для получения полномочий суперпользователя используется утилита sudo; доступны варианты дистрибутивов с разными пакетами графических оболочек - GNOME - по умолчанию в версии 18.04, KDE – Kubuntu, Xfce – Xubuntu, LXDE/ LXQt – Lubuntu и другие. в версии Ubuntu 18.04 сбор пользовательских данных включён по умолчанию (возможно отключить); ядро Linux версии 4.15 в LTS версии; проект разрабатывается и поддерживается компанией Canonical.   Плюсы дистрибутива Ubuntu: исправлен цикл релиза и период поддержки, в сравнении с Debian; наличие долгосрочной поддержки (LTS) с 5-летним сроком предоставления обновлений безопасности; интерфейс, дружественный для начинающих; множество как официальной, так и пользовательской документации; широко распространенный дистрибутив с обширным комьюнити, большим количеством репозиториев и широкой возможностью выбора программ для установки. поддержка новейших технологий «из коробки» - к примеру, 3D эффекты графической оболочки и элементов рабочего стола; простая установка проприетарных драйверов для различных устройств беспроводных сетей и видеокарт NVIDIA и ATI; возможность выбора варианта дистрибутива с менее требовательной графической оболочкой.   Минусы: отсутствие совместимости с дистрибутивом Debian; часто выходящие важные изменения дистрибутива, как правило, отталкивают некоторых пользователей; не LTS релизы поставляются только с 9-месячной поддержкой безопасности.   Минимальные системные требования дистрибутива Ubuntu: 2 GHz dual core процессор; 2 GiB – доступная оперативная память; 25 GB – свободного места на жестком диске; CD/DVD привод или USB порт для.   Несколько не вошедших в ТОП рейтинга, но все еще интересных дистрибутивов Linux   Antergos Antergos- это относительно новый дистрибутив Linux, основывающийся на Arch. Изначально выпущенный в 2012 году под именем Cinnarch, этот дистрибутив был клоном Arch Linux, с Cinnamon в качестве окружения рабочего стола. На уровне системы отличий между Antergos и Arch Linux – нет. Разница между дистрибутивами находится в подходе к пользователю. В отличие от Arch, рассчитанного на уже опытного пользователя, Antergos направлен на всех, как опытных, так и начинающих Linux пользователей. В качестве установщика Antergos использует собственную разработку - CNCHI, созданный чтобы максимально упростить для пользователя процесс установки. Минимальный набор входящих в дистрибутив приложений подойдет тем, кто хочет собрать дистрибутив под свои нужды. Если же вам нужен уже готовый к работе дистрибутив, предоставляющий полный набор приложений для повседневного использования - вам Antergos не подойдет. Галийское слово Antergos (означающее: предки) было выбрано, «чтобы связать прошлое с настоящим». Это название символизирует, что несмотря на все глубокие существенные изменения в дистрибутиве, глубокая связь с основой дистрибутива, Arch Linux - остается. Официальный сайт - https://antergos.com/   Особенности дистрибутива Antergos: основывается на Arch Linux; Использует версию ядра 4.20; Доступны такие виды графической оболочки – Cinnamon, GNOME, KDE, Xfce, Openbox, MATE Скользящая модель обновлений.    Плюсы дистрибутива Antegos: Открытое сообщество, как для разработчиков, так и для пользователей с их пожеланиями и замечаниями; Собственный установщик, упрощающий процесс установки; Поддерживается то же железо, что и у Arch Linux, Отличный внешний вид благодаря сотрудничеству с Numix; Использует репозитории Arch Linux; Быстрый выход обновлений для разнообразного ПО.   Минусы дистрибутива Antergos: Сложности с установкой проприетарных драйверов на ряд устройств - нужно ставить вручную.   Puppy Linux Puppy Linux это дистрибутив Linux, созданный Барри Каулером в 2003 году. Puppy Linux – не является цельным дистрибутивом Linux, как Debian. Puppy Linux также не является дистрибутивом Linux с несколькими разновидностями, как Ubuntu (с его вариантами Ubuntu, Kubuntu, Xubuntu и т. д.), хотя и поставляется в разных вариантах. Puppy Linux - это совокупность нескольких дистрибутивов Linux, построенных на одних и тех же общих принципах, с использованием одного и того же набора инструментов, на основе уникального набора приложений и конфигураций, специфичных для Puppy, и в целом обеспечивающих согласованное поведение и работу, независимо от того, какой дистрибутив вы выбираете. Не смотря на очень маленький размер, дистрибутив является полнофункциональным. В отличие от дистрибутивов LiveCD, которые должны постоянно подгружать данные с компакт-диска, Puppy загружается сразу в RAM. Таким образом все ПО будет запускаться практически мгновенно и мгновенно реагировать на ввод данных пользователем. Puppy Linux может загружаться с любого USB-накопителя, CD-ROM, Zip-диска или супердиска LS 120/240, дискет, внутреннего жесткого диска. Он может даже использовать мультисессионный формат CD-RW / DVD-RW, чтобы сохранить всё обратно на CD / DVD без жесткого диска вообще.   Есть три основных направления дистрибутивов Puppy Linux: официальные дистрибутивы – являются дистрибутивами общего назначения и поддерживаются командой Puppy Linux. Как правило, создаются с использованием сборщика систем Puppy Linux (называемого Woof-CE). собранные в коллекцию Woof, дистрибутивы Puppy Linux - разрабатываются для удовлетворения конкретных потребностей, предназначаются для общего пользования и собраны с использованием системного компоновщика Puppy Linux с рядом дополнительных или модифицированных пакетов. неофициальные производные дистрибутивы («щенки») - являются ремастерами (или ремастерами ремастеров), созданными и поддерживаемыми энтузиастами Puppy. Обычно предназначаются для определенных конкретных целей.   Официальный сайт - http://puppylinux.com/   Особенности дистрибутивов Puppy Linux: минимум системных служб; ядро версии 4.4. Можно обновить до 4.9; свой менеджер пакетов - Puppy Package Manage; поддерживает архитектуру i386, x86_64.   Плюсы дистрибутивов Puppy Linux: ядро и софт, оптимизированные под домашнего пользователя; содержит все инструменты повседневного использования; легкая установка – драйвера на большинство современного и старого оборудования работают автоматически; малый размер системы – 300 MB или меньше; возможна работа в режиме полной установки, а также полноценная работа c CD-ROM (LiveCD) или USB-Flash; возможность установки нескольких FRUGAL дистрибутивов на раздел с установленным Windows; удобная переносная система с вашими настройками на USB-флешке, карте памяти или HDD; удобный оконный «бабушка-френдли» интерфейс системы; большое количество производных дистрибутивов под нужды каждого пользователя.   Минусы дистрибутивов Puppy Linux: Из-за необходимости поддерживать совместимость со старым железом, графический интерфейс, некоторыми пользователями воспринимается сильно устаревшим.   Рекомендуемые системные требования: 1 или больше GHz - процессор; 2 GB - оперативная память.   Manjaro Linux Manjaro это дистрибутив Linux, основывающийся на Arch Linux. Впервые представленный в 2011 году, дистрибутив Manjaro до 2013 года находился в режиме беты. Основываясь на Arch, проект Manjaro со времен своего основания своей целью ставил создание дистрибутива, сочетающего в себе как дружественность по отношению к неопытным пользователям, так и возможности Arch Linux. Официальный сайт - https://manjaro.org/ Особенности дистрибутива Manjaro: Использует менеджер пакетов Pacman; Поддерживает платформу x86-64; Поддерживает версию ядра 4.20.3; Отказ от использования персональных архив пакетов (Personal Package Arhive - PPA).   Плюсы дистрибутива Manjaro: Удобный менеджер драйверов с возможностью автоматической установки; Поддержка обширного списка оборудования; Использование репозиториев Arch, полная совместимость с Arch User Repository; rolling release в обновлениях с предварительным тестированием пакетов участниками проекта Manjaro; удобная возможность установки множество версий ядра и удобного переключения между ними; доброжелательное сообщество.   Минусы дистрибутива Manjaro: Отказ от поддержки архитектуры i686; Пользователи отмечают перенасыщенность брендингом включая обои, закладки в браузерах и тп; Относительно малочисленной сообщество со всем вытекающим для Linux-пользователя.   Вывод. Выбирая для себя операционную систему, стоит помнить, что операционная система — это инструмент, который, с одной стороны, должен быть для вас удобным, а с другой – обладать нужным для вас функционалом. Какая система лучше для пользователя: Windows или Linux, или MacOs, или FreeBSD– это тема многих «священных форумных войн», так и не давших однозначного ответа на этот вопрос. Такие же баталии, хотя и с меньшим градусом агрессии, проходят на тему «лучший дистрибутив linux». Мы не сможем дать Вам однозначного ответа на вопрос – какой дистрибутив является лучшим дистрибутивом Linux для разработчика. Если Вы только раздумываете над возможностью перейти на работу c OC Linux, Вам будет полезно рассмотреть наш рейтинг в качестве отправной точки. Если же Вы уже являетесь опытным пользователем Linux – мы надеемся, что наш рейтинг дистрибутивов Linux поможет Вам в выборе нового инструмента, или утвердит в желании остаться на проверенном Вами. Не так важно определиться раз и на всегда в операционной системе. Не бывает однозначно абсолютно удобных инструментов (многие разработчики используют одновременно 2 и более операционных систем.). Главное, чтобы Вы продолжали профессионально расти и развиваться, используя подходящие и удобные для Вас инструменты. Со своей стороны, портал ITVDN готов предоставлять для этого развития актуальную и полезную информацию.

План: 1. Різниця між синхронним та асинхронним кодом 2. Багатозадачність процеси й потоки, у чому різниця 3. Особливості багатозадачності в JavaScript 4. Асинхронні операції на практиці HTTP-запит як найпоширеніший кейс 5. Підходи до написання асинхронного коду: Promise    Async/Await Observable 6. Практичні поради Різниця між синхронним та асинхронним кодом Для початку давайте визначимо ці два терміни: Синхронний код - це код, який виконується послідовно, функція за функцією. Асинхронний код - код, який може виконуватися паралельно: наступна функція запускається, не чекаючи завершення попередньої. Щоб провести аналогію з реального життя, уявімо кухаря. Якщо кухар працює синхронно, то поки він не завершить приготування однієї страви, не переходить до наступної. Але це неефективно й призводить до втрати часу. Якщо ж кухар діє асинхронно, то поки м’ясо запікається в духовці, а на плиті закипає вода, він нарізає овочі. Тобто він один, але не стоїть без діла - виконує інші задачі, поки щось готується саме. Уявімо, що кухар - це процесор. А запікання м’яса в духовці - це завантаження файлу з мережі. Кухар може просто стояти й дивитись, як м’ясо готується. А може нарізати овочі, перевіряти, чи не з’явились нові замовлення, або скролити стрічку в соцмережі. Так само і з програмами: поки мережева карта завантажує файл, процесор не мусить чекати - він може малювати інтерфейс, оновлювати прогрес-бар чи виконувати обчислення у фоні. Але для цього потрібно правильно написати код - так, щоб він міг працювати асинхронно. Код який виконується синхронно ```js console.log("Початок"); console.log("Дія"); сonsole.log("Кінець"); ``` Результат: Початок Дія Кінець   Код який виконується асинхронно. і ``js console.log("Початок"); setTimeout(() => { // за допомогою setTimeout ми відкладаємо запуск коду на певний час   console.log("Дія через 2 секунди"); }, 2000); сonsole.log("Кінець"); ``` Результат: Початок Кінець Дія через 2 секунди Це не та багатозадачність, як у деяких інших мовах програмування. Тут не використовуються додаткові потоки, а все працює завдяки механізму подій. Але про це детальніше дал Багатозадачність: процеси й потоки, у чому різниця Багатозадачність в операційній системі - це можливість запускати та керувати кількома задачами одночасно. Наприклад, працювати в браузері, слухати музику, завантажувати файл і паралельно редагувати код у Visual Studio. На практиці процесор дуже швидко перемикається між усіма цими задачами, створюючи ілюзію одночасного виконання. Якщо процесор багатоядерний - деякі задачі справді можуть виконуватись паралельно. Багатозадачність тісно пов'язана з двома важливими поняттями - процесами та потоками. Процес (process) - це окремий екземпляр програми у пам'яті, який має власні ресурси: виділену область оперативної пам'яті, дескриптори файлів, змінні оточення тощо.  Потік (thread) - це одиниця виконання всередині процесу. Потоки одного процесу працюють незалежно, але мають спільний доступ до пам'яті та ресурсів процесу. Процеси дозволяють запускати різні програми одночасно - наприклад, Google Chrome, Visual Studio Code і т.д.  Потоки дають змогу виконувати кілька задач усередині однієї програми. Наприклад, у Visual Studio Code один потік відповідає за оновлення інтерфейсу, інший перевіряє помилки в коді, ще один формує підказки під час написання. Це, звісно, спрощений приклад - у реальності VS Code використовує ще й окремі процеси для розширень і мовних серверів. Операційна система керує як процесами, так і потоками. Вона розподіляє процесорний час між ними, ставить у чергу, може призупиняти виконання або відновлювати його за потреби. Давайте трохи адаптуємо наш приклад з кухарем із попереднього посту. Уявімо, що процес - це ресторан, а потік - це кухар. Ресторан має все необхідне для приготування їжі: кухонне приладдя, продукти, рецепти (це можна розглядати як пам’ять і доступ до інших ресурсів). Кухар читає рецепт і, використовуючи ресурси ресторану, готує страву - так само, як потік виконує інструкції нашої програми, використовуючи ресурси процесу. Якщо ресторан хоче готувати кілька страв одночасно, йому потрібно більше кухарів, які працюють паралельно на одній кухні. Аналогічно, якщо програма повинна виконувати кілька задач одночасно - завантажувати файли, обробляти введення, оновлювати інтерфейс - вона може використовувати кілька потоків. Коли ми створюємо програму і хочемо зробити її зручною для користувача, а також ефективною з точки зору використання ресурсів, які виділяє операційна система на процес, ми іноді починаємо використовувати потоки та прийоми багатопотокового програмування. Це велика окрема тема, і ми її зараз чіпати не будемо. Одна з причин - у JavaScript немає прямого доступу до потоків. Уточнення. Якщо ви хочете використовувати JavaScript і все ж таки працювати з потоками - у вас є Web Workers:  https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers  А якщо JavaScript виконується не в браузері (наприклад, у Node.js), тоді можна використовувати модуль `worker_threads`. Але варто розуміти, що це не частина стандарту мови, а можливість середовища виконання. Додаткові корисні ресурси по цій темі: https://www.youtube.com/@CoreDumpped - канал з короткими відео про те як працює комп'ютер. Modern Operating System by Andrew Tanenbaum - принцип побудови та роботи операційних систем (може бути викликом для новачка, але нормально як для технічної книжки) Особливості багатозадачності в JavaScript JavaScript працює в одному потоці - це означає, що в будь-який момент часу виконується лише один фрагмент коду. Увесь код, який ми пишемо, виконується у call stack: це структура, в яку потрапляють усі функції, що викликаються. Якщо одна з функцій виконується довго (наприклад, важке обчислення), усі інші задачі - включно з обробкою кліків, рендерингом чи відповідями від сервера - будуть чекати, поки call stack не звільниться. Щоб не блокувати цей єдиний потік, браузер надає асинхронні API (setTimeout, fetch, Web API). Коли ми викликаємо, скажімо, fetch(), у стек додається лише короткий виклик цієї функції. Власне мережевий запит виконується в окремому потоці, який створює браузер. Тобто, один потік виконує задачі які є у call stack, а інший потік чекає поки відповідь поверне сервер. Але асинхронна операція колись завершиться і треба механізм який віддасть нашому головному потоку результат роботи іншого потоку. Коли це стається колбек або проміс‑резолвер не додається одразу у call stack. Спершу він потрапляє до черги подій (task queue). За роботою черги стежить event loop. Його правило просте - поки стек порожній дістати першу задачу із черги і покласти у стек. Так ми досягаємо псевдобагатозадачності: основний потік виконує короткі шматки коду послідовно, а довгі операції «живуть» поза стеком. Коли довгі операції завершуються вони формують чергу задач, які треба виконати а event loop ці задачі закидає до стеку, коли call stack стає порожнім. Це максимально спрощене пояснення, і без візуалізації може здатися складним. Якщо хочете краще зрозуміти, дуже раджу подивитись відео Jake Archibald — "In The Loop" на YouTube (англійською).  https://www.youtube.com/watch?v=8aGhZQkoFbQ Або приходьте на мій курс JavaScript Поглиблений, де ми розбираємо це на практиці.  Також корисна стаття на MDN, де ці процеси описані докладніше. Асинхронні операції на практиці: HTTP-запит як найпоширеніший кейс Один з прикладів асинхронної операції - це запит на сервер через HTTP-протокол. Якщо організовувати запит через JavaScript у браузері без використання React, Angular або Vue.js, то це можна зробити за допомогою: fetch XMLHttpRequest Спеціалізована бібліотека, наприклад, Axios Ось так буде виглядати простий код написаний на fetch ```js fetch('https://jsonplaceholder.typicode.com/users')   .then(res => res.json())   .then(data => console.log(data)); ``` А так на axios (axios одразу повертає розпарсений JSON як response.data, на відміну від fetch, де потрібно викликати .json() вручну) ```js axios.get('https://jsonplaceholder.typicode.com/users')   .then(response => console.log(response.data)); ``` Якщо розглянути саме fetch то ось що відбулося під капотом: fetch створює HTTP запит вказавши HTTP метод, заголовки, тіло тощо Цей запит передається у вбудовану систему Web API - окрему від JavaScript середу, яка працює в іншому потоці. JavaScript не чекає відповіді - основний потік продовжує виконувати інший код fetch повертає Promise - об'єкт, що представляє асинхронну операцію, результат якої з’явиться пізніше Коли відповідь від сервера приходить, Web API кладе callback в чергу. Event Loop перевіряє, чи call stack порожній, і виконує цю мікрозадачу. Така поведінка дозволяє браузеру одночасно виконувати інші задачі, не чекаючи завершення запиту. Про використання асинхронного коду в JavaScript є [безкоштовний урок на YouTube](https://www.youtube.com/watch?v=cvR1EQ1R0EQ) Також більше про синтаксис Promise можна дізнатися в уроці [Асинхронний код. Promise](https://itvdn.com/ua/video/javascript-essential-ua/js-promise-ua) на ITVDN, а детальніше про варіанти організації такого коду буде написано далі. Підходи до написання асинхронного коду Складність роботи з асинхронним кодом полягає в тому, що обробка результату операції відбувається не відразу, а через певний час після її запуску. Ми ініціюємо асинхронну операцію й можемо виконувати інші завдання, але все одно маємо якось дізнатися про її завершення та обробити результат. Проблема в тому, що в цей момент програма вже виконує інші дії. Тому для обробки асинхронних операцій використовується push-модель взаємодії: отримувача даних (наш код) викликає провайдер даних - окремий механізм, який керує асинхронною операцією. По суті, розробнику потрібно відреагувати на подію завершення асинхронної операції. Для цього існує кілька підходів: callback-функція Promise async/await (синтаксичний цукор над Promise) Observables Використання функцій зворотнього виклику (callback) Почнемо з callback-функцій. Це найпростіший підхід, але він може призвести до заплутаного коду, особливо коли одна асинхронна операція запускає іншу, і так утворюється ланцюг. Уявімо, що маємо функцію downloadImage(url, callback), яка завантажує зображення асинхронно, не блокуючи основний потік. Перший параметр - це адреса зображення, яке потрібно завантажити, а другий - функція, яку буде викликано після завершення завантаження. При цьому саме зображення буде передане як параметр у callback. Приклад використання: ```js downloadImage(url1, image => document.body.append(image)) ``` На перший погляд усе просто. Але якщо потрібно завантажити кілька зображень послідовно, код стає менш зрозумілим: ```js downloadImage(url1, image => {             document.body.append(image);             downloadImage(url2, image => {                         document.body.append(image);                         downloadImage(url3, image => {                                     document.body.append(image);                         })             }) }); ``` Така вкладена структура швидко ускладнюється, особливо якщо замість одного рядка з DOM-змінами з’являється додаткова логіка. Подібний стиль називають "Pyramid of Doom", і його краще уникати. Один зі способів спростити обробку асинхронних викликів - це використання Promise. Використання Promise Promise - це об’єкт, який представляє асинхронну операцію. У перекладі з англійської promise означає «обіцянка». Можна уявити, що це обіцянка від браузера надати в майбутньому або результат операції, або помилку, пов’язану з її виконанням. Приклад використання: перепишемо попередню функцію downloadImage, щоб вона повертала Promise. ```js let promise = downloadImage(url1); promise.then(image => document.body.append(image)); ``` Тут ми все одно використовуємо callback-функцію, але передаємо її вже в метод .then() об’єкта promise. Це важливий момент: тепер асинхронна операція має об’єктне представлення, яке можна передавати як параметр у різні частини коду; можна будувати ланцюжки промісів, позбуваючись вкладеності, яка виникала з callback. Приклад: ```js downloadImage(url1)                          // отримуємо проміс .then(image => {                             // вказуємо що робити коли promise перейде в стан resolved             document.body.append(image);             return downloadImage(url2);                // виконуємо метод, який повертає promise }) .then(image => {                             // результат роботи попереднього промісу передається як значення             document.body.append(image);             return downloadImage(url3); }) .then(image => {             document.body.append(image); }); ``` Тепер код виглядає лінійним і набагато зручнішим для супроводу. У прикладах вище ми не розглядали, як саме створюється Promise, адже важливо зрозуміти мотивацію використання цих об’єктів. Тим більше, що більшість API браузера вже повертають готові проміси. Наприклад: ```js fetch('<https://jsonplaceholder.typicode.com/users>')   .then(res => res.json()); ``` Якщо хочете детальніше розібратися зі створенням Promise вручну - перегляньте документацію на MDN або мій відео урок на ITVDN. Async/await Супроводжувати синхронний код завжди простіше, ніж асинхронний. У 2012 році в мові C# з’явився синтаксичний цукор, який значно спростив роботу з асинхронними операціями: замість вкладених callback можна було використовувати послідовний синтаксис з новими ключовими словами async та await. Згодом цю концепцію перейняли й інші мови програмування, зокрема Python та JavaScript. В JavaScript підтримку async/await додали у 2017 році. Призначення ключових слів async - додається до функції та вказує, що вона завжди повертає Promise. await - використовується перед об’єктом-промісом, щоб "дочекатися" результату перед виконанням наступних рядків коду. Перепишемо попередній приклад із завантаженням зображень, використовуючи async/await: ```js let image = null;   image = await downloadImage(url1); document.body.append(image);   image = await downloadImage(url2); document.body.append(image);   image = await downloadImage(url3); document.body.append(image); ``` Тепер код виглядає як звичайний синхронний: немає вкладених callback, усе читається рядок за рядком. Можна подумати, що await "зупиняє" виконання, очікуючи на результат промісу. Насправді ж код не блокує основний потік - під капотом він перетворюється на машину станів, де кожен стан описує дію до або після await. Ще одна перевага async/await - знайомий синтаксис для обробки помилок: ```js try {             let image = null;               image = await downloadImage(url1);             document.body.append(image);               image = await downloadImage(url2);             document.body.append(image);               image = await downloadImage(url3);             document.body.append(image); } catch (ex) { // обробка помилки } ``` У результаті асинхронний код виглядає так само зрозуміло, як і синхронний, що значно спрощує його супровід. Observable Observable - це ще один підхід до організації асинхронного коду. Назва походить від однойменного патерна проєктування (Observer pattern), який описує створення об’єктів, за якими можна «спостерігати», отримуючи від них сповіщення. Тобто це реалізація подієвої моделі за допомогою ООП. У сучасному JavaScript ця ідея пішла далі й стала основою реактивного програмування та бібліотеки RxJS. Якщо Promise представляє одне майбутнє значення (успішне або помилкове), то Observable - це потік значень, які можуть з’являтися з часом. Можна уявити: Promise - це одна посилка, яку ви отримаєте в майбутньому; Observable - це підписка на журнал, нові випуски якого надходитимуть регулярно. Щоб створити Observable, використовують конструктор або готові оператори RxJS. Наприклад, функція downloadImages(urls) може завантажувати кілька картинок і відправляти їх «у потік» по мірі завантаження: ```js import { Observable } from 'rxjs';   function downloadImages(urls) {   return new Observable(subscriber => {     urls.forEach(url => {       downloadImage(url, image => {         subscriber.next(image); // надсилаємо картинку у потік       });     });     subscriber.complete(); // повідомляємо, що потік завершено   }); } ``` Щоб використати Observable, на нього треба підписатися за допомогою subscribe: ```js downloadImages([url1, url2, url3])   .subscribe({     next: image => document.body.append(image), // що робити з новим значенням     error: err => console.error(err),           // обробка помилок   }); ``` Переваги Observable працюють із потоком даних, а не з одним результатом; підтримують підключення операторів трансформації (фільтрація, мапінг, комбінування потоків); можна легко скасувати виконання (відписатися від потоку). Нижче приклад обробки даних через оператори. В RxJS оператори підключаються через метод pipe: ```js import { filter, map } from 'rxjs/operators'; downloadImages([url1, url2, url3])   .pipe(     filter(image => image.width > 100), // пропускаємо лише великі картинки     map(image => {       image.classList.add('highlight');       return image;     })   )   .subscribe({     next: image => document.body.append(image),     error: err => console.error(err),     complete: () => console.log('Готово')   }); ``` Таким чином, як і у випадку з Promise, можна будувати ланцюжки обробки. Але Observable значно гнучкіші: вони дозволяють працювати не лише з одним значенням, а з динамічною послідовністю даних у часі. Для глибшого занурення рекомендую офіційний гайд Observable на RxJS.dev. та відео уроки Observables. Частина 1, та Observables. Частина 2[1]  Практичні поради по работі за асинхроним кодом Не змішуйте підходи без потреби Якщо почали писати з async/await, не вставляйте всередину .then() без особливої причини. Це ускладнює читання. Обробляйте помилки Використовуйте try/catch для async/await або .catch() для Promise. У випадку Observable завжди додавайте обробку error у subscribe(). Скасовуйте непотрібні операції Для Observable використовуйте unsubscribe(), коли потік більше не потрібен. Для fetch можна застосувати AbortController, щоб зменшити навантаження й уникнути витоків пам’яті. Уникайте "Pyramid of Doom" Замість вкладених callback застосовуйте Promise, async/await або Observable. Використовуйте паралельне виконання Якщо операції незалежні, запускайте їх одночасно через Promise.all(). Ізолюйте логіку обробки Розділяйте завантаження даних та маніпуляції з DOM. Це спростить тестування й повторне використання коду. Логуйте стан і помилки Під час розробки виводьте у консоль ключові події асинхронних операцій, щоб відстежувати їх послідовність. Пам’ятайте про event loop Розуміння різниці між мікрозадачами й макрозадачами допоможе прогнозувати порядок виконання коду. Перевіряйте сумісність середовища Деякі API можуть бути відсутні у певних середовищах (наприклад, fetch у Node.js доступний лише починаючи з версії 18).