Коротко про мене Мене звати Зел, я розробник-фрілансер із Сінгапуру. У вільний від роботи час я люблю розбиратися в коді і принагідно публікувати у своєму блозі ті цікавості, які я виявив чи вивчив. Вступ Швидше за все вам уже доводилося чути про такий термін, як REST API, особливо якщо ви стикалися з необхідністю отримання даних з іншого джерела (такого як Twitter або GitHub). Але що ж все-таки це таке? Що ми можемо робити з цим і як ми можемо це використовувати? У цій статті ви дізнаєтеся все про REST API для того, щоб працювати з ними та читати пов'язану з ними документацію. Що ж таке REST API? Давайте уявимо, що ви намагаєтеся знайти фільми про Бетмена на YouTube. Ви відкриваєте сайт, вбиваєте у форму пошуку слово «Бетмен», тиснете «Окей» і бачите список фільмів про супергероя. Так само працює і WEB API. Ви шукаєте щось і отримуєте список результатів від ресурсу, до якого здійснюєте запит. Дослівно API розшифровується як Application Programming Interface. Це набір правил, що дозволяє програмам спілкуватися одна з одною. Розробник створює API на сервері та дозволяє клієнтам звертатися до нього. REST – це архітектурний підхід, що визначає, як API мають виглядати. Читається як "Representational State Transfer". Цьому набору правил і слідує розробник під час створення свого застосунку. Одне з цих правил каже, що при зверненні до певної адреси ви повинні отримувати певний набір даних (ресурс). Кожна адреса - маршрут, пакет даних - запит, у той час як результуючий ресурс – відповідь. Анатомія запиту Важливо розуміти структуру запиту: Маршрут відправки. Тип методу. Заголовки. Тіло (або дані). Маршрут – це адреса, за якою надсилається ваш запит. Його структура приблизно така: Root-endpoint - це точка прийому запиту на стороні сервера (API). Наприклад, кінцева точка GitHub - https://api.github.com. Шлях визначає ресурс, до якого здійснюється запит. Це щось на кшталт автовідповідача, який просить вас натиснути 1 для одного сервісу, 2 для іншого і так далі. Для розуміння того, які саме шляхи вам доступні, вам слід переглянути документацію. Наприклад, припустимо, ви хочете отримати список репозиторіїв для конкретного користувача на Git. Згідно з документацією, ви можете використати наступний шлях для цього: Вам слід підставити під пропуск ім'я користувача. Наприклад, щоб знайти список моїх репозиторіїв, ви можете використати маршрут: Остання частина маршруту – це параметри запиту. Технічно запити не є частиною REST-архітектури, але на практиці зараз все ґрунтується на них. Тож давайте поговоримо про них детальніше. Параметри запиту дозволяють використовувати у запиті набори пар «ключ-значення». Вони завжди починаються знаком питання. Кожна пара параметрів після чого розділяється амперсандом (щось подібне до цього): Як тільки ви намагаєтеся отримати список репозиторіїв для користувача, ви додаєте ці три опціональні параметри і після чого отримуєте наступний результат: Якщо ж ви бажаєте отримати список моїх недавно запушених репозиторіїв, вам слід ввести наступне: Отже, як же зрозуміти, що маршрути робочі? Що ж, настав час перевірити їх на практиці! Тестування за допомогою Curl Ви можете надіслати запит за допомогою будь-якої мови програмування. JavaScript може використовувати методи на кшталт Fetch API або JQuery`s Ajax Method. Рубі використовує інше. І так далі. У цій статті я використовуватиму таку утилітку, як Curl. Справа в тому, що вона вказана в офіційній документації для веб-сервісів. Якщо ви зрозумієте, як використовувати цю утиліту, ви зрозумієте, як працювати з API. Після чого ви можете робити запити будь-якою зручною для вас мовою. Перед тим, як продовжити, слід переконатися, що Curl встановлений на вашій машині. Якщо ж він не встановлений, саме час встановити. У такому разі ви отримаєте помилку "command not found". Для того щоб використовувати утиліту, необхідно ввести наступне (за прикладом): І як тільки ви підтверджуєте введення, ви отримуєте відповідь (на зразок цього): Щоб отримати список користувацьких репозиторіїв, вам слід змінити запит за тим же принципом, який був обговорений раніше. Наприклад, щоб отримати список моїх репозиторіїв, вам слід ввести наступне: Якщо ж ви бажаєте включити параметри запитів, переконайтеся, що ви їх екрануєте. Справа в тому, що без екранування знаки питання і рівності розцінюються системою як спецсимволи і виконання команди відбудеться з помилкою. Також спробуйте інші команди та зробіть запити! В результаті ви отримуєте схожі відповіді. JSON JSON – JavaScript Object Notation – загальний формат для надсилання та прийому даних за допомогою REST API. Відповідь, що відправляється Github, також міститься у форматі JSON. Зміст об'єкту цього формату приблизно наступний: Повертаємось до анатомії запиту. Ви вивчили, що запит складається із чотирьох частин: Маршрут відправки. Тип методу. Заголовки. Тіло (або дані). Тепер давайте спробуємо розібратися з рештою. Тип методу Метод позначає тип запиту, який здійснюється; де-факто він є специфікацією операції, яку повинен здійснити сервер. Усього існує п'ять типів запитів: GET POST PUT PATCH DELETE GET – використовується для отримання з боку серверу певного ресурсу. Якщо ви здійснюєте цей запит, сервер шукає інформацію та відправляє її вам назад. По суті, він здійснює операцію читання на сервері. Дефолтний тип запитів. POST – необхідний для створення певного ресурсу на сервері. Сервер створює в базі даних нову сутність та сповіщує вас, чи був процес створення успішним. По суті, це операція створення. PUT та PATCH – використовуються для оновлення певної інформації на сервері. У такому разі сервер просто змінює інформацію існуючих сутностей у базі даних та повідомляє про успіх виконання операції. DELETE – як і випливає з назви, видаляє вказану сутність із бази чи сигналізує про помилку, якщо такої сутності в базі не було. Сам же API дозволяє вказати, який метод має бути використаний у певних контекстних ситуаціях. GET запит у цьому випадку необхідний, щоб одержати список всіх репозиторіїв зазначеного користувача. Також можна використовувати curl: Спробуйте надіслати цей запит. Як відповідь ви отримаєте вимогу про аутентифікацію. Заголовки Заголовки використовуються для надання інформації як клієнту, так і серверу. Взагалі, їх можна використовувати для багато чого; наприклад, та сама автентифікація та авторизація. На офіційній сторінці MDN можна знайти список доступних заголовків. Заголовки являють собою пари ключів-значень. Приклад: Також приклад із використанням curl: (Примітка: заголовок Content-Type у випадку Github для роботи не є обов'язковим. Це всього лише приклад використання заголовка в запиті, нічого більше). Для перегляду надісланих заголовком даних можна використовувати наступне: Тут зірочка відноситься до додаткової інформації, наданої за допомогою curl. > відноситься до заголовків запиту, а <, відповідно, - до заголовків відповіді. Щоб надіслати інформацію з curl, використовуйте наступне: Для відправки множинних полів ми можемо використати декілька подібних конструкцій: Також, якщо необхідно, ви можете розбити ваш запит на декілька ліній для забезпечення більшої читабельності: Якщо ви знаєте, як розгорнути сервер, ви можете створити власний API та протестувати свої запити. Якщо ж ні, обов'язково спробуйте. Існує безліч інформації, присвяченої цьому. Якщо ж бажання розгортати свій сервер немає, спробуйте безкоштовну опцію Request bin. Після чого ви отримаєте адресу, яку спокійно зможете тестувати. Переконайтеся, що ви створюєте власний request bin, якщо ви хочете протестувати саме ваш запит. Зважайте на те, що дефолтний час існування request bin – 48 годин. Тому ті приклади адрес, які я тут наводжу, на момент прочитання статті давно застаріли. Тепер спробуйте надіслати деяку інформацію, після чого оновіть свою сторінку. Якщо все пройде успішно, ви побачите наступне: За замовчуванням curl відправляє дані так, ніби вони були відправлені за допомогою полів форм. Якщо ви бажаєте надіслати дані через JSON, ваш Content-Type повинен дорівнювати application\json, внаслідок чого вам необхідно відформатувати дані у вигляді JSON-об'єкту. По суті, це все, що вам необхідно знати про структуру запиту. Тепер давайте згадаємо про аутентифікацію. Що ж це таке і навіщо вона потрібна? Аутентифікація Ви б не дозволили нікому чужому отримати доступ до вашого банківського рахунку без спеціального дозволу, чи не так? За таким же принципом розробники не дозволяють неавторизованим користувачам робити на сервері все, що їм заманеться. Оскільки POST, PUT, PATCH, DELETE запити змінюють базу даних, розробники повинні завжди бути на варті неавторизованого доступу до них. Проте іноді GET запити також вимагають аутентифікації (наприклад, коли ви хочете переглянути стан вашого банківського рахунку). У випадку з вебом існує два способи представитися системі: Через нік і пароль (базова автентифікація) Через секретний токен Секретний токен дозволяє представити вас системі через соцмережі на кшталт Github, Google, Twitter і так далі. Тут же я розгляну лише базову автентифікацію. Для виконання базової аутентифікації ви можете використовувати наступне: Спробуйте залогінитися під свій профіль за запитом, вказаним вище. Як тільки ви успішно увійдете у свій профіль, ви побачите відповідь "problems parsing JSON". Чому? Все просто: системі ви представилися, але - от біда - нічого корисного їй не надали. Усі типи запитів потребують певної інформації. Тепер же давайте поговоримо про статус-коди та можливі помилки. Статус-коди та можливі помилки Деякі з повідомлень, наведених вище, якраз і належать до кодів помилок. Логічно, що вони з'являються лише тоді, коли щось іде не зовсім так, як було заплановано. Що ж до статусу кодів, вони дозволяють вам пізнати успіх (або невдачу) під час виконання певного запиту. Бувають статус-коди від 100 до 500+. Загалом їх можна поділити на такі групи: 200+: запит успішний 300+: запит перенаправлений на інший маршрут 400+: помилка на стороні клієнта 500+: помилка на стороні сервера Ви можете відлагодити статус відповіді за допомогою –v або –verbose. Наприклад, я спробував отримати доступ до певного ресурсу без авторизації. Відповідно, я спіймав помилку: У випадку ж, коли запит невірний через помилку в самій інформації, що передається, ви отримуєте статус-код 400: Версії API Час від часу розробники оновлюють свої API. Іноді оновлення можуть бути такими сильними, що розробник бажає здійснити реліз нової версії. У такому випадку, якщо ваш застосунок ламається, це відбувається через те, що ви писали код з урахуванням старого компонента, тоді як новий дещо відрізняється в плані реалізації. Запросити поточну версію API можна двома шляхами. Через маршурт Через заголовок Наприклад Твіттер використовує перший спосіб. На момент написання версія Twitter API була 1.1. Водночас GitHub використовує інший спосіб: На закінчення У цій статті ми розглянули, що таке REST API і як його можна використовувати спільно з curl. Крім того, ви також вивчили, як залогінитись за допомогою запиту і що таке статус-код. Я щиро сподіваюся, що ця стаття дозволила вам підвищити свій рівень загальних і не дуже знань щодо такого важливого аспекту веб-розробки. Буду радий будь-яким вашим коментарям тут. Автор перекладу: Євген Лукашук Джерело Ще більше матеріалів на цю тему: ASP.NET Core Web API. Практичний курс ASP.NET WEB API 2 REST API в Node.js  JAX-RS Client API. Asynchronous REST Створення API на PHP та JavaScirpt

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 и прочие. Азат обожает все, что связано с технологиями и финансами, так же увлекается инновационными способами обучения и просвещения людей. Автор перевода: Евгений Лукашук Источник

Навіщо потрібний гарний баг-репорт? Які якості гарного баг-репорту у розробці програмного забезпечення? Характеристики та методи для повідомлення про баг Ефективний баг-репортинг Простий шаблон баг-репорту Важливі фічі у вашому звіті про помилки Номер помилки/ідентифікатор Найменування помилки Пріоритет Платформа/Середовище Опис Кроки для відтворення помилки Очікуваний та фактичний результат Скріншот Додаткові поради для написання гарного баг-репорту Висновок Навіщо потрібний гарний баг-репорт? Баг репорт це звіт про помилки. І якщо його складено правильно, то шанси на швидке виправлення цих багів вищі. Таким чином, виправлення помилки залежить від того, наскільки якісно ви про неї повідомите. Складання звітів про помилки - не що інше, як навичка, і зараз ми розглянемо, як її сформувати. "Сенс написання звіту про проблеми (баг-репорту) полягає в тому, щоб виправити ці проблеми" - Cem Kaner. Якщо тестувальник не повідомляє про помилку правильно, програміст, швидше за все, відхиляє цю помилку, заявивши, що вона невідтворювана. Це може нашкодити робочому настрою тестувальників, зачепити їх професійну гордість, їх его. Які якості гарного баг-репорту у розробці програмного забезпечення? Будь-хто може скласти приклад баг репорту. Але не кожен може написати ефективний баг-репорт. Ви повинні вміти добре розрізняти баг-репорт середньої якості та гарний баг-репорт. Як відрізнити гарний та поганий баг-репорти? Це дуже просто – застосуйте наступні характеристики та методи, щоб якісно повідомити про помилку. Характеристики та методи включають в себе: 1) Наявність чітко визначеного номера помилки: Завжди надавайте унікальний номер кожному повідомленню про помилку. Це, у свою чергу, допоможе вам чітко ідентифікувати запис про помилку. Якщо ви використовуєте будь-який інструмент автоматичного формування баг-репортів, цей унікальний номер буде генеруватися автоматично кожного разу, коли ви робите звіт. Запишіть номер та короткий опис кожної помилки, про яку ви повідомили. 2) Відтворюваність: Якщо знайдена вами помилка невідтворювана, вона ніколи не буде виправлена. Ви повинні чітко вказати кроки для відтворення помилки. Не приймайте та не пропускайте жодного кроку відтворення. Помилку, яка описана крок за кроком, легко відтворити та виправити. 3) Будьте конкретні: Не пишіть нарис про проблему. Пишіть конкретно і по суті. Спробуйте описати виявлену проблему мінімальною кількістю слів та максимально ефективним способом. Не поєднуйте описи кількох багів в одному звіті, навіть якщо вони здаються схожими. Напишіть різні звіти для кожної проблеми. Ефективний баг-репортинг Звіти про помилки є важливим аспектом тестування програмного забезпечення. Ефективний баг-репорт добре розуміється командою розробників і дозволяє уникнути плутанини чи непорозуміння. Гарний звіт про помилку має бути чітким і коротким, без будь-яких пропущених ключових моментів. Будь-яка відсутність ясності веде до непорозуміння та уповільнює процес розробки. Опис дефектів та складання звітів – одна з найважливіших, але часто ігнорованих областей у життєвому циклі тестування. Правильно складений текст звіту про знайдений баг є дуже важливим для реєстрації помилки. Один із важливих моментів, які повинен мати на увазі тестер, - це не використовувати командний тон у звіті. Такий тон порушує моральний стан колективу та створює нездорові робочі відносини. Використовуйте нейтральний тон. Не думайте, що якщо розробник припустився помилки, то ви можете використовувати грубі слова. Перш ніж повідомляти, не менш важливо перевірити, чи був баг-репорт за цією помилкою раніше, чи ні. Дублікати помилок – це постійна проблема у циклі тестування. Перевіряйте весь список виявлених багів. Іноді розробники можуть знати про проблему і ігнорувати її в майбутньому випуску. Використовуйте спеціальні інструменти, такі як Bugzilla, який автоматично шукає дублікати помилок. Тим не менш, найкраще додатково вручну шукати дублікати помилок. Чітко вказуйте інформацію про помилку: «Як?» і «Де?". Звіт повинен ясно показувати, як було виконано тест і де саме стався дефект. Читач звіту повинен легко відтворити помилку та знайти її. Майте на увазі, що мета написання баг-репорту – дати розробнику можливість візуалізувати проблему. Він повинен чітко розуміти суть дефекту, прочитавши звіт про помилку. Не забудьте надати всю необхідну інформацію, яку розробник шукає. Крім того, майте на увазі, що звіт про помилки буде збережено для майбутнього використання і він повинен бути гарно написаний та містити необхідну інформацію. Використовуйте змістовні речення та прості слова, щоб описати знайдені помилки. Не використовуйте заплутані твердження, які витрачають час читача. Повідомляйте про кожну помилку як про окрему проблему. У разі опису кількох багів в одному звіті, ви не зможете закрити його, доки всі проблеми не будуть вирішені. Таким чином, краще за все розбити великі проблеми на окремі баги. Це гарантує, що кожна помилка може бути оброблена окремо. Добре написаний баг-репорт допомагає розробнику відтворити помилку у своєму терміналі. Це також допомагає їм правильно діагностувати проблему. Простий баг репорт шаблон Це проста форма баг-репорту. Його зміст може змінюватись в залежності від використовуваного вами інструменту для створення звітів про помилки. Якщо ви пишете баг-репорт вручну, необхідно згадати деякі поля, наприклад номер помилки, який повинен бути призначений вручну. Укладач звіту: Ваше ім'я та адреса електронної пошти. Продукт: У якому продукті ви знайшли цю помилку. Версія: Версія продукту з помилкою, якщо така є. Компонент: Основні підмодулі продукту. Платформа: Вкажіть апаратну платформу, де ви виявили цю помилку. Різні платформи, такі як "ПК", "MAC", "HP", "Sun" і т. д. Операційна система: Вкажіть усі операційні системи, у яких ви виявили помилку. Операційні системи, як-от Windows, Linux, Unix, SunOS, Mac OS. Згадайте різні версії ОС, такі як Windows NT, Windows 2000, Windows XP і т. д., якщо це можна застосувати. Пріоритет: Коли потрібно виправляти помилку? Пріоритет зазвичай встановлюється від P1 до P5. P1 слід розуміти як "виправити помилку з найвищим пріоритетом" і P5 - "виправити, якщо дозволяє час". Серйозність помилки: Визначає вплив помилки. Типи Серйозності помилки: Блокувальник (Blocker): подальша робота з тестування неможлива. Критична (Critical): збій застосунку, втрата даних. Major: серйозна втрата функціональності. Minor: незначна втрата функціональності. Незначна (Trivial): деякі поліпшення інтерфейсу користувача. Поліпшення (Enhancement): запит нової функції або деякого покращення існуючої. Статус помилки: Коли ви реєструєте помилку в будь-якій системі відстеження помилок, за замовчуванням статус помилки буде «Новий». Пізніше помилка проходить через різні етапи, такі як "Виправлено", "Перевірено", "Повторно відкрито", "Не виправлено" тощо. Призначити розробнику: Якщо ви знаєте, який розробник відповідає за той конкретний модуль, в якому виникла помилка, ви можете вказати адресу електронної пошти цього розробника. В іншому випадку залиште це поле порожнім, оскільки це надасть полю авторства помилки значення власника модуля, якщо менеджер не призначить помилку розробнику. URL: URL-адреса сторінки, на якій сталася помилка. Коротке резюме: Додайте короткий опис помилки. Орієнтуйтесь на 60 слів або менше. Переконайтеся, що складене резюме відображає проблему та місце, де вона знаходиться. Опис: Детальний опис помилки. Використовуйте такі поля для поля опису: Відтворювані кроки: чітко згадайте кроки для відтворення помилки. Очікуваний результат: як додаток має поводитися на вказаних вище етапах. Фактичний результат: який фактичний результат виконання вищезгаданих кроків, тобто поведінка помилки. Це важливі кроки у звіті про помилки. Ви також можете додати "Тип звіту" як ще одне поле, яке описуватиме тип помилки. Типи звітів включають в себе: Помилка в коді Помилка проєктування Нова пропозиція Проблема із документацією Апаратна проблема Важливі фічі у вашому звіті про помилки Розглянемо кілька складових звіту про знайдений баг. Нижче наведено важливі елементи баг-репорту: 1) Номер помилки/ідентифікатор: Номер помилки або ідентифікаційний номер (наприклад, xyz007) значно спрощує складання баг-репорту та пошук місця помилки. Розробник може легко перевірити, чи виправлено конкретну помилку, чи ні. Це робить весь процес тестування та повторного тестування більш плавним та легким. 2) Найменування помилки: Заголовок помилки читається частіше, ніж будь-яка інша частина баг-репорту. Варто вказати в ньому все про те, що входить в баг. Назва помилки має бути досить осмисленою, щоб читач міг її зрозуміти. Чіткий заголовок помилки полегшує розуміння, і читач легко зможе перевірити, чи було повідомлення про помилку раніше і чи було її виправлено. 3) Пріоритет:  В залежності від серйозності помилки для неї може бути встановлений пріоритет. Помилка може бути Blocker, Critical, Major, Minor, Trivial або пропозицією щодо покращення функціоналу. Пріоритет помилки від P1 до P5 може бути заданий так, щоб найважливіші з них переглядалися першими. 4) Платформа/Середовище:  Вказівка ​​конфігурації ОС та браузера потрібна для більшої точності в баг-репорті. Це найкращий спосіб повідомити, як можна відтворити помилку. Без точної платформи або середовища програма може поводитися по-іншому, і помилка на стороні тестувальника може не повторюватися на стороні розробника. Тому краще чітко вказати середовище, в якому було виявлено помилку. 5) Опис:  Правильний опис помилки допомагає розробнику зрозуміти помилку. Він описує проблему, що виникла. Поганий опис створить плутанину та витратить час розробників і тестерів. Необхідно чітко повідомити про ефект в описі. Завжди корисно використовувати повні речення. Рекомендується описувати кожну проблему окремо. Не використовуйте такі терміни, як «я думаю» чи «я вважаю». 6) Кроки для відтворення помилки:  Гарний звіт про помилку має чітко вказувати кроки для відтворення. Кроки повинні включати дії, які спричиняють помилку. Не робіть загальних заяв. Будьте конкретні у наступних кроках. Гарний приклад правильно написаної покрокової процедури наведено нижче: Послідовність кроків: Виберіть продукт wer05. Натисніть на «Додати до кошика». Натисніть «Видалити», щоб видалити продукт із кошика. 7) Очікуваний та фактичний результат:  Опис помилки буде неповним без зазначення очікуваних та фактичних результатів. Необхідно описати в загальних рисах, який результат тесту і що очікував користувач у разі коректної роботи програми. Читач звіту повинен знати, який результат тесту буде коректним. Чітко згадайте, що сталося під час тесту і який був результат. 8) Скріншот: Одна картинка коштує тисячі слів. Зробіть скріншот із прикладом збою з відповідними виділеннями, щоб вказати дефект. Виділіть несподівані повідомлення про помилки світло-червоним кольором. Це привертає увагу до необхідної області. Деякі додаткові поради для написання гарного баг-репорту Нижче наведено деякі додаткові поради, щоб написати гарний звіт про помилку: 1) Негайно повідомте про проблему: Якщо ви виявите будь-яку помилку під час тестування, не потрібно чекати, щоб написати докладний звіт про помилку пізніше. Натомість напишіть звіт про помилку негайно. Це забезпечить гарну якість звіту та відтворюваність кроків отримання помилок. Якщо ви вирішите написати звіт про помилку пізніше, то є великі шанси пропустити важливі деталі в баг-репорті. 2) Відтворіть помилку тричі перед написанням баг-репорту: Ваш баг має бути відтворюваним. Переконайтеся, що ваші кроки досить чіткі, щоб відтворити помилку без будь-якої двозначності. Якщо ваша помилка не відтворюється щоразу, ви все одно можете помилитися, вказавши періодичну природу багу. 3) Протестуйте цю ж помилку на інших схожих модулях:  Іноді розробник використовує один і той самий код для різних схожих модулів. Таким чином, ймовірність того, що помилка в одному модулі виникне і в інших подібних модулях, вища. Ви навіть можете спробувати знайти серйознішу версію знайденої помилки. 4) Складіть гарне резюме помилки: Короткий опис помилки допоможе розробникам швидко проаналізувати природу помилки. Низька якість звіту надмірно збільшить час розробки та тестування. Правильно взаємодійте з вашим баг-репортом. Майте на увазі, що зведення про помилки використовується як довідкова інформація для пошуку помилки в інвентарі помилок. 5) Прочитайте декілька разів звіт про помилку, перш ніж натиснути кнопку «Надіслати»:  Прочитайте всі речення, формулювання та кроки, які використовуються у баг-репорті. Подивіться, чи не створює якесь речення двозначність, яка може призвести до неправильної інтерпретації. Слід уникати слів або речень, що вводять в оману, щоб скласти чітке повідомлення про помилку. 6) Не використовуйте образливих виразів:  Приємно, що ви зробили хорошу роботу і виявили помилку, але не використовуєте це для критики розробника чи нападок на будь-яку людину. Висновок Що таке баги? Це недосконалості ПЗ, з якими необхідно боротися, і один із головних помічників у цьому – репорти про помилки. Ми розглянули деякі особливості складання звіту про знайдений баг. Немає сумнівів, що ваш баг-репорт повинен бути якісним документом. Зосередьтеся на написанні гарних звітів про помилки і витратьте деякий час на виконання цього завдання, оскільки саме якісний баг-репорт є основною точкою зв'язку між тестером, розробником та менеджером. Менеджери зі свого боку повинні пояснити своїй команді, що складання гарного звіту про помилки є основним обов'язком будь-якого тестувальника. Ваші зусилля щодо написання гарного звіту про помилки не тільки збережуть ресурси компанії, але й створять гарні стосунки між вами та розробниками. Для кращої продуктивності команди намагайтеся написати якомога гарний звіт про помилки. З нашого боку для якісної підготовки тестувальників пропонуємо вам ознайомитися з курсом підготовки спеціаліста-тестувальника на ITVDN - Quality Assurance. За матеріалами статті.

В этой статье мы рассмотрим 25 наиболее часто встречающихся вопросов на интервью для новичков в программировании на Java. Все это реальные вопросы на собеседовании Java Junior Developer.   Можно ли в Java переопределить статический метод? Нет, статический метод в Java мы не можем переопределить. Мы можем только скрыть его. В Java статические методы - это те методы, которые можно вызывать без создания экземпляра класса. С другой стороны, если подкласс имеет ту же сигнатуру метода, что и базовый класс - это будет переопределением метода. Статический метод в Java не может быть переопределен по таким причинам: Статические методы - это те, которые принадлежат непосредственно классу. Они не принадлежат объекту, и при переопределении объект решает, какой метод должен быть вызван. Переопределение метода происходит динамически (во время выполнения), это означает, что определение того, какая версия метода будет использоваться происходит во время выполнения в соответствии с объектом, используемым для вызова, в то время как статические методы ищутся статически (во время компиляции). Когда вы запустите программу выше, вы получите следующий результат: Hello...Good morning Hello...Good morning Hello...everyone Согласно правилам переопределения методов, вызов метода разрешается во время выполнения по типу object. Таким образом, в нашем примере выше d.hello (), во втором вызове, должен вызывать метод hello () класса DisplayMessage, поскольку ссылочная переменная класса Display ссылается на объект DisplayMessage, но вызывает hello () самого класса Display. Это происходит потому, что выполнение статического метода разрешается во время компиляции. Таким образом, если статический метод у производного класса имеет ту же сигнатуру, что и статический метод базового класса, это будет называться сокрытием метода, а не переопределением метода. Можно ли выполнить перегрузку метода main() в Java? Достаточно распространенный по языку Java вопрос на интервью. Да, вы можете перегрузить метод main() в Java. В Java можно выполнить перегрузку метода main(), но когда мы запустим нашу программу, JVM будет искать общедоступный статический void main (String [] args) и выполнит этот метод. Перегрузка метода main() в Java: Когда вы запустите программу выше, вы получите такой результат: Inside main(String[] args) Видно, что метод main() у нас перегружен, но все же JVM вызывает метод с подписью public static void main (String [] args). Обратите внимание, что JVM считает var args public static void main (String... args) таким же, как public static void main (String [] args). Если мы хотим вызвать именно перегруженный метод, то вам нужно вызвать его из метода main с сигнатурой public static void main (String [] args). Например: Когда вы запустите программу выше, вы получите такой результат: Inside main(String[] args) Inside main(Integer args) Inside main(Integer arr) Как видите, мы вызвали перегруженные методы из main() с помощью аргумента String []. Можем ли мы в Java переопределить приватные методы? В Java мы не можем переопределить private методы, так как они видны только классу-владельцу. Каков базовый класс для всех классов в Java? java.lang.Object - это базовый класс для всех объектов. Можете ли вы перечислить некоторые важные методы из класса object? Среди важных методов класса object выделяют: hashcode - в качестве возвращаемого значения имеет хеш-значение объекта; equals - сравнивает ссылки на объекты; wait -  текущий поток ожидает, пока не будет вызвано notify или notifyAll; notify - пробуждает один поток, который ожидает блокировки; notifyAll - пробуждает все потоки, ожидающие блокировки; toString - обеспечивает представление объекта в виде строкового значения; clone - этот метод применяется для клонирования объекта; finalize - этот метод вызывается, когда объект подвергается обработке сборщиком мусора. Какие два метода вам нужно переопределить при помещении пользовательского объекта в качестве ключа для HashMap? Вам нужно будет переопределить методы hashcode() и equals() в пользовательском классе, помещая объекты пользовательского класса в HashMap.   В чем отличия в Java между HashMap и HashSet? HashMap В HashMap реализован интерфейс Map, который выполняет сопоставление некого ключа со значением. Он не синхронизирован и не является потокобезопасным. Не допускаются дублирующиеся ключи, а также null ключи и null значения. HashSet В HashSet реализован интерфейс Set, не допускающий дублирования значений. Он не синхронизирован и не является потокобезопасным. Выше employeeSet будет иметь 2 элемента, так как Set не допускает повторяющихся значений. Метод add применяется для добавления элементов в HashSet. Если этот метод возвращает true, тогда элемент добавляется успешно, но, если возвращается false – это значит, что вы пытаетесь вставить дублирующее значение. public boolean add(Object o) Одна из главных особенностей HashSet - объекты, которые мы собираемся добавить в HashSet, должны реализовывать методы Hashcode() и equals(), чтобы мы могли проверять наличие дублирующихся значений. Если мы добавляем пользовательские объекты в HashSet, то мы должны переопределить методы Hashcode() и equals() в соответствии с нашими потребностями. Если HashMap и HashSet не будут переопределены, объект будет принимать реализацию по умолчанию, что может быть нежелательно. HashMap vs HashSet:   Можем ли мы иметь абстрактный класс без какого-либо абстрактного метода в нем? Да, вы можете иметь абстрактный класс без создания какого-либо абстрактного метода.   Что вы знаете о переменной с модификатором transient? Когда вы будете ее использовать? Переменные с модификатором transient (нерезидент) применяются при сериализации. Если вы не хотите делать сериализуемую переменную, вы можете сделать ее переменной с модификатором transient. Transient переменная - это переменная, значение которой не будет сериализоваться во время сериализации объекта. А при десериализации - вы получите значение по умолчанию для этих переменных. Допустим, у вас есть класс Country, и вы не хотите сериализовать атрибут населения, поскольку он будет меняться со временем, поэтому вы можете объявить атрибут населения как transient, и он больше не будет сериализован.   Можете ли вы вызвать метод start() дважды в Java? Нет, вы не можете вызвать метод start() дважды. Это вызовет llegalStateException. После того как поток был запущен, он не может быть запущен снова. Если вы попытаетесь снова запустить поток, он выдаст исключение IllegalThreadStateException Давайте разберемся с помощью примера: Когда вы запустите программу выше, вы получите такой результат: Thread is runningException in thread "main" java.lang.IllegalThreadStateException at java.lang.Thread.start(Thread.java:705) at org.arpit.java2blog.StartThreadAgainMain.main(StartThreadAgainMain.java:16) Как вы можете видеть, когда мы пытались запустить поток во второй раз, он вызывал исключение IllegalThreadStateException. Если вы попытаетесь снова запустить поток, он выдаст исключение IllegalThreadStateException   Почему String неизменяемый (immutable) в Java? В Java класс String неизменяемый. Если вы возьмете словарное значение слова «immutable», это означает, что он не может быть изменен с течением времени, соответственно строка не может быть изменена в Java. Давайте разберемся с примером. Как видите, значение str1 не изменилось. Она создала другой объект String со значением «Hellojava2blog», но не изменил String str1. Это объясняет, что String является неизменяемым по своей природе. Теперь давайте разберемся, каковы потенциальные причины сделать String неизменной в Java. Пул строк: Если вы просто присваиваете значение String, используя двойные кавычки, это значение сохраняется в области, называемой строковым пулом, и на одну строку могут ссылаться многие ссылочные переменные. Если бы String оказался изменяемым, то это повлияло бы на все ссылающиеся на нее переменные. Потокобезопасность: Неизменяемые объекты по умолчанию являются потокобезопасными, поэтому вам не нужно устанавливать для них синхронизацию, и экземпляр String можно безопасно разделить между несколькими потоками. Безопасность: Если бы String был изменяемым, это могло бы привести к множественным проблемам безопасности. Например, при подключении к базе данных вы предоставляете имя пользователя, пароль, порт и имя хоста и т. д. в виде строки. Если бы строка - была изменяемая, то любой хакер мог бы изменить ссылочное значение, что было бы угрозой безопасности для приложения. Хэш-значение кэша: Когда вы используете String в качестве ключа в HashMap или HashSet или любой другой коллекции, вы можете кэшировать ее хеш-значение. Поскольку String является неизменяемым по своей природе, вам не нужно пересчитывать хэш каждый раз, поскольку он будет постоянным. Это значительно повышает производительность для этой коллекции на основе хеша. Загрузка классов: Строка используется в механизме загрузки классов. Она передается в качестве параметра. Если бы строка оказалась изменяемой, это вызвало бы прямую угрозу безопасности, поскольку любой хакер мог бы ее изменить.   Знаете ли вы, как сделать класс неизменным (immutable)? Можете ли вы предоставить шаги для этого? Неизменяемый класс - это класс, состояние которого нельзя изменить после создания. Пример: String - лучший пример неизменяемого класса. Создав строку, вы не сможете ее изменить. Неизменяемый класс очень прост для понимания, он имеет только одно состояние. Неизменяемые классы являются потокобезопасными. Это самое большое преимущество неизменяемого класса, потому что, - вам не нужно применять синхронизацию для неизменяемых объектов. Также, неизменяемый класс может быть полезен при помещении объекта неизменяемого класса в HashMap или может использоваться для целей кэширования, поскольку его значение не изменится. Неизменяемые объекты по умолчанию являются потокобезопасными. Шаги для создания неизменяемого класса: Финализируйте свой класс: Если вы финализируете свой класс - ни один класс не сможет его расширить, следовательно, не сможет переопределить методы этого класса. Пометьте все переменные класса модификаторами доступа private и final: Если вы сделаете переменную экземпляра private - ни один внешний класс не сможет получить доступ к переменным экземпляра, и, если вы сделаете их final - вы не сможете их изменить. Скажите «нет» методам-мутаторам: Не создавайте метод set для некоторых переменных класса, тогда не будет возможности явно изменить состояние переменных экземпляра. Выполните клонирование изменяемых объектов при возврате из метода получения: Если вы вернете клон объекта из метода get, то вернется объект. При этом, ваш оригинальный объект останется без изменений.   Можем ли мы иметь статический метод в интерфейсе? Да, у нас может быть статический метод в интерфейсе из Java 8.   Можете ли вы объявить конструктор финальным (final)? Нет, вы не можете объявить конструктор финальным.     В чем разница между StringBuffer и StringBuilder? Что такое Java ClassPath? ClassPath - это переменная окружения, которую виртуальная машина Java (JVM) использует для определения местоположения всех классов, используемых программой. Например: jre / lib / rt.jar имеет все классы Java, и вам также необходимо включить файлы jar или файл классов, которые используются программой.   У вас есть список пользовательских объектов? Как вы можете их отсортировать? Вам необходимо использовать интерфейс Comparable или Comparator для сортировки списка пользовательских объектов.   Что такое модификатор volatile в Java? Если вы пометите любую переменную как volatile, эта переменная будет считываться из основной памяти, а не из кэша  центрального процессора, поэтому каждый поток будет иметь обновленное значение в переменной.   Назовите два разных способа вызвать сборщик мусора? System.gc() или Runtime.getRuntime().gc().   Что такое маркерный интерфейс в Java? Можете ли вы привести несколько примеров маркерного интерфейса? Маркерные интерфейсы - это те интерфейсы, которые не содержат в себе никаких методов и полей. Примерами интерфейсов маркеров являются: Serializable, Cloneable, Remote.   Сколько объектов будет создано ниже: String str1= new String("John"); String str2= new String("John");   Здесь будут созданы три объекта, два в динамической памяти и один в постоянном пуле String.   Можете ли вы провести различие между проверяемым исключением (Checked Exception) и непроверяемым исключением (Unchecked Exceptions)? Что такое исключение? Исключением является нежелательная ситуация или условие при выполнении программы. И если вы неправильно обрабатываете исключение, то это может привести к аварийному завершению программы. Что такое проверяемое исключение? Проверяемые исключения - это те исключения, которые проверяются при компиляции. Если вы не обработаете их, вы получите ошибку компиляции. Используя блок try и catch вы можете поместить код ошибки в блок try и перехватить исключение в блоке catch. Что такое непроверяемое исключение? Непроверяемые исключения - это те исключения, которые не проверяются во время компиляции. Java VM не будет «ругаться», если вы не обработаете такие исключения. Если вы выполните код выше вы получите: Exception in thread "main" java.lang.NullPointerException at org.arpit.java2blog.NullPointerExceptionExample.main(NullPointerExceptionExample.java:7)   В чем разница между ArrayList и LinkedList? Как вы решите, какой из них вам нужно использовать? Один из распространенных вопросов интервью: «В чем разница между ArrayList и LinkedList». Прежде чем мы действительно увидим различия, давайте кратко рассмотрим оба. ArrayList: ArrayList – является реализацией интерфейса List. ArrayList не синхронизирован (поэтому не является потокобезопасным). ArrayList реализован с использованием массива в качестве внутренней структуры данных. Его можно динамически изменять. LinkedList: LinkedList является реализацией интерфейса List и интерфейса Deque. LinkedList не синхронизируется. LinkedList реализован с использованием двусвязного списка в качестве внутренней структуры данных.   Свойство ArrayList LinkedList Внутренняя структура данных Использует динамический массив для хранения элементов внутри. Он использует дважды связанный список для внутреннего хранения элементов. Скорость выполнения Если нам нужно вставить или удалить элемент в ArrayList, это может занять O(n), так как он использует массив, и нам может потребоваться сместить элементы в случае вставки или удаления. Если нам нужно вставить или удалить элемент в связанном списке, это займет O(1), так как он внутренне использует двусвязный список. Поиск В ArrayList поиск выполняется быстрее, т.к. он использует массив, основанный на индексах. Сложность - O(1). Поиск в LinkedList идет медленнее, т.к. он использует двусвязанный список. Сложность равна O(n). Интерфейсы ArrayList реализует только интерфейс List, поэтому его можно использовать только как List. LinkedList реализует интерфейсы List, Deque, поэтому его можно использовать как List, Stack или Queue. Когда использовать ArrayList и LinkedList? Это на самом деле зависит от нашей потребности. Если нам требуется произвести большое количество вставок или удалений, то нам следует использовать LinkedList. Если у нас имеется мало вставок или удалений, но выполняется много поисковых операций, то тогда нам следует использовать ArrayList.   В чем разница между wait и sleep в Java? Один из распространенных вопросов на интервью Java разработчика: «В чем разница между wait и sleep в Java?». Прежде чем мы действительно увидим различия, кратко ознакомимся с обоими.     sleep vs wait:   Вы запустили три потока из основного потока. Вы должны убедиться, что основной поток завершился последним. Как вы это сделаете? Вы можете использовать Java Thread Join() для достижения этого сценария. Без использования метода Join:     Когда вы запускаете программу выше, вы получите следующий результат: Main thread ends here T2 in run method T1 in run method T3 in run method С помощью метода Join: Когда вы запустите программу выше, вы получите следующий результат: T2 in run method T3 in run method T1 in run method Main thread ends here Как видите, основной поток завершается последним в этом сценарии.     Итоги Мы с вами рассмотрели 25 распространенных вопросов на собеседовании на должность Junior Java Developer.  Конечно же, полноценная подготовка к собеседованию Java разработчика должна включать и практическую и теоретическую подготовку. Готовясь к собеседованию, имеет смысл с одной стороны подготовиться, используя различные наборы вопросов и ответов Java собеседований, а с другой стороны  - быть готовым к решению задач на собеседованиях Java. С нашей стороны, ITVDN.com предлагает комплексную программу подготовки Java разработчика, включающую в себя видео курсы по Java и сопутствующим технологиям.  Рекомендуем вам также ознакомиться с серией видео «Подготовка к собеседованию в IT компании. Вопросы и ответы. Хитрости. Трюки.»   По материалам статьи.

Види SQL запитів Типи SQL запитів за їх видами Створення та налаштування бази даних Приклади простих запитів SQL до баз даних SELECT INSERT UPDATE DELETE DROP Приклади складних запитів до бази даних MS SQL Висновки Кожен сайт в Інтернеті, будь-який проєкт, який обробляє значний обсяг інформації, змушений зберігати цю інформацію у тих чи інших базах даних (БД). Переважна більшість проєктів інформацію зберігають у БД реляційного типу, роблячи записи в різних подобах таблиць. Як внесення нових записів, так і звернення до наявних здійснюється завдяки використанню запитів, що складаються конструкціями SQL (structured query language) – непроцедурної декларативної мови структурованих запитів. У нашому випадку це означає, що, використовуючи конструкції SQL ми будемо звертатися до БД, повідомляючи, що потрібно зробити з даними, але не вказуючи яким саме способом це потрібно зробити. Фактично SQL є набором стандартів для написання запитів до БД. Остання чинна редакція стандартів мови SQL - ISO/IEC 9075:2016. Ґрунтуючись на вказаних стандартах мови SQL, ряд організацій випустили свої розширені версії стандартів зазначеної мови. Подібні версії іноді називають діалектами SQL. Варіанти специфікацій SQL розробляються компаніями та співтовариствами і служать, відповідно, для роботи з різними СУБД (Системами Управління Базами Даних) – системами програм, заточених під роботу з продуктами зі своєї інфраструктури. Найбільш застосовувані сьогодні СУБД, що використовують свої стандарти (розширення) SQL: MySQL — СУБД, що належить компанії Oracle. PostgreSQL — вільна СУБД, що підтримується та розвивається спільнотою. Microsoft SQL Server — СУБД, що належить компанії Microsoft. Застосовує діалект Transact-SQL (T-SQL). Діалекти SQL, які створюються, специфікуються і використовуються різними організаціями, мають як спільні риси, так і ряд відмінностей у можливостях розширень. Загальними рисами діалектів є основні конструкції, які застосовуються практично без відмінностей у багатьох реляційних БД. Основні відмінності діалектів полягають у відмінностях використаних типів даних, кількості, реалізації та детальних можливостей команд. Різні діалекти застосовують як різні набори зарезервованих слів, так і різні набори команд. Тут ми розглядатимемо запити, застосовуючи конструкції зі специфікацій діалекту T-SQL. Торкнемося класифікації SQL запитів. Виділяють такі види SQL запитів: DDL (Data Definition Language) – мова визначення даних. Завданням DDL-запитів є створення БД та опис її структури. Запитами такого виду встановлюються правила того, в якому вигляді різні дані будуть розміщуватися в БД. DML (Data Manipulation Language) – мова маніпулювання даними. До запитів цього типу входять різні команди, використовуючи які безпосередньо здійснюються деякі маніпуляції з даними. DML-запити потрібні для додавання змін до вже внесених даних, для отримання даних з БД, для їх збереження, для оновлення різних записів і для їх видалення з БД. До елементів DML-звернень входить основна частина SQL операторів. DCL (Data Control Language) – мова управління даними. Включає запити та команди, що стосуються дозволів, прав та інших налаштувань СУБД. TCL (Transaction Control Language) – мова управління транзакціями. Конструкції такого типу застосовують для керування змінами, які здійснюються з використанням DML-запитів. Конструкції TCL дозволяють нам проводити об'єднання DML запитів у набори транзакцій.   Основні типи SQL запитів за їх видами: Нижче ми розглянемо практичні приклади застосування SQL запитів для взаємодії з БД, використовуючи запити двох категорій – DDL та DML.   Створення та налаштування бази даних Нам потрібна буде для прикладів БД MS SQL Server 2017 та MS SQL Server Management Studio 2017. Розглянемо послідовність дій того, як створити запит SQL. Скориставшись Management Studio, спочатку створимо новий редактор скриптів. Щоб це зробити, на стандартній панелі інструментів оберемо «Створити запит», або скористаємось клавіатурною комбінацією Ctrl+N. Натискаючи кнопку «Створити запит» у Management Studio, ми відкриваємо тестовий редактор, використовуючи який можна виконувати написання SQL запитів, зберігати їх і запускати. Використовуємо для початку прості запити SQL, завдяки яким можна створити та налаштувати нову БД, щоб отримати можливість надалі з нею працювати. Створимо нову БД з ім'ям “b_library” для бібліотеки книг. Щоб це зробити, наберемо в редакторі такий SQL запит: CREATE DATABASE b_library; Далі виділимо введений текст і натиснемо F5 або кнопку "Виконати". У нас створиться БД "b_library". Усі подальші маніпуляції ми можемо провести із цією створеною нами БД. Для цього спочатку підключимося до цієї бази: USE b_library; У БД "b_library" створимо таблицю авторів "tAuthors" з такими стовпцями: AuthorId, AuthorFirstName, AuthorLastName, AuthorAge: CREATE TABLE tAuthors ( AuthorId                      INT                  IDENTITY (1, 1) NOT NULL, AuthorFirstName        NVARCHAR (20)        NOT NULL, AuthorLastName         NVARCHAR (20)    NOT NULL, AuthorAge                   INT                              NOT NULL ); Заповнимо нашу таблицю такими авторами: Олександр Пушкін, Сергій Єсенін, Джек Лондон, Шота Руставелі та Рабіндранат Тагор. Для цього використовуємо такий SQL запит: INSERT tAuthors VALUES ('Александр', 'Пушкин', '37'), ('Сергей', 'Есенин', '30'), ('Джек', 'Лондон', '40'), ('Шота', 'Руставели', '44'), ('Рабиндранат', 'Тагор', '80'); Ми можемо подивитися в «tAuthors» записи шляхом відправлення до СУБД простого SQL запиту: SELECT * FROM tAuthors; У нашій БД «b_library» ми створили першу таблицю «tAuthors», заповнили «tAuthors» авторами книг і тепер можемо розглянути різні приклади запитів SQL, якими ми зможемо взаємодіяти з БД. Приклади простих запитів SQL до баз даних. Розглянемо основні запити SQL. SELECT 1) Виведемо всі наявні у нас БД: SELECT name, database_id, create_date FROM sys.databases; 2) Виведемо всі таблиці у створеній нами раніше БД «b_library»: SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='BASE TABLE' 3) Виводимо ще раз наявні у нас записи за авторами книг зі створеної вище «tAuthors»: SELECT * FROM tAuthors; 4) Виведемо інформацію про те, скільки у нас є записів рядків у «tAuthors»: SELECT count(*) FROM tAuthors; 5) Виведемо з «tAuthors» два записи, починаючи з четвертого. Використовуючи ключове слово OFFSET, пропустимо перші три записи, а завдяки використанню ключового слова FETCH – позначимо вибірку наступних 2 рядків (ONLY): SELECT * FROM tAuthors ORDER BY AuthorId OFFSET 3 ROWS    FETCH NEXT 2 ROWS ONLY; 6) Виведемо з «tAuthors» всі записи із сортуванням в алфавітному порядку за першою літерою імені автора: SELECT * FROM tAuthors ORDER BY AuthorFirstName; 7) Виведемо з «tAuthors» дані, попередньо по AuthorId відсортувавши їх за спаданням: SELECT * FROM tAuthors ORDER BY AuthorId DESC; 8) Виберемо записи з "tAuthors", значення AuthorFirstName у яких відповідає імені "Александр": SELECT * FROM tAuthors WHERE AuthorFirstName='Александр'; 9) Виберемо з "tAuthors" записи, де ім'я автора AuthorFirstName починається з "се": SELECT * FROM tAuthors WHERE AuthorFirstName LIKE 'се%'; 10) Виберемо з "tAuthors" записи, в яких ім'я автора (AuthorFirstName) закінчується на "ат": SELECT * FROM tAuthors WHERE AuthorFirstName LIKE '%ат' ORDER BY AuthorId; 11) Зробимо вибірку всіх рядків із «tAuthors», значення AuthorId у яких дорівнює 2 або 4: SELECT * FROM tAuthors WHERE AuthorId IN (2,4); 12) Виберемо в "tAuthors" такий запис AuthorAge, значення якого - найбільше: SELECT max(AuthorAge) FROM tAuthors; 13) Проведемо вибірку з "tAuthors" по стовпцях AuthorFirstName та AuthorLastName: SELECT AuthorFirstName, AuthorLastName FROM tAuthors; 14) Отримаємо з "tAuthors" всі рядки, у яких AuthorId не дорівнює трьом: SELECT AuthorId, AuthorFirstName, AuthorLastName  FROM tAuthors WHERE AuthorId!='3'; INSERT INSERT – це вид запиту SQL, у разі застосування якого СУБД виконує додавання нових записів у БД. Додамо до «tAuthors» нового автора – Вільяма Шекспіра, 51 рік. Відповідно, у полі AuthorFirstName додасться Вільям, в AuthorLastName додасться Шекспір, в AuthorAge – 51. До AuthorId, у нашому випадку, автоматично додасться значення, інкрементоване відносно попереднього на 1. INSERT INTO tAuthors VALUES ('Уильям', 'Шекспир', '51'); Перевіримо: SELECT * FROM tAuthors;   UPDATE UPDATE – SQL запит, який дозволяє внести зміни або дописувати нову інформацію до тих записів, які вже існують. Внесемо коригування до шостого запису (AuthorId = 6). Значення змінимо для полів імені, прізвища та віку автора. UPDATE tAuthors SET AuthorFirstName = 'Лев', AuthorLastName='Толстой', AuthorAge = '82' WHERE AuthorId = '6'; Потім звернімося до БД, щоб вивести всі наявні записи: SELECT * FROM tAuthors; Ми бачимо зміни інформації в записі автора під номером 6. DELETE DELETE – SQL запит, виконуючи який у СУБД проводиться операція видалення певного рядка з таблиці в БД. Звернемося до "tAuthors" з командою на видалення рядка, де AuthorId = 5: DELETE FROM tAuthors WHERE AuthorId = '5'; Щоб побачити зміни, знову звернемося до бази для виведення всіх записів: SELECT * FROM tAuthors; Ми бачимо, що запис автора під номером 5 тепер відсутній у tAuthors і, відповідно, не виводиться з іншими записами. DROP DROP – ключове слово в SQL, яке використовується для видалення даних за допомогою запиту. Наприклад, видалення деякої таблиці з БД. Після розгляду ряду простих запитів до БД ми можемо повністю видалити нашу таблицю tAuthors, виконавши простий SQL запит: DROP TABLE tAuthors;    Далі розглянемо складні запити SQL. Приклади складних запитів до бази даних MS SQL Складні запити SQL представляють собою комбінації простих запитів. Виконуючись, прості запити повертають згруповані в проміжні таблиці набори даних. А складний запит уже маніпулює даними, отриманими завдяки простим «підзапитам». Складні запити отримуються такими способами: Переміщенням одного запиту в інший. В цьому випадку зовнішній вираз називатиметься основним запитом, а вкладений вираз - підзапитом. Застосування з SQL запитами різних операторів об'єднання результатів виконання підзапитів. Такі оператори називають реляційними. Розглянемо у SQL приклади складних запитів. Скористаємося нашою попередньою таблицею tAuthors та створимо додатково ще одну таблицю з книгами цих авторів – tBooks. У якості ідентифікатора авторів книг використовуємо значення AuthorId з "tAuthors", а назва книги - BookTitle. CREATE TABLE tBooks ( BookId             INT                  IDENTITY (1, 1) NOT NULL, BookTitle        NVARCHAR (20)        NOT NULL, Author             INT                     NOT NULL ); Заповнимо «tBooks» такими книгами: INSERT tBooks VALUES ('Руслан и Людмила', '1'), ('Кавказский пленник', '1'), ('Евгений Онегин ', '1'), ('Радуница', '2'), ('Преображение', '2'), ('Мартин Иден', '3'), ('Морской волк', '3'), ('Белый Клык', '3'); 1) Зробимо вибірку з БД усіх книг, у яких ім'я автора – «Александр»: SELECT BookId, BookTitle FROM tBooks WHERE Author = (SELECT AuthorId FROM tAuthors WHERE AuthorFirstName = 'Александр'); Отримаємо: 2) Зробимо вибірку даних із «tBooks» усіх книг, авторами яких є люди з іменами «Александр» або «Сергей»: SELECT BookTitle FROM tBooks WHERE Author = SOME(SELECT AuthorId FROM tAuthors WHERE AuthorFirstName IN ('Александр', 'Сергей')); 3) Зробимо вибірку за книгами з таблиці «tBooks», у яких імена авторів НЕ «Сергій» та НЕ «Олександр»: SELECT * FROM tBooks WHERE Author != ALL(SELECT AuthorId FROM tAuthors WHERE AuthorFirstName IN ('Александр', 'Сергей')); 4) Візьмемо таблицю «tBooks» і зробимо з неї вибірку всіх книг із зазначенням як імен, так і прізвищ авторів цих книг із «tAuthors»: SELECT tBooks.BookId, tBooks.BookTitle, tAuthors.AuthorFirstName, tAuthors.AuthorLastName FROM tBooks JOIN tAuthors ON tAuthors.AuthorId = tBooks.Author; Висновки Ми з вами розглянули декілька варіантів найпростіших і найскладніших SQL запитів. Звичайно цю статтю не варто розглядати ні як навчальний посібник, ні як вичерпний перелік можливостей запитів у T-SQL та інших діалектах. Її швидше за все можна вважати прикладом SQL запитів для початківців. Однак вона може бути для Вас відправною точкою. Існує набагато більше різних SQL запитів. Це і запити з циклічними конструкціями, і рекурсивні, і різна робота зі змінними, і інші види запитів та підзапитів. Якщо Ви хочете вивчити цю дуже важливу специфічну мову складання запитів до БД – можете пройти відповідні курси на нашому порталі ITVDN.com, обравши відповідний Вам діалект: Transact-SQL - https://itvdn.com/ru/video/ssms_tsql SQL Essential - https://itvdn.com/ru/video/sql-essential SQL Практикум - https://itvdn.com/ru/video/sql-workshop MySQL - https://itvdn.com/ru/video/mysql-essential PostgreSQL - https://itvdn.com/ru/video/postgresql

Здравствуйте, друзья! Все, кто выбирает для себя путь IT-разработки, проходят через традиционную последовательность действий: Выбор конкретной специальности. Определение необходимых к изучению языков и технологий. Непосредственное обучение + практика. Составление портфолио, в котором демонстрируется весь набор знаний и навыков, которым вы обладаете. Поиск работы согласно специальности. Последний, пятый пункт, является не менее важным, чем предыдущие. В наше время поиск работы ведется в основном с помощью сети Интернет. Следовательно, возникает потребность в использовании проверенных веб-сайтов, на которых вас не введут в обман. Также, ресурс должен быть дружелюбным к пользователю, иметь интуитивно понятные механизмы поиска работы и выдавать вам те вакансии, которые вы ищете. Мы подготовили для вас список самых эффективных ресурсов поиска работы в IT секторе, которым можно доверять, и которые при этом удобны в использовании. Информация о каждом сервисе будет структурирована в следующем виде: особенности сервиса; аналитика уровня зарплат определенных специалистов и частота ее обновления; возможность подписки и отслеживания вакансий по определенной категории; наличие дополнительной информации о компаниях, которые размещают вакансии; наличие вакансий для начинающих и стажеров; количество открытых вакансий на текущий момент; контингент работодателей (отечественные/зарубежные); предложения на релокейт; удобство использования сервиса. Этих показателей должно быть достаточно, чтобы по максимуму раскрыть возможности каждого рассматриваемого ресурса. Начнем!   DOU   Профессиональное сообщество разработчиков, запущеное Максимом Ищенко в 2005 году. Один из главных IT-ресурсов Украины, на котором публикуются новости, аналитические статьи и другая информация, связанная с IT индустрией. Также, ДОУ располагает форумом, где любой зарегистрированный пользователь может задать свой вопрос и получить развернутые ответы от множества IT-специалистов. Данный сервис имеет специальный раздел “Работа”, где каждый желающий может просмотреть список опубликованных вакансий как для программистов, так и для нетехнических специалистов, задействованных в IT. Заглавная страница с вакансиями выглядит следующим образом (на рисунке лишь ее часть):     Справа изображено ведущие компании и количество их вакансий (лишь часть компаний):     Перейдя к вакансии, вы увидете типичное описание компании и требования к кандидату. Откликнуться на предложение предлагают через Google, Facebook, GitHub, LinkedIn, Вконтакте, Twitter.     Как можно видеть из рисунка, каких-либо механизмов помощи в создании резюме на ДОУ нет — его оформление полностью и целиком возлагается на плечи соискателя работы. Перейдем к анализу ресурса согласно нашим пунктам. Аналитика уровня зарплат определенных специалистов и частота ее обновления. ДОУ имеет собственный зарплатный виджет, который составляется на основании зарплатного опроса. Результаты опроса публикуются раз в полгода (в декабре и июне-июле)     В виджете указываете город, интересующую вас должность и применяющийся язык программирования (если вакансия связана с программированием), затем имеете возможность наблюдать I квартиль, медиану и III квартиль заработной платы: I квартиль - это значение з/п, ниже которого в упорядоченном по возрастанию массиве находится 25% данных о заработных платах; III квартиль - значение з/п, выше которого в упорядоченном по возрастанию массиве находится 25% данных о заработных платах; медиана - значение з/п, расположенное в середине изучаемого массива, который упорядочен по возрастанию. На вкладке “Динамика” можно наблюдать, как менялись зарплаты по самым популярным направлениям. К примеру, вот такая ситуация наблюдалась у JavaScript:      Вкладка ”По городам” отображает статистику зарплат по всем главным направлениям в крупнейших городах Украины (Киев, Львов, Харьков, Днепр, Одесса).     Последняя вкладка демонстрирует различного рода демографические показатели: пол разработчиков (в процентном соотношении), их возраст, опыт работы, уровень знания английского, город проживания, образование, размер и тип компании.    Также, ДОУ каждый год составляет портрет украинского IT-специалиста, в который входят такие показатели, как: город проживания, пол, опыт работы, профессиональный уровень разработчиков, количество компаний, в которых работали, причины выбора IT-специальности, самое важное при выборе работы, удовлетворенность зарплатой, оформление трудоустройства и другие показатели. Если вам интересно, можете ознакомиться с портретом украинского IT-специалиста за 2020 год. Дополнительная информация о компаниях, которые размещают вакансии. У каждой вакансии помечена компания-работодатель, нажав на иконку которой можно перейти на профиль этой компании на ДОУ и ознакомиться с ним. Таким образом вы без проблем можете просмотреть рейтинг этой компании (он есть не у всех), прочесть информацию о работодателе, просмотреть фотографии сотрудников, узнать расположение офиса, контактные данные и отзывы других людей о данном месте работы.  Возможность подписки на рассылку вакансий. Отсутствует, однако частично реализуется при помощи телеграм-канала “Junior дайджест dou.ua”, речь о котором пойдет ниже. Наличие вакансий для начинающих и стажеров. Сервис DOU располагает специальным разделом “Первая работа”, который находится на странице “Работа” в соответствующей вкладке. Он обновляется каждый месяц и содержит список актуальных курсов и вакансий для новичков, а также стажировки. Во внимание принимаются все крупные города Украины. Имеется в наличии и специальный телеграм-канал, который помогает следить за новинками на ресурсе.     Количество открытых вакансий. На момент написания статьи на сайте ДОУ размещено более 7000 вакансий. Карантинные меры довольно ощутимо ударили по количеству предложений от работодателей в 2020, но сейчас количество предложений не то что достигло уровня начала 2020-го года, а даже перепрыгнуло его. Контингент работодателей. Точной информации нет, однако подавляющее большинство работодателей из Украины. Также присутствуют и иностранные компании. Предложения на релокейт. На странице вакансий в ДОУ в самом верху можно найти фильтр быстрого перехода “Работа за рубежом”. Удобство использования сервиса. В целом, данный ресурс достаточно информативен и комфортен в использовании. Полноценный сервис, на котором украинский разработчик может найти практически все необходимое: различные статьи, портрет и зарплаты разработчиков, вакансии, опросы, рейтинги IT-компаний и многое другое. Можно создать свою тему и узнать мнение других разработчиков касательно какого-либо вопроса. При первых посещениях сайта разбегаются глаза от его насыщенности информацией, однако, со временем к этому привыкаешь и начинаешь быстро находить искомое.   Djinni     Djinni (он же “Джинни”, “Джинн”) - ресурс, позиционирующий себя как сервис анонимного поиска работы для программистов, тестировщиков, UI/UX дизайнеров, специалистов DevOps, PM-ов и всех тех, кто работает в сфере IT. Был запущен в 2012 году в качестве части ресурса dou.ua, однако затем обрел собственный домен. Как Джинн работает. Соискатель размещает заявку на сайте, не раскрывая при этом своей личности. В ней указываются такие параметры, как: категория (специализация), имеющийся опыт работы, зарплатные ожидания, желаемая должность, уровень владения английским языком, варианты занятости, города для поиска работы, ключевые слова для рекрутера. После заполнения и публикации профиля просто ждёте, пока на вас выйдет работодатель. Получается эдакий поиск работы наоборот — ищете не вы, а вас. Однако, рекрутеры также могут размещать вакансии, на которые вы вольны отзываться, не раскрывая своей личности. Сам соискатель ничего никому не платит, в то время, как работодатель в случае успешного найма обязан заплатить 25% от месячной зарплаты кандидата, по факту выхода на работу. Оплата не требуется лишь в том случае, если на работу принимается специалист уровня Junior. Аналитика уровня зарплат определенных специалистов и частота ее обновления. Джинн располагает собственным виджетом зарплат, который собирает необходимую статистику автоматически путем подсчета, сколько предложений получил кандидат и на какую зарплату. К примеру, если FrontEnd разработчик в Киеве с з/п $2500 получил 10 предложений, то он будет посчитан 10 раз. Если предложений не было, то и в статистику он не попадет. Сама статистика обновляется раз в сутки и наочно демонстрирует динамику рынка.     Рассмотрим рисунок выше (с изображением статистики по .NET разработке). Над каждым столбиком диаграммы показано общее количество предложений. Это не количество вакансий, а показатель уровня спроса. Чем больше предложений, тем больше компаний пытаются нанять такого специалиста. На диаграмме приведены данные за последние 6 месяцев активности на Джинни. Сам виджет имеет несколько фильтров: город, категория (специализация), опыт работы и уровень знания английского, что позволяет настраивать и просматривать статистику согласно личным предпочтениям. Также данный сервис способен отправлять вам на почту статистику по выбранной специальности и городу — так называемая зарплатная рассылка. Это позволит быть в курсе з/п в IT и понимать, во сколько примерно оценивается специалист из той или иной области. Дополнительная информация о компаниях, которые размещают вакансии. Сам Джинн не размещает дополнительную информацию о работодателях, однако в предложенных рекрутерами вакансиях зачастую можно отыскать ссылки на веб-сайты компаний.  Возможность подписки на рассылку вакансий. Раз в месяц Джинн присылает статистику зарплат и наймов по выбранной вами технологии и городу. Наличие вакансий для начинающих и для стажеров. Вакансии для начинающих имеются в небольшом количестве. Однако на Джинне новичкам будет тяжело. Таких людей очень много, а рекрутеры редко ищут неопытных разработчиков, поэтому надо составить хороший профиль, быть активным и откликаться на вакансии самостоятельно.  Чтобы не быть голословными, вот пример хорошо составленных профилей:     Количество открытых вакансий. На момент написания статьи на сайте Djinni размещено 14 417 вакансий. Контингент работодателей. Согласно данным 2017-го года, примерно 80% работодателей — украинские компании, остальные 20% — зарубежные (Европа, США). Предложения на релокейт. Джинн имеет телеграм-канал Трактор на Джинне, который специализируется на поиске relocate-вакансий, предусматривающих переезд в другую страну. На данный момент канал заморожен, а вместо него запущен бот для подписки на вакансии. С его помощью можно получать уведомления о подписках и новых сообщениях на Джинне, создавать подписки на вакансии, изучать статистику вакансий и зарплат. Удобство использования сервиса. Djinni — достаточно комфортный сервис, который имеет приятный современный интерфейс, лишенный ненужных деталей. Также в наличии удобная система фильтров, позволяющая определять зарплатную статистику и предложения от работодателей эффективно и быстро. Главная особенность Джинна — анонимность, что дает возможность искать работу не беспокоясь о раскрытии вашей личности, если вы в этом нуждаетесь. Несмотря на то, что главный акцент данный ресурс ставит именно на соискателей работы и их комфорт, он также будет полезен и работодателям. Дополнительно можете ознакомиться с бесплатным вебинаром “Джинн - сервис анонимного поиска работы для программистов”, в котором участвует сам создатель платформы Djinni — Максим Ищенко.   LinkedIn     Социальная сеть для делового общения, которая ориентирована на поиск сотрудников и вакансий. На данный момент в ней зарегистрировано более 645 млн пользователей из разных уголков планеты. Основные функции LinkedIn заключены в следующем: поиск контактов (знакомые, коллеги, рекрутеры, HR-ы, интересующие вас личности и т. д.) и установление с ними связи (расширение своей сети); отслеживание новостей по вашим интересам путем использования хештегов; непосредственный поиск работы; отслеживание вакансий путем подписки на интересующие вас компании; гибкое управление системой настроек различных уведомлений; публикация информации о деловых поездках, предстоящих профессиональных мероприятиях и другого профессионального контента; получение подтверждения ваших профессиональных навыков вашими коллегами; общение с другими пользователями сети; настройка собственного профиля, где указывается ваш карьерный путь, места обучения, профессиональные достижения и т. д.; возможность генерировать резюме на основании вашего профиля.   Аналитика уровня зарплат определенных специалистов и частота ее обновления. LinkedIn запустил собственную службу под названием LinkedIn Salaries. На данный момент она работает лишь для США, поэтому вы сможете посмотреть только американские зарплаты.  Дополнительная информация о компаниях, которые размещают вакансии. Данная социальная сеть, подобно сети Facebook, имеет странички компаний, на которых публикуются различные мероприятия, фотографии и новости. Возможность подписки на рассылку вакансий. Отслеживание вакансий возможно путем подписки на интересующие вас компании, а также при помощи хэштегов (#dotnet, #backend и т. д.). Наличие вакансий для начинающих и для стажеров. LinkedIn на странице поиска вакансий имеет фильтр “Должностной уровень”, в нем - опцию “Стажер”. После ее выбора вы сможете просматривать все вакансии, предусматривающие стажировку.  Количество открытых вакансий. На момент написания статьи количество открытых вакансий - более 12 млн. Количество открытых вакансий в регионе Украина — 155 301, Республика Беларусь — 34 329, регион Россия — 21 504, Казахстан — 12 974. Контингент работодателей. LinkedIn имеет многонациональное сообщество, которое включает в себя пользователей из 200 государств. Соответственно, работодателей можно найти практически в любой стране, где пользуется спросом данный ресурс. Предложения на релокейт. Поскольку данная социальная сеть с огромным мультинациональным сообществом, она в естественном порядке содержит вакансии, предусматривающие смену места проживания. Однако совершать поиск таких предложений необходимо вручную. Удобство использования сервиса. Несмотря на свою многофункциональность и обилие различных инструментов, LinkedIn все очень компактно совмещает и предоставляет солидный, а также удобный интерфейс. Каких-либо недостатков замечено не было. LinkedIn имеет все, что только может пожелать IT-разработчик, ищущий работу. Единственный нюанс — необходимо знание английского языка — сеть-то интернациональная. Также, существует мобильное приложение под Android и iOS, которое позволяет оперативно использовать LinkedIn с вашего гаджета. Напоследок козырь в рукаве этой соцсети: если вы программист уровня Middle+ и имеете более 400 контактов, можете забыть о других сайтах поиска работы, ведь вы не останетесь без внимания рекрутеров.   HeadHunter (Россия) / GRC (Украина)     HeadHunter (HH) — международный кадровый портал, разработанный в России в 2000 году. Несколько лет спустя было открыто украинское представительство компании. В 2019 году в связи с трансформацией бренда было принято решение о переименовании украинского сегмента ресурса на GRC (grc.ua). Согласно заявлениям владельцев, отличительной чертой GRC является то, что он создан усилиями профессионалов по подбору персонала. Также, ресурс дает возможность создать детализированное резюме при помощи специально разработанной формы. На самом деле по своему внешнему виду, функционалу и возможностям HH и GRC почти идентичны. Поэтому здесь мы будем говорить об обоих ресурсах сразу. Если они будут иметь какие-то различия, сделаем на этом акцент. Аналитика уровня зарплат определенных специалистов и частота ее обновления.  Отсутствует. Дополнительная информация о компаниях, которые размещают вакансии. Подобно ДОУ, данные ресурсы имеют странички компаний, публикующих вакансии. Перейдя по ссылке, можно прочесть краткую информацию о компании, а также подписаться на нее, тем самым постоянно отслеживая новые предложения от выбранного работодателя. Возможность подписки на рассылку вакансий. GRC и HH обладают такой возможностью. Для того чтобы получать по email-у новые вакансии, необходимо авторизоваться на сайте под своим логином и паролем. С помощью функции «Автопоиск» при поиске вакансий можно сохранять параметры запроса, а затем ежедневно отслеживать интересующие вакансии. Также можно подписаться на обновление предложений определенной компании, которая вас интересует. Наличие вакансий для начинающих и для стажеров. Ресурсы имеют фильтр “Нет опыта”, который выбирает для соискателя только те предложения, которые ориентированы на новичков с определенным уровнем знаний, но не имеющих опыта работы.  Количество открытых вакансий. HeadHunter. На момент написания статьи было отмечено 821 657 открытых вакансий. При этом количество оставленных резюме — 49 097 833. GRC. На момент написания статьи — 8201 открытая вакансия. При этом количество оставленных резюме — 1 594 886. Контингент работодателей. Если рассмотреть оба ресурса в совокупности, то наибольшее количество вакансий исходит из России. На втором месте по численности идет Украина и страны СНГ. За ними — множество стран из Азии, Африки, Южной и Северной Америки, Европы, однако количество их вакансий очень мало. Предложения на релокейт. GRC и HH не имеют специального фильтра для нахождения вакансий, предусматривающих смену жительства. Однако, можно выполнять фильтрацию по интересующим вас странам/областям/городам. Удобство использования сервиса. HH и GRC имеют приятный интерфейс и удобную систему поиска вакансий. Помимо айтишных там можно найти и множество других вакансий, что дает ресурсам большей универсальности и массовости.   Work.ua     Work.ua — один из лучших украинских ресурсов для поиска работы, который был запущен еще в 2006 году. В 2013 году была разработана удобная мобильная версия сервиса. Свою цель создатели Work.ua обозначают следующим образом: “Предоставлять самый лучших сервис поиска работы, чтобы помогать людям быть счастливее и развивать Украину ”. Ресурс содержит вакансии, ориентированные на широкий круг соискателей. Также на сайте публикуются новости рынка труда и небольшие информативные статьи — как аналитические, так и те, что носят рекомендательный характер. Новоприбывшему на Work.ua очень пригодится гайд по использованию сервиса, хотя и сам по себе сервис интуитивно понятен. Аналитика уровня зарплат определенных специалистов и частота ее обновления.  Данный сервис имеет собственную аналитику уровня зарплат по городам и профессиям. К примеру, по запросу “программист” вы можете увидеть следующую статистику:     Также, можно просмотреть среднюю зарплату, исходя из выбранной специальности:     Ознакомиться с более подробной статистикой можно здесь. Дополнительная информация о компаниях, которые размещают вакансии. Практически каждая вакансия закреплена за определенной компанией. Нажав на логотип компании, вы попадаете на небольшую страничку внутри сервиса Work.ua, которая содержит краткое описание работодателя, количество сотрудников, сферу предоставления услуг, контактные данные, ссылку на сайт компании и список вакансий. Возможность подписки на рассылку вакансий. Work.ua предоставляет рассылку вакансий на почту, а также в Telegram (бот @jobs_workua_bot). Обе достаточно удобны и информативны. К примеру, в телеграме вы получаете регулярные сообщения с новыми вакансиями, которые включают название должности, компанию-работодателя, город, зарплату (если такова заявлена) и ссылку на само предложение. Наличие вакансий для начинающих и для стажеров. На Work.ua есть специальный фильтр “Без опыта”, который выводит только те вакансии, которые ориентированы на новичков и стажеров. Также есть специальный раздел “Для студентов”, что может помочь найти подработку либо полноценную работу учащимся в вузе (даже с возможностью смены места проживания!).    Количество открытых вакансий. На момент написания статьи было отмечено 47 576 открытых вакансий. Также, согласно статистике сайта, его посещают 450 тыс. человек в день, он имеет 2.8 млн резюме и 100 тыс. работодателей. Контингент работодателей. Среди опубликованных 47 576 вакансий 926 ориентированы на работу за рубежом (в основном это Польша, Чехия, Словакия, Германия, балтийские страны и другие европейские государства). Предложения на релокейт. Некоторые вакансии из раздела “Работа в других странах” предусматривают смену места жительства, однако поиск таких предложений необходимо осуществлять вручную, ведь множество вакансий могут просто предлагать удаленную работу. Удобство использования сервиса. Work.ua имеет хороший дизайн в синих и голубых тонах. Он сразу дает понять, что здесь все заточено под пользователя. Использовать сервис приятно и удобно — ничто не вызывает диссонанса, как и в мобильной версии. Ресурс имеет гибкую систему поиска, которая предусматривает поиск вакансий по: категориям, городам, компаниям, должностям. Естественно, присутствует и расширенный поиск (фильтрация по опыту, категории, виду занятости, наличия инвалидности и т. д.). Work.ua подходит всем, кто ищет работу - как айтишникам, так и другим соискателям. В целом — хороший сервис для поиска работы с новостями, статьями, аналитикой и рассылкой вакансий на email и Telegram.   Хабр Карьера     Проект известного в СНГ сервиса под названием Хабр. Будучи запущенным в 2017 году, сегодня Хабр Карьера находится в фазе активного развития. Достаточно удобный ресурс, который позволяет находить как вакансии соискателям, так и специалистов работодателям. Аналитика уровня зарплат определенных специалистов и частота ее обновления. Аналитика присутствует во вкладке “Зарплаты”. Однако, она не позволяет произвести сегментацию по конкретным профессиям, а подается в виде среднего показателя по всем IТ специализациям за первое или второе полугодие, начиная со второго полугодия 2017 года.     Также присутствует опция “Диаграммы зарплат”. Как заявляют создатели, это инструмент для работы со статистикой по всем зарплатам в IT, которые были накоплены с момента запуска зарплатного калькулятора на Хабр Карьере. Здесь вы найдете готовые отчеты по основным IT-специализациям, квалификациям, языкам программирования и группам городов. Данные можно смотреть отдельно по полугодиям и в динамике с 2017 года. Единственный нюанс — просматривать диаграммы зарплат могут только зарегистрированные пользователи с созданным профилем компании, у которых есть размещенная вакансия или приобретен доступ к базе резюме. Дополнительная информация о компаниях, которые размещают вакансии. Сервис в удобной форме предоставляет всю важную информацию. Таким образом, вы можете узнать рейтинг компании на Хабр Карьера, просмотреть открытые и архивные вакансии, изучить информацию о сотрудниках компании, узнать о подписчиках и тех, кто хочет работать в данной компании, расположение офисов, контакты, полезные ссылки и общую информацию о компании. Возможность подписки на рассылку вакансий. Вы можете подписаться на интересующие вас компании и следить за их новостями. Также, есть возможность получать вакансии на почту в соответствии с заданным вами фильтром. Наличие вакансий для начинающих и для стажеров. Сервис имеет специальный фильтр “Квалификация” во вкладке “Вакансии” — для начинающих как раз подойдут пункты “Intern” и “Junior”.   Количество открытых вакансий. На момент написания статьи было зафиксировано 2022 размещенные вакансии. Контингент работодателей. В подавляющем большинстве работодатели из России. Также, есть небольшая украинская и белорусская диаспора. Предложения на релокейт. Имеются, но такие вакансии необходимо искать вручную. Удобство использования сервиса. Сервис очень удобен и приятен в использовании. Пользовательский интерфейс располагает всей необходимой информацией как для работодателя, так и для соискателя работы. Ничто не подвисает, любой фильтр обрабатывается достаточно быстро. Заметно, что создатели сервиса проделали хорошую работу для предоставления максимального комфорта своим юзерам.   dev.by   Сервис для белорусских айтишников, который является своеобразным братом украинского DOU. Является важным сервисом Беларуси, на котором распространяются новости, ведутся корпоративные блоги, публикуются вакансии, собирается аналитика зарплат в отечественном IT, а также предоставляется другая информация, связанная с данным сектором. Во вкладке “Зарплаты” заявляется, что на jobs.dev.by 1732 компании, 132 123 пользователя и 586 вакансий. Аналитика уровня зарплат определенных специалистов и частота ее обновления. На уже упомянутой вкладке “Зарплаты” присутствует хорошая аналитика зарплат со множеством фильтров: можно указать должность, промежуток времени, опыт работы, город, используемые в работе технологии и языки программирования. Согласно заданным критериям вы и получите информацию о заработной плате.     К примеру, выборка с критериями “2020 год”, “Software Engineer”, “Опыт от 3 до 7 лет”, “Минск” выдала такой результирующий график:   Также, вы можете просмотреть средний показатель зарплаты в IT практически за любой интересующий вас месяц. Дополнительная информация о компаниях, которые размещают вакансии. Компании имеют свои собственные “странички” на jobs.dev.by, где вы можете узнать такую информацию, как: общие сведения о компании, ее рейтинг согласно определенным параметрам, кол-во сотрудников и их отзывы, год основания компании, просмотреть фотогалерею (если работодатель размещал фото), контактные данные, официальные представители (со ссылками на их аккаунты), адрес, компании-соседи.  Возможность подписки на рассылку вакансий. Такая возможность присутствует. Вы можете описать свой опыт, ожидания от работы, пожелания по зарплате, а затем получать подходящие предложения и вакансии на электронную почту.   Наличие вакансий для начинающих и для стажеров. Сервис имеет фильтр “Junior”, который производит выборку вакансий, подходящих для потенциальных интернов и джунов. Количество открытых вакансий. На момент написания статьи было зафиксировано 586 размещенных вакансии. Контингент работодателей. В подавляющем большинстве работодатели из Беларуси. Предложения на релокейт. Необходимо искать вручную. Также, можно указать этот пункт в качестве пожелания во время оформления подписки на рассылку вакансий. Удобство использования сервиса. Сервис достаточно удобен, помимо вакансий и зарплатной аналитики предлагает различные новости и истории от разработчиков Беларуси. Интерфейс понятен, хотя и содержит много информации. Однако, к нему очень быстро привыкаешь и в краткие сроки начинаешь отлично в нем ориентироваться.   Заключение   В данной статье были рассмотрены самые лучшие ресурсы для поиска работы в IT в Украине, Беларуси, Россие. Затрагивались как локальные сервисы, так и один интернациональный. Мы постарались пройтись по всем самым важным пунктам и показать, насколько удобен и функционален тот или иной job-ресурс. Если вы опытный разработчик, то регистрируйтесь на LinkedIn, заполняйте профиль, расширяйте свою сеть общения и ждите предложений от рекрутеров. Если же вы новичок, то вам не помешает искать работу на всех отечественных ресурсах сразу, ведь кандидатов без опыта много, и каждый хочет свое место под солнцем. Надеемся, статья была полезной для вас. Пишите в комментариях свое мнение и задавайте интересующие вас вопросы!   Желаем вам здоровья и успехов! Оставайтесь с ITVDN!

Тип сайта и его тематика Функциональность сайта На сегодняшний день более половины всех сайтов в сети Интернет используют ту или иную систему управления контентом (Content Management System – CMS). Однако термин CMS не получил, к сожалению, четкого определения. Он может иметь несколько значений в зависимости от сценариев и целей человека или проекта. Некоммерческая международная организация AIIM (Association for Information and Image Management - Ассоциация по вопросам Управления Информацией и Изображениями) ввела в обиход понятия ECM (Enterprise Content Management) и WCM (система управления веб-контентом) как две составных части CMS.  В этом случае под ECM подразумевается программный комплекс, обеспечивающий документооборот, работу внутренней базы знаний и организующий в общем виде набор бизнес-процессов предприятия. Как одну из функций ECM может включать в себя и работу с веб контентом. Хорошим примером такого типа систем является платформа Microsoft SharePoint. В свою очередь WCM стало включать в себя набор инструментов в некотором комплексе, позволяющем управлять веб-сайтом и контентом на нем. Часто также CMS также называют «движком» сайта. В обиходе у разработчиков устоявшимся значением, подразумеваемым под CMS, является некоторая программная система, применяемая для создания, редактирования и управления контентом сайта и устанавливаемая на свой хостинг. В дальнейшем, в этой статье мы примем за основу именно это - последнее определение, более похожее на WCM. Стоит отметить и часто включаемые в число CMS так называемые SaaS решения (software as a service – услуга доступа к программному обеспечению). В случае такого типа услуг компании не предоставляют код, который вы можете скачать, установить и настроить под себя на своём хостинге. Провайдеры услуги SaaS предлагают для клиентов свои платформы, со своим хостингом, своими индивидуальными возможностями без предоставления CMS в обиходном понимании. При такой схеме вы фактически оплачиваете не владение вашим сайтом, а его аренду. В нашей статье мы не будем рассматривать такой тип услуг.   Рассмотрим подходы, которых следует придерживаться, решая вопрос как выбрать движок для сайта.   Критерии выбора CMS для вашего сайта Тип сайта и его тематика Большой выбор различных систем управления контентом на рынке объясняется различиями в типах сайтов, для которых лучше всего конкретная CMS подойдет. Будет это форум или интернет магазин, блог или корпоративный сайт, сайт-визитка или новостной портал – определенность с тематикой сайта это первое, от чего будет зависеть правильный выбор CMS. Функциональность сайта Не смотря на определенную специализацию каждой CMS под определенные задачи, на сегодняшний день для ТОП CMS существует огромное количество различных расширений (плагинов, модулей), существенно увеличивающих их функциональность и возможности «донастройки». К примеру существующими плагинами можно превратить «блоговый» движок в интернет-магазин, а на движке портала сделать форум. Однако нужно понимать, что большое количество дополнительных плагинов будут влиять и на быстродействие, и на безопасность, и на внутреннюю слаженность работы механизмов сайта, из-за возможных конфликтов этих расширений. Также определенный набор проблем может доставить и необходимость регулярных обновлений как самого движка, так и установленных плагинов. Без таких обновлений у вас будут открываться дыры в безопасности, а это вряд ли вам понравится. А обновление большого числа расширений может вызвать конфликты совместимости. Поэтому правильный выбор CMS это баланс между нужной готовой функциональностью движка «из коробки» и количеством (и качеством) установленных расширений. Исходя из задач и потребности в балансе, сложно однозначно ответить на вопрос «какая CMS лучше?». Требовательность к ресурсам Правильный выбор тематики сайта приводит к необходимости выбора условной «мощности» движка. «Мощнее», в нашем случае, вовсе не обязательно значит – «лучше». Если вы нуждаетесь, к примеру, в сайте-визитке, установка движка портала для вас будет избыточной. Значительная часть ресурсов мощной CMS останется не задействованной. При этом требования к хостингу такого сайта будут выше – вам понадобится больше оперативной памяти, больше ресурсов процессора, могут понадобиться некоторые специфические настройки сервера и предустановленное программное обеспечение. Также стоит понимать, что, к примеру, сайты администрации для поселка и для города миллионника хоть и имеют общую тематику, но будут иметь разный дизайн, функциональность, наполнение, разную посещаемость и, соответственно, разные требования. Поэтому, при выборе вам следует исходить и из масштабов вашего будущего сайта. Неправильный выбор выльется либо в необоснованное удорожание и хостинга, и администрирования вашего сайта, либо в нехватку ресурсов. Возможность кастомизации движка Многим владельцам сайтов не хватает возможностей «голой» CMS. Кроме того, из-за специфики каждого конкретно бизнеса и каждого конкретного сайта, возможности расширения с помощью дополнительных плагинов тоже может быть недостаточно. Может потребоваться индивидуальная доработка движка, тем оформления или доработка под заказчика тех плагинов, функциональности которых не вам хватает. В этом вопросе нам очень важно будет понимать следующие моменты: Количество разработчиков на рынке – специалистов по конкретной CMS; Количество и качество документации к CMS и плагинам; Развитость сообщества пользователей и разработчиков конкретной CMS. Можно с уверенностью сказать, что чем более распространён движок – тем больше доступных специалистов, тем проще внести нужные правки и тем дешевле эти правки обойдутся. Стоит уделить внимание и особенностям SEO-оптимизации конкретного движка. Если вы хотите, чтобы аудитория вашего сайта росла, вам придется соответствовать ряду правил, касающихся и скорости работы сайта на различных типах устройств, и внешнего дизайна сайта вообще и конкретных страниц в частности, и внутренней иерархии страниц, и правильной настройки индексации и т.п. Возможность проведения SEO оптимизации вашего сайта сложно переоценить.  Наличие уже встроенных в CMS SEO инструментов или доступных качественных плагинов, а также возможность доработки их под ваши нюансы проекта привлеченными разработчиками, будут очень важны на этапе продвижения вашего сайта. Стоимость CMS и доработки. На рынке сегодня присутствуют как качественные бесплатные, так и значительное количество различных платных CMS. Кроме того, выбирая бесплатные CMS, вам вероятно захочется добавить в них платные расширения.  Выбирая между платными и бесплатными вариантами вам стоит заранее определиться с несколькими моментами: Представить себе (хотя бы приблизительно) стратегию развития вашего сайта. От понимания дальнейших перспектив будет зависеть комбинация доступных расширений и необходимость их доработок. Может так сложиться, что выбор бесплатной CMS, с учетом плагинов и доработок для получения нужного функционала, окажется существенно дороже, чем купить платную CMS и платный плагин, получив при этом техническую поддержку разработчиков этой CMS. Также может оказаться, что нужный для вас плагин под конкретную CMS нужно будет разрабатывать с нуля, тогда как под другую CMS такой плагин есть уже готовый, давно выпущенный и протестированный в реальной работе.   Распространенность CMS и ее востребованность Если выбранный вами движок сайта окажется непопулярным и его разработчики решат перестать выпускать обновления, вы столкнетесь с рядом проблем. Это и падение уровня безопасности системы, и ухудшение внешней привлекательности на фоне новых сайтов-конкурентов, использующих новые технологические решения. Также существенно сложнее будет найти специалиста для внесения доработок в движок, использующий уже устаревшие и непопулярные технологии. В свою очередь выход новейшей версии движка может быть связан с кучей багов системы, наличия новых дыр безопасности, несовместимости со старыми плагинами и другими сложностями. Самописные движки Наличие такого числа сложностей при выборе системы управления для своего сайта может вызвать у вас желание заказать или написать свой сайт с нуля. Действительно, ряд проектов прямо потребует от вас такого подхода. Подключение к своим специфическим сервисам, интеграция с другими уникальными проектами, гибкость в дизайнерских и архитектурных решениях – в определенных обстоятельствах написание своего движка будет правильным решением. Однако стоит сразу учитывать набор проблем, с которыми вам предстоит столкнуться: Подсадка «на иглу» одного разработчика. Полноценно разбираться в куче кода, с слабо или вовсе недокументированными возможностями, сможет только сам автор кода. Новому разработчику может оказаться проще переписывать модули вашего сайта с нуля, чем тратить время на разбор чужого кода. Это с одной стороны существенно удорожит работу, а с другой жестко привяжет вас к конкретному разработчику. Даже сменив одного программиста на другого, вы оказываетесь в той же ситуации, только теперь с новым разработчиком. Сроки и цена разработки. Написание нужных модулей «с нуля» будет стоить значительно дороже и займет значительно больше времени, чем адаптация уже существующего движка и плагинов с хорошей документацией от авторов. Проблемы тестирования и ошибок. В движках, которые используют каждый день миллионы человек, есть значительный плюс – большинство багов выявляются мгновенно и быстро перекрываются обновлениями. Наличие багов в вашей самописной системе будет зависеть как от навыков вашего разработчика, так и от применяемых им технологий. Эта комбинация может нести большое количество скрытых проблем как работоспособности, так и безопасности, которые останутся не выловленными, пока не станет слишком поздно. В результате разработка своего движка оказывается выгодна, практически, только крупным компаниям со своими внутренними отделами разработки и тестирования, которые будут писать свой сайт и поддерживать его работоспособность независимо от сторонних разработчиков. Статистика использования CMS   По данным сайта w3techs.com более 55% всех Web-сайтов в Интернете управляются теми или иными CMS. Как видно из диаграммы более 33% всех сайтов в Интернете работают на движке WordPress. Фактически это более 60% от сайтов, управляемых теми или иными CMS. Следующие по популярности системы CMS: Joomla – 5.4%, Drupal – 3.5%, Magento – 1.8%, PrestaShop – 1.4%. Набравшие в этой диаграмме высокие места Shopify (2.7%), Squarespace (2.7%) и Wix (1.8%) предлагают услуги SaaS (которые мы здесь не рассматриваем). По данным портала WhatСms первое место по числу сайтов среди популярных CMS также принадлежит WordPress - 52.74%. Затем идут Joomla - 5.219%, Drupal - 3.953%, Magento - 2.840%, PrestaShop - 1.671%. Blogger, как и несколько компаний в предыдущей диаграмме, является SaaS платформой. По данным портала BuiltWith первые три места среди не SaaS CMS занимают: WordPress - 28.27%, Joomla – 26.93%, Drupal – 8.84%. По данным портала SimilarTech, предлагающего свой ТОП движков для сайтов, среди 9,5 млн сайтов на CMS также лидирует WordPress, заняв 68% рынка CMS. Слетом идет Drupal (версии 6 и ниже) – 4%, Joomla – 3%, Drupal 7 – 1%, Typo3 – 1%. В число других CMS вошли как SaaS решения, так и другие полноценные CMS, включая и Drupal 8. Проанализировав указанную статистику, мы выбрали следующий 6 ТОП CMS: WordPress, Joomla, Drupal, Magento, PrestaShop и Typo3. Проведем краткий обзор движков для сайтов, входящих в наш ТОП CMS.   1) WordPress Выпущенный впервые в 2003 году, CMS WordPress быстро завоевал популярность как у продвинутых разработчиков, так и простых пользователей. Благодаря простой настройке, не самой высокой требовательностью к ресурсам хостинга и огромному количеству расширений эта CMS уже многие годы занимает первое место. На сегодня именно WordPress называют лучшей CMS для блога. WordPress идеально подходит для довольно простых веб-сайтов, таких как ежедневные блоги и новостные сайты, и для тех, кто ищет для себя простую CMS. Дополнения позволяют легко расширять функциональность сайта. К примеру, благодаря плагину WooCommerce, из сайтов на движке WordPress получается удобный для управления интернет-магазин – один из самых распространенных вариантов интернет-магазинов в сети. Нужно отметить и большое количество SaaS решений, использующих на своей платформе этот движок. Часть успеха WordPress в представленных диаграммах без сомнения относится к SaaS решениям. Официальный сайт WordPress: https://wordpress.org/ Особенности WordPress: Последняя версия - 5.0.3 от 09.01.2019. Написан на PHP. Более старые версии чем 5.0 официально объявлены «небезопасными». Минимальные требования к хостингу, поддержку которых обещает разработчик: PHP 7.3 MySQL 5.6 или MariaDB 10.0; HTTPS; Apache или Nginx. Плюсы WordPress: Бесплатная CMS распространяется с открытым исходным кодом. Огромное количество как платных, так и бесплатных шаблонов, и плагинов. Удобная панель администратора. Простая CMS для пользователя. Отмечают простоту использования и легкость установки как движка, так и тем, и расширений. Большое сообщество. Достаточно высокая производительность. Доступные платные плагины с проверенным качеством. Минусы WordPress: Относительно не маленькая требовательность к ресурсам, особенно при установке значительного числа плагинов. Отсутствие технической поддержки в не SaaS вариантах. Многие плагины написаны некачественно, что создает проблемы в работе и дыры в безопасности. Сайты на WordPress взламывают чаще всего.   Для каких сайтов используют CMS WordPress: Популярность WordPress продолжает расти: При этом в Украине сейчас 34910 сайтов используют эту CMS, а в Российской Федерации - 297353.   2) Joomla CMS Joomla впервые увидела свет в 2005 году. Отражая философию этого движка, его назвали словом, звучащим на суахили как «всё вместе». Фактически разрабатываемая как CMS для порталов, Joomla позволяет создавать сайты с большей гибкостью контента и внутренней структуры, чем WordPress, но при этом с достаточно простым и интуитивно понятным интерфейсом. Эта CMS поддерживает электронную коммерцию, социальные сети и многое другое. Используя этот движок, разработчики создают сайты-визитки, интернет-магазины, фотогалереи, порталы (включая новостные), блоги и другие сайты. Рядом пользователей, Joomla признается лучшей CMS для сайта типа портал. Официальный сайт: https://www.joomla.org/ Особенности движка Joomla: Последняя версия – 3.9.3 от 12.02.2019. Написана на PHP и JavaScript. Минимальные системные требования: PHP 5.3.10; MySQL  5.1 или SQL Server 10.50.1600.1 или PostgreSQL 8.3.18; Apache 2.0 или Nginx 1.0 или Microsoft IIS 7. Плюсы Joomla: Бесплатное распространение с открытым исходным кодом по лицензии GNU GPL v2, включая обновления; Частое предоставление обновлений движка; Большое сообщество пользователей и разработчиков; Большое количество доступных платных и бесплатных тем и плагинов; Относительно не высокий уровень требований к разработчику и пользователю. Минусы Joomla: Отсутствие технической поддержки. Вторая CMS по числу взломов. Joomla применяется в следующих сферах: В Украине 907  сайтов используют эту CMS и 3800 сайтов - в Российской Федерации. Есть определенная тенденция по снижению популярности CMS Joomla: 3) Drupal Впервые вышедшая в 2000 году, CMS Drupal является мощным, удобным для разработчиков инструментом для создания сложных сайтов. Как и большинство мощных инструментов, Drupal требует определенных знаний и опыта для работы. На основе Drupal часто создают порталы, новостные сайты, форумы, интернет-магазины - одни из самых продвинутых сайтов. Тем не менее Drupal является самым сложным для пользователя движков из тройки лидеров. Хотя его использование с каждым выпуском и становится все проще, если вы не готовы погрузиться в изучение этого программного обеспечения или не можете нанять кого-то, кто его знает, возможно, это не лучшая система управления контентом для вас. Официальный сайт: https://www.drupal.org/   Особенности Drupal CMS: Последняя версия 8.6.10; Ядро предоставляет только минимальный функционал, нужный для работы CMS, остальной функционал добавляется за счет плагинов. Установка модулей происходит в связке. Если для реализации функционала какого-то модуля нужны другие модули – они установятся автоматически в связке с первым модулем. Минимальные требования к хостингу для CMS Drupal 8: PHP 5.x/7.x для x86 и PHP 5.x для x64; MySQL 5.5.3 или MariaDB 5.5.20, или Percona Server 5.5.8, или PostgreSQL 9.1.2, или SQLite 3.6.8; Microsoft SQL Server и MongoDB поддерживаются благодаря отдельным модулям; Apache 2.x (используется в качестве Web-сервера для Drupal чаще всего) или Nginx (0.7.x, 0.8.x, 1.0.x, 1.2.x), стабильная версия 1.8.x или 1.9.x. Плюсы Drupal: Бесплатная CMS с открытым исходным кодом GNU GPL 2+. Стабильная работа ядра движка. Большое количество бесплатных тем, и различных расширений. Достаточно развитое сообщество разработчиков. Для решения типовых задач есть готовые наборы плагинов. Drupal известен своей мощной таксономией и способностью отмечать, классифицировать и организовывать сложный контент. Минусы Drupal: Сложность использования для начинающих пользователей. Меньшее количество доступных бесплатных плагинов чем у предыдущих CMS. Отмечают большую требовательность к хостингу за счет более частых обращений движка к базе данных, чем у других движков. Сегодня эту CMS используют в 7110 сайтов в Украине и 45189 сайтов в Российской Федерации. Можно наблюдать определенное снижение интереса к этой CMS по сравнению с 2016 годом:   4) Magento CMS Magento — движок для интернет-магазинов и других вариантов электронной коммерции. В основном популярен в западных странах и слабо представлен в русскоязычной части Интернета из-за слабой интеграции с местными сервисами. В настоящий момент является собственностью Adobe Inc. В основном Magento используется для крупных проектов. Считается не рентабельным использовать его для магазинов с несколькими сотнями позиций в обороте из-за относительно высокой стоимости разработки. Официальный сайт: https://magento.com/. Особенности CMS Magento: Написан на PHP. Последняя версия 2.3.0 от 28.11.2018. Требования к хостингу: LAMP (Linux, Apache, MySQL, and PHP) или LNMP; Apache 2.x или Nginx 1.7.x; PHP 5.6 или 5.5 или 5.4; MySQL 5.6 (Oracle or Percona); HTTPS; Доступ к crontab и к записи в .htaccess. Плюсы Magento: Бесплатная система с открытым исходным кодом. Движок оптимизирован под требования поисковых систем «из коробки». Готовая функциональность движка в базовой версии. Являясь собственностью Adobe Inc., отлично поддерживает интеграцию с сервисами Adobe. Минусы Magento: Несмотря на открытый исходный код, многими разработчиками считается не удобным работать с этой CMS из-за особенности организации ее кода. В бесплатной версии нет технической поддержки, платная версия будет стоить несколько тысяч долларов в год. Отсутствует интеграция с платежными средствами и другими локальными сервисами на постсоветском пространстве. Низкая скорость загрузки страниц сайта «из коробки». Большая часть настроек сайта потребует специфических знаний и навыков.   В Украине на сегодня 1113 сайтов используют CMS Magento и 1774 используют ее в Российской Федерации. После 2016 года можно наблюдать некоторое снижение числа сайтов на этой CMS:    5) PrestaShop PrestaShop – это еще один пример простой CMS с открытым исходным кодом для создания интернет-магазина. Созданный в 2008 году, этот движок достаточно быстро обрел популярность и продолжает ее наращивать. Это достаточно простая бесплатная CMS создана для организации торговых площадок и интернет магазинов. Официальный сайт: https://www.prestashop.com Особенности PrestaShop: Текущая версия – 1.7.5.1 от 18.02.2019. Написан на PHP с применением фреймворка Symfony. Минимальные требования к хостингу: PHP 5.6; MySQL 5.0; Server RAM – чем больше, тем лучше; Unix, Linux или Windows; Apache 2.2 или Nginx 1.0 или Microsoft’s IIS Web server 6.0. Плюсы PrestaShop: Бесплатный движок с открытым исходным кодом. Большое количество доступных тем оформления и расширений. Достаточный для начала работы интернет-магазина стандартный набор базовой версии движка. Имеет отличную русскую локализацию. Богатый выбор модулей для развития интернет-магазина. Хорошая интеграция с различными сервисами на постсоветском пространстве. Простота установки и работы. Удобная интуитивно понятная панель администрирования. Базовая версия имеет хорошую SEO-оптимизацию. Активные сообщества разработчиков. Минусы PrestaShop: Качественные темы и расширения являются платными. Более требователен к ресурсам чем WordPress. Низкая безопасность у бесплатных тем и плагинов. Наблюдаются баги при проведении внутренней оптимизации. Можно видеть рост популярности CMS PrestaShop. Например, на сегодня уже 2461 сайт работает на этом движке в Украине, и 8423 сайтов - в Российской Федерации.    6) Typo3 Typo3 это CMS с открытым исходным кодом. Впервые этот относительно универсальный движок был представлен в 1998 году. Typo3 часто применяется для новостных порталов, интернет-магазинов, корпоративных сайтов и других вариантов сайтов.   Официальный сайт: https://typo3.org/.   Особенности Typo3: Написан на PHP. Последняя версия 9.5.4 от 22.01.2019. Особенностью Typo3 является то, что в проектах на этой CMS вся информация публикуется от администратора и сайты не работают с пользовательским контентом. Typo3 не приспособлена для создания блога, активно взаимодействующего с пользователем портала или социальной сети. Минимальные требования к хостингу: Linux, Windows или Mac; PHP> = 7.2; PostgreSQL / Microsoft SQL Server / MariaDB >= 10.2 / MySQL >= 5 <= 5.7 / SQLite; Apache httpd или Nginx или Microsoft IIS, Caddy Server. Плюсы Typo3: Простота администрирования сайта. Возможность управления несколькими проектами из одной панели администратора. Возможность создания отдельных разделов на сайте с раздельным доступом для разных типов пользователей. Минусы Typo3: Относительно высокая требовательность движка к ресурсам сервера. Сложность изучения документации. Основная часть материалов не переведена с английского. Также, как и у ряда предыдущих CMS, у Typo3 наблюдается снижение популярности с 2016 года. В свою очередь в Украине на этом движке зарегистрировано 399 сайтов, в Российской Федерации - 1327. Полезным будет рассмотреть и сравнение производительности среди ТОП CMS.   Популярные CMS. Сравнение производительности. Согласно опубликованным данным тестирования ряда CMS, можно сделать вывод о наиболее быстром движке (пусть и в искусственных  - «тепличных» условиях теста). Указанные данные в таблице – это количество обрабатываемых запросов в секунду. Наиболее быстрой в данном исследовании среди популярных CMS показала себя WordPress 5.0 с версией PHP 7.3.   Вывод В нашем кратком обзоре CMS мы рассмотрели ТОП 6 наиболее распространенных CMS в мире. Как мы видим, каждая из них имеет свою специфику и особенности. Из-за разных возможных сфер применения сложно выбрать лучшую систему управления сайтом. Как лучшая CMS для блогов многими пользователями отмечается WordPress, а PrestaShop многими определяется как лучшая CMS для сайта интернет-магазина. Стоит понимать, что большая часть представленных в нашем ТОП CMS движков являются относительно универсальными. Кроме PrestaShop и Magento, ориентированных на интернет-коммерцию, с помощью других движков можно делать разнотипные проекты. Однако многими разработчиками признается, что никакая универсальная CMS не будет работать в конкретной сфере также хорошо, как специально разработанная для этой цели CMS. Поэтому, полезно кроме данного обзора ТОП CMS, рассмотреть отдельно ТОП CMS для блогов, ТОП CMS для интернет-магазинов, ТОП CMS для форумов, и далее. Такие обзоры помогут лучше понять, как правильно выбрать движок для сайта с вашими уникальными потребностями. Как вы могли заметить, рассмотренные CMS из ТОП движков для сайтов написаны на PHP. Если вы определились с CMS для своего проекта и хотите его сами доработать, или просто хотите научиться работать с топовыми проектами сети Интернет - вам, вероятно, будет интересен наш набор курсов  и вебинаров на портале ITVDN: WordPress Starter и WordPress Essential WordPress: создаем блог за час Интеграция верстки лендинга на CMS WordPress PHP Starter How To PHP Starter PHP Essential