<p>Мы начинаем <strong>серию вебинаров</strong>-практикумов по С++, Qt и QML. В ходе данного цикла вебинаров будут рассмотрены все этапы создания кроссплатформенных графических приложений на основе фреймворка Qt.</p> <p><strong>Всего будет 4 вебинара:</strong></p> <ol> <li>Знакомство с QML. Пятнашки (17 сентября)</li> <li>Model View Controller в Qt. Знакомство с QML - продолжение. (24 сентября)</li> <li>Работа с базами данных в Qt (22 октября)</li> <li>Работа с сетью в Qt (29 октября)</li> </ol> <p>Мы рассмотрим самые важные части фреймворка в процессе создания приложения &quot;Книга контактов&quot;, которое с каждым вебинаром будет улучшаться и масштабироваться. Таким образом, вы узнаете, как создавать интерфейс своей программы, как в нее добавить работу с базой данных, а также как создавать клиент-серверные приложения. Но, прежде чем приступать к созданию книги контактов, мы попрактикуемся с QML на примере создания игры &#39;Пятнашки&#39;.</p> <p>Итак, тема первого вебинара&nbsp; - <strong>Знакомство с QML. Пятнашки</strong><br /> <br /> В течении вебинара будет разработана игра &laquo;Пятнашки&raquo; с бизнес-логикой на C++ и графикой на QML. Эта маленькая игра позволит на практике понять основные принципы и best practices в QML.</p> <p>После просмотра данного вебинара, зритель освоит базовую информацию о языке QML и об его интеграции с C++, что позволит ему эффективно разрабатывать графические приложения с динамичным пользовательским интерфейсом, используя Qt фреймворк.</p> <p>Приложение, разработанное в течении вебинара, может стать примером в портфолио джуниор разработчиков.</p> <p><strong>План вебинара:</strong></p> <p>1) Структура QML компонентов</p> <p>2) Компоненты QtObject, Item</p> <p>3) Базовые графические компоненты</p> <p>4) Взаимодействие C++ и QML:</p> <ul> <li>Q_PROPERTY</li> <li>Q_INVOKABLE</li> </ul> <p>5) Компоненты ListView, GridView</p> <p>6) Сигналы-слоты в QML</p> <p>7) Свойства, алиасы</p> <p>8) Регистрация своих классов в метасистеме</p> <p>9) Кастомизация компонентов</p> <p>&nbsp;</p> <p><strong>Целевая аудитория:</strong></p> <p>Данный вебинар будет интересен разработчикам, желающим попрактиковаться с фреймворком Qt или людям, которые ранее не сталкивались с QML, а разрабатывали свои графические приложения с помощью Qt Widgets.</p> <p>Также он будет интересен новичкам, которые хотят научиться писать кросплатформенные графические приложения на C++.</p>

Тренди. Найвищі зарплати Junior, Middle, Senior інженерів. Найвищі зарплати керівної інженерної ланки. Зарплати інших ІТ-фахівців. Найвищі зарплати в США, Європі та решті світу. Дані для рейтингу. Levels.fyi – компанія, що базується в США – нещодавно опублікувала річний звіт за 2023 рік з переліком компаній, міст, тайтлів та різних трендів, які мають найбільші грошові винагороди. Відповідно до інформації на сайті компанії, аналітичні матеріали Levels.fyi дозволяють людям будувати кращі кар’єри в ІТ, відштовхуючись від чесних та прозорих зарплат. Давайте разом подивимось, які ІТ-спеціалісти в яких куточках світу отримують найбільше?   Тренди Спочатку дізнаємось, як змінилися зарплати ІТ-спеціалістів порівняно з 2022 роком. На картинці нижче – медіанні ЗП в доларах США (сумарно за рік) для кожного сімейства спеціальностей. Найвідчутніший приріст мають технічні менеджерські напрямки, повний штиль у Data Scientists, а невеликий від’ємний приріст – у розробників програмного забезпечення та дизайнерів продукту.   Найвищі зарплати Junior, Middle, Senior інженерів Розглянемо річні компенсаційні медіани інженерів, які мають досвід від 0 до 15+ років в розробці. В кожному розділі буде ТОП-7 компаній, які найбільш щедро винагороджують своїх працівників в залежності від їхнього досвіду. Укладачі рейтингу зазначають, що в поняття компенсації входять зарплата, акції та бонуси, отримані за минулий рік, але для простоти ми ототожнюємо “компенсацію” та “зарплату” в даній статті. Інженер початкового рівня (від 0 до 2 років досвіду) Рейтинг включає інженерів рівня Intern/Trainee/Junior. Зазвичай це випускники з невеликим або взагалі нульовим досвідом в галузі. Вони розвивають та підтримують компоненти низької та помірної складності, використовуючи настанови та підтримку членів команди з більшим досвідом. Тут вам можуть бути знайомі Figma та LinkedIn. Перша компанія – всесвітньо відомий розробник онлайн-інструменту для дизайнерів, а друга – соціальна мережа для встановлення ділових зв’язків.  Engineer (від 2 до 5+ років досвіду) Даний тайтл можна прирівняти до Middle. Сюди відносяться спеціалісти, які працюють над компонентами середньої та високої складності, і навіть здатні керувати невеликою командою або проєктом. Можуть менторити та консультувати менш досвідчених інженерів, проводити код-рев’ю, працювати над невеликими проєктами від початку до кінця. Межі відповідальності такого фахівця різняться від команди до команди. В багатьох компаніях спеціалісти можуть працювати постійно на цьому рівні, не боячись, що їх звільнять за те, що вони не просуваються кар’єрною драбиною далі. Senior Engineer (понад 5 років досвіду) Сеньйори – від них очікується керування іншими та просування власних комплексних технічних ініціатив. Можуть виконувати візіонерські функції, визначаючи подальший вектор руху команди. Також здатні впливати на інші команди в межах компанії. Їхня роль більше охоплює дизайнерські задачі, ніж реалізацію – залежно від розміру та очікувань компанії. Зазвичай таких спеціалістів в компанії не більше 30%.   У кого в ІТ найбільші ЗП? Рейтинг світу. Найвищі зарплати керівної інженерної ланки Staff Engineer – інженер управлінського апарату Ця посада передбачає 10+ років досвіду, і є досить бажаною порівняно з Junior, Middle та Senior. Менше 10% персоналу займають цю позицію, при цьому їхній вплив досить масштабний і простягається на різні організації. Інженерам даної ланки довіряють важливі бізнес-проєкти та встановлення технічного бачення для однієї або декількох організацій. Найбільшу винагороду отримують саме staff-інженери з OpenAI – компанії, що наприкінці 2021 року випустила в світ славнозвісний ChatGPT і нещодавно мала бурхливий скандал навколо звільнення гендиректора OpenAI Сема Альтмана. Principal Engineer – головний інженер Посада передбачає 15+ років досвіду, причому менше 3% персоналу сягають цього рівня. Головний інженер характерний для компаній середнього та великого розміру, а в маленьких зазвичай відсутній. Вплив Principal Engineer може поширюватися як на всю компанію, так і на індустрію. Від цих спеціалістів очікують повну автономію в роботі. Аналітики рейтингу зазначають: даний тайтл властивий малому відсотку людей в компанії, а тому деякі компанії не мають інформації в достатній кількості, аби бути включеними в цей список.   Зарплати інших ІТ-фахівців. ІТ-компанії з найбільшими ЗП Аналітики даного звіту розробили стандарт рівнів для менеджерських ролей та ролей індивідуального спеціаліста (individual contributor) в цьому році. Оскільки на початку 2023 у них не була встановлена система рівнів, вони вказують ТОП-5 компаній з найвищим рівнем компенсації, використовуючи медіанне значення в межах компанії для наведених нижче професійних категорій незалежно від рівня. Варто враховувати, що це найвищі медіани, і вони можуть не відображати весь ринок. Software Engineering Manager SE Manager може керувати однією або кількома командами інженерів, які створюють програмне забезпечення (ПЗ). Він комбінує технічні обов’язки з управлінськими і відповідає за: створення сприятливого середовища для ефективної роботи Engineering-команди; визначення структури та навантаження, яке покладається на кожного в команді; трансляцію команді загального руху та цілей компанії; контроль та підготовку технічного роадмапу разом з Tech Lead та інженерами для визначення інструментів, ресурсів та пріоритетів у роботі; надання технічної експертизи; вимірювання показників якості та ефективності команди; тощо. Product Manager Product Manager орієнтований на стратегічне управління продуктом в цілому, включаючи стратегію продажів, ринковий аналіз і взаємодію з клієнтами. На відміну від SE Manager, даний фахівець досить далекий від технічної складової і натомість сконцентрований на досягненні бізнес-цілей. Він фокусується на визначенні функціональності та властивостей продукту, які задовольняють потреби клієнтів, взаємодіє з усіма рівнями команди, включаючи розробників, маркетологів, дизайнерів і т. д. Product Designer Це НЕ UX/UI дизайнер. У Product Designer`а зміщено фокус з UX/UI на досягнення цілей бізнесу, продукту. Якщо “юікс-юай” займається безпосередньо створенням інтерфейсу (роль виконавця), то PD аналізує ринок користувачів, досліджує та визначає їхні потреби, на основі чого можна спроєктувати якісний інтерфейс, який приноситиме користувачеві максимально комфортний досвід, а власнику – аудиторію і прибутки (роль мудрого архітектора, дослідника). Hardware Engineer Важка артилерія від світу розробки. Ці спеціалісти займаються не програмним, а апаратним забезпеченням – “залізом”. Серед їхніх обов’язків: дизайн, розробка, тестування комп’ютерних систем та пристроїв, розробка схемотехнічних рішень та друкованих плат, покращення існуючих пристроїв (заміна компонентів, тестування тощо). Data Scientist Data Scientists працюють з великими обсягами даних і виконують збір, аналіз, структурування і подальшу візуалізацію інформації. Спочатку йде збір великої кількості невпорядкованих даних, а потім – їхнє перетворення у зручний формат, з яким далі працюють аналітики.   Найвищі зарплати в США, Європі та решті світу В яких містах світу топові ЗП у галузі Software Engineering? Американські аналітики дають відповідь і на це питання. Ситуація в США, Європі та світі загалом, відповідно: До останньої картинки автори додають примітку: цей список включає лише одне місто з найвищою оплатою праці в кожній країні. Інші міста в межах країни також можуть мати високу зарплату, яка не відображена в цьому списку.   Дані для рейтингу Головне джерело даних для аналітики – анонімні відгуки, які можна залишити у відповідній формі на сайті. Для цього треба надати наступну інформацію: Розмір компенсації. Інформація про рівні у компанії. Бонуси від компанії. У 2023 році компанія Levels.fyi отримала понад 200 000 заявок від тисяч компаній з усього світу. Нещодавно ми досліджували рівень ЗП та кар’єрний шлях українських DevOps-спеціалістів та Embedded-розробників – переходьте за посиланнями, щоб дізнатись, наскільки цінується їхня праця.

Введение Всем привет! У меня давно созрела навязчивая мысль написать о том, какой является структура работы в техническом отделе SEO. “Почему именно такая тематика?” - спросите Вы. Это наболевшее. Иногда клиенты, да и просто люди, которые не занимаются всерьез данным продуктом, смотрят на весь процесс со стороны и  думают: “Да это же просто дело. Взял проектик, денек-два оптимизировал сайт, ссылочек подкупил, всего делов. Может мне и самому SEO заняться?” Забавляет и интернет-пространство, например, рекламой с лозунгами наподобие: “Хватит платить сеошникам. Продвинь свой сайт самостоятельно!”. Это не может не веселить, если, конечно, не учитывать, что часть пользователей все-таки ведутся на подобные вещи. Ну а если всерьез, то я скажу банальную вещь, что любая стоящая работа требует не менее качественного подхода. Любое интернет-агентство маленького, среднего или большого размаха разрабатывает и выстраивает свой процесс отработки клиентских проектов. В данной статье мы рассмотрим только работу технического отдела, потому что существует еще и аккаунтинг, и топ-менеджмент, которые тоже  важны во взаимодействии компании и клиента. Но там “своя кухня” и она несколько отличается от технической. Идем дальше… Как известно, для того, чтобы построить качественный и надежный дом, нужно начать с фундамента. Так вот, в отделе SEO таковым является регламент процедур и тайминга. Это путеводитель как для руководителя отдела, так и для остальных членов команды. Зачем он нужен? Отвечаю. У каждой компании в отработке находится много текущих + еженедельный поток новых клиентов, которые требуют в разы больше внимания, чем текущие. Когда я приведу пример технологии Abweb, Вы поймете критическую важность этого регламента. Если одновременно ведется работа по десяткам проектов, просто физически невозможно держать все в голове. Необходимо иметь универсальный план действий, который разбит на множество подзадач и переносить его в проекцию каждого проекта. Ну, теперь конкретно о процессах Для того, чтобы всю информацию было проще воспринять, я четко структурирую все процессы в виде двух таблиц. Как правило, процесс продвижения можно условно поделить на 2 глобальных этапа: внутренняя и внешняя оптимизация. Поэтому и процедуры для них разные. Внутренняя оптимизация (1-й месяц) Процедура Старт выполнения Тайминг Проверка доступов от клиента (админка, FTP, хостинг) 1-й день работ 5 рабочих дней Создание папки проекта и файла проекта в CRM с семантикой и основными доступами 1-й день работ Анализ проекта, составление технического задания по внутренней оптимизации для программиста и техническое задание для копирайтера 2-й день работ Отправка сформированных технических заданий аккаунт-менеджеру, который ведет проект. В тот же день, когда составлено ТЗ, но не позднее 5-ого рабочего дня со старта проекта Внедрение правок на тестовом домене. В день, когда аккаунт-менеджер дал сигнал, что ТЗ на оптимизацию утверждено клиентом. 5 рабочих дней (4 дня реализация + 1 день на исправление багов по программной части) Написание текстов для целевых страниц. В день, когда аккаунт-менеджер дал сигнал, что ТЗ на тексты утверждено клиентом. Отправка выполненного ТЗ по оптимизации на тестовом домене аккаунт-менеджеру. В день, когда ТЗ было полностью внедрено и проверено. 1 рабочий день Отправка написанных текстов аккаунт-менеджеру. В день, когда тексты были полностью написаны и проверены. Перенос выполненных правок на основной домен. В день, когда аккаунт-менеджер дал сигнал, что ТЗ на тестовом утверждено клиентом. 2 рабочих дня Размещение текстов. В день, когда аккаунт-менеджер дал сигнал, что клиент утвердил тексты. 3 рабочих дня Тестирование основной функциональности сайта после внесенных правок (форм заказа, авторизация, регистрация, добавление контента и его сохранение и т.д.) + исправление багов, если они есть В день, когда все правки по внутренней оптимизации были перенесены на основной домен. 2 рабочих дня Отправка сайта и целевых страниц на принудительную переиндексацию поисковыми системами для скорейшего индексирования ПС В день, когда все правки по внутренней оптимизации были перенесены на основной домен + протестирован основной функционал 1 рабочий день Добавление сайта в систему мониторинга для отслеживания позиций. Когда все внедрено, отправлено на переиндексацию. Итого примерно 19 рабочих дней Ситуация выглядит таким образом, что за 16 рабочих дней (условно 3 рабочих недели) вся оптимизация должна быть внесена на основной версии сайта. 1 рабочая неделя отводится на тестирование выполненных правок, переиндексацию сайта, мониторинг динамики по позициям и составления отчета по всей проделанной работе. Обращаю внимание, что тут предлагается такой подход, в котором сначала все внедряется на тестовой копии (которую обязательно нужно закрыть от индексации), демонстрируется и согласовывается с клиентом и, если все OK, переносится на основной домен.  Я склонен считать, что это процесс затратный по времени, но зато безопасный! Переходим ко второму и последующим месяцам. Второй и дальнейшие месяцы плюс-минус похожи в плане выполняемых процессов. Внешняя оптимизация (2-й и последующие месяцы) Процедура Старт выполнения Тайминг Планирование и составление ссылочной стратегии в виде ТЗ со списком закупаемых анкоров. После получения оплаты 3 рабочих дня Регистрация аккаунтов для закупки ссылок по проекту 1 этап закупки ссылок На 4-й рабочий день 2 рабочих дня Пополнение ссылочного аккаунта для 1 этапа Плановая проверка сайта на предмет внутренней оптимизации/составление ТЗ по дооптимизации/отправка аккаунт-менеджеру на утверждение 12-й рабочий день 2 рабочих дня Внедрение правок по дооптимизации на основании предыдущего пункта В день, когда аккаунт-менеджер дал сигнал, что ТЗ на дооптимизацию утверждено клиентом. 4 рабочих дня Пополнение ссылочного аккаунта для 2 этапа 14-й рабочий день 2 рабочих дня 2 этап закупки ссылок Модерация ссылочных бирж 1 раз в 2 рабочих дня 11 рабочих дней Наполнение ТЗ на ссылки списком доноров, откуда куплены ссылки За день до составления и отправления отчета аккаунт-менеджером. 1 рабочий день Итого примерно 22 рабочих дня Выше приведена таблица со всеми процедурами и ориентировочными дедлайнами по каждому из них. Хочу сделать акцент на том, что весь этот грандиозный план действий должен быть ориентиром, но всегда бывают исключения. Сроки реализации задач часто зависят от сложности и объема работ по проекту, оперативности клиента по согласованиям технических заданий, текстов и внесенных правок. Могут также вклиниваться и форс-мажорные задачи, которых мы, как правило, не ожидаем. К таким нюансам нужно быть морально готовым и все равно максимально выстроить процессы под нужные дедлайны. Достаточно ли этого? Буду честен. Конечно, нет. Недостаточно лишь прописать процедуры. Чтобы все было “в ажуре”, Вам и нам нужны: Квалифицированные и перспективные ребята, которые будут закрывать все вопросы и задачи, которые расписаны выше (SEO-специалисты, копирайтеры, программисты и т.д.); Календарные планы по процессам. Например, календарный план по закупке ссылочной массы на каждый месяц, который позволит не запутаться в большом потоке, когда что закупать; Правильная постановка задач друг другу в худшем случае с помощью блокнота, а в лучшем - CRM-систем или других программ для фиксирования задач и планирования; Высокая степень самоорганизованности и четко выстроенный тайм-менеджмент у каждого сотрудника; Регулярное проведение планерок. Я с удовольствием поделился с Вами прототипом своего видения по выстраиванию процессов в отделе производства SEO. Буду рад услышать замечания и положительные отзывы. На сегодня пока все;)

Введение В данной статье мы познакомимся со стандартными операторами и их применением в языке программирования JavaScript для работы с переменными и со значениями. Сперва познакомимся со специфической терминологией, которая используется при работе с операторами.Большинство операторов обозначаются символами пунктуации, такими как =, +, - и другими. Некоторые – специальными ключевыми словами, к примеру, delete и new. Но, как знаки пунктуации, так и ключевые слова обозначают обычные операторы, просто используют для этого разный синтаксис. Оператор присвоения Операнд – то, к чему будет применен оператор, или порой можно встретить название: «аргумент оператора». Оператор присваивания выглядит как знак равенства = :    var a = 1, b = 2; В данной строке переменной "a" было присвоено значение 1, а переменной b – значение 2.      var a = a + 2; В этой строке переменной "a" было присвоено ее значение, увеличенной на 2. Иначе говоря, сперва выполнится операция сложения текущего значения переменной a, результат которого будет пере-присвоен переменной a. Полезной особенностью данного оператора является использование его по цепочке:      var a, b, c;       a = b = c = 2 + 3; В результате работы последней строки всем трем переменным будет присвоено значение 5. Арифметические операторы Арифметические операторы используются для определения простейших математических операций над операндами, в качестве которых могут выступать как значения, так и переменные: плюс + , минус - , умножить * , поделить / , деление по модулю (определение остатка от деления) %. Большинство JavaScript-операторов работают с двумя операндами, следовательно, способны два простых выражения объединить в одно более сложное. Но JavaScript поддерживает несколько унарных операторов, которые преобразуют только одно выражение в другое, более сложное. Таким оператором является унарный минус, который изменяет знак числа на противоположный. В таком случае оператор «минус» в выражении -1 представляет собой унарный оператор и выполняет смену знака у своего единственного операнда 1. <script type="text/javascript">         var x = 1;         document.write(-x + " ");         document.write(-(-x) + " ");         document.write(-(x + 4) + " "); script> Унарный плюс, используемый в качестве арифметического оператора, не выполняет каких-либо действий: <script type="text/javascript">         document.write(+1);         document.write(" ");         document.write(+(1 - 2)); script> Более распространенным применением унарного плюса является преобразование значения в число. В случае объединения двух выражений в одно более сложное используются бинарные операторы, иначе говоря, бинарным называют оператор, который применяется к двум операндам, к примеру, если оператор плюс будет стоять между двумя числами, он будет представлен в своей бинарной форме: <script type="text/javascript">         var a = 1, b = 2;      document.write(a + b + " ");      document.write(b + a + " "); script> Кроме того, если у нас есть две переменные со строковыми значениями, бинарный плюс сложит эти строки. произведя конкатенацию, а применение унарного плюса к каждой из переменных произведет преобразование их значений к числу. var a = "2"; var b = "3"; alert(a + b); // "23", произошла конкатенация строк alert(+a + b); // "23", второй операнд - всё ещё стоковая переменная alert(+a + +b); // 5, число, поскольку оба операнда предварительно преобразованы в числа ((+a) + (+a)) В то же время, если использовать оператор «минус», мы получим другие результаты: var a = "2"; var b = "3"; alert(a - b); // -1, произошло неявное преобразование типов Таким образом, мы подошли к тому, что создавая JavaScript-выражения, важно обращать внимание на типы данных, передаваемых операторам, и, как следствие, на типы данных, которые они возвращают. Стоит отметить, что различные операторы требуют, чтобы операнды, с которыми они работают, возвращали значения только определенного типа. Так, нельзя выполнить умножение строк, поэтому выражение var a = "text1" * "text2"; не является допустимым и приведет к ошибке. В то же время, выражение var a = "2" * "3"; вполне допустимо, потому что интерпретатор JavaScript будет пытаться по мере возможностей преобразовать выражение в требуемый тип данных, в нашем случае из строкового типа в числовой. Познакомимся с работой операторов умножения и деления на простом примере. В данном случае мы используем бинарные формы операторов, поскольку они взаимодействуют с двумя операндами: <script type="text/javascript">      document.write("2" / 2 + " "); // 1, произойдет неявное преобразование строки в число      document.write(((2 + 2) * 6) / "12" + " "); // 2, произойдет неявное преобразование строки в число      document.write(12 * 7 / 2 + " "); // 42      document.write(17 % 7 + " "); // 3, возвращаем остаток от целочисленного деления      document.write(21 / 3 - 1 + " "); // 6, наблюдаем правильный порядок выполнения операций: сперва деление, затем нахождение разницы script> Если с работой операторов +, -, *, / в самом простом их применении мы были знакомы еще из младшей школы, то с оператором % стоит познакомиться детальней. Оператор деления по модулю % вычисляет остаток, получаемый при целочисленном делении первого операнда на второй, которые в курсе школьной математики именовались как делимое и делитель соответственно, а в результате самого деления мы получали частное и остаток от деления. Деление по модулю подразумевает возвращение остатка от деления. Например, выражение var a = 190 % 27; будет выполнено следующим образом: Оператор деления по модулю зачастую применяют к целочисленным операндам, но он корректно работает и с вещественными значениями. Так, в итоге выполнения выражения var a = -6.3 % 3; переменной a будет присвоено значение -0.3. Кроме этого, стоит отметить следующие особенности вычислений в JavaScript:  <script type="text/javascript">        var a = 4,        b = true;        c = undefined,        d = Infinity,        e = 0,        res = undefined;         res = a * d;         document.write(res + " "); // Infinity, умножение числа на бесконечность возвращает бесконечность         res = a + b;         document.write(res + " "); // 5, true преобразовывается в 1 и производится операция сложения         res = a / e;         document.write(res + " "); // Infinity, деление числа на ноль возвращает бесконечность         res = a * c;         document.write(res + " "); // NaN, умножение числа на неопределенный тип данных, вернет сигнализацию об ошибке в виде NaN - Not a Number script> В дальнейшем мы познакомимся с такими операторами как инкремент/декремент, операторами сравнения, равенства и идентичности, которые будут часто использоваться в написании клиентских сценариев c использованием языка JavaScript.

Обобщенный паттерн Репозиторий Чтобы избежать недоразумений, давайте для начала проясним, что здесь имеется ввиду под понятием обобщенного репозитория. Видели ли вы когда-нибудь интерфейс вроде этого: Или может вы видели его брата-близнеца, который имеет иной вариант метода Get: Вдохновение для написания первого примера пришло из официальной документации Microsoft для ASP.NET MVC 4. Что же касательно второго примера, в Интернете вы можете найти бесконечное число блогов, описывающих именно этот вариант написания репозитория — иногда лишь с небольшими отличиями в виде возвращения IEnumerable<TEntity> вместо IQueryable<TEntity>. И в последнем случае часто еще и с дополнительным методом для генерации запросов. Что-то вроде этого: Так что плохого в них, вы можете спросить? Почти ничего, если не считать плохое именование методов из примера Microsoft (здесь лучше было бы использовать Find и FindAll вместо Get и GetAll). Но «почти ничего» - это далеко не то же самое, что «ничего». Первую проблему, которую я здесь вижу, так это нарушение Принципа Сегрегации Интерфейсов (Interface Segregation Principle). Они выражают полный набор CRUD-операций даже для тех сущностей, для которых операции удаления не имеют никакого смысла (к примеру, когда вы деактивируете пользователей вместо удаления их записей из базы данных). Но эта проблема может быть решена при помощи просто разбиения на три интерфейса — для чтения, обновления и удаления записей. Реальная проблема, которую мы здесь имеем, заключается в некорректном использовании. Оригинальная идея заключается в том, что интерфейсы должны быть использованы в качестве базовых для ваших пользовательских интерфейсов. Что-то вроде этого: Ваши обработчики событий и сервисы (клиенты пользовательских репозиториев) должны сами определять нужные методы и помещать их в пользовательские интерфейсы. Это в теории. К сожалению, за свою карьеру мне довольно часто приходилось видеть несколько иную картину: Кто-то создал рабочую реализацию IGenericRepository. Что хуже в этой реализации, так это то, что эта имплементация почти всегда регистрируется в IoC-контейнере и может быть внедрена в ваши обработчики команд и сервисы точно так же, как и любая другая зависимость. Код выглядит достаточно красиво и чисто. На самом деле — нет. Почему именно так — скажу немного позже. Теперь же я бы хотел поговорить об одном из решений неправильной интерпретации GenericRepository<T> многих разработчиков. Само решение выглядит примерно так (диалог на code-review): Джим Сеньор: вы когда-либо слышали, что NHibernate ISession или DbSet из Entity Framework на самом деле репозитории? А то, что вы только что создали — всего лишь небольшая обертка над ISession или DbSet? Де-факто, мы можем отказаться от этого обобщенного репозитория и просто использовать DbSet — результат будет аналогичным. Единственное, в чем IGenericRepository<T> действительно полезен — так это в том, что он скрывает большую часть ненужных для нас методов, которыми обладает DbSet. Джонни Джуниор: да, в этом действительно есть смысл. Я полагаю, использование обобщенного репозитория в нашем случае было лишним (счастливо возвращаемся к написанию программы…) Как по мне, что GenericRepository<T>, что DbSet – в большинстве ситуаций их использование лишнее (ну разве что вы пишите наиболее заCRUDженное приложение в своей жизни). Почему? Вот почему: Единственный способ убедиться, что все LINQ-запросы будут верно преобразованы в SQL — это протестировать их на том же типе базы данных, что находятся в продакшине. Кроме того, в таком случае задача написания интеграционных тестов становится достаточно затруднительной. К примеру, взглянем на код: Чтобы выполнить эти запросы, должны быть соблюдены два условия. За счет этого интеграционный тест становится менее читабельным. Теперь же давайте представим, что этот метод помещен в метод репозитория. Теперь в тесте нам нужно просто вызвать метод репозитория и проверить результат — просто, не так ли? Я уверен, вы согласитесь, что LINQ-предикаты внутри сервисов нельзя использовать повторно и они имеют плохую тенденцию повторяться на протяжении всего кода. Даже если программист желает извлечь запрос в свой собственный метод, обычно это будет приватный метод конкретного сервиса. Инкапсуляция запросов внутри методов репозитория приведет к большей читабельности кода и в значительной мере упростить его использование. LINQ-предикаты не именуются. Как правило, единственный способ узнать, что же, собственно говоря, делает наш запрос (без углубления в его логику), так это имя переменной-результата. К сожалению, искусство информативного именования переменных постигается с опытом, а поскольку в нашей индустрии полно начинающих программистов, мы имеем дело с переменными вроде result, ordersToProcess или просто — orders. Создавая обертку над запросами в виде метода репозитория, это автоматически обязывает разработчика дать этому самому методу конкретное имя. Даже если это имя не из лучших, в последствии провести небольшой рефакторинг не составит труда! Порой, по причине скорости, мы вынуждены доставать данные из базы посредством чистого SQL. Подумайте, вы действительно хотите в своей бизнес-логике работать с такими низкоуровневыми сущностями, как DbConnection или SqlException? Подобный код лучше прятать за методами репозиториями.   Никаких обобщений — только конкретные репозитории   Перед тем как начать разработку репозитория, необходимо определить его интерфейс. Интерфейс должен содержать только те методы, которые нужны конечным клиентам. Другими словами, если никому не нужно удалять сущности данного типа, нет никакого смысла в написании функционала для их удаления. Если вы боитесь закончить среди разных имен для базовых CRUD-операций — таких как Delete в одном репозитории и Remove в другом — вы можете создать полезные интерфейсы типа ICanDeleteEntity<TEntity>, ICanUpdateEntity<TEntity> и так далее. В таком случае конкретный репозиторий будет реализовывать только действительно нужные из них. Ни один из методов репозитория не должен возвращать IQueryable<T>. Также убедитесь, что репозиторий не возвращает IQueryable<T>, скрытые за IEnumerable<T>. Всегда вызывайте ToList() или ToArray() дабы «материализовать» значения, придав им более конкретный тип данных. Как только заходит речь о реализации репозитория, вы можете наследовать абстрактный класс GenericRepository<TEntity>. Если угодно — можно также использовать напрямую ISession и DbSet. Не важно, какой подход вы выбираете. Помните: любые «лишние» в данном контексте методы — по типу Delete из базового класса — будут скрыты за интерфейсом репозитория. Также не забывайте, что ваш репозиторий не несет ответственности за транзакции базы данных. Лучше всего эта концепция реализуется при помощи паттерна Unit Of Work. Этот паттерн уже реализован в рамках ISession и DatabaseContext. Все, что нам нужно — это хороший интерфейс над ними: Для большинства веб-приложений чтобы начать транзакцию через IUnitOfWork в виде начала запроса и Commit / Rollback в конце запроса — этого функционала вполне достаточно. Так же подобное может быть достигнуто при помощи фильтров действий или декораторов обработчиков / сервисов. Пример репозитория, созданного при соблюдении всех приведенных рекомендаций:   Сейчас все стало ясно, но давайте еще раз проясним. Каждый метод наших репозиториев должен быть учтен по крайней мере одним интеграционным тестом, который должен использовать тот же тип базы данных, что и продакшн. Всегда используйте интеграционные тесты для проверки своих репозиториев. Немного о недостатках Не существует роз без шипов, и представленный выше подход — не исключение. Некоторые из них можно решить, используя отличимую от трехуровневой архитектуру. Наиболее часто с конкретными репозиториями возникали следующие проблемы: За длительное время репозитории могут набрать большое количество Find-методов. Достаточно часто эти методы похожи друг на друга. Есть два способа это предотвратить. Один из них — это группировка нескольких Find-методов в один общий. Этот метод должен принимать object, что представляет собой критерий запроса. Пример: Чтобы создать запрос с критерием запроса, мы строим набор критериев шаг за шагом:   Зачастую слишком большие репозитории обрастают целой плеядой различных сервисов. Вы можете избежать этого при помощи чего-то, что я называю CQRS-light. Отличием от полной версии является использование тех же таблиц как для чтения, так и для записи. Используя эту технологию, мы можем использовать ту же самую ORM как для чтения, так и для записи. Обращаться же к CQRS только в тех случаях, когда приложение в этом действительно нуждается (например, при обработке 80+ колонок, с использованием 20+ join). Диаграмма ниже представляет типичную архитектуру CQRS-приложения: Ключевые принципы CQRS-light следующие: Деление всех действий пользователя на две категории. Первая категория — действия, изменяющие систему. К примеру, оформление заказа в интернет-магазине. Вторая категория — действия, систему не трогающие. К примеру, просмотр списка товаров. Первая категория пишет — это команды, другая — читает, это запросы. Обработчики запросов для доступа к данным могут использовать только репозитории. Доступ к данным может осуществяться посредством любой технологии. Обычная конфигурация включает в себя ORM для чтения-записи, ORM для записи и микро-ORM для чтения (вроде Dapper) или же ORM для записи и чистый SQL для чтения. Обработчики команд для доступа и изменения данных могут использовать только репозитории. Для получения данных из базы обработчики команд не должны использовать обработчики запросов. Если обработчик команд должен выполнить комплексный запрос и этот запрос должен получить ответ от обработчика запроса, вы должны продублировать логику этого обработчика запроса и поместить его как в обработчик запроса, так и в метод репозитория (операции чтения и записи должны быть разделены). Обработчики запросов тестируются только в интеграционных тестах. Для обработчиков команд существуют юнит и — опционально — также интеграционные тесты. CQRS даже в своей легкой форме — сама по себе объемная тема и заслуживает отдельного блога. Теперь же давайте вернемся к теме недостатков паттерна конкретного репозитория. Другой недостаток, о котором я бы хотел упомянуть, заключается в нежелательной миграции бизнес-логики в определение запросов. К примеру, даже такой простой запрос:   содержит часть бизнес-логики, описывающей необходимые параметры, дабы заказ стал активным. Как правило, ORM не позволяет нам инкапсулировать такие части логики в отдельные свойства, как IsActive. Что нам здесь нужно, так это паттерн спецификации. Теперь наш запрос в форме паттерна спецификации будет выглядеть так: Автор перевода: Евгений Лукашук Источник

Здравствуйте, дорогие читатели. Меня зовут Владимир. Любая технология рано или поздно приедается и рост себя как специалиста затрудняется. Было принято решение что то кардинально поменять в своей жизни. А так как писать различные интересные проекты я просто обожаю, было принято решение начать изучение в корне другой платформы, среды разработки и языка программирования. Поиск этой платформы оказался достаточно прост для меня. Я решил, что это будет мобильная платформа. У меня было много разных телефонов с разными операционными системами. Но свой выбор я сделал в пользу iOS, так как при железе слабее, чем у других телефонов, софт работает намного быстрее, чем на других платформах. Это не все преимущества этой платформы, но о других я рассказывать я не буду, дабы не раздувать дискуссию на эту тему. Скажу лишь одно, что телефон c iOS меня ни разу не подвел, даже в самые нужные моменты. Разумеется, что для разработки под iOS необходим mac, и я его купил. Перед покупкой, разумеется, пробовал разработку под мобильные платформы в гибридных платформах типа Xamarin, Ionic, но на то время функционал в них был не так совершенен, как сейчас, да и пользуясь ими, я бы остался на платформе Windows, это нарушало цель, которую я перед собой поставил по поводу другой платформы. В течение отпуска, где то за месяц я разобрался, как писать под iOS приложения и сразу начал искать проект, на котором смогу потренироваться. Друг предложил такой проект и я взялся. За 9 месяцев написал серьезное приложение, купил учетную запись разработчика, выкладывал сборки на Test Flight, их тестировали тестировщики, прошел валидацию в App Store и выложил приложение в App Store. А теперь по сути. Я постараюсь написать серию статей, в которых распишу простым языком, что надо делать, чтобы у вас тоже это получилось и вы таки выложили свое приложение в App Store. Касаемо разработки под iOS, то это просто мое хобби во вне рабочее время (надо же как то развлекаться), основной хлеб приносит разработка под Windows/Web платформу с технологиями Microsoft. Итак, приступим. Включите свой мак, найдите на панели задач иконку App Store и нажмите на нее. Выглядит эта иконка вот так: Затем введите в поле поиска, текст “xcode”, вы должны увидеть следующее:  У меня Xcode уже установлен, поэтому на скриншоте отображается кнопка “Open”, у вас будет отображаться кнопка “Install”. Установите Xcode себе на компьютер, версия Xcode с которой мы будет работать с вами в этом примере, будет 8, на текущий момент это последняя версия этой среды разработки. Язык программирования, который мы будем использовать, называется Swift, по синтаксису он больше похож на JavaScript и где-то даже на C# местами. Синтаксис языка Swift в этих статьях мы разбирать не будем, в сети интернет есть полно руководств на эту тему. Сам синтаксис языка не сложно изучить, это делается за день, сложность как раз возникнет при попытке разработки приложения под iOS. Вот именно эту сложность, мы с вами и постараемся одолеть. Чтобы серия статей была как-то взаимосвязана, мы с вами напишем проект под названием “Warehouse” (склад), в котором можно будет добавлять товары, заполнять их атрибуты, редактировать и удалять товары. Данные будут сохраняться в настройки телефона. Вы уже установили Xcode 8? Если да, тогда запускайте его, вы увидите следующее: Нажмите кнопку “Create a new Xcode project”. Вы увидите такой экран:  Выделите проект “Single View Application” и нажмите кнопку “Next”. Вы попадете на экран задания названия проекта: На данном скриншоте виден пример того, как заполнить название приложения. В поле “Product Name“, введите “Warehouse”, так будет называться наше приложение. В поле “Organization Name”, введите свои имя и фамилию, или название вашей компании. В поле “Organization Identifier”, вводится уникальный идентификатор приложения, который будет использоваться как ключ при регистрации данного приложения в iTunes, чтобы была возможность подписывать сборки и отправлять на бета сервер Test Flight для тестирования, но об этом позже. Вкратце “com” - это сокращенно “company”, “bozhek” это название компании, у вас это будет другое название. В поле Bundle identifier видно полное название вашего приложения в iTunes. В поле Language, оставьте Swift. В поле Devices, выберите iPhone. Нажмите кнопку “Next”. Откроется проект, который мы создали: Обратите внимание на красный кружок в поле Status: “Signing for Warehouse reguires a development team”. Это сообщение говорит нам о том, что приложение надо подписать сертификатом, без сертификата мы не соберем и не запустим это приложение. Давайте это исправим. В поле Team, откройте выпадающий список и выберите в нем пункт “Add an Account...”, откроются свойства среды разработки Xcode, с предложением ввести логин и пароль от  вашей учетной записи в App Store, под которой вы устанавливаете приложения себе на телефон: Если же у вас по каким то причинам нет этой учетной записи, создайте ее, нажав на кнопку “Create Apple ID”. Создание этой учетной записи я не буду рассматривать в данной статье, поскольку она создается очень легко и в сети интернет есть полно информации на эту тему. Итак, вы ввели в поля Apple ID и Password свои данные, нажмите кнопку “Sign In”. После этого красный круг с ошибкой пропадет и вы увидите следующее: Теперь вы сможете собрать и запустить свой проект. Заметьте, я рассказываю чисто практически как и что делается, особо не вникая в детали. Если вам нужна более подробная информация, вбейте в гугл WWDC, и посмотрите официальные видео сессии от компании Apple, в их двухчасовом видео много воды, но зато есть теория, которая будет вам нужна. Я даю только суть. Нажмите на иконку приложения в проекте: Выберите симулятор “iPhone 7”. Затем нажмите на кнопку Собрать и запустить приложение: Будет запущена сборка проекта и запущен симулятор “iPhone 7”, в котором откроется наше приложение: Сейчас мы видим только белый экран и больше ничего, так как мы еще ничего не делали. Чтобы выйти на рабочий стол в симуляторе, выполните сочетание клавиш Shift + Command + H, это сочетание означает нажатие кнопки Home: Вы увидите на рабочем столе наше приложение "Warehouse". Теперь давайте остановим выполнение приложения, для этого в Xcode нажмите кнопку: Теперь давайте посмотрим, что у нас есть внутри проекта. Выделите в левой панели среды разработки файл “Main.storyboard”, в этом файле содержится представление приложения. В панели справа отображаются свойства представления. Разработка под iOS строится через паттерн MVC (Model View Controller), файл Main.storyboard, содержит View, которые вы будете использовать в своем приложении для создания визуального  интерфейса. Теперь давайте выделим в панели свойств вкладку Class: В поле Class , мы видим класс контроллера, привязанный к данному представлению. Теперь выделите вкладку Size: На данной вкладке задаются размеры представления. Выделите вкладку Events: На данной вкладке задаются обработчики событий в представлении с привязкой к методам в контроллере. Теперь выберите в левой панели файл ViewController.swift : На 9 строке подключено пространство имен UIKit. На 11 строке объявляется класс с именем ViewController, который наследуется от базового класса контроллера UIViewController. На 13 строке мы переопределяем метод, загрузки представления, этот метод вызывается когда представление начинает свою загрузку. В этом методе необходимо предварительно проинициализировать данные элементов управления, используемых на вашем представлении. На строке 14, вызывается метод базового класса ViewController. Код на строке 18 нам пока не интересен, мы его рассматривать не будем, чтобы не путаться. На этом урок завершается. На следующем уроке, в первой части, мы рассмотрим с вами, как пользоваться элементами управления, как привязывать к ним обработчики событий и как взаимодействовать с ними.

14 января 2017 года ITVDN отметил свой третий День Рождения! Благодарим всех участников акции за ответы на вопросы анкеты, а главное - за добрые слова и пожелания в адрес создателей проекта. Как и было обещано, все клиенты ITVDN в честь Дня Рождения получили в подарок бонусы (см. В Личном кабинете), а трое счастливчиков выиграли подписку ITVDN на три месяца. Имена победителей: Руслан Коваль Анатолий Спивакин Артем Соляр Видео запись розыгрыша. Подарочные сертификаты будут отправлены победителям на адреса электронной почты, указанные в анкете. А мы хотим поделиться со вами отзывами участников акции о нашем ресурсе. Ответы на вопрос: Что ITVDN значит лично для Вас? «ITVDN для меня - лучший русскоязычный образовательный ресурс по технологиям Microsoft. Я прошел здесь много курсов, даю отзывы о вашей работе, чтобы вы могли становиться лучше!», Геннадий Чурсов.   "Благодаря ITVDN я стал front-end разработчиком! Процветания всей команде! Новых курсов по Spring!" Олег Жихарев.   «Я очень благодарен, что есть такой замечательный ресурс на русском языке! Очень понятные объяснения и за это отдельное большое спасибо. Очень важно, что у вас такие грамотные преподаватели, и речь даже не о знании программирования (в чем я тоже ни капельки не сомневаюсь), но и в умении грамотно и понятно объяснить ученикам материал», Руслан Сайфуллин.   «Jump-start в технологиях. Удобный способ выйти из своей технологической ниши и посмотреть на соседние технологии. Эффективнее по времени и деньгам, нежели покупка книг», Антон Касьянов.   «Замечательный ресурс, который помог и продолжает помогать постигать C#», Дмитрий Старцев.   "Я изучала только JavaScript / Frontend Developer и могу сказать, что более подробного и понятного изложения материала нигде нет. Очень нравится что есть тренажёр, помимо теории ты проверяешь, что запомнил," Анастасия Бутылова.   «ITVDN для меня – это обучающий ресурс с высочайшим качеством курсов, которые позволяют в кратчайшие сроки погрузится в IT технологии и пройти сложный путь от самого зеленого новичка до гуру разработки!», Юрий Дмитрин.    «Это возможность быстро и в короткие сроки разобраться в новых для себя темах. Отличный формат подачи материала», Алексей Глущенко.   «ITVDN помог мне с выбором направления, а именно .net developer, и дал чёткий план в своём развитии», Михаил Розенберг.   «ITVDN - это возможность сменить профессию, и начать зарабатывать деньги», Юрий Манин.   «Много новой и полезной информации. Открытие новых горизонтов для профессионального роста», Александр Веред.   «Я решил стать свитчером. Скоро сдаю экзамен по .NET и начинаю поиски работы. Оглядываясь назад понимаю, что без ITVDN мне вряд ли бы удалось продвинуться так далеко. Великолепный ресурс. И Шевчук - преподаватель от Бога (жаль, что перестал начитывать лекции, забросил С# Prof Express). Хотелось бы увидеть более широкую программу поддержки выпускников, в том числе иногородних. Всего Вам наилучшего и не забросить ресурс." Сергей Дмитрук.   "Лучший онлайн сервис по изучению информационных технологий компании Microsoft! Начинал с него свое изучение ООП, БД, алгоритмов и т.д. Каждый раз слежу за новостями, и появление нового курса вдохновляет меня как начинающего разработчика," Максим Давлетчин.   "Ваш ресурс стал меня большим открытием. Именно благодаря ему я наконец-то определился для себя с планом обучения по выбранной специальности. Ваши видеокурсы очень легки в восприятии и помогают заполнить все пробелы в той или иной предметной области. Отдельная благодарность лекторам за качественное преподавание материала." Андрей Донченко.   "Один из самых толковых, содержательных и прорывной проект в онлайн образовании  Украины, а главное ДОСТУПНЫ многим ! Это настоящий шанс для всех, кто желает стать программистом! Отрадно, что это у нас! Лично мне сильно помогли Ваши курсы: полнотой и содержательностью уроков, доступностью, удобством в пользовании! Надеюсь, ваше дело будет маяком и надёжной гаванью, доступной для всех, ищущих знаний." Андрей Щёткин.   "ITVDN - очень хороший ресурс с качественными курсами. Материал объясняется понятно, упражнений ровно столько, сколько нужно для понимания и запоминания информации," Анна Кузнецова.   "Это уникальная возможность удалённого обучения, возможность просмотреть интересующий материал в любое удобное время, а также возможность просмотреть повторно видео по тому или иному уроку после очного обучения на курсах. Также дополнительно хочу подчеркнуть о возможности закрепления материала и прокачки знаний в "Тренажере", который очень удобен и в который хотелось бы, чтобы добавлялись новые курсы," Артем Петрук.   "Для меня ITVDN - это ресурс неисчерпаемых знаний, охватывающих практически всю IT сферу. Благодаря ему, я могу совершенствовать свои навыки в программировании, тем самым одновременно продвигаясь по карьерной лестнице, что является очень важным для меня," Даниил Округ.   "Качественные курсы, после которых можно сразу применять полученные знания на практике," Игорь Безруков.   "Для мене ITVDN - це крок вперед. Як на мене -  це одні з найкращих курсів по програмуванню. Кваліфіковані викладачі роблять курс цікавим і захоплюючим.  ITVDN  - це те, що робить тебе більш спроможним. Дякую вам." Васьків Василь.   "Отличные курсы по разработке игр, которые очень помогли в создании своего игрового проекта," Иван Туманов. "Очень классные видеокурсы, хорошо структурированы и собраны по отдельным специальностям." Vsevolod Gonchar.   "ITVDN лично для меня - это ресурс, который помогает от новичков (как я) и до професионала, которым я планирую стать вместе с вами. У вас собран лучший контент по програмированию. И это очень удобно что он в одном месте. Поздравляю!" Андрей Вакулюк.   "ITVDN придает мне силы и уверенность в завтрашнем дне! Без курсов ITVDN я бы забросил обучение программированию. Спасибо всей команде! Здравия желаю!" Денис Гаев.   "Отличный сайт для обучения, приемлемые цены и одни из лучших, на мой взгляд, преподавателей." Гуменяк Дмитрий.   "Лично для меня ITVDN ассоциируется со Знаниями именно с большой буквы, к которым стремлюсь, и которых лично мне так не хватает." Сергей Скрипник.   "Возможность пройти качественную переквалификацию для начала карьеры в IТ-сфере." Геннадий Шпинёв.   "Один из лучших образовательных online ресурсов для IT-специалистов." Андрей Грандюк.   "Для меня ITVDN это № 1 русскоязычный образовательный онлайн портал! Он даже на много  лучше распиаренного "GeekBrains". Во-впервых, потому что там очень дорого, во-вторых, Ваши специалисты очень хорошо подают материал. Огромное  спасибо за Ваш труд! Я желаю Вам миллион учеников и процветания!" Андрей Грачев.   "Короткі та змістовні уроки від справжніх професіоналів. Ніякої води. Можливість швидко розвиватися. Вивчати те, що подобається." Юрій Тураш.   "Очень хороший ресурс. Помог мне начать изучение ASP.NET MVC. Хорошее доступное объяснение непонятного с первого взгляда материала." Дмитрий Анисько.   "Единственные уроки по Java, которые подробнейшим образом дали ответы на интересующие меня вопросы." Татьяна Корчинова.   "Лучший ресурс для самообучения." Андрей Багрий.   "ITVDN выпускает лучшие рускоязычные видеокурсы для IT специалистов. Больше всего нравится подача материала от Александра Шевчука, Дмитрия Охрименко и Александра Марченко. Очень понравилась серия видео "Карьера в IT". Владимир Долгий.   "ITVDN - один из лучших и современных сервисов обучения web-технологиям." Руслан Галиев.   "Полезный, познавательный и интересный контент, отлично подходящий для саморазвития. Работаю в сфере helpdesk, хочется развиваться и двигаться дальше, Ваш проект отлично помогает в этом," Dmitry Mazur.   "ITVDN - очень интересный ресурс. Видео уроки и учебный материал сыграли важную роль в моей учебе. С их помощью я смог освоить много новых технологий и начать карьеру программиста. Надеюсь на дальнейшее обновление видеокурсов и создание новых, так как они помогают постоянно развиваться и совершенствовать свои навыки, понять некоторые моменты в простом виде," Федор Петренко.   "Очень полезный ресурс, который позволяет мне удобно а главное качественно обучаться в сфере IT-технологий. Очень нравится читать интересные публикации в блоге,слушать новые бесплатные IT-вебинары. Спасибо Вам ребята!" Гурина Анастасия.   "Качественные уроки от специалистов,  которые учат лучше, чем моём ВУЗе." Наталия Проскурничая.   "Для меня ITVDN -  это новая возможность учиться, совершенствовать свои навыки, получать новые знания от лучших специалистов в своих областях, и все это в удобном формате и в удобное для меня время!" Екатерина Морозова.   "Для меня этот портал открыл путь в новый мир, с него началась моя карьера программиста, за что я выражаю огромную благодарность Александру Шевчуку, его курсы были отправной точкой для меня." Эдуард Степанов.   Благодарим всех за приятные отзывы! Оставайтесь с нами!

Visual Studio Qt Creator CLion Eclipse Xcode Code::Blocks NetBeans   Відмінності між IDE та текстовим редактором Рейтинг IDE для С++ за даними Standard C++ Foundation Рейтинг IDE серед користувачів Reddit Рейтинг IDE для C++ від компанії JetBrains Рейтинг найкращих середовищ розробки для C/C++ IDE від G2 Crowd Висновок У роботі будь-якого сучасного розробника програмного забезпечення є інструменти, які стали практично обов'язковими для щоденного застосування. Якщо говорити про програмування мовою C++, таким інструментом, насамперед, буде звичайно інтегроване середовище розробки або IDE (Integrated Development Environment). Звичайно, досвідчений програміст може обійтися і без використання IDE, але це істотно позначиться на таких моментах, як швидкість розробки, якість коду і, звичайно ж, зручність самого процесу написання цього коду. Сьогодні ми розглянемо ТОП-7 найкращих середовищ програмування на C++. Це найчастіше використовувані інструменти від різних компаній та спільнот.   Відмінності між IDE та текстовим редактором Для початку нагадаємо різницю між текстовим редактором, який використовується для написання програм, і повноцінною IDE. Якщо спростити, текстовий редактор – це програма, за допомогою якої розробник взаємодіє безпосередньо з кодом як з текстом. Використовуючи клавіатуру, за допомогою текстового редактора розробник вводить символи та ключові слова мови програмування, описуючи цими словами якийсь алгоритм, зрозумілий надалі комп'ютеру. Код, написаний на C++ за допомогою текстового редактора коду, потрібно буде відправити на компілювання в іншу програму – компілятор, який не входить до складу текстового редактора. Інтегроване середовище розробки, у свою чергу, є комплексом окремих інструментів розробника, який дозволяє не тільки написати код програми, але й скомпілювати цей код у готовий додаток, провести тестування цієї програми, пошук помилок, рефакторинг та інші дії. До складу сучасних IDE як окремі елементи вже входять: текстовий редактор; компілятор (або інтерпретатор – для інтерпретованих мов програмування); відлагоджувач; система управління версіями; інші інструменти. Сучасні IDE можуть суттєво розширювати свій функціонал завдяки різним плагінам. Варто зазначити, що деякі текстові редактори (наприклад Vim, Visual Studio Code, Emacs), завдяки доступним плагінам, також розширюють свій функціонал, доводячи його до практично IDEшних можливостей. Однак це все ж таки два різних інструменти розробника. Текстовий редактор призначений скоріше для внесення дрібних змін до коду окремих файлів майбутньої програми. IDE, у свою чергу, працює з програмою комплексно, розглядаючи її в цілому як проект або набір проектів, а не як окремі текстові файли з кодом. Звідси й різниця у доступних можливостях цих інструментів.   Рейтинг IDE для С++ за даними Standard C++ Foundation Ознайомимося з даними опитування, проведеного серед 3240 розробників у лютому 2018 року організацією Standard C++ Foundation (Некомерційна організація з Бйорном Страуструпом у якості одного з керівників. Метою організації є підтримка спільноти розробників програмного забезпечення C++). За даними цього опитування, розробники на C++ виділили такі засоби розробки, як найчастіше використовувані: Перше місце серед IDE у Visual Studio з 55.28% розробників, що використовують його, друге у Qt Creator – 24.41% розробників, третє місце у CLion – 14.66%, четверте місце займає Eclipse – 12.78% розробників, п'яте місце у XCode – 12.22% розробників, шосте місце у Android Studio – 5.15%, сьоме у Code::Blocks – 4.85%. Як ми бачимо, багато розробників для роботи використовують текстові редактори з різними розширеннями функцій або без них. До таких входять: Vim – 37.93% розробників, Visual Studio Code – 25.77% розробників, Emacs (технічно, це текстовий редактор з розширеннями функціоналу до IDE) – 13.55%, Sublime – 12.78%.   Рейтинг IDE серед користувачів Reddit За результатами опитування, проведеного серед 1860 учасників наприкінці лютого 2018 року у співтоваристві r/cpp на порталі reddit.com, перше місце також займає Visual Studio – 28.43%:   Серед представників IDE до числа найчастіше використовуваних також увійшли: Qt Creator – 11.64%, CLion – 8.91%, Xcode – 4.05%, Eclipse – 3.98%, Code::Blocks – 2.43%.   Рейтинг IDE для C++ від компанії JetBrains Компанія JetBrains, одна з провідних компаній-творців інструментів для розробників (зокрема творець і власник одного з провідних IDE для C++ – CLion), представила в 2018 році свою статистику інтегрованих середовищ програмування С++, які найчастіше використовуються. За даними цієї статистики, перше місце серед різних середовищ розробки для C++ також отримує Visual Studio, що використовується 32% програмістів. Наступні місця в цьому рейтингу інтегрованих середовищ розробки розподілилися таким чином: друге місце у CLion – 11%, третє місце у Xcode – 5%, четверте місце у Eclipse – 5%, п'яте у QtCreator – 4%, шосте місце у Atom – 3 %, сьоме у NetBeans – 3%. Також корисною буде статистика від тієї ж компанії JetBrains, що показує компілятори, котрі найбільш часто застосовуються в розробці:   Рейтинг найкращих середовищ розробки для C / C++ IDE від G2 Crowd Цікаві дані надає аналітична платформа G2 Crowd. Проаналізувавши частоту використання розробниками різних середовищ розробки на C/C++ та ступінь задоволеності цими інструментами, компанія представила таку інфографіку: З цієї схеми ми все ще спостерігаємо лідирування Visual Studio серед інших середовищ розробки C++. Досить нішевими продуктами виявляються CodeLite та Code::Blocks. Ми розглянули кілька відкритих рейтингів найкращих середовищ програмування C++. Використовуючи вказані дані, ми зробили свій рейтинг найкращих середовищ розробки.   1) Visual Studio Visual Studio посідає перше місце у нашому рейтингу. Це широко відоме повнофункціональне середовище розробки від компанії Microsoft, яке дозволяє працювати з такими платформами, як Windows, Інтернет, хмара та Android. Можливості IDE Visual Studio дозволяють правильно та ефективно писати код, реорганізовувати, аналізувати та виправляти проблеми з кодом. Система IntelliSense передбачає API-інтерфейси в міру їх написання і виконує автоматичне завершення для підвищення швидкості та ефективності розробки. Саме ця IDE дозволяє новачкові найлегше увійти в процес розробки. Офіційний сайт – https://visualstudio.microsoft.com/ru/ Особливості Visual Studio: Свій компілятор – MSVC. Існують версії, що працюють на macOS та Windows. Підтримує такі мови: ASP.NET, Ajax, DHTML, Visual C++, JavaScript, JScript, Visual Basic, Visual C#, Visual F#, XAML та ін. Плюси IDE Visual Studio: Безкоштовно поширюється Visual Studio Community з достатнім набором можливостей. Платні версії можуть надаватися навчальним закладам та студентам безкоштовно. Зручна система розумного автодоповнення. Велика кількість налаштувань середовища розробки під «себе» завдяки вбудованим механізмам і доступним доповненням. Мінуси IDE Visual Studio: Версії Visual Studio Professional та Visual Studio Enterprise є платними. Масштабна IDE, досить вимоглива до заліза. Ряд розробників вважають її надмірною для створення дрібних проектів. Досить невелика швидкість запуску проектів та додатків. Не працює на Linux. Платні версії з розширеним функціоналом розповсюджуються за підпискою: Professional - від 45 $ на місяць, Enterprise - від 250 $ на місяць.   2) Qt Creator Qt Creator – ще одне досить зручне і швидке інтегроване середовище розробки C++, що пропонує цікаві можливості для розробника. Ця кросплатформна IDE має сучасний редактор коду C++, вбудований зручний графічний інтерфейс, дизайнер форм, інструменти навігації та багато іншого. Серед розробників багато хто обирає його за його API та бібліотеки, оскільки вони послідовні, деталізовані, зручні та гарно документовані. Qt Creator поставляється з повним набором інструментів розробника, які призначені для одночасного створення додатків і користувацьких інтерфейсів, а потім для подальшого їх розгортання в різних мобільних ОС і настільних ПК. Часто відзначають простоту та чуйність інтерфейсу. Він включає в себе зручний редактор коду з можливістю підсвічування синтаксису і автозаповненням, можливість створення інтерфейсу користувача використовуючи перетягування, інструмент візуального відлагодження та ін. Офіційний сайт: https://www.qt.io Особливості IDE Qt Creator: Доступні версії під Linux, macOS, Windows. Підтримувані компілятори: GCC / G++; MinGW; Linux ICC; Clang; Nim; QCC; MSVC. Доступні розширення, що дозволяють працювати з такими мовами, як Python, Ruby, Java, PHP та іншими. Плюси IDE Qt Creator: Наявність безкоштовної версії. Інтелектуальна система підказок. Можливість компіляції проектів для різних систем. Мінуси IDE Qt Creator: Платна версія від 459 $ на місяць. Безкоштовна версія має низку обмежень.   3) CLion Clion – це потужне і кросплатформне IDE для C і C++ від компанії JetBrains, яке включає сучасні стандарти C++, libc++ і Boost. Це IDE добре знає коди та спрощує рутину, дозволяючи зосереджуватися на основних речах розробки. Однією з його основних можливостей є рефакторинг, який дозволяє вам перейменовувати символи, зрушувати елементи вгору або вниз за ранжуванням, змінювати сигнатуру функції, а також гарантувати, що її автоматичний рефакторинг правильно генеруватиме необхідні зміни в коді. Інтегрований відлагоджувач аналізує та вирішує проблеми за допомогою дружнього користувацького інтерфейсу IDE з GDB / LLDB в якості бекенду. Більше того, він також віддалено зв'язується з нативними процесами чи відлагодженнями. Офіційний сайт IDE Clion - https://www.jetbrains.com/clion/ Особливості IDE Clion: Лише платні версії IDE. Підтримувані мови C і C++. Доступні версії під Linux, Windows, macOS. Підтримує такі компілятори: GCC / G++; MinGW; MSVC. Плюси IDE Clion: Зручні інструменти для розробки візуальних інтерфейсів. Зручні механізми відлагодження додатків. Можливості розширення функціоналу плагінами. Інструменти пошуку помилок у коді в потоковому режимі. Мінуси IDE Clion: Відсутня безкоштовна версія цього IDE. Річна підписка від 199 $.   4) Eclipse IDE Eclipse, заснована на платформі Eclipse, є однією з провідних IDE для розробників на C++ та C. Eclipse пропонує підтримку розробки проектів та кероване середовище розробки з різними наборами інструментів. Він також підтримує різні інструменти, сортування, навігацію за гіперпосиланнями, редактор коду з функцією підсвічування синтаксису, інструменти візуального відлагодження та багато іншого. Це безкоштовне ПЗ з відкритим вихідним кодом, що працює з усіма основними ОС, включаючи Windows, Mac OS X і Linux. Eclipse може похвалитися зручним інтерфейсом. Особливості IDE Eclipse: Працює на таких ОС: Windows, macOS, Linux. Працює з такими мовами: C, C++, Java, Perl, PHP, Python, Ruby та інші. Працює з такими компіляторами: GCC / G++; MinGW; Cygwin. Плюси IDE Eclipse: Простота як установки, так і застосування. Зручний механізм розроблення графічних інтерфейсів. Інструмент із відкритим вихідним кодом. Розповсюджується безкоштовно. Кросплатформність. Велика кількість доступних модулів розширення – багато розробників відзначають, що можливості модулів цієї IDE значно випереджають такі в інших середовищах розробки. Мінуси IDE Eclipse: Ряд розробників відзначають незручність використання механізмів автодоповнення під час написання коду.   5) Xcode Xcode – це повноцінна IDE, що включає набір інструментів для розробки, створена компанією Apple для написання ПЗ під macOS, iOS, WatchOS і tvOS. Xcode вважається найкращою IDE для Mac, будучи створеною розробниками самої операційної системи. Офіційний сайт IDE Xcode - https://developer.apple.com/xcode/ Особливості IDE Xcode: Працює з такими мовами, як AppleScript, C, C++, Java, Objective-C. Працює лише на macOS. Використовує Apple LLVM та GCC компілятори. Плюси IDE Xcode: Зручні інструменти для створення програмного забезпечення під комплекс платформ Apple. Механізми автодоповнення коду. Зручні інструменти для роботи із графічними інтерфейсами. Мінуси IDE Xcode: На ОС Windows та Linux ця IDE не працює.   6) Code::Blocks Code::Blocks або CodeBlocks – це IDE з відкритим вихідним кодом, що розповсюджується безкоштовно. Code::Blocks написана на C++ з використанням wxWidgets в якості інструментарію GUI. Code::Blocks – це IDE, що розширюється і налаштовується, яка працює на таких платформах, як Windows, Linux і macOS. Різний функціонал може бути доданий до цієї IDE шляхом встановлення або написання плагіну. Наприклад, завдяки таким плагінам доступні функції компіляції та відлагодження. Code::Blocks підтримує додавання різних, як готових, так і користувацьких плагінів. Розробники можуть легко налаштувати цю IDE під свої потреби, і навіть легко переміщатися інтерфейсом вкладок. Спочатку IDE Code::Blocks був створений для роботи з C++, але тепер ви також можете запускати програми на C та Fortran. Офіційний сайт IDE Code::Blocks - http://www.codeblocks.org/ Особливості Code::Blocks: Підтримує роботу з такими компіляторами: MingW / GNU GCC; MSVC++; Clang; Digital Mars; Borland C 5.5; Open Watcom. Повністю написаний C++; Працює на Linux, Mac та Windows; Підтримує такі мови: C, C++, Fortran; Плюси Code::Blocks: Вбудований відлагоджувач. Кросплатформний. Підтримка паралельного збирання. Є відкритим програмним забезпеченням. Повна підтримка точок зупинки. Інтегроване інтелектуальне підсвічування синтаксису. Досить чуйна спільнота. Можливість налаштування IDE розробниками під «себе». Мінуси Code::Blocks: Ця IDE погано підходить для розробки великих проектів.   7) NetBeans NetBeans – це одне з часто використовуваних розробниками інтегроване середовище програмування C++. Спонсорований компанією Oracle, проект IDE NetBeans був переданий у 2016 році до рук фонду Apache. На сьогоднішній день NetBeans поставляється з відкритим вихідним кодом. Написане на Java, це IDE має можливість працювати на всіх системах, які підтримують Java – Windows, Linux, macOS та Solaris. NetBeans IDE виглядає як інтерфейс із функцією перетягування, спільно зі списком шаблонів проектів. Використовувати NetBeans зручно для створення додатків C/C++ як з динамічними, так і зі статичними бібліотеками. Крім того, воно надає великий набір інструментів для програмістів на C/C++. NetBeans має багато плагінів, які можуть розширити можливості програмного забезпечення. Офіційний сайт NetBeans - https://netbeans.apache.org Особливості IDE NetBeans: Знаходиться під управлінням Apache Software Foundation. Підтримує такі мови: Java, HTML, HTML 5, C, C++ та інші. Працює на Windows, Linux, macOS і Solaris. Підтримується робота з такими компіляторами: Oracle Solaris Studio; GCC/G++; CLang / LLVM; Cygwin; MinGW. Плюси IDE NetBeans: Безкоштовне розповсюдження під ліцензією вільного програмного забезпечення. Зручний інтуїтивний інструмент створення графічного інтерфейсу GUI Builder. Велика кількість розширень. Кросплатформність. Інтелектуальне автозавершення коду. Велика спільнота. Мінуси IDE NetBeans: Користувачі відзначають тривалий запуск додатку. Ряд користувачів відзначають незручність роботи з дебагером.   Висновок Існує досить багато інтегрованих середовищ розробки на C++. Для вибору IDE під розробку на C++, як і будь-якого іншого інструмента розробника, справедливий індивідуальний підхід. Відштовхуючись від поточних завдань, базової ОС, мов, необхідних плагінів, вимог команди та інших, суто індивідуальних факторів розробки, вибір вами кращого середовища програмування C++ буде різним. Ми рекомендуємо обирати середовище розробки з нашого ТОП 7. Якщо ж ви хочете конкретну пораду для початківця – під Windows спробуйте почати розробляти із Visual Studio у безкоштовній версії Community. У якості безкоштовного середовища розробки C++ під Linux спробуйте Code::Blocks і NetBeans. Згадуючи вибір найкращого платного середовища розробки C++ для Linux і macOS, ми рекомендуємо спробувати тріальну версію платної IDE – CLion. У будь-якому випадку, якщо ви плануєте розробляти на C++ протягом тривалого часу, вибір головного інструменту навряд чи буде для вас остаточним. Пробуйте різні варіанти та стежте за нововведеннями і змінами. Розробникам-початківцям на C++ ми рекомендуємо ознайомитися з відео курсами ITVDN: C++ для початківців. C++ Essential. C++ Advanced.

Види 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

На сегодняшний день W3C уже выпустило релиз 5.2. Это второй пересмотр HTML 5, который идет сразу за HTML 5.1, увидевшего свет в прошлом году. В 2014 году мы выразили желание устраивать «ревизию» HTML каждый год. Что же, похоже, наше желание было услышано. Эта статья представляет из себя что-то наподобие обновленного мануала о том, что такое HTML. В прошлом году мы серьезно пересмотрели спецификацию. Мы ввели некоторые новые фичи и убрали то, что на данный момент не является частью современной веб-платформы (или то, что никогда не получало широкой гласности). Как всегда, мы также исправили некоторые замеченные баги спецификации, убедившись, что материал точно соответствует современному изменчивому веб-миру. Было внедрено множество различных фичей. Благодаря Payment Request API процесс ведения коммерции в вебе стал значительно проще и позволил снизить риски, связанные с возможными ошибками в виде багов или невнимательностью оператора. Новые функции защиты, такие как Content Security Policy, защищают пользователей более эффективно, в то время как работа, проделанная в ARIA, помогает разработчикам создавать качественный функционал веб-сайтов специально для людей с ограниченными возможностями. HTML 5.2 делает проверенную систему плагинов устаревшей. Новые технологии или возможности, такие как виртуальная реальность или скоростная передача, теперь разрабатываются как часть веб-платформы. Подобный подход позволяет обеспечить лучший контроль за системой безопасности, часто снижая стоимость разработки, и позволяет больше обращать внимание на создание сервисов, нежели на выбор платформы. Новая документация и исправление багов подняли HTML на новый уровень. Обозначение main – элемента было улучшено для поддержки современных паттернов дизайна, элемент style теперь может быть использован внутри блока body. Численные ограничения на код были упразднены, в то время как некоторые для обеспечения лучшей безопасности наоборот – усилены. Теперь браузеры предоставляют лучшую поддержку для интернациональных email-адресов и позволяют людям писать письма на тех языках, которые они используют в повседневной жизни. И это только несколько красноречивых примеров касательно того, как W3C улучшила HTML, дабы отображать запросы современного веб-рынка. Также существует ещё много изменений, больших и маленьких, в этом обновлении. Вместе с этим обновлением мы передаем привет некоторым членам нашей команды, таким как Стив Фолкнер и Тревис Ляйтред, выступивших редакторами HTML 5.0, Аррон Айхольц – разработчикам новой кодовой структуры HTML 5.1. И также Алексу Данилу. Их вклад был воистину важным, и их усилия послужили строительным фундаментом для всех тех, кто продолжил совершенствовать спецификацию разметки HTML. Также обратите свое внимание на First Public Working Draft HTML 5.3. Это была часть наших планов по созданию новой HTML-рекомендации в 2018 году. Кроме того, некоторые наши планы претерпели изменения, потому что мы стараемся отслеживать, нужно ли что-то изменить \ дополнить в спецификации согласно современным требованиям или нет. Мы стараемся улучшать работу с интернациональными особенностями, доступностью спецификации и учитываем все пожелания сообщества. Сангван Мун продолжает работать как редактор. Кроме того, нашу команду пополнили такие люди, как Брюс Левсон, Патриция Аас, Шветанк Дихит, Ттеренс Еден и Ксяоиян Ву. Еще раз спасибо Стиву Фолкнеру за то, что остается с нами и работает над новыми версиями спецификации. Для нас честь иметь настолько интернациональную команду, и мы верим, что их профессионализм принесет свои плоды. И хотя всегда есть гора достаточно монотонной работы по поддержке технологии, я верю, что этот год будет воистину годом HTML. Веб представляет из себя платформу для каждого, и то, что наша команда объединяет специалистов из великого множества стран, является свидетельством того, что наша работа не напрасна и мы вносим вклад в общее дело веб-разработки. Мы внимательно следим за обновлениями HTML и рады будем сообщать вам наиболее актуальную информацию. Автор перевода: Евгений Лукашук Оригинал статьи