Конец 2025 года — хороший момент, чтобы не гадать о будущем, а опереться на данные. Какие навыки реально ценились работодателями в течение года? Во что люди инвестировали время и деньги, обучаясь? И какие выводы из этого стоит сделать при планировании карьеры в 2026 году? В этой статье используются два независимых международных исследования: World Economic Forum — Future of Jobs Report 2025 Coursera — Global Skills Report 2025 Оба отчёта дают целостную картину того, какие навыки были наиболее значимыми в 2025 году и какие из них сохраняют стратегическую ценность на следующий год. 1. Какие навыки были ключевыми в 2025 году: взгляд работодателей Данные World Economic Forum (WEF) В отчёте Future of Jobs Report 2025 Всемирный экономический форум проанализировал ответы более 1 000 компаний-работодателей по всему миру, представляющих десятки миллионов сотрудников. 🔝 Топ-10 навыков, которые сильнее всего влияли на карьеру в 2025 году: Аналитическое мышление Устойчивость, гибкость и адаптивность Лидерство и социальное влияние Креативное мышление Самомотивация и осознанность Технологическая грамотность Эмпатия и активное слушание Любознательность и непрерывное обучение Управление талантами Клиентоориентированность и сервисное мышление 📌 Ключевой вывод WEF: В 2025 году карьерный рост определялся не отдельными техническими знаниями, а сочетанием мышления, soft skills и способности эффективно работать с технологиями. 2. Какие технические навыки реально осваивали люди в 2025 году Данные Coursera Global Skills Report 2025 Отчёт Coursera основан не на прогнозах, а на реальном поведении пользователей: более 170 млн обучающихся по всему миру данные по тысячам курсов и профессиональных программ связь обучения с запросами бизнеса и рынка труда Это делает отчёт особенно ценным для понимания того, какие навыки имеют практическую карьерную отдачу и сохранят актуальность в 2026 году. 3. Самые востребованные технические навыки по итогам 2025 года (по данным Coursera) 1. Навыки в сфере искусственного интеллекта (AI) AI стал ключевым направлением обучения в 2025 году. Наиболее популярные области: Generative AI Machine Learning Prompt Engineering Использование AI в бизнесе, аналитике, маркетинге и управлении Важный сдвиг 2025 года: Ценится не только разработка AI, но и умение применять его в повседневной профессиональной работе. 2. Data & Analytics Аналитика данных укрепила позиции как одна из самых стабильных карьерных зон. Ключевые навыки: Data Analysis SQL Python для анализа данных Data Visualization (Tableau, Power BI) Роли, которые активно развивались в 2025 году: Data Analyst Business Analyst Product Analyst 3. Облачные технологии (Cloud) Хмарная инфраструктура окончательно стала стандартом. Наиболее востребованные платформы: AWS Microsoft Azure Google Cloud Platform (GCP) 4. Кибербезопасность Рост цифровых сервисов усилил спрос на специалистов по защите данных. Ключевые направления: Основы кибербезопасности Cloud Security Risk & Compliance Network Security Разработка ПО (прикладные навыки) В 2025 году рынок всё больше ценил инженерный подход, а не знание одного языка. Актуальные технологии: Python JavaScript Backend-разработка API и интеграции Базовые DevOps-практики 4. Профессиональные сертификации с наибольшей ценностью Отдельный вывод Coursera — рост доверия работодателей к профессиональным сертификатам. Сертификации, которые показали наибольшую востребованность в 2025 году: Google Professional Certificates (Data Analytics, Project Management, Cybersecurity, UX) IBM Professional Certificates (AI, Data Science, Backend Development) Microsoft Certifications (Azure, Data, AI Fundamentals) AWS Certifications (Cloud Practitioner, Solutions Architect — Associate) Meta Certificates (Frontend, Backend, Marketing Analytics) 📌 Тренд 2025 года: Для junior- и middle-специалистов сертификации всё чаще воспринимаются как альтернатива классическому образованию. 5. Что означают итоги 2025 года для планирования 2026 🔹 Карьерный фокус на 2026 год логично строить на трёх группах навыков: Мышление, адаптивность и устойчивость Коммуникация, эмпатия и лидерство Практические технические навыки + подтверждённые сертификации 🔹 AI и работа с данными перестали быть нишевыми навыками — они становятся базовыми для широкого круга профессий, включая non-tech роли. 🔹 Непрерывное обучение закрепилось как норма рынка, а не временный тренд. Источники World Economic Forum — Future of Jobs Report 2025 https://www.weforum.org/publications/the-future-of-jobs-report-2025/ Coursera — Global Skills Report 2025 https://www.coursera.org/skills-reports/global

Если ты планируешь войти в ИТ и не знаешь, с чего начать — эта статья для тебя. Выбор первого языка программирования похож на выбор первого велосипеда: важно, чтобы он подходил именно тебе, а не был «самым модным». Как карьерный консультант и HR, я опираюсь на реальные кейсы студентов и запросы компаний. Делюсь коротким и понятным планом, который поможет грамотно выбрать свой первый язык. 🎯 Шаг 1. Определи свою целевую сферу Задай себе вопрос: что именно я хочу создавать? Это твой главный ориентир. 🧑‍💻 FrontEnd (веб-сайты, интерфейсы) → JavaScript, затем можно добавить TypeScript, React 📱 Мобильные приложения → Kotlin (Android), Swift (iOS) или React Native 📊 Аналитика, машинное обучение, ИИ → Python 🏦 Корпоративные решения, банковские системы → C# / .NET или Java 🧪 QA Automation (автотесты) → Python, Java, JavaScript 💡 Совет: если пока не определился — выбери универсальный язык для старта, например, Python или JavaScript. 📊 Шаг 2. Проверь актуальность на рынке По данным DOU и Djinni (на 2025 год), топ-5 языков по количеству вакансий: JavaScript / TypeScript Python C# Java PHP JavaScript доминирует благодаря своей универсальности (веб, мобильная разработка, backend).  Python — лидер в области ИИ, автоматизации и научных вычислений.  C# / .NET — популярное решение для бизнеса в Украине и Восточной Европе.  Java — основа для многих международных проектов, особенно в банках и крупном бизнесе. 🔍 Работать с языком, на который стабильно есть спрос — логичный шаг для первой работы. 👶 Шаг 3. Начни с доступного для изучения Даже самый крутой язык не поможет, если ты не сможешь его понять. Вот три языка, с которых проще всего начать: Python — простой синтаксис, читается как английский, используется во многих сферах JavaScript — быстрый результат: написал код — увидел на экране C# — хорошо структурирован, помогает быстро освоить основы ООП 🧠 Если тебя пугает синтаксис или ты сомневаешься — посмотри бесплатные вводные уроки. На ITVDN есть 3 открытых занятия, которые помогут выбрать направление без риска. 🔮 Шаг 4. Смотри в будущее Программист не учит один язык на всю жизнь. Но первый создает базу, на которую легко ложатся следующие. Хочешь стать FullStack-разработчиком? Комбинируй JavaScript (FrontEnd) + Node.js или C# (BackEnd) Хочешь пойти в Data Science — начинай с Python, а затем добавь библиотеки как Pandas, NumPy, TensorFlow 💡 Вывод Не существует «идеального» языка для всех. Выбор должен быть практичным:  ✅ под твои задачи  ✅ с учётом спроса  ✅ с учетом сложности на старте 🎓 Выбирай путь, который не только приведёт к первой работе, но и сделает обучение интересным. И помни: важна не конкретная технология, а твоё желание учиться!

Введение Многие разработчики заблуждаются, считая, что CSS – единственный способ работы с анимацией в WEB. CSS становится все более и более популярным, он считается самым надежным и удобным инструментом создания анимаций. Но это не означает, что он лучше, чем JavaScript. В этой статье мы расскажем, почему лучше использовать JavaScript, а не CSS, а также разоблачим мифы, связанные с CSS. 1. JQuery JavaScript и JQuery ошибочно объединяют. Анимации, разработанные с JavaScript – быстрые и динамичные, тогда как анимации JQuery – медленные. Причина в том, что несмотря на его мощные инструменты, JQuery  не был создан для анимации. 2. Отсутствие управления вращением и позиционированием Для выполнения анимации необходимо использовать элементы управления вращением и определением позиции. В CSS все эти функции содержатся в свойстве «transform». Это создает проблемы для уникальной анимации чего-либо через один общий элемент. Например, анимирование «rotation» и «scale» отдельно, с разными таймингами, возможно только с JavaScript, потому что он позволяет использовать различные функции, не поддерживаемые CSS. CSS удобно использовать только для простой анимации. 3. Производительность с Velocity и GSAP Velocity и GSAP – наиболее популярные библиотеки JavaScript. Они работают без JQuery. Нет уменьшения производительности, так как эти библиотеки работают за пределами основных анимаций JQuery. Velocity и GSAP можно применять даже, когда jQuery не используется на странице.  * Работа без JQuery * / Velocity(element, { opacity: 0.4 }, 900); // Velocity TweenMax.to(element, 1, { opacity: 0.4 }); // GSAP В приведенном выше примере Вы видете, что velocity использует тот же синтаксис, даже когда JQuery не применяется. Он просто смещает все элементы в правильном направлении, чтобы создать пространство для целевых элементов. 4. GPU-фактор Полностью оптимизированный код с GPU отлично подходит для выполнения различных задач, включая преобразование матриц и изменение прозрачности, поэтому все ведущие браузеры сначала перенаправляют такие задачи от CPU к GPU. Нужно разделять все анимационные элементы на разные слои GPU. Таким образом мы избавимся от необходимости вычислять каждый пиксель в каждой минуте. Можно сэкономить много времени, просто перемещая один пиксель за другой. Обратите внимание: нет необходимости делать собственный слой для каждого элемента из-за ограничения видеопамяти GPU. 5. Быстрые анимации JavaScript JavaScript обходит CSS в производительности и скорости. JavaScript достаточно универсальный, чтобы создать впечатляющую 3D демо-анимацию, которую Вы можете увидеть через WebGL. Он достаточно быстрый, чтобы построить мультимедийный тизер, разработанный с использованием Flash, или After Effects. С JavaScript это легко сделать с помощью canvas. Вывод Данная статья доказывает, что анимация JavaScript более быстрая, по сравнению с анимацией CSS. Но это не означает, что CSS не стоит использовать. Он хорошо подходит для простой анимации, но если Вы хотите сделать анимацию более гибкой, Вам лучше использовать JavaScript. Источник: http://www.script-tutorials.com/css-vs-javascript-myths-fall-to-pieces/

Введение Давайте рассмотрим практику написания AngularJS приложения. Приведенные ниже примеры помогут вам писать приложение правильно, чисто и более обдуманно. С помощью применения данной практики вы разработаете приложение, которое будет разделено на блоки, что в конечном итоге поможет строить правильную архитектуру приложения. Итак, начнем. 1) Создавая новое приложение, старайтесь разделять модуль, контроллер, фабрику, вынося их в отдельные файлы. Этот прием имеет ряд приимуществ: улучшается читаемость приложения улучшается рефакторинг приложения легче производить дебаггинг приложения //плохая практика angular        .module('app', ['ngRoute'])        .controller('myController', myController)        .factory('myFactory', myFactory); function myController() { }; function myFactory() { }; //рекомендуется //myapp.module.js – файл модуля angular        .module('app', ['ngRoute']); //mycontroller.js – файл контроллера angular .module('app') .controller('myController', myController); function myController() { }; //myfactory.js – файл фабрики angular        .module('app')        .factory('myFactory', myFactory); function myFactory() { }; 2) Старайтесь оборачивать код в самовызывающиеся функции. Это позволяет : сохранить переменные от глобального объекта scope предотвратить перетирание глобальных переменных (т.к. они локальны) при минификации кода помогает избежать путаницы переменных //плохая практика angular        .module('app')        .factory('myfactory', myfactory); function myfactory() { }; //рекомендуется (function () {     'use strict';     angular         .module('app')         .factory('myfactory', myfactory);     function myfactory() { }; })(); 3) Старайтесь придерживаться иерархии именования. Это поможет правильно структурировать приложение, что в итоге приведет к правильной архитектуре программы. Избегайте создания модуля через переменную и используйте цепочный синтаксис (в виде цепочки) //плохая практика var app = angular.module('app', [        'ngAnimate',        'ngCookies',        'firebase' ]); //рекомендуется angular        .module('app', [        'ngAnimate',        'ngCookies',        'firebase' ]); 4) Используйте именованные функции. Код становится более читабельным и куда лучше тестируется.  //плохая практика angular        .module('app')        .controller('mycontroller', function () { }); //рекомендуется (обратите внимание на контроллер он вынесен в отдельный файл //от модуля) //myapp.module.js – файл модуля angular        .module('app', ['ngRoute']); //mycontroller.js – файл контроллера angular .module('app') .controller('myController', myController); function myController() { }; 5) Используйте controller as нотацию вместо просто controller. Она более читабельна, помогает не запутаться в коде      //плохая практика     <div ng-controller=”myController”>{{title}}div>     //используем     <div ng-controller=”myController as mycontroller”>{{mycontroller.name}}div> 6) Используйте слово vm(ViewModel) внутри контроллера вместо ключевого слова this. Это поможет избежать подмены контекста внутри функции.  //антипаттерн function mycontroller () {        this.name = {};        this.deleteSome = function () {}; }; //паттерн function mycontroller () {        var vm =  this;        vm.name = {};        vm.deleteSome = function () {}; }; Это лишь базовые приемы, которые вы можете использовать в своей практике. Они помогут вам избежать некоторых проблем в вашей роботе и сделать код вашего приложения чище и понятнее. Желаю вам хорошего кода и светлых идей.

Введение  Подошел к концу 2014 год и самое время спросить себя: «Какие тенденции будут преобладать в сфере веб-разработки в 2015 году?». Представляем вашему вниманию подборку трендов, которые, по нашему мнению, будут популярны в следующем году. 1. Адаптивный дизайн Вместе с ростом популярности на планшеты начал расти спрос на адаптивный дизайн, сегодня это - неотъемлемая часть любого сайта. С помощью “Responsive Design” пользователь сможет спокойно просматривать Ваш сайт на любом девайсе, будь то PC или мобильный телефон. Зачем Вам адаптивный дизайн? Ответ простой, сейчас все больше пользователей просматривают новости через разные устройства с разным расширением экрана, поэтому выбор ресурса напрямую зависит от удобства его использования на всех носителях. Главный критерий выбора – ширина контента не должна превышать ширину экрана, иначе пользователю будет неудобно воспринимать информацию и он к вам больше не вернется.  2. Плоский дизайн (Flat Design) Плоский дизайн начал набирать свою популярность после релиза Windows 8, благодаря компании Microsoft и ее Metro-стилю. Концепция плоского дизайна заключается в том, что двухмерные изображения не перегружают восприятие пользователя и уменьшают загруженность ресурса. В плоском дизайне отсутствуют лишние эффекты: тени, блики и градиенты, в противовес им выдвигаются яркие цветовые решения. 3. Карточный дизайн Карточный дизайн — это способ подачи контента на страницах сайта. Каждая карточка содержит в себе определенную информацию, это дает ресурсу возможность концентрировать внимание пользователя и легко группировать содержимое сайта.  Главное преимущество данного типа дизайна — это легкость взаимодействия пользователя с Вашим сайтом, ведь карточки легко можно опубликовать на своей странице в социальных сетях, сохранить в избранное или прокомментировать. Первопроходцами карточного дизайна считаются  Pinterest и Google+. Благодаря своей отзывчивости и адаптивности все больше сайтов переходит на карточный дизайн. 4. Фоновые изображения и видео За последнее время все большую популярность набирают ресурсы с широкоформатным изображением  или видео на фоне,  с небольшой цитатой поверх него. Этот прием идеально подходит для сайта-портфолио или сайта-визитки. 5. Рисованные иллюстрации и шрифты Сайты с рисованной типографикой или иллюстрациями подкупают своей неповторимостью. Все больше сайтов начали использовать в своем дизайне элементы, разработанные вручную, именно под определенный проект. Эти детали делают сайт уникальным и запоминающимся, пользователю приятней пользоваться таким сайтом, он захочет рассказать о нем другу и обязательно вернется сам. 6. SVG иконки и анимации SVG — это специальный язык разметки векторной графики, который разрабатывается W3C с 1999 года. Возможность создавать SVG изображения доступна в большинстве векторных редакторов: Illustrator, Corel Draw или Sketch. SVG-графика часто используется для создания иконок, они выглядят качественней и легко адаптируются под разные расширения экрана. И напоследок, с помощью SVG можно создавать анимированные иконки.  Источник: http://www.sevensignature.com/blog/articles/top-10-sign-things-come-2015-web-design-trends/

Тренды. Самые высокие зарплаты Junior, Middle, Senior инженеров. Самые высокие зарплаты руководящего инженерного звена. Зарплаты других IT-специалистов. Самые высокие зарплаты в США, Европе и остальном мире. Данные для рейтинга. Levels.fyi – компания, базирующаяся в США – недавно опубликовала годовой отчет за 2023 год с перечнем компаний, городов, тайтлов и различных трендов, имеющих крупнейшие денежные вознаграждения. Согласно информации на сайте компании, аналитические материалы Levels.fyi позволяют людям строить лучшие карьеры в IT, отталкиваясь от честных и прозрачных зарплат. Давайте вместе посмотрим, какие IT-специалисты в каких уголках мира получают больше всего?   Тренды Сначала узнаем, как изменились зарплаты IT-специалистов по сравнению с 2022 годом. На картинке ниже – медианные ЗП в долларах США (суммарно за год) для каждого семейства специальностей. Наиболее ощутимый прирост имеют технические менеджерские направления, полный штиль у Data Scientists, а небольшой отрицательный прирост – у разработчиков программного обеспечения и дизайнеров продукта.   Самые высокие зарплаты Junior, Middle, Senior инженеров Рассмотрим годовые компенсационные медианы инженеров, имеющих опыт от 0 до 15+ лет в разработке. В каждом разделе будет ТОП-7 компаний, наиболее щедро вознаграждающих своих работников в зависимости от их опыта. Составители рейтинга отмечают, что в понятие компенсации входят зарплата, акции и бонусы, полученные за прошлый год, но для простоты мы отождествляем "компенсацию" и "зарплату" в данной статье. Инженер начального уровня (от 0 до 2 лет опыта) Рейтинг включает инженеров уровня Intern/Trainee/Junior. Обычно это выпускники с небольшим или вообще нулевым опытом в отрасли. Они развивают и поддерживают компоненты низкой и умеренной сложности, используя наставничество и поддержку членов команды с бóльшим опытом. Здесь вам могут быть знакомы Figma и LinkedIn. Первая компания – всемирно известный разработчик онлайн-инструмента для дизайнеров, а вторая – социальная сеть для установки деловых связей. Engineer (от 2 до 5+ лет опыта) Данный тайтл можно приравнять к Middle. Сюда относятся специалисты, которые работают над компонентами средней и высокой сложности, и даже способны управлять небольшой командой или проектом. Могут менторить и консультировать менее опытных инженеров, проводить код-ревью, работать над небольшими проектами от начала до конца. Пределы ответственности такого специалиста отличаются от команды к команде. Во многих компаниях они могут работать постоянно на этом уровне, не опасаясь, что их уволят за то, что они не продвигаются по карьерной лестнице дальше. Senior Engineer (более 5 лет опыта) Сеньоры – от них ожидается управление другими и продвижение собственных комплексных технических инициатив. Могут выполнять визионерские функции, определяя дальнейший вектор движения команды. Также способны влиять на другие команды в пределах компании. Их роль больше охватывает дизайнерские задачи, нежели реализацию – в зависимости от размеров и ожиданий компании. Обычно таких специалистов в компании не более 30%.   У кого в IT самые большие ЗП? Рейтинг мира. Наивысшие зарплаты руководящего инженерного звена Staff Engineer – инженер управленческого аппарата Эта должность предусматривает 10+ лет опыта, и является достаточно желанной по сравнению с Junior, Middle и Senior. Менее 10% персонала занимают эту позицию, при этом их влияние достаточно масштабно и простирается на разные организации. Инженерам данного звена доверяют важные бизнес-проекты и установку технического видения для одной или нескольких организаций. Наибольшее вознаграждение получают именно staff-инженеры из OpenAI – компании, которая в конце 2021 года выпустила в свет знаменитый ChatGPT и недавно имела бурный скандал вокруг увольнения гендиректора OpenAI Сэма Альтмана. Principal Engineer – главный инженер Должность предполагает 15+ лет опыта, причем менее 3% персонала доходят до этого уровня. Главный инженер характерен для компаний среднего и большого размера, а в маленьких обычно отсутствует. Влияние Principal Engineer может распространяться как на всю компанию, так и на индустрию. От этих специалистов ждут полной автономии в работе. Аналитики рейтинга отмечают: данный тайтл присущ малому проценту людей в компании, поэтому некоторые компании не имеют информации в достаточном количестве, чтобы быть включенными в этот список.   Зарплаты других IT-специалистов. IT-компании с самыми большими ЗП Аналитики данного отчета разработали стандарт уровней для менеджерских ролей и ролей индивидуального специалиста (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 нам пока не интересен, мы его рассматривать не будем, чтобы не путаться. На этом урок завершается. На следующем уроке, в первой части, мы рассмотрим с вами, как пользоваться элементами управления, как привязывать к ним обработчики событий и как взаимодействовать с ними.