Если вы тоже пробовали «вайб-кодить», сжигали тонны денег на подписки, получали много вроде бы почти готового кода, который потом не могли довести до прода, — эта статья для вас. Я не буду говорить, что ИИ — это плохо, так как считаю, что ИИ — это очень сильный инструмент. Но топором махать умеючи надо: а то вместо того, чтоб дом срубить, да дров нарубить, оттяпаешь себе палец.

Я давно в теме и уже писал на Хабре про то, как мы делали техдокументацию для ЦФА с нейронкой. Но тогда это была командная работа, а сейчас я хочу рассказать про то, что происходит, когда ты один, у тебя есть LLM, и ты пытаешься сделать продукт. Есть ненулевая вероятность, что корпоративная разработка перестроится, и то, что сейчас десятки или сотни специалистов делают долго и дорого, с ИИ можно делать иначе. Может быть эффективнее. Может быть нет. Вот про это и расскажу.

Эйфория

Когда про вайбкодинг кричали с каждого утюга и умного чайника, для погружения в соло-разработку я решил попробовать Codex. Но бесплатный пробный тариф закончился раньше, чем я успел что-либо понять. Попытка купить подписку не увенчалась успехом: санкции, блокировки, сомнительные способы оплаты и прочее.

Но не в наших правилах сдаваться, так что аналог, доступный в РФ, был найден. Выглядело похоже. Поигрался с пробником и купил подписку Pro на год. Решил сделать сайт с аналитикой по цифровым финансовым активам, так как был в теме, а об удобном едином источнике развёрнутых данных по всему рынку не знал. Парсинг открытых источников, удобная инфографика, актуальная информация по всему рынку в одном месте — казалось бы, ресурс будет полезен для потенциальных инвесторов.

Это была первая попытка решить с ИИ более или менее большую задачу и я вёл себя как с командой людей: иногда обсуждал с ИИ абстрактные темы, шутил, приводил неочевидные примеры, — создавал «атмосферу». Выстраивал производственные процессы, определял DOR и DOD, придавал виртуальной команде не только профессиональные черты, но и персональные характеры и, конечно, имена. Устраивал мозговые штурмы, груминги с рассмотрением с разных точек зрения и спорами как внутри, так и с привлечением внешних экспертов в виде других LLM.

Мне казалось, что это помогает — как с людьми. Казалось, что это создаёт инновационный фон, в котором работа идёт лучше и в спорах рождается истина. Со стороны, видимо, это смотрелось странно, очень напоминало игру в стратегию с элементами РПГ. А может и шизофрению, когда тихо сам с собой ведёшь беседу и радуешься завязавшемуся спору, как ребёнок новой игрушке.

Это была эйфория. Виртуальная команда почти сама что-то уверенно делала, искала информацию, проверяла гипотезы, сама уточняла цели, нарезала задачи, проектировала, грумила и, конечно, меняла файлы проекта, наращивая код и инфраструктуру. Проект быстро обрастал «мясом» и казалось, что доделать остаётся совсем немного — ну, пара итераций, и всё будет готово. Чутьё подсказывало: скоро будет прорыв. Знакомая картина?

Но прорыва не было. Я промучался пару месяцев и забросил. А если быть честнее — еле-еле заставил себя дотолкать хоть что-то до прода уже чисто из принципа.

Через несколько месяцев я с трудом опубликовал хоть как-то работающий сайт, убрав оттуда все наполеоновские планы и грандиозные перспективы развития. Динамический парсинг, регулярное обновление данных, дриллинг по данным, по собранной наполовину вручную базе — всё это исчезло. Сайт стал статичным, который просто открывается и не вызывает у пользователя истерику.

Я тогда пока не осознал проблему. Я просто настолько устал добиваться простого полезного инкремента в почти готовый продукт, что больше попыток повторить такой опыт ещё пока не делал.

Осознание пришло позже.

ИИ — не команда людей

Когда я начал работать с ИИ, то делал это так, как привык с людьми: обсуждал с ним идеи, шутил, приводил примеры из жизни, строил «команду». Мне казалось, что это создаёт контекст, в котором работа идёт лучше. Как с командой: если людям комфортно, они работают продуктивнее.

Кажется естественным, что я антропоморфизировал LLM. В конце концов, она все-таки разговаривает. К тому же научная фантастика научила меня ожидать, что говорящие компьютеры будут разговаривать как люди и с ними можно даже шутить (конечно, если это не HAL 9000).

На LLM этот принцип работает с точностью до наоборот.

Каждое слово, которое я писал в чат, — притча или шутка, любое абстрактное рассуждение, пример «из жизни» — всё это оседало в контекстном окне. Но модель не «понимала» юмор и не «вдохновлялась бирюзой», как бы мне ни хотелось, а просто учитывала всё как данные. А когда я потом просил поправить одну функцию, как-то неожиданно выстреливала не та информация и модель начинала переписывать архитектуру — потому что в контексте было полно «второстепенных» сигналов, которые она считала такими же важными, как задачи, ведущие к основной цели.

Шутка стреляла. Но не там, где я хотел.

В остальном общение так похоже на человеческое, что невольно всплывают в голове проверенные подходы и ловишь себя на мысли, что пишешь в ИИ «пожалуйста».

Это называется забивание контекста. Это не баг, а фича архитектуры LLM.

Мы, люди, умеем фильтровать: на совещании можем пошутить, обсудить посторонние темы, отпуск и хорошую погоду, а потом вернуться к делу — и в голове у нас останется суть, а не весь шум. А LLM так не умеет: для неё всё, что попало в контекст, одинаково значимо, пока не доказано обратное. Когда контекст переполняется, модель начинает «плыть»: путаться, противоречить себе, забывать, зачем мы вообще начали.

Я потом посмотрел статистику в личном кабинете. У одного из запросов на вход было 39 650 токенов, а на выход — 103 токена. Вдумайтесь: 99,7% входных токенов — это то, что модель перечитывала, чтобы сгенерировать 103 токена ответа. И это только один запрос. А если таких запросов 20–30 до первого полезного инкремента? Контекст растёт лавинообразно, и каждый следующий запрос стоит дороже, а качество падает.

Есть исследования, которые это подтверждают. В работе «Structured Session Management for LLM-Augmented Software Development» (Zenodo, 2026, DOI: 10.5281/zenodo.19410828) вводится понятие «session entropy» — накопление противоречий и потерь контекста в длинных сессиях. Исследование, «Output-Maximizing Long-Context Programming» (Zenodo, 2026), прямо критикует итеративные воркфлоу и предлагает генерировать большие артефакты за один проход, вместо того чтобы дробить работу на мелкие шаги.

Сейчас будет важная мысль: Agile и MVP — это костыли под человеческие ограничения. Человек не может долго держать фокус, ему нужны короткие итерации и обратная связь. LLM этих ограничений не имеет — но имеет своё: контекстное окно. И когда мы применяем к ИИ человеческие практики, мы не помогаем ему, а забиваем ему голову мусором.

К примеру, ИИ по умолчанию склонен делать заглушки. «Вот тут пока заглушку, потом доделаем, вот тут заготовку на будущее». В разработке с людьми это признак того, что команда понимает, что делает, и легко возвращается к задаче, когда приходит время. Съесть слона по кускам — это так понятно и привычно. С ИИ это уводит в дебри и в итоге ломает всё.

Почему так? Потому что LLM обучали на «лучших практиках». А для разработки цифровых продуктов сейчас — это Agile, Scrum, итеративная разработка, MVP — всё то, что создано для людей. Есть, конечно, и ортодоксы, но это больше связано с бюджетами и годовыми планами, и количество таких практик в датасетах для обучения сильно меньше. В обучающих данных большинство примеров и практик, подходящих для команд людей, и они находятся ближе к центру распределения вероятностей. Модель выдаёт то, что наиболее одобряемо, — типовое, безопасное, «среднее». Она не «понимает», что работает с другим исполнителем. Она делает то, что делали бы люди, и так, как они бы обычно делали.

Но модель — не человек, и через несколько итераций она легко забывает, зачем была заглушка. Или путается. Или решает «улучшить» заглушку, ломая то, что уже работало.

Теперь я почти не даю делать заглушки, с ИИ это только усложняет достижение цели. Сразу делаем достаточный для использования продукт, тем более ИИ не осторожничает и может сразу выдавать крутейшие решения, к которым команда людей пришла бы далеко не сразу. Да, это дольше на старте. Но количество итераций сокращается, и контекст не забивается мусором.

Пример. Когда я делал торгового бота, после получения рабочего продукта я захотел улучшить интерфейс: сделать фон контрастнее, выровнять иконки, поправить текст. Простая задача, правда? Я в системном промпте попросил сделать именно это, а модель, не сделав простые изменения там, где надо, по-тихому внесла много изменений совсем в других местах, и я обнаружил это далеко не сразу, а потом, чтобы восстановить работоспособность, пришлось откатывать и терять в том числе множество полезных изменений. На основе недоделанных предложений и второстепенных, по моему мнению, обсуждений из прошлых итераций она переписала архитектуру и ключевую логику — и всё развалилось.

Если бы я сразу продумал интерфейс и зафиксировал в ТЗ, не пришлось бы итеративно доводить его до ума с риском порушить ранее выстраданное. И косметика не привела бы к переделкам там, где уже всё работало и меня устраивало.

Кстати, в Китае это, кажется, понимают лучше. Пока на Западе два лагеря спорят, что делать — хоронить Agile или адаптировать, — китайские команды просто делают и перестраивают процесс под инструмент. Подход называется AI-native процесс разработки, если что. Прагматично.

Метод тыка

После наступившего разочарования я забросил разработку. Подписка осталась, но я перестал туда заходить. Казалось, что это не для меня: слишком сложно, слишком дорого, слишком непредсказуемо.

А потом совершенно случайно нащупал другой подход, когда просто проверял, как работает API. Открыл чат с LLM, попросил вывести команды для диагностики через терминал. Сам понимал их с трудом, но по инструкции копировал и выполнял. Ответы, включая множество неудачных, я возвращал обратно в чат и получал новые инструкции. Так как многие данные у ИИ или не совсем актуальны для разработки в РФ, особенно в части блокировок ранее обычно просто доступных библиотек и сервисов, то итераций с терминалом было очень много, но зато не нужно собирать исходный код и получать ошибку только после сборки.

С терминалом мне понравилось куда больше, и получалось выяснять важные детали куда быстрее. Например, бот в мессенджере — как обычно принято и как ИИ рекомендовал для продвижения — я решил всё же не делать, хотя и нашёл рабочий вариант. Шаг за шагом что-то заработало.

Потом скопировал код в блокнот, сохранил файлы, установил окружение, нужные библиотеки, и в итоге собрал продукт. По факту перешёл на разработку с чатом LLM, блокнотом и командной строкой. UAT проходил сам в браузере, иногда собирая данные из режима разработчика. И так постепенно получилось вполне рабочее расширение для браузера.

В процессе я начал замечать закономерности. Одна из них — контекст.

Неочевидное решение проблемы контекста

Когда я понял, что контекст — это главная проблема, я начал думать, как её решить. И тут мне помогла теория решения изобретательских задач. Один из её принципов: если система упирается в противоречие, ищи решение не в очевидном месте, а на периферии. Не там, где все ходят.

Очевидное решение было: «писать промпты короче». Но это не работало — контекст всё равно забивался, потому что в одном чате смешивались разные темы.

Неочевидное решение: разделить чаты. Не «один чат — одна задача», а «один чат — одна тема». Белая книга — отдельно. ТЗ — отдельно. Разработка — отдельно. Маркетинг — отдельно. И не смешивать.

Это выглядело нелогично: зачем мне три-четыре чата, если можно всё в одном? Раньше я так и делал — как с командой, где все обсуждают всё вместе. Но с ИИ это не работает. И разделение чатов оказалось тем самым неочевидным решением, которое сработало.

Дополнительный эффект: я стал точнее формулировать. Потому что перед тем, как перейти в следующий чат, я должен был вычитать результат предыдущего и понять, что именно передать. Это дисциплинирует.

Артефакты собираю в Obsidian — в Markdown-формате, чтобы всё было под рукой. Понравилось, что чат со всей историей доступен с разных устройств. Вполне можно продвигаться и со смартфона: ясно, что исходный код пересобрать неудобно, но подумать над ролями или сегментами пользователей и поискать информацию для маркетинга — вполне.

Технологическая спираль провернулась

Я не сразу понял, что мой подход — это, по сути, возврат к классической модели: сначала требования, потом проектирование, потом код, потом тестирование. Без итераций или с их минимальным количеством. Даже состав участников на этих этапах был разный, и они могли между собой особо не пересекаться. Без «давайте сделаем MVP и посмотрим, и допилим».

Вернулся обратно в чат с LLM и блокнотом не потому, что «старое — правильное». Я пришёл к этому потому, что итераций должно быть меньше — иначе контекст забивается. Контроля должно быть достаточно, чтобы принимать решения. Развитие идёт по спирали: мы возвращаемся к старым методам, но на новом уровне.

Исследования это подтверждают.

К примеру, работа «Evaluating Classical Software Process Models as Coordination Mechanisms for LLM-Based Software Generation» (arXiv:2509.13942v1, 2025) сравнила Agile, Waterfall и V-модель как способы координации для LLM. Результат: Waterfall оказался наиболее эффективным. Agile дал лучшее качество кода, но ценой более высокой вычислительной стоимости — а для соло-разработчика это твои токены и твоё время.

Другая работа, «SDAD: Spec-Driven Agentic Development for the AI-Native SDLC» (arXiv:2608.20341v1, 2026), прямо говорит о «Waterfall Resurgence» и «BDUF 2.0» (Big Design Up Front). Смысл в том, что скорость агентов не отменяет инженерную дисциплину — она перемещает её вверх по потоку, в точность спецификаций, явные gates и проверяемую provenance.

То есть я не «изобрел велосипед». Я интуитивно пришёл к тому, что другие формулируют как методологию. Просто сформулировал это как «не давать контексту забиваться».

Отдельно про ИИ-агентов.

Про них сейчас много говорят: мол, агенты всё сделают сами, надо только правильно настроить. У меня опыт в этой теме небольшой, и я не буду делать громких заявлений. Но поделюсь ощущением.

Мне кажется, что пока не разобрался с ИИ в обычном чате — лезть в агентов не только бесполезно, но даже опасно. Это как, не научившись медленно ездить с инструктором по учебной площадке, сразу влезть за руль гоночного болида или даже просто слишком резвой спортивной машины. В целом если очень хочется, то можно, и скучно не будет, но скорее выгоришь и разобьёшься, чем доберёшься до пункта назначения.

У меня был опыт с агентами, который закончился пока неудачно. В той среде, где я пробовал, всё выглядело солидно: файлы создаются, структура растёт, работы вроде бы много. Но довести до прода не получилось. И самое неприятное — было трудно понять, где именно всё пошло не так. В разработке с людьми, когда команда делает много файлов и уверенно двигается, это признак того, что процесс идёт правильно. С ИИ это может означать совсем другое: он уходит в такие дебри, что проще стереть и начать заново, чем разбираться, как так получилось.

Поэтому я для себя решил: сначала нужно научиться работать с ИИ в чате. Понять его ограничения, научиться управлять контекстом, выстроить процесс. А агенты — это следующий уровень. Доверять чьи-то жизни или даже критическую информацию, пока не разберёшься как следует, явно не стоит. Может быть, когда-нибудь, когда правила Айзека Азимова будут вшиты в корневой промпт. Но не сейчас.

Некоторые мои правила

Обычно прошу нумеровать вопросы, так, чтобы удобнее комментировать выдачу и не путаться. В системном промпте я запретил одновременно существенно продвигать разные варианты без выбора основного. Бывает, что ИИ выдаёт несколько вариантов действий. Я отвечаю по одному, не фокусируюсь на другом, и мы идём дальше. Потом дочитываю вариант два — там интересные мысли. Пишу промпт. Но вторая итерация сместила контекст.

Переделка архитектуры или корневой логики — только по прямому указанию или после предварительного согласования. Большие переделки оценивать и предварительно согласовывать. Часто после начала разработки новые идеи или серьёзные изменения требований лучше начать заново в новом контексте, чем переделывать в старом.

Сбор контекста чата для передачи в другой теперь делаю регулярно, это похоже на точки отката или передачу задачи другой команде. Иногда такой контекст закидываю в другие LLM с заданием дать конструктивную критику. Собираю разные мнения и устраиваю спор, тут главное не увлекаться слишком. Однажды даже была мысль собрать разные модели в роли советников и устраивать показательные придворные словесные дуэли, а я в роли верховного арбитра, но кажется, это уже слишком. Тема для фантазёров тут обширная, кажется, скоро продуктивные системные промпты будут вполне себе ходовым товаром.

ИИ — это очень сильный инструмент. Но не волшебная палочка. Любым мощным инструментом необходимо сначала научиться правильно пользоваться. Мы все в опасности, если проверенные рабочие подходы для людей из середины нормального распределения будут основой для датасетов для общения ИИ, и промпты не будут это учитывать.

Пока писал эту статью, случилась забавная вещь. Я работал с LLM в одном длинном чате: загружал примеры статей, правила, обсуждал структуру, правил формулировки. Мы прошли вместе несколько версий текста — сначала черновик, потом редактуру, потом ещё раз редактуру. И вот на каком-то этапе я присылаю свою финальную правку: убрал в начале упоминание конкретной модели, хотел плавно подвести к этому дальше по тексту.

А в ответ получаю текст, где эта правка откатилась. Модель вернула мою старую формулировку почти в самое начало. Как будто моих правок и не было.

Я спрашиваю: «Как ты оцениваешь запылённость текущего контекста? Ты явно поменял текст, который я правил, и вернул то, что я убрал». Я это называю запылённостью контекста: когда в диалоге накапливается много второстепенного и модель перестаёт различать, что важно, а что нет. Это не совсем полная аналогия загруженности, ближе к термину «забивание».

И получаю честный ответ. Модель сказала: да, контекст запылён. У неё в памяти лежат несколько версий текста — первая, вторая, третья, моя правка. И когда она собирала «цельный текст», она «схватила ту, которая первая попалась» или «наиболее полную по её ощущению». Не ту, что я только что прислал.

Я сидел и думал: это же ровно то, о чём я пишу статью. Модель не умеет чётко разделять «вот это самая свежая версия, работай только с ней». Ей нужно явно сказать: «вот финальная версия, всё остальное забудь». Она не понимает, что мои правки — это не просто «ещё один текст в контексте». Это новый источник истины, который отменяет предыдущие.

И главное — это не баг. Это та же самая природа LLM, о которой я писал выше. Для модели всё, что в контексте, одинаково значимо, пока не доказано обратное. Четыре версии статьи для неё — это четыре равноправных набора данных. И она берёт тот, который «вероятнее» — то есть ближе к центру распределения, к тому, что чаще встречалось в обучающих данных. А не тот, что я только что прислал.

Я потом пересобрал текст у себя: сам склеил все правки в один файл, отправил заново одним куском и сказал: «Работаем только с этим. Всё, что было раньше, — не существует». И это сработало.

С тех пор я всегда так делаю с большими текстами. Не «вот тебе правка, примени к предыдущей версии», а «вот тебе финальная версия целиком, остальное забудь». Иначе получается как у нас с этой статьёй: пишешь про перегрузку контекста — и сам в неё попадаешь.

Мета-ирония, конечно. Но зато на своём опыте убедился, что это работает именно так, как я описываю.

Что я вынес из этого опыта

Главное, что я вынес из этого опыта: не надо впрямую переносить на ИИ человеческие практики. Agile, MVP, короткие итерации, «атмосфера в команде», настроение, поручения в стиле «додумай сам» — всё это создано для людей. У ИИ другие ограничения, и с ними надо работать иначе.

Я знаю, что многие выстраивают производственный процесс вайб-разработки на основе лучших работающих корпоративных практик. Пытаются нащупать привычные точки контроля. Но при большом потоке информации, который генерирует ИИ, это, на мой взгляд, бесполезно. В моём случае я понял, что не успеваю отслеживать все изменения, которые вносит модель. А модель этими изменениями может кардинально поменять вектор развития. И доверять ей по привычке, как человеку — «раз исполнитель уверенно говорит по теме и результаты показывает, значит всё нормально», и смотреть можно только в привычных ключевых точках — не работает.

Конкретно для меня это значит:

Меньше итераций. Чем меньше итераций, тем меньше мусора в контексте. Тем точнее промпты. Тем лучше результат.

Точнее и полнее промпты. Прежде чем идти в следующий чат, надо вычитать результат предыдущего и понять, что именно передать. Это дисциплинирует.

Отдельные чаты под каждую тему или цель. Белая книга, ТЗ, разработка, маркетинг — всё отдельно. Не смешивать.

Не давать делать заглушки. Сразу рабочий продукт. Да, дольше на старте, но меньше переделок потом.

Контролировать изменения архитектуры и ключевой логики. Переделка — только по прямому указанию, а лучше в отдельном новом контексте. Иначе модель перепишет половину приложения, когда ты просил поправить кнопку.

У меня два доведённых до результата пет-проекта. Первый — торговый бот для одного из брокеров: расширение для браузера, сигналы, лимитные заявки, управление позициями. Сделал за две-три недели. Второй — аналитика цифровых финансовых активов: агрегатор данных, парсинг открытых источников, инфографика. Занял полтора-два месяца, дался тяжело. Разница между проектами для меня показательна: бот я делал после того, как нащупал подход. Аналитику — до, когда ещё пытался работать с ИИ как с командой людей. Отсюда и результат.

Это не «правильная методология». Это то, что сработало у меня. У кого-то может быть иначе. Но если вы тоже пробовали вайб-кодить, сжигали токены и не могли довести проект до прода, — может быть, дело не в инструменте. Может быть, дело в том, что мы относимся к ИИ как к человеку. А он — не человек.

Также подписывайтесь на мой ТГ, который я почти не веду.

Однажды, в самом начале карьеры, когда я была молода и горяча, мы пилили приложение. Большое, серьёзное, адски сложное и практически неподъёмное. Сидели до ночи, заливались литрами кофе, выходили в выходные и на ноябрьские праздники, чтобы на руках пронести первый релиз — сдобренный молитвами и нашими слезами.

Я помню, как сейчас, ту прекрасную зимнюю пору: готовилась к демо. Последняя попытка. Последний шанс выйти в прод до нового года. Коллеги из других команд уже ушли на новогодний корпоратив — пить, курить и веселиться. А мы узким кружком готовились к демонстрации. Часики тикали, всё почти готово. Я открываю финальную вкладку… и у меня схлопывается интерфейс в ошибку 500, приложение встаёт колом — ни туда, ни сюда.

Мы выкатываем глаза, разработчик начинает исправлять дефекты наживую, а минутная стрелка стремительно приближается к началу демо.

Пока все собираются, я начинаю тираду в духе: «Добрый день, здравствуйте, дорогие коллеги. Мы очень рады представить вам наш мертворождённый релиз…»

На фоне вижу, как разработчик машет руками и показывает пальцами вверх: он починил, всё будет хорошо.

Я радостно показываю новый функционал, который, вообще-то, был хорош — действительно годный для старта, чтобы опробовать и понять: надо/не надо. Мне он нравился от начала и до конца. Всё шло гладко, я подробно рассказывала про каждую кнопочку, вкладочку и ссылку — всё будет ровнее ровного.

И тут я понимаю… О боже. Холодный пот выступает на лбу, когда я осознаю, что в тестировании бэкенда я совсем забегалась и даже не открывала ту злополучную вкладку, которая может схлопнуть приложение.

Нет.

В ней не пророс буйным цветом дефект регресса. Она не тестировалась вообще.

Никогда.

Ошибка 500 не была случайностью. Она была слепым пятном, про которое в спешке я забыла!

Господь. Я была плохой девочкой и тестировала без документации и тест-кейсов. Но обещаю, что это мой последний провал (ха-ха — нет). Обещаю потом всё задокументировать (нет). Обещаю аккуратно ввести рабочие планы (всё ещё нет).

Я взмолилась (всем известным богам) и в частности своему разработчику, который стоял за моей спиной, пил кофе и следил за демо. Мне было страшно и стыдно; с трясущимися пальцами я медлила открыть ту самую вкладку.

Кажется, мозг отключился. Я уже приготовила монолог: «Мы так задумывали — чтобы приложение умирало между запросом и ответом. Так вы сможете сделать себе чай, пока серверы проходят свой персональный краш-тест.»

Быть опозоренной перед всеми: заказчиками, пользователями, инфобезой, командой разработки. Я ощутила как над моей головой нависла секира невидимого палача, чтобы одним рывком – точным и расчетливым – перерубить мою карьеру на корню. Я была готова выкладывать свое резюме на hh под бой курантов.

И вдруг кружок загрузки завертелся — вкладка открылась.

За моей спиной аналитик и разработчик дают друг другу «пять» и чокаются кружками мерзкого американо, потому что молоко скисло ещё вчера.

Мы справились. За час мы пролетели через все эмоциональные качели: провал — успех — осознание приближающегося конца — смерть — и снова успех.

Не помню, напились ли мы после того рабочего дня или залипали в стену до новогодних праздников. Кажется, мой мозг заблокировал те воспоминания, которые случились именно тогда.

Хочу отметить: потом мы долго и скрупулёзно доводили процессы до ума, чтобы уже не бегать с горящей задницей перед релизом.

Да, мы бегали.

Да, у нас были провалы.

Да, у нас были дефекты в проде.

Очень много «да». Я складываю руки в молитве за каждый такой провал и верю, что мне ещё много чему предстоит научиться. И да — я облажаюсь еще раз. Я в этом уверена и с какой-то тёплой надеждой жду момента, когда снова придётся преодолеть очередную катастрофу.

К чему это я? Приближается горячий сезон, и каждый из нас готовится к нему. Не знаю, как вы, но мои единственные планы на высокий сезон — это скидки на Алиэкспресс и попытка ухватить навесной унитаз по вопиюще низкой цене. Я слишком долго пила антидепрессанты, чтобы работать в таком режиме в свои 27.

Никто не вспомнит, как ты задерживался на работе. Тебя заменят другим человеком, и никто не поставит памятник (разве что ты сам соберёшь его из гор пластиковых кофейных стаканчиков).

sorry not sorry

Хочу поддержать каждого, кто проходил через подобное. У меня нет слов, чтобы описать, сколько боли и нервов было потрачено тогда, и сколько трудностей ждёт нас впереди.

Если вы дошли до этого места — спасибо вам. И помните: всё обязательно получится (или не получится). Не теряйте веры. Не теряйте надежды. Продолжайте учиться и совершенствоваться.

Будущее не будет радужным и безоблачным — на самом деле, никогда не будет.

Но я верю в вас. Я учусь на своих провалах и катастрофах. Я знаю, что иногда была не права и по-старинке остаюсь идиоткой время от времени (уже меньше, но всё ещё бывает).

Проанализировав около 50 сервисов с ИИ, я выбрала 29 инструментов для написания отчетов по практике. Отбор я проводила по критериям: удобство интерфейса, качество текста, скорость работы, безопасность и стоимость. В этом обзоре — восемь самых удобных нейросетей, десять дополнительных и семь бесплатных, а также полезные советы, как использовать ИИ.

ТОП-12 нейросетей для написания отчета по практике в 2026 году

1. Экзамка — сервис, функционирующий на базе сразу нескольких продвинутых ИИ-моделей.
2. Кэмп — нейросеть для помощи в создании отчета с автоматическим подбором источников.
3. СДАЛ — команда нейромоделей и три тарифа на выбор.
4. ChatGPT — популярная нейросеть для помощи в решении разнообразных задач, в том числе академических.
5. Study AI — платформа с ChatGPT, Claude, DeepSeek и прочими популярными моделями.
6. Zaochnik — многофункциональный ИИ-помощник для студентов и школьников.
7. SmartBuddy — поддержка популярных форматов и проверка по ГОСТу.
8. WordyBot — мощный генератор академических текстов с автоформатированием.
9. ruGPT — нейросеть для помощи в учебе со встроенным умным редактором.
10. GPTunneL — кастомные AI-ассистенты для узкоспециализированных вопросов.
11. AiWriteArt — отличный генератор текстов и изображений для студентов.
12. GPT-Tools — универсальный набор инструментов на базе ChatGP.

Обратите внимание: ИИ-инструменты предназначены исключительно для помощи в структурировании, генерации идей и создании черновиков. Окончательная работа должна быть выполнена студентом самостоятельно с соблюдением принципов академической честности. Использование готовых текстов для сдачи как своих недопустимо и может повлечь ответственность.

Лучшие нейросети для написания отчета по практике

1. Экзамка

AI-генератор для помощи в создании дипломов, ВКР, докладов и прочих академических работ. Результат – уникальные и качественные тексты, которые с легкостью пройдут проверку на плагиат и AI. Сервис использует технологию MixAI, которая объединяет в себе сразу несколько передовых ИИ-моделей для оптимального результата.

Обратите внимание: использование готовых, созданных ИИ текстов для сдачи как своих недопустимо и может повлечь ответственность.

• Стоимость: от 149 рублей
• Пробный период: есть (генерация только оглавления и списка литературы)

Основные возможности:

• Генерация текстов: создание оформленных по ГОСТ документов.
• Решение учебных задач: выдаст решение и ход рассуждений, достаточно указать входные данные. Доступны задачи по алгебре, экономике, информатике, юриспруденции и проч.
• AI-антидетектинг и уникальность: результат проходит проверку на уровень ИИ и антиплагиат.

Преимущества:

• Почти мгновенный результат: достаточно задать промпт и требования, ответ сервис выдаст максимум через 10 минут.
• Свобода редактирования: перед запуском генерации можно вручную отредактировать предложенное платформой оглавление. Сгенерированный текст также можно корректировать уже в MS Word.
• Удобный личный кабинет: все сгенеренные ранее работы хранятся в вашем личном кабинете, отслеживать статус работ и запускать новый также можно через ТГ-бот.

Недостатки:

Ограниченная пробная версия: качество текста нельзя оценить, не запустив первую генерацию, В бесплатной пробной версии доступно только оглавление работы и список литературы для нее.

Сайт сервиса >>>

2. Кэмп

Нейросеть от Kampus AI — это инновационный инструмент, разработанный для ускорения и упрощения процесса создания академических текстов. Сервис использует искусственный интеллект для подбора релевантных источников, формирования структуры и генерации связного текста на основе введенной темы. Это позволяет значительно сократить время, затрачиваемое на подготовку эссе, и повысить эффективность работы.

Обратите внимание: использование готовых, созданных ИИ текстов для сдачи как своих недопустимо и может повлечь ответственность.

• Стоимость: от 52 рублей за работу.
• Пробный период: есть

Основные возможности:

• Генерация текста по заданной теме – сервис самостоятельно подбирает информацию и формирует связный текст.
• Анализ и подбор релевантных источников – нейросеть учитывает ключевые аспекты темы, используя актуальные материалы.
• Автоматическое структурирование – создание логичного и последовательного текста с введением, основной частью и заключением.
• Проверка уникальности – алгоритм обеспечивает высокий уровень оригинальности (не менее 96%).
• Гибкость в корректировке – возможность редактирования и доработки текста перед финальной выдачей.
• Разнообразие тем – подходит для школьных, студенческих и научных работ по разным дисциплинам.

Преимущества:

• Быстрота: сервис позволяет получить текст всего за несколько минут.
• Удобство: достаточно указать тему, утвердить предложенные источники и проверить текст.
• Доступность: низкая стоимость делает сервис привлекательным для студентов с любым бюджетом.

Недостатки:

• Ограничения ИИ: нейросеть может не справляться со сложными или узкоспециализированными темами.
• Необходимость контроля: рекомендуется самостоятельно проверять факты и корректность информации в полученной работе.

Сайт сервиса >>>

3. СДАЛ

На платформе «трудятся» AI-ассистенты, помогая учащимся быстро и качественно писать курсовые, рефераты, сочинения и другие работы, решать задачи и даже строить чертежи. Также нейросети проверяют тексты на уникальность и «человечность» — все в одном окне. Разработчики предоставляют три варианта оплаты: на месяц, на три месяца и сразу на год. Последний выгоднее.

• Цена: от 149 руб./мес.
• Тестовый период: да, неполный набор функций
• Регистрация: email, Telegram

Плюсы

• круглосуточная поддержка по любым вопросам доступна на всех тарифах;
• авторизация через «Телеграм» для мобильного доступа к «пульту управления» работой;
• время генерации черновика — пять минут.

Минусы

Пока нет отдельного приложения для телефона.

Сайт сервиса >>>

4. ChatGPT

ChatGPT — это продвинутый чат-бот с искусственным интеллектом, разработанный компанией OpenAI. Он предназначен для имитации общения с реальным человеком, понимает и генерирует человекоподобный текст на основе контекста и полученных данных из сети. Нейросеть обучена на массиве текстовых данных, что позволяет ей давать релевантные и информативные ответы.

• Стоимость: от 20 $ в месяц
• Пробный период: есть (помощь только оглавлением и списком литературы)

Основные возможности

• Генерация научных текстов: создание связных и логичных черновиков по заданной теме, адаптированных под различные стандарты.
• Ответы на вопросы: предоставление информативных и релевантных ответов на широкий спектр вопросов.
• Перевод текста: перевод с одного языка на другой с сохранением смысла и стиля.
• Вдохновение при создании творческих работ: написание стихов, рассказов, сценариев и других творческих текстов.

Преимущества

• Универсальность: подходит для решения широкого спектра задач, от написания кода до помощи в создании студенческих работ.
• Обучение на большом объеме данных: обеспечивает информативные и релевантные ответы.
• Постоянное обновление: регулярные обновления и улучшения модели для повышения качества работы.

Недостатки

• Необходимость контроля качества: сгенерированные тексты могут требовать дополнительной проверки и доработки для соответствия специфическим требованиям.
• Зависимость от введенных данных: качество результата напрямую связано с точностью и полнотой предоставленной информации.

Сайт сервиса >>>

5. Study AI

StudyAI — это онлайн-платформа, где можно найти десятки популярных ИИ-моделей, полезных в том числе для студентов и учащихся. Помимо генераторов текстов сервис предлагает ИИ для создания изображений, презентаций, схем и даже видео. Все эти инструменты включены в одной подписке, на каждый запрос расходуется определенное количество токенов, при этом самые передовые модели (GPT-5,Gemini, DeepSeek) доступны бесплатно.

Обратите внимание: использование готовых, созданных ИИ текстов для сдачи как своих недопустимо и может повлечь ответственность.

• Стоимость: от 199 рублей в неделю
• Пробный период: есть

Основные возможности:

• Генерация текстов любой сложности: лучшие языковые модели, между которыми можно переключаться в зависимости от задачи.
• Создание презентаций: превратит текст в наглядные слайды.
• AI-наставник: учитель/репетитор/консультант по любым темам, включая академические вопросы.
• Решение задач: по фото или тексту, с объяснением логики.
• Генератор изображений и видео: создаст визуал с нуля или отредактирует имеющийся.

Преимущества:

• Разнообразие моделей: ИИ-инструменты для создания текстов и визуала.
• Бесплатный тариф: включает GPT, DeepSeek, Gemini (с ограничениями по токенам в день).

Недостатки:

• Нет безлимитного тарифа: каждый запрос списывает токены с вашего счета.

Сайт сервиса >>>

6. Zaochnik

Инновационная нейросеть, интегрированная в платформу Zaochnik, предназначенная для оптимизации процесса написания студенческих работ. Сервис создан для студентов и школьников, нуждающихся в эффективном инструменте для подготовки учебных проектов, таких как отчеты по практике, рефераты, курсовые, дипломные работы и другие академические задания.

• Цена: бесплатно
• Бесплатный период: 5 попыток
• Регистрация: не требуется

Основные возможности

• Генерация текстов: автоматическое создание связных и логичных черновиков по заданной теме, адаптированных под академические стандарты.
• Редактирование и улучшение: корректировка и доработка существующих текстов для повышения их качества и соответствия требованиям вузов.
• Проверка уникальности: оценка оригинальности созданного контента с учетом академических стандартов.
• Структурирование и оформление: помощь в структурировании материалов и оформлении списка литературы в соответствии с требованиями вузов и ГОСТа.
• Поиск и анализ информации: сбор и анализ релевантных источников для обоснования аргументов и теоретической базы работы.

Преимущества

• Бесплатный пробный доступ: все инструменты ИИ Zaochnik GPT доступны пользователям бесплатно в пробной версии.
• Универсальность: подходит для оптимизации создания различных типов учебных работ, включая отчеты, рефераты, эссе, курсовые и дипломные проекты.
• Поддержка на всех этапах: помощь от исследования темы до финальной корректировки и оформления работы.

Недостатки

Ограничения в понимании сложных тем: ИИ может не полностью раскрыть узкоспециализированные темы.

Сайт сервиса >>>

7. SmartBuddy

В набор сервисов для помощи в создании плана отчета по практике входят: инструмент для формулировки заключения, перефразирования и перевода текста и выделения основной мысли. Важно относиться к сгенерированным фрагментам как к черновикам, которые требуется доработать самостоятельно. Платформа поддерживает форматы: PDF, .xlsx, DOCX, PPTX и другие.

• Стоимость: рассчитывается в токенах по факту
• Пробный период: есть, даже без авторизации, но с ограничениями

Основные возможности

• Использование популярных нейросетей: Claude, Gemini, Claude, DeepSeek, Stable Diffusion XL.
• Проверка на соответствие нормам ГОСТ.
• Экспорт в Word.

Преимущества

• Нет подписки — платите только за фактическое использование.
• Много кастомных инструментов: для построения диаграмм, объяснения кода, подбора синонимов.
• Встроенный редактор для расширения или сокращения текста.

Недостатки

Сервисы на сайте распределены не по тематическим группам, а по алфавиту.

Сайт сервиса >>>

8. WordyBot

WordyBot.ai — это инновационная нейросеть, предназначенная для автоматической генерации текстов различного объема и тематики. Сервис ориентирован на студентов, исследователей и авторов, которым требуется быстрое создание структурированных и содержательных материалов. Благодаря использованию передовых алгоритмов искусственного интеллекта, WordyBot.ai способен создавать тексты, соответствующие академическим стандартам и требованиям.

Обратите внимание: использование готовых, созданных ИИ текстов для сдачи как своих недопустимо и может повлечь ответственность.

• Стоимость: от 350 рублей
• Пробный период: есть

Основные возможности:

• Генерация текста по заданной теме: пользователь вводит тему и ключевые слова, после чего нейросеть автоматически создает план и текст.
• Автоматическое составление плана: сервис бесплатно генерирует структуру будущей работы, которую можно редактировать.
• Встроенный редактор: после генерации текста доступен онлайн-редактор, позволяющий вносить правки, добавлять или удалять фрагменты и адаптировать материал под конкретные требования.
• Список источников: WordyBot.ai автоматически подбирает и оформляет список литературы по ГОСТу, основываясь на использованных материалах.
• Поддержка различных типов работ: сервис подходит для помощи в создании курсовых, дипломных работ, рефератов, эссе, докладов, научных статей и других видов текстов.

Преимущества:

• Экономия времени: быстрая генерация текста позволяет значительно сократить время на подготовку учебных и научных работ.
• Автоматизация оформления: автоматическое составление плана и списка литературы снижает вероятность ошибок и упрощает процесс подготовки работы.
• Гибкость настроек: возможность редактирования плана и текста позволяет адаптировать материал под специфические требования.

Недостатки:

• Качество генерируемого текста: несмотря на высокую уникальность, сгенерированные тексты могут требовать дополнительной проверки и доработки для соответствия специфическим требованиям.

Сайт сервиса >>>

9. ruGPT

Сервис со специальной нейросетью для помощи студентам. Модель предложит план отчета по практике по гуманитарным и техническим дисциплинам за минуту. Редактировать сгенерированный черновик доступно прямо на платформе. Благодаря встроенным инструментам легко проверить готовый текст на уникальность, подобрать синонимы и перефразировать фрагменты работы.

• Стоимость: от 165 рублей в месяц
• Пробный период: бесплатный тариф с 10 текстовыми запросами

Основные возможности

• Помощь в создании содержания и черновика для отчета по практике.
• Встроенный текстовый редактор и проверка на оригинальность.
• Помимо текста, доступна генерация и редактирование изображений, видео, аудио и презентаций.

Преимущества

• Каталог готовых промптов, в том числе и для учебных целей.
• Скорость: подготовка содержания для отчетной работы занимает не больше минуты.
• Четыре тарифа на выбор с отменой в любой момент.

Недостатки

Нет отдельного приложения — только в браузере.

Сайт сервиса >>>

10. GPTunnel

На этой площадке вы найдете популярные нейросети: ChatGPT, Gemini, Claude, а также AI-ассистентов для помощи с отчетом. Среди них, например, «Грамотей», подсвечивающий ошибки в вашем тексте, «Перефразировщик», подбирающий синонимы и варианты вербализации одной и той же мысли. Возможно бесплатное пользование, а также промокоды со скидками в Telegram.

• Стоимость: только по факту, в токенах
• Пробный период: есть

Основные возможности

• Доступ к 100+ популярным нейросетевым моделям.
• Инструменты для работы с текстом, изображениями, видео, музыкой, а также аналитикой и ПО.
• ИИ-агенты для узких задач.

Преимущества

• Плата только за использованные токены — ничего лишнего.
• Большой выбор нейросетей от ChatGPT до новой Grom.
• Бесплатные обучающие материалы по эффективной работе с ИИ.
• Доступ к API.

Недостатки

Без подписки трудно научиться контролировать бюджет.

Сайт сервиса >>>

11. AiWriteArt

AiWriteArt — это инновационная платформа, использующая возможности искусственного интеллекта для создания уникальных текстов и изображений. Сервис предназначен для блогеров, маркетологов, предпринимателей и всех, кто стремится эффективно генерировать качественный контент для различных целей, включая блоги, социальные сети и интернет-магазины. Благодаря интеграции с мощной нейросетью ChatGPT, AiWriteArt обеспечивает быстрое и удобное создание материалов, экономя ваше время и ресурсы.

Обратите внимание: использование готовых, созданных ИИ текстов для сдачи как своих недопустимо и может повлечь ответственность.

• Стоимость: от 150 рублей в месяц
• Пробный период: есть

Основные возможности:

• Генерация текстов: создание уникальных статей, постов для социальных сетей, описаний товаров и других текстовых материалов на основе заданных параметров.
• Генерация изображений: создание оригинальных изображений с помощью искусственного интеллекта для использования в блогах, социальных сетях и на сайтах.
• Преобразование и рерайт текста: автоматическое изменение стиля и слов текста при сохранении его смысла.
• AI-чат: интерактивный помощник на основе искусственного интеллекта, готовый ответить на вопросы пользователя по различным темам.

Преимущества:

• Многофункциональность: помимо генерации текстов и изображений, AiWriteArt предлагает инструменты для преобразования речи в текст, суммирования текста, объяснения сложных понятий и многое другое.
• Универсальность: подходит для создания разнообразного контента, от блогов до научных работ.
• Доступность: возможность начать использование без необходимости ввода данных кредитной карты и наличие бесплатной пробной версии.

Недостатки:

• Ограниченные возможности бесплатной версии: для полного доступа ко всем функциям может потребоваться приобретение платной подписки.
• Зависимость от настроек пользователя: качество и релевантность создаваемого контента могут зависеть от точности введенных данных и выбранных параметров.

Сайт сервиса >>>

12. GPT-Tools

GPT-Tools — это вспомогательный инструмент с ИИ для написания отчета, предоставляющая набор инструментов на основе нейросети Chat GPT на русском языке. Сервис предлагает широкий спектр функций, от генерации текстов до анализа и оптимизации рабочих процессов, что делает его полезным для студентов, профессионалов и всех, кто ищет эффективные решения с помощью искусственного интеллекта.

Обратите внимание: использование готовых, созданных ИИ текстов для сдачи как своих недопустимо и может повлечь ответственность.

• Стоимость: от 540 рублей в месяц
• Пробный период: есть

Основные возможности:

• Генерация и редактирование текстов: создание уникальных текстов по заданной теме, включая помощь с написанием эссе, рефератов, докладов и других академических работ.
• Анализ и оптимизация текста: инструменты для сокращения текста, повышения уникальности, синонимайзер, проверка орфографии и синтаксический разбор.
• Специализированные генераторы: создание сценариев, бизнес-планов, песен, стихов, аннотаций и других специфических текстов.
• Образовательные инструменты: разбор слова по составу, анализ стихотворений, составление онлайн-тестов и конспектов по тексту.
• Чат-боты с нейросетью: возможность общения с преднастроенными ИИ в роли психолога, отличника, языкового репетитора или программиста.

Преимущества:

• Многоязычная поддержка: возможность генерации и редактирования текстов на нескольких языках, включая русский, английский, украинский и испанский.
• Настраиваемый тон ответа: выбор стиля генерируемого текста, такого как смешной, профессиональный, саркастический и другие.
• Ежедневные бонусы: зарегистрированные пользователи получают от 500 кредитов ежедневно для использования различных инструментов платформы.
• Регулярные обновления: платформа постоянно обновляется, добавляя новые функции и улучшая существующие.

Недостатки:

• Ограниченные лимиты без оплаты: бесплатные лимиты могут быть недостаточны для интенсивного использования, что требует приобретения дополнительных кредитов.
• Ограниченная поддержка: время работы службы поддержки ограничено с 10:00 до 19:30 по московскому времени, что может быть неудобно для пользователей из других часовых поясов.

Сайт сервиса >>>

8. RoboGPT

RoboGPT — мощная платформа на базе искусственного интеллекта, предназначенная для бизнеса, учебы и карьеры. Она предоставляет инструменты для помощи в создании структуры, черновиков и фрагментов текстов по заданной теме. Работает в режиме диалога, что позволяет уточнять детали и адаптировать текст под требования пользователя.

Обратите внимание: использование готовых, созданных ИИ текстов для сдачи как своих недопустимо и может повлечь ответственность.

• Стоимость: от 315 рублей
• Пробный период: есть

Основные возможности:

• Генерация текста: помощь в создании академических работ для студентов.
• Генерация изображений: создание и редактирование графического контента (удаление фона, трансформация изображений).
• Преобразование и рерайт текста: интеллектуальное переписывание материалов для повышения уникальности.

Преимущества:

• передовые ИИ-модели для создания уникального контента;
• автоматическое соблюдение SEO-стандартов и академических требований;
• интеграция с различными инструментами для бизнеса и маркетинга;
• высокая степень персонализации, адаптированной под стиль и цели бизнеса;
• возможность интеграции с существующими рабочими процессами через API.

Недостатки:

• необходимо зарегистрироваться для доступа ко всем функциям;
• ограничение на количество запросов в рамках бесплатного доступа.

Сайт сервиса >>>

Еще 10 русскоязычных ИИ-сервисов для помощи в написании отчетов по практике

Если вы ищете другой вспомогательный ИИ-сервис для помощи с написанием отчета, попробуйте альтернативные платформы.

• Gerwin AI — нейросеть, доступная через Telegram-бот, предназначенная для автоматического написания и редактирования текстов. Подходит для работы с академическими и маркетинговыми материалами.
• MitupAI — это ИИ для помощи в создании отчета по практике, генерирующий содержание для их разделов на русском языке. Сервис позволяет создать структуру отчета, составить описание процесса и выводы, а также улучшить стилистику с помощью LLaMa или ChatGPT.
• Бегемот — нейросеть, специально разработанная для помощи в написании контрольных, курсовых и дипломных работ. Учитывает академические стандарты и помогает оформлять работы в соответствии с требованиями вузов.
• ReText — мощный инструмент, который поможет создать отчет. Может использоваться как для генерации нового контента, так и для рерайта.
• Chad AI — российский аналог ChatGPT с возможностью генерации статей, фрагментов эссе и других текстов. Отличается понятным интерфейсом и хорошим качеством обработки запросов.
• Robotext — сервис для отчетов по практике, автоматического создания текстов, слоганов и рекламных объявлений. Хорошо подходит для маркетологов, копирайтеров и предпринимателей.
• Wordify — универсальный и удобный онлайн-сервис для письма и редактирования. Платформа подходит как для учебных, так и для профессиональных проектов.
• AI txt — эта нейросеть поможет в написании структурных разделов отчета: вводная часть, описание процессов и заключение, обеспечивая качество и соответствие академическим стандартам.
• CopyMonkey — ИИ-сервис, заточенный под создание текстов для e-commerce. Отличается возможностью автоматической генерации описаний товаров для маркетплейсов.
• НейроТекстер — инструмент для написания статей, эссе и других текстов. Включает функции стилистической корректировки и проверки грамотности.

Бесплатные нейросети для помощи в работе над отчетом по практике

Нейросеть для написания отчета по практике бесплатно может помочь, если нужно быстро справиться с задачей. В этом разделе мы расскажем о бесплатных нейросетях, которые помогут легко создать структуру письменной работы и проверить ошибки.

1. ruGPT

Российская нейросеть, которая поможет сделать контрольную работу с помощью ИИ. Обеспечивает генерацию уникальных и стилистически правильных материалов, подходящих для различных целей.

Какие основные особенности?

• Специализация на русском языке и текстах академического стиля.
• Автоматическая генерация с возможностью редактирования.
• Гибкость в создании контента под заданные параметры.

2. Davinchi

Сервис с ИИ для написания отчета по практике бесплатно также позволяет генерировать SEO-статьи, рекламные креативы, контент для блогов и многое другое. Простота в использовании делает Davinchi подходящим как для студентов, так и для профессионалов.

Какие основные особенности?

• Автоматическая генерация текстов разного объема и тематики.
• Поддержка многоуровневой структуры для логичной подачи информации.
• Возможность редактирования и корректировки результатов.

3. GigaChat

Российская альтернатива ChatGPT, разработанная Сбербанком. Нейросеть подойдет для написания отчета по практике на русском, умеет создавать структуры, список литературы и небольшие фрагменты текстов.

Какие основные особенности?

• Поддержка диалогового режима для уточнения деталей.
• Генерация осмысленных и логически выстроенных текстов.
• Возможность использования для написания академических работ.

4. YaGPT2

Бесплатный ИИ-ассистент от «Яндекса», встроенный в голосового помощника Алиса. Поможет написать отчет по практике через нейросеть онлайн, будет обрабатывать текстовые запросы, генерировать связные тексты, помогать в поиске информации и структурировании материала.

Основные характеристики:

• Интеграция с экосистемой «Яндекса», удобный доступ через Алису.
• Возможность генерации ответов в разговорном формате.
• Создание структурированных текстов на русском языке.

5. АйБро

Бесплатная нейросеть для отчета онлайн, ориентированная на создание студенческих работ. Может формировать структурированные тексты, помогать с формулировкой идей и анализировать предложенные темы.

Основные характеристики:

• Генерация текстов с учетом логики и структуры эссе.
• Возможность редактирования и доработки сгенерированных материалов.
• Дружелюбный интерфейс для удобного взаимодействия.

6. Neural

Сервис, созданный специально для студентов, нуждающихся в помощи с курсовыми и дипломными работами. Нейросеть поможет сделать отчет по практике, учитывая академические стандарты при создании текстов.

Основные характеристики:

• Поддержка академических форматов и стандартов.
• Генерация материалов на основе заданных тем и требований.
• Возможность адаптации текста под нужную структуру.

Как нейросети могут упростить написание отчетов по практике?

Нейросети значительно упрощают написание отчетов по практике, выполняя рутинные задачи, на которые обычно уходит много времени:

• Автоматический сбор и структурирование данных: нейросеть помогает быстро организовать и обработать информацию, чтобы не тратить время на ручное выделение ключевых фактов.
• Генерация черновика: ИИ может создавать различные разделы отчета на основе введенных данных, например, описание процессов, цели и задачи, выводы и рекомендации.
• Проверка грамматики и стиля: она автоматически находит и исправляет ошибки, улучшает стилистику.
• Оформление списка литературы: нейросеть может корректно оформить список литературы в соответствии с требованиями ГОСТ, что также экономит время.
• Оптимизация структуры: ИИ помогает выстроить отчет по логической структуре, делая его понятным и четким.

Пример промпта для нейросети:

«Создай подробный план для отчета по практике на тему “Анализ работы маркетингово отдела компании X”. В отчете должны быть разделы: введение, цели и задачи практики, методы исследования, описание процессов в отделе маркетинга, результаты, выводы и рекомендации. Включи список литературы по ГОСТу и проверь текст на грамматические ошибки».

С помощью такого запроса нейросеть поможет создать краткое содержание отчета, готовое для дальнейшего редактирования или использования.

Как эффективно использовать нейросети для написания отчетов? Пять простых шагов

Чтобы нейросети помогали выполнять учебные задания, достаточно следовать пяти простым шагам.

Определите цели

Прежде чем использовать нейросеть, важно понять, что именно вы хотите от нее получить. Подумайте, что нужно создать: план, список литературы или что-то еще. Решите, что именно нейросеть должна делать: анализировать информацию или проверять ошибки. Чем яснее будут ваши задачи, тем лучше нейросеть справится с ними.

Выберите подходящий инструмент

Существует много разных сервисов для работы с нейросетями, каждый с разными возможностями. Чтобы выбрать подходящий, решите, что вам нужно: написать введение, проверить стиль или сделать список литературы. Прочитайте, какие функции у разных платформ, и выберите тот сервис, который лучше всего соответствует вашим требованиям.

Подготовьте данные

Нейросеть работает с теми данными, которые вы ей дадите. Поэтому перед использованием соберите все материалы: факты, цифры, требования к оформлению. Составьте список того, что должно быть в готовой работе, например, цели исследования, методы, результаты и выводы. Чем лучше вы подготовите данные, тем точнее нейросеть выдаст результат.

Настройте нейросеть

После выбора инструмента настройте его под свои нужды. Это может включать в себя установку параметров, например, длины текста или стиля написания. Некоторые нейросети позволяют обучать их на примерах, чтобы они лучше понимали, как должен выглядеть ваш отчет. Настроив нейросеть, вы получите наилучший результат.

Отредактируйте результат

Даже самые умные алгоритмы могут допустить ошибки или неточности. Проверьте грамматику, стиль и правильность данных. Если нужно, добавьте свои замечания и уточните детали. Убедитесь, что работа соответствует вашим требованиям.

ИИ при написании отчетов: сильные стороны и ограничения

Нейросети для помощи в написании отчетов по практике предлагают значительные преимущества, но также имеют и некоторые ограничения. Давайте разберемся, что важнее — плюсы или минусы этих технологий.

Преимущества

• Скорость. Нейросеть генерирует контент в несколько раз быстрее, чем человек. Благодаря этому сокращается время на подготовку учебных проектов.
• Автоматизация рутины. Искусственный интеллект выполняет рутинные процессы: собирает данные, структурирует информацию, создает шаблоны и библиографические списки. Тем самым ИИ освобождает пользователя от однотипной работы.
• Улучшение качества. Умные алгоритмы повышают качество письменной работы, подсвечивая орфографические и грамматические ошибки, улучшая стиль и избегая повторов.
• Кастомизация и адаптация. Нейросеть поддается настройке под специфические задачи. Она учитывает требования учебных заведений и работодателей, а также адаптирует документы под индивидуальные запросы.

Недостатки

• Зависимость от качества данных. Качество результата зависит от исходных данных. Если нейросеть получает неполную или неточную информацию, результат будет некачественным или даже ошибочным.
• Ограниченная креативность. Нейросеть генерирует материалы на основе шаблонов и алгоритмов, но не может предложить оригинальные идеи или нестандартные решения, что важно при написании креативных или исследовательских проектов.
• Необходимость в человеческом контроле. Несмотря на высокую степень автоматизации, нейросети требуют проверки и корректировки со стороны человека, чтобы избежать ошибок и несоответствий. Например, в работах могут быть фактические ошибки, которые нейросеть не обнаружит самостоятельно.

Как сбалансировать преимущества и недостатки?

Использование нейросети с человеческим контролем — лучший подход. Нейросеть ускоряет процесс и повышает качество, но итоговый результат требует проверки и доработки.

Часто задаваемые вопросы: Все, что нужно знать о нейросетях для отчетов

1. Какие нейросети лучше всего подходят для написания отчетов?

Подойдут, например, такие нейросети, как Kampus AI, Zaochnik и Study AI. В отличие от генераторов отчета по практике, эти сервисы помогают создавать качественные материалы, выдавая интересные идеи и проверяя готовое содержание на ошибки.

2. Насколько точны результаты, которые генерирует нейросеть?

Точность, с которой нейросеть выдает ответы, зависит от качества исходных данных. Поэтому важно проверять и корректировать как вводную информацию, так и результаты.

3. Нужно ли мне быть экспертом в области нейросетей, чтобы использовать их для создания отчетов?

Нет, использование Examka AI, WordyBot и других платформ, не требует опыта работы с нейросетью. Все сервисы имеют интуитивно понятный интерфейс, и вам нужно просто ввести основные данные для создания отчета.

4. Могу ли я использовать нейросети бесплатно?

Да, многие сервисы предлагают бесплатные функции. Например, Zaochnik предоставляет полный доступ к своей нейросети без регистрации, а Study AI — бесплатные запросы каждую неделю. Однако для получения полного набора функций, обычно нужно оформить подписку.

5. Как выбрать подходящую нейросеть для написания отчетов?

Если нужно быстро создать отчет с минимальными усилиями, выберите Zaochnik или Study AI, которые предлагают простые в использовании шаблоны и функции. Для более сложных проектов с индивидуальными требованиями, например, Kampus AI будет лучшим выбором, так как тот поддерживает больше дисциплин и предоставляет много возможностей для кастомизации.

Использование таких сервисов позволяет ускорить работу, но важно помнить, что ИИ — это всего лишь вспомогательный инструмент, а не замена аналитического мышления и научного подхода.

Если у вас уже был опыт использования нейросетей для учебы, расскажите об этом в комментариях — какой сервис оказался самым полезным? Будет интересно узнать ваши впечатления и советы другим студентам.

Итак, начнём действовать.

Понедельник с чистого кода

Спросите коллег, с которыми работаете в одной команде и которым доверяете, о своих слабых сторонах. Объясните, почему для вас это важно. Пусть они знают, вы исследуете свои «гибкие» навыки. Будьте беспристрастными и слушайте внимательно, не перебивая. Соберите всю информацию и внимательно проанализируйте.

Если вы получили несколько общих ответов, уточните и разберите всё по деталям. Коллеги называют вас импульсивным и несдержанным? Узнайте у них конкретнее, в чём это проявляется и что их конкретно не устраивает.

В идеале к концу дня получится список слабопрокаченных навыков. Его можно брать за основу.

Прочитать по теме: HBR Guide. Эмоциональный интеллект

Вторник для self-менеджмента и против стресса

Во вторник заведите чек-лист или дневник, где будете фиксировать всё, что раздражает, вызывает сильные негативные эмоции, доводит до стрессового состояния.

Потратив час после работы, проанализируйте написанное. Напротив каждого фактора запишите, что можно сделать/поменять/делегировать уже завтра. Американская ассоциация психологов называет основными источниками стресса чрезмерную загруженность, низкую оплату труда, неоднозначные требования, неясные ожидания. Скорее всего, эти факторы влияют и на вас. Не волнуйтесь, всё поправимо.

После определения неизбежных стрессовых точек придумайте здоровую реакцию на них: например сделать физическое упражнение, асану из йоги, пройтись. «Расшатанный» чрезмерной нагрузкой, лишней информацией, доступностью социальных сетей, бессонными ночами организм легче поддаётся стрессу. Ваша главная задача — создать здоровые условия для себя. Оберегайте себя от информационной передозировки, установите границы личной жизни и работы, введите цифровые диеты, отключитесь от всех видов связи в выходные.

Прочитать по теме: EQ. Эмоциональный интеллект на практике, Stress literally shrinks your brain (7 ways to reserve this effect)

Среда для общения и развития коммуникативных навыков

Коммуникации — это всё: от умения слушать, поддерживать диалог до публичных выступления и нетворкинга в команде. Мы провели исследование среди программистов Selectel на предмет важности и влияния soft skills на их ежедневный труд. Абсолютное большинство назвало самым главным в работе «умение слушать и давать обратную связь».

Постарайтесь в этот день максимально много общаться. Высказывайте своё мнение, не скрывайте новые идеи, аргументированно отстаивайте свою позицию. Помогите решить проблему коллеге. Побеседуйте с тем парнем в странном мерче, с которым никогда не говорили раньше.

При личном общении попробуйте применить правила серийной предпринимательницы Дип Патель:

• установите зрительный контакт с собеседником и не вращайте головой как китайский болванчик;
• экспериментируйте и практикуйте перед зеркалом, гримасничайте, расскажите самому себе о проблемах в проекте или в коде;
• следите и контролируйте язык тела: не чешитесь, не стучите головой об стенку или пальцами по столу;
• активно слушайте речь собеседника, задавайте вопросы и будьте открыты к диалогу.

Почитать по теме: Язык телодвижений. Как читать мысли окружающих по их жестам

Четверг: don’t work hard, work smart

Сегодня вы скажете «нет» пожирателям времени и расставите приоритеты. Утром возьмите лист бумаги и составьте план задач на день. Постарайтесь быть объективны, не пишите больше семи блоков, выберите только срочные и важные дела. Записывайте и отмечайте там же в листе каждое отвлечение: переписка в Facebook, светские беседы за кофе, выполнение сторонних задач не из списка — записывайте всё. В конце дня проведите анализ. Уверяем, что открывшаяся картина вас удивит.

Прочитать по теме: 7 привычек высокоэффективных программистов

Пятничная эмпатия

Эмпатия — это понимание чувств и переживаний через сопереживание. Британские учёные поговаривают: склонность к эмпатии заложена генетически. Но в этот раз мы им не поверим.

Разберёмся, зачем вам становиться эмпатом. Открытый и эмоциональный человек легко найдёт общий язык код с любым homo technicus, обрастёт связями и контактами. Сопереживание — ключ к пониманию мотивов и логики. Эмпаты реже конфликтуют, потому что видят и чувствуют страхи других, а значит, легче шагают вперёд по карьерной горе.

Тренер, автор книг про отношения Эндрю Собель даёт рекомендации по развитию сопереживания. В переработанном виде рекомендуем применить их в пятницу:

1. Выберите новый маршрут на работу, пообедайте в новом кафе, не бойтесь выходить из обычной среды. Свежие впечатления = свежие эмоции.
2. Проявляйте любопытство и задавайте как можно больше вопросов каждому, кто вам интересен: охраннику, секретарю, молодому специалисту, клиенту. Интересуйтесь их опытом и жизнью.
3. Собель предлагает пережить чужой опыт в прямом смысле. Если не боитесь, то поменяйтесь на день обувью со своим коллегой. Вечером расскажите друг другу о впечатлениях.
4. Испытайте себя. Например посетите урок игры на гитаре или порисуйте акварелью с бокалом вина вечером после работы. Начните учить SQL или Java. Новый опыт и знания — это смирение, а смирение — маленький шажок к сопереживанию.
5. Выберите для выходного чтения художественную книгу, следите за чувствами и эмоциями героев. В эти выходные мы читаем А. Сальникова «Опосредованно» и вам рекомендуем.

Почитать по теме: How to improve soft skills

Командный субботний завтрак

По неофициальной статистике, примерно треть программистов мечтают научиться работать в команде. Потратьте эту субботу на совместный завтрак с коллегами. Соберитесь в уютном кафе в центре города, поболтайте, попробуйте необычную кухню или новые сорта кофе. Может быть, кофе с морской солью и карамелью. Потратьте время на осознанное общение друг с другом. Основа качественной работы в команде — хорошие и дружественные отношения и взаимопонимание.

Воскресные итоги

Ну что, герой, воскресенье и время подвести итоги.

Последний совет: помните, что ваш успех зависит от вашей уверенности в себе. Поэтому посвятите этот день вере в себя и позитивному мышлению.

На этой неделе вы поучаствовали в маленьком приключении и сделали ещё один шаг к тому, чтобы познакомиться с самим собой. Вы стали отзывчивее, общительнее, душевнее. Вы не боитесь высказывать своё мнение, советуетесь с коллегами. Среди сотрудников компании у вас, возможно, уже появились новые друзья. Теперь у вас есть набор инструментов, которые помогут изменить вашу жизнь!

Вы стали настоящим hero of Soft Wars. Поздравляем!

Приложение Revolut

В нашем приложении много типов картинок для отображения — есть списки транзакций с разными иконками, списки карточек, Lottie-анимации, гифки. Покажу, как мы работаем с картинками на примере списка транзакций.

У нашего списка транзакций насчитывается несколько десятков типов ячеек. Для примера мы возьмем пять:

В каждом случае картинка взята из отдельного источника или сгенерирована.

Как работает стандартный способ отображения картинок

Создадим адаптер для такого списка.

Так будет выглядеть стандартный шаблон адаптера для RecyclerView. Реализуем биндинг значений:

Появляется портянка условий, потому что внутри адаптера для каждого вида транзакции мы строим отдельную логику. Можно усложнить и использовать свой ViewType под каждый источник. Тем более к этому подталкивает контракт адаптера:

Учитывая, что в нашем случае может быть несколько десятков видов транзакций, стандартный способ реализации адаптера не подходит.

Как улучшить адаптер

Можем выделить два основных подхода к расширению — ViewType или делегаты. Остальные не упоминаю специально: по своей сути они будут похожи на второй подход.

Первый вариант — ViewType — можно использовать, когда приложение простое, то есть содержит один простой список и, например, пару экранов. Нам этот способ не подходит, потому что такие адаптеры нельзя переиспользовать. Если мы будем расширять адаптер, добавляя новые ViewType, адаптер будет неконтролируемо расти. Кроме того, под каждый экран нам придётся создавать свои адаптеры.

Второй подход — с делегатами — выглядит привлекательнее. Он позволяет не создавать разные адаптеры под каждый экран, а использовать делегаты. Четыре года назад об этом писал Ханс Дорфман, и на GitHub можно найти много библиотек с реализацией такого подхода. Мы будем использовать реализацию самого Дорфмана.

Смотрим на пример простого делегата, который отображает ProgressBar.

Внутри делегата, как и в стандартном адаптере, создаем ViewHolder. Происходит биндинг. Главное отличие от стандартного адаптера в том, что у каждого делегата есть своя модель. Она будет использоваться, чтобы отобразить нужный тип ячейки. В свою очередь, у каждой модели есть интерфейс ListItem с полем listId и методом calculatePayloads внутри.

Перейдём к реализации адаптера, который умеет отображать делегаты.

В этой реализации видно, зачем нужен интерфейс ListItem — его удобно использовать для ListDiffCallback, чтобы DiffUtil не обновлял ячейки, которые не изменились, и не запускал лишние анимации. Кроме того, так как для моделей используется Data class, нам из коробки доступен equals. Вся работа с DiffUtil сводится к правильному созданию модели делегата.

Под каждый экран адаптер создаётся так: мы в конструкторе передаём список делегатов, который экран должен поддерживать.

Благодаря делегатам создание адаптера под каждый экран упрощается.

Как отображать картинки

Теперь уберём логику загрузки и отображения картинок из адаптера, разгрузим onBindViewHolder. Мы должны реализовать две сущности — модель картинки и делегат, который будет уметь загружать и отображать её. Рассмотрим пример модели, где загружаем картинку из ресурсов.

Сначала сделаем интерфейс Image. Затем опишем набор параметров для ResourceImage, по которым хотим настраивать отображение. В данном случае — id ресурса картинки и цвета, если хотим её закрасить.

Теперь перейдём к делегату загрузки и определим его интерфейс. Отсюда понятно, зачем нам интерфейс Image.

Каждый делегат должен уметь делать две вещи:

1. определять, умеет ли он отображать переданную картинку или нет;
2. отображать картинку в ImageView.

Так будет выглядеть делегат загрузки картинки из ресурсов.

Здесь:

• метод suitsFor() проверяет, что image — ResourceImage;
• внутри метода displayTo() мы устанавливаем картинку в ImageView и, если colorRes не null, то выставляем tint.

Это самый простой из возможных делегатов.

Как объединить делегаты

Объединим все поддерживаемые делегаты в одном месте и сократим интерфейс взаимодействия до метода displayTo().

Обращаю внимание на строку 18. При помощи метода first() мы находим первый подходящий делегат для отображения картинки. Если нужный делегат не найден, возможен краш, и это не ошибка проектирования. Мы намеренно придерживаемся принципа fail-fast, чтобы быстро избавиться от неочевидного поведения. Например, когда картинка не отобразилась, а мы не знаем причину.

Как запустить трансформации

Разберёмся, зачем в отображении транзакции могут понадобиться трансформации. Предположим, у нас есть аватарка контакта или продавца, которую мы получаем из сети. Она может иметь любую форму и размер, но в приложении Revolut мы должны отобразить её круглой и определённого размера — 40х40 dp.

Настроим модель и добьёмся такого поведения.

Возьмём UrlImage. Любая картинка, которой нужна поддержка трансформаций, должна иметь соответствующие настройки. Можно ввести интерфейс TransformableImage со свойством transformations:

Класс настроек может выглядеть так:

Для отображения картинок используем Glide. Соответственно, трансформации ориентированы под эту библиотеку.

Так создаётся массив преобразований. Отмечу два момента, которые помогут избежать лишней работы.

Во-первых, поля помечены как nullable, и это позволяет задавать только нужные трансформации. Во-вторых, не очевидно, но критично, в каком порядке трансформации будут вызваны.

Представим, что на входе — очень широкая картинка, которую надо повернуть, отмасштабировать и скруглить. Сравним два сценария развития событий.

В первом случае сначала мы поворачиваем картинку на 90 градусов, затем закругляем и только после этого меняем ширину. Во втором случае мы сначала меняем ширину.

Второй сценарий эффективнее, так как поворот и скругление «дешевле» делать на меньших изображениях.

Вернёмся к реализации. Ранее мы создали массив, который теперь должны передать в Glide, когда он будет отображать картинку по URL. Создаём объект RequestOptions и передаём ему массив. Помним, что нельзя передавать пустой массив — Glide упадёт. Поэтому обязательно добавляем проверку.

Так как будем переиспользовать трансформации в разных делегатах, будет удобно вынести их в экстеншн applyImageTransformations.

Также добавляем метод в интерфейс TransformableImage — getGlideTransformsArray(). Сам интерфейс и экстеншен applyImageTransformations помечены как internal. Так мы избегаем утечки абстракции, и конечный пользователь моделей и делегатов не знает, что используется внутри — в публичных интерфейсах Glide не виден. Удобно, если захотим заменить Glide на другую библиотеку.

В итоге код сокращается до такого вида:

Как создать делегат для отображения транзакции

Посмотрим снова на наш список транзакций. Мы уже знаем, как работает адаптер делегатов. Теперь создадим делегат для отображения транзакции.

Базовая реализация адаптера выглядит так:

Отображение текста убрано для упрощения. Мы научим этот делегат отображать транзакции с картинками из сети, из ресурсов, показывать аватар контакта, который создаётся из инициалов.

Сначала модифицируем модель.

В каждом случае передаём свои параметры, все в одном месте. Примерно так будет отображаться картинка:

Сразу видим минусы:

• такое решение тяжело расширять;
• важен порядок, который в свою очередь может быть неочевидным;
• бизнес-логика находится внутри адаптера (делегата).

Начнём сначала и попробуем использовать делегаты. Сделаем несколько доработок.

В модели вместо всех параметров оставляем только картинку на отображение:

В итоге список транзакций примет такой вид:

Поведение становится более явным, и мы вынесли логику из адаптера.

Как создать делегат для генерируемой картинки

Теперь рассмотрим частный случай и создадим делегат, который будет генерировать изображение из двух символов. В первую очередь, определим требования к этому делегату. Очевидно, он должен уметь отображать буквы и настраивать отображение.

Модель будет выглядеть следующим образом:

Для настройки фона используем ImageTransformations.

Перейдём к генерации битмапы. Можем использовать обертку TextDrawable, где внутри отрисовка идёт при помощи Canvas. Далее эту битмапу нужно обработать и установить в ImageView.

За счёт использования экстеншена реализация делегата занимает пару строк. Покажу, как он работает.

Первый вариант, где заданы базовые настройки:

Во втором варианте добавляем трансформацию скругления:

И в третьем — поворачиваем картинку. Нам ничего не стоит отображать иконку аватара в том виде, в котором это требуется согласно дизайну:

Как создать кастомную трансформацию

Представим, что нам надо сделать флип по горизонтали. Сначала создадим каркас класса трансформации:

В случае с Glide базовый класс должен быть BitmapTransformation. Glide снова упрощает жизнь, так как содержит TransformationUtils с нужными методами. Остаётся лишь добавить эту трансформацию к остальным.

Как тестировать

Одна из главных причин, почему стоит использовать именно этот способ работы с картинками — тестирование.
Нарисуем примерную схему архитектуры (clean) и покажем, как данные доходят до слоя UI. В качестве данных будем рассматривать список транзакций.

Получилась довольно стандартная схема. База данных возвращает список моделей, на уровне репозитория мы мапим их в модели доменного уровня. Тот, в свою очередь, передаст их на уровень выше — до UI. Каждый этап маппинга моделей покрывается тестами.

Рассмотрим, как может выглядеть доменная модель транзакции:

У неё есть доступ к id транзакции, сумме и дате. Как понять, что показывать — это денежный перевод или покупка в магазине? Откуда брать название, URL? Нам помогут sealed class.

Здесь мы видим два типа транзакций — перевод и покупка. Каждый имеет уникальный набор параметров.

Далее разберёмся, что является моделью для слоя UI, и для этого вспомним, как выглядел наш делегат для адаптера RecyclerView.

Модель делегата отлично подходит в качестве UI-модели.

Рассмотрим несколько сценариев, которые можем протестировать только за счёт использования делегатов для адаптера и картинок.

Кейс 1 — Перевод контакту без аватарки

Проверяем, создаётся ли модель картинки для отображения инициалов, если отсутствует URL аватара .

Кейс 2 — Перевод контакту с аватаркой

Ожидаем, что будет создана UrlImage с одной трансформацией.

Кейс 3 — Покупка в магазине, у которого в системе есть аватар

Идентично кейсу 2: ожидаем, что будет создана UrlImage с одной трансформацией.

Кейс 4 — Покупка в магазине без аватарки

В данном случае можем сделать дополнительную проверку: каждая покупка может относиться к разным категориям, и иконки будут отличаться. Можем также проверить, мапим ли каждую категорию в нужную иконку.

Выводы

Отображение картинок с помощью делегатов даёт несколько преимуществ.

Во-первых, мы освобождаем адаптер от логики, которой в нём быть не должно. Он не должен отвечать за выбор источника картинки в зависимости от набора параметров.

Во-вторых, мы абстрагировались от способа загрузки и обработки изображений. Теперь в любой момент времени мы почти без боли можем заменить Glide на что-то другое.

В-третьих, как следствие, мы можем тестировать отображение нужного типа картинки. То есть фактически тестировать отображение данных на экране.

Наконец, этот подход просто очень удобен.

Создание компьютерных игр не только интересное, но и прибыльное дело. По прогнозам аналитической компании Newzoo, игровая индустрия по объёмам в этом году превысит $152 млрд, а доходы отдельных игровых компаний уже давно исчисляются в миллиардах долларов.

На лекциях преподаватели образовательной программы «Менеджмент игровых проектов» рассказали, как можно выйти на этот рынок и создать свою игру. Они осветили все аспекты разработки, начиная от набора команды и технической поддержки и заканчивая маркетинговым планом. Всего лекций было четыре: «Построение процессов работы команды для создания игры», «Геймдизайн и креатив в игровой разработке», «Технические основы разработки», «Релиз близко. Маркетинг за месяц до выхода игры и месяц после». Мы собрали для вас краткий конспект каждого занятия и ссылки на видеозаписи.

Построение процессов работы команды для создания игры

На лекции были рассмотрены важные процессы работы над проектом: определение концепции продукта и выбор «product owner», подбор команды, распределение ролей в команде и выбор SCRUM-мастера, составление бэклога (backlog) и работа с ним, оценка задач и планирование спринта. Слушатели узнали о том, какие есть ключевые ритуалы в работе, как верно оценить результаты и повысить мотивацию команды.

«Любая игра начинается с идеи, которая пройдёт определённый путь, прежде чем окажется готовым продуктом. Но далеко не каждая идея сможет этот путь пройти до конца…»

Согласно статистике, среди всех игр, которые начинали запускаться, коммерческого запуска достигли меньше 1 %: начинающие разработчики часто ошибочно считают, что идея игры — это главное. Но идея становится ценностью лишь тогда, когда выполнено два условия:

1. Она оформлена хотя бы в виде первичной документации.
2. У вас появляется команда, способная воплотить эту идею в жизнь.

Разработка игры состоит из следующих этапов:

1. Подготовка.
2. Препродакшн.
3. Продакшн.
4. Релиз.

Подготовка

Этап подготовки включает в себя формирование идеи (вижн), поиск стратегии, предварительный анализ рынка, поиск и формирование команды, выбор управленческих методологий.

«На рынке много инди-проектов, которые выходят в магазины самостоятельно. Преимущественно это игры для платформы Steam. Не стоит забывать и о краудфандинге».

Анализ рынка — один из важнейших этапов при подготовке. Ключевой момент — это понимание своей аудитории: кто в вашу игру будет играть? Почему она будет выделяться на рынке? На эти вопросы нужно дать ответ именно на подготовительном этапе, иначе после выпуска игры может оказаться, что она никому не интересна.

Вижн — это самое главное, что у вас есть на начальном этапе разработки. Хороший вижн занимает одну страницу А4, на которой должно уместиться описание игры (платформа, жанр, сеттинг, модель распространения, описание геймплея, основные фичи и механики, цели игрока), референсы, USP (1 killer-фича + 2–3 уникальных/новых фичи и др.) Любой человек, который прочитает вижн, должен сразу понять, что за игру вы делаете.

«Когда у вас готов вижн, с вашей идеей игры можно работать».

В геймдеве используется два основных подхода к управлению командой/проектом: Agile и Waterfall. Большинство компаний использует гибридные методы, берущие элементы из обоих этих подходов. Waterfall — подход к управлению командой, основанный на последовательном, линейном цикле разработки. Agile же основан на гибкости и итерациях в развитии продукта/проекта. У каждого есть свои недостатки и достоинства. SCRUM — один из самых популярных методов практического внедрения философии Agile в IT-командах, он определяет роли, обязанности и ключевые «церемонии» в команде. Итерации в SCRUM называются спринтами.

«Есть минимальный набор документации, без которой дальше двигаться сложно».

Препродакшн

Препродакшн включает в себя составление документации, концепт, feature-list, art-style doc, бюджет, бизнес-план, проектный план, адаптацию и «срабатывание» команды, построение процессов. Самый незаменимый документ — это концепт, который позже «перерастает» в геймдизайн-документ. Бюджетом и бизнес-планом пренебрегать тоже не стоит, т. к. без них будет трудно понять, сколько вы заработали на продаже игры, выгодно ли вам продать игру за ту сумму, которую предложит заинтересовавшийся издатель. Результатом препродакшна является прототип или демоверсия вашей игры для демонстрации.

«Пока прототип не цепляет игрока, не стоит делать из него игру. Лучше разработать новый прототип».

Продакшн

Продакшн — это разработка игры, составление документации (геймдизайн-документ, маркетинговый план, план продвижения), повседневное управление проектом, решение возникающих проблем, корректировка планов и установок с препродакшна. Результат данного этапа — версия игры, ещё не финальная, но уже готовая к демонстрации пользователям.

«Продакшн — это самый длинный этап, на котором игра реализуется в полном объёме, со всеми её фичами и возможностями».

Разработка игры — это стрессовый процесс. Не забывайте о мотивации и уровне счастья сотрудников. У нормальной организации две задачи: максимальная прибыль предпринимателя и максимальное благосостояние сотрудника, причём не только в деньгах. Максимальное благосостояние в такой системе равно максимальной производительности всех участников процесса.

«Счастливый сотрудник = эффективный сотрудник!»

Релиз

Финальный этап включает в себя шлифование игры до финальной версии, оптимизацию под различные устройства, версии игры на разные платформы, публикацию игры в магазины. Результатом данного этапа является финальная версия игры, доступная в магазинах.

Намного более подробно все эти темы объясняются на занятиях курса «Управление командой» программы «Менеджмент игровых проектов» в Высшей школе бизнес-информатики НИУ ВШЭ. Кстати, на этом курсе слушатели сразу пробуют сами пройти путь разработчика на игропрактике Game Dev Sim. Это настольная игра — симулятор работы игровой студии, где участники как владельцы собственной компании набирают себе команду и проходят через все этапы разработки, решают возникающие проблемы, пользуются возможностями и воплощают мечту о создании игры.

Полностью послушать лекцию можно на YouTube-канале Высшей школы экономики.

Геймдизайн и креатив в игровой разработке

В чём различие между геймдизайном и продюсированием? Какова роль геймдизайна в создании игр? В чём польза и вред креатива? И главный вопрос: как правильно подходить к креативным задачам в геймдизайне?

«Игровая индустрия большая и очень-очень богатая. Объём мирового рынка составляет около $130 млрд».

Российская игровая индустрия появилась не так давно, но уже стала очень успешной. Западная же индустрия старая и очень опытная, она может позволить себе делать более масштабные проекты. Есть два принципиально разных подхода к созданию игр: путь крупных компаний с большими командами специалистов, работающими над множеством проектов, и путь инди-команд, где каждый участник может выполнять множество ролей.

Специалистов команды разработки можно условно разделить на три категории: «технари» (программисты, веб-разработчики, системные администраторы и т. д.), художники (специалисты, отвечающие за визуальную составляющую игры) и идеологи (геймдизайнеры и продюсеры). Инди-команды как раз могут состоять всего из трёх человек, которые значительную часть работы отдают на недорогой аутсорсинг.

Идеолог игры

Многие думают, что игры придумывают и делают именно геймдизайнеры, но это не так. Идеологом игры является продюсер. Главные задачи продюсера: обеспечить всё необходимое для создания игры, привлечь ресурсы (деньги, люди, время), иметь чёткое видение и план достижения целей, довести проект до релиза и коммерческого успеха. Именно продюсер принимает все ключевые решения по игре, но несёт полную ответственность за результат и качество проекта. И он практически всегда участвует в собеседованиях потенциальных сотрудников.

У продюсера три ключевых подхода к созданию игры:

1. 100-процентный клон.
2. Инновация.
3. Венчур.

И, конечно же, у каждого из этих подходов есть свои плюсы и минусы.

«Ваша игра успешная, если она зарабатывает деньги».

Но заработать деньги — это не единственная цель создателей игры, есть ещё много других, не менее важных: набрать аудиторию, раскрутить бренд, обучить чему-то (образовательные игры), достичь творческой реализации.

«Чтобы сделать крутую игру, нужно набраться опыта».

Геймдизайнер

Геймдизайнер — это человек, который делает всё и сразу. Это редкий специалист, которому нужно иметь опыт и знания практически во всех областях, но профессионалом в каждой из них можно и не быть. Геймдизайнер реализует видение продюсера, пишет и актуализирует ГД-документации, рассчитывает характеристики, баланс и экономику игры, участвует в разработке сюжета/ЛОРа, нарратива, разработает ТЗ для других специалистов, контролирует исполнение этих задач, конфигурирует продукт, создаёт инструментарий, участвует в работе над левел-дизайном, проводит тестирование.

Внесение данных в игру, настройка различных параметров, другая базовая работа — это то, с чего начинает большинство геймдизайнеров. Часть из них постепенно совершенствует свои навыки и учится программировать, что повышает эффективность работы с данными. Но большинство затем переключается на другие направления геймдизайна.

«Написать диздок — это одна задача, но не менее важно донести информацию максимально просто и легко».

Хорошим тоном считается добавлять в документацию простые диаграммы, схемы, которые коротко и ёмко показывают, о чём ваша игра. Это также помогает команде в работе над игрой и позволяет на любом этапе разработки быстро ввести в курс дела новых сотрудников.

Приведём пример проектирования интересного геймплея, который создаёт Retention (удержание игроков в игре).

Цели должны отвечать на главный вопрос игрока: «Зачем мне в это играть?» или «Почему мне это интересно?». Цели бывают сиюминутными, краткосрочными и долгосрочными.

«Работа геймдизайнера — это, прежде всего, исследование».

Есть два способа стать геймдизайнером:

1. Читаем статьи, учимся программировать, рисовать, моделить, делаем инди-игру, набираемся опыта, вкладываем свои деньги, пробуем попасть на работу в большую компанию, где научат. Набравшись опыта, идём делать продукты.
2. Получаем опыт коллег, которые уже наступали на грабли, экономим время и быстро учимся, делаем свой дипломный проект, идём в компании-партнёры вуза и трудоустраиваемся.

Какой подход лучше? Это вы сможете понять, если посмотрите полную запись лекции.

Технические основы разработки

На третьей лекции у слушателей была возможность узнать о технических задачах при разработке игр: игровой логике, графике (двухмерной и трёхмерной), физике игрового мира, звуке, игровых картах, хранении данных, тестировании игры. Участники узнали об игровых движках (на примере UE4 и Unity) — логике, физике и картах, средствах разработки графики и звука (Photoshop, Max/Maya, Audition) и инфраструктуры — базы данных, репозитории, сборка проекта, автоматическое тестирование.

«Вы сделали крутую игру, которая порвёт рынок, принесёт вам миллионы и обеспечит яхту!.. Как из мечты это превратить в реальность?»

Раньше один разработчик игр был всеми и сразу: геймдизайнером, программистом, иллюстратором, автором звуковых дорожек, тестировщиком и т. д. Но сейчас ситуация изменилась: в крупных компаниях и командах над одним проектом работает около 200 человек и больше, с разными специализациями, на самых разных должностях. Тем не менее, даже сейчас люди продолжают делать игры в одиночку или маленькими командами.

«Делая игру, вы должны верить, что она заработает, что она будет интересна и востребована».

Состав игры с технической точки зрения выглядит следующим образом:

1. Игровая логика.
2. Графика (2D и 3D).
3. Интерфейс.
4. Игровые карты.
5. Физика игрового мира.
6. Звук.
7. Хранение и пересылка данных.
8. Инфраструктура.

Игровая логика — это спецификации того, что при условии А произойдёт событие В, например: если персонаж ударит монстра мечом, то он нанесёт ему 3 урона из 10 hp. И всё это должно быть где-то закодировано — этим занимаются программисты гейм-механики, но часто этим занимаются геймдизайнеры.

«Всё, что вы придумали для своей игры, должно быть кем-то реализовано».

Большинство игр тяжело представить без графики, которую можно, с точки зрения технологического производства, разделить на два основных типа: 2D и 3D. Интерфейс — это то, как игрок взаимодействует с игрой. На практике интерфейсами занимаются отдельные люди, потому что для этого требуются особые навыки, отличающиеся от тех, какими владеют даже очень хорошие художники.

Если в игре есть игровой мир, то в ней должны быть карты, на которые нужно поставить много различных объектов, сделать красивый ландшафт, расставить монстров и т. д. Всем этим занимается левел-дизайнер.

Важная часть игрового мира — это физика; задача сложная и для программиста, и для геймдизайнера. Звук — широкая область деятельности: музыка, простые звуки (выстрелы, взрывы и т. д.) и озвучка. В игре очень много данных, которые нужно хранить и пересылать (клиент-серверные протоколы). Инфраструктура же нужна для того, чтобы всё перечисленное стало возможным: репозиторий, различные системы хранения документации, билдеры и т. п. Сейчас даже в инди-командах используют достаточно много хороших практик, чтобы упростить разработку.

Средства разработки и решения при создании игры:

1. Дизайн (спецификации).
2. Целевые платформы.
3. Движок.
4. Код.
5. Клиент и сервер.
6. Ассеты (карты, арт, звук и т. д.).
7. Специалисты.

Особенности работы с движком

Движок — это комплексное ПО, которое позволяет вам не делать всё с нуля, а сразу даёт много готовых решений, например: редактор карт, систему искусственного интеллекта и многое другое. Важно понимать, на каких языках программирования вы будете писать код. Самые частые решения для клиентских и большинства мобильных игр — это C++ и C#. Для серверной же части применяются намного больше вариантов: PHP, Python, Java и множество других языков.

«Движок — ключевой выбор для разработки игры».

Когда-то движки были прерогативой крупных студий, т. к. их нужно было делать с нуля, а коммерческие (например Unreal Engine) стоили дорого. Но сейчас они стали практически бесплатными и доступны даже ограниченному в средствах инди-разработчику. Что же даёт движок? Прежде всего, это:

1. Графика/рендеринг.
2. Физика.
3. Звук.
4. Искусственный интеллект.
5. Редактор.
6. Сетевой код.
7. Оптимизация.
8. Готовые библиотеки и решения: платежи, VR/AR, многое другое.

Чтобы понять, какой именно движок подходит для вашей игры, нужно обратить внимание на следующие характеристики: графика, логика (Blueprints, Flowgraph и др.), языки программирования, физика, средства 3D-разработки, интерфейсные решения. Современные движки значительно упрощают работу с базами данных.

«Об оптимизации лучше задуматься заранее».

3D-модель начинается с 2D-модели. Концептом может быть не только отрисовка, но и реальный объект или даже фотографии, которые называют референсами. Сначала делается базовая 3D-модель, а после неё — HighPoly (детализация). На выходе получаются красивые 3D-модели, которые часто показывают на промо-артах, но в самой игре этих моделей, скорее всего, не будет. Причина проста: на основе HighPoly создают LowPoly-модели, в которых меньше полигонов и немного ниже качество, но зато такой подход помогает лучше оптимизировать игры. Далее на модели накладываются текстуры для последующего экспорта в движок, где уже ведётся дальнейшая работа по анимации. Наиболее популярные программы для работы с 3D: 3ds Max, Maya, Blender (free).

«Снизить качество проще, чем повысить».

Звуковые эффекты большинство разработчиков берёт из различных доступных библиотек звуков. Главная проблема работы со звуком в играх — это озвучка: готовые голоса вы не найдёте нигде. Озвучка, сделанная своими силами, обычно звучит непрофессионально и слабо. Есть два решения проблемы: 1) игра без голосов; 2) работа с профессиональными актёрами. Самые распространённые звуковые редакторы: WavePad, Adobe Audition, Audacity (free).

Чтобы не запутаться во всей этой информации при работе, используют такие инфраструктуры, как системы документооборота, постановки задач, контроля версий и т. д. Системы документооборота применяют для хранения дизайна, выкладывания артов, планов, комментирования и т. д. Наиболее яркие примеры систем: MediaWiki, Confluence, GoogleDocs. Системы постановки задач подразделяются на локальные и удалённые (онлайн) и позволяют контролировать и оценивать: каково текущее состояние проекта, какие задачи выполнены или выполняются, и кто их выполняет, сроки и объёмы выполнения и т. д. Самые популярные системы: Jira (Atlassian), Youtrack (JetBrains), Redmine, Trello, Мегаплан, Asana, Wrike. Системы контроля версий позволяют работать вместе над одним проектом, иметь полную историю изменений с возможностью отката и переноса и интегрироваться со всей остальной инфраструктурой. Примеры: SVN, Git, Mercurial, Perforce, Microsoft TFS.

«Не стоит разрабатывать игры без системы контроля версий, даже в одиночку».

Посмотреть эту лекцию полностью вы можете на YouTube-канале Высшей школы экономики.

Релиз близко. Маркетинг за месяц до выхода игры и месяц после

Выход игры. Именно к этому стремятся все разработчики. И именно период релиза является одним из самых важных для проекта. Увидит ли его аудитория, какие оценки он получит от профильной прессы, можно ли будет рассчитывать на поддержку платформы? Сделать всё возможное, чтобы игра получила свою «путёвку в жизнь», — вот задача маркетинга на данном этапе. Как максимизировать эффект от маркетинговых активностей, не тратя лишнего? Всё это обсуждалось на заключительной лекции цикла «Как создать свою игру».

о том, как подготовить маркетинговые материалы, обеспечить PR-поддержку и наладить работу с лидерами мнений.

«Когда останется месяц до релиза игры, у вас появится ощущение, что вы не всё успеваете… И чаще всего оно будет верным».

Так как же за один месяц сделать то, на что у многих уходит по полгода?

Рассмотрим гипотетическую ситуацию: у вас есть хорошая игра, месяц до выхода и некоторый бюджет. Есть у вас и конкуренты: каждый день в Steam выходит от 10 до 30 новых продуктов, в App Store и Google Play — около 1500. Большинство разработчиков игр столкнётся с маркетингом ещё на этапе разработки.

«Если не заниматься маркетингом игры, то шансы, что она «взлетит», равны нулю».

Жизнь маркетолога за месяц до релиза, можно условно разделить на пять стадий: осознание, паника, ревизия, планирование, исполнение. Рассмотрим их подробнее:

1. Осознание: релиз неизбежен! Чем ближе дедлайн, тем больше мобилизуется команда.

Для маркетолога самое важное на этом этапе понять, что от него хотят, и поставить цели. Все цели должны отвечать следующим критериям:

1. Быть чёткими и конкретными.
2. Быть измеряемыми.
3. Быть достижимыми. К этому критерию нужно относиться с особым вниманием, т. к. в случае неудачи виноватым останется именно маркетолог.
4. Иметь чёткие временные рамки.

Чтобы эффективно использовать имеющийся бюджет, вся команда должна чётко понимать эти цели. Когда сроки и ответственные исполнители назначены, наступает вторая стадия.

2. Паника. На второй стадии будет казаться, что вы ничего не успеваете, денег нет, и ничего не получается. Самое главное здесь не допустить, чтобы паника переросла в депрессию, т. к. это может привести к стадии глухого отрицания, из которого человеку трудно себя вывести. Самый простой способ перейти из состояния паники в более продуктивное — начать проводить «маркетинговую ревизию».

3. Ревизия. На третьей стадии маркетологу нужно понять, что сейчас имеется из маркетинговых ассетов, с чем вы будете дальше работать, и что нужно доделать прямо сейчас. Маркетинговые ассеты анализируются по трём основным аспектам: для игроков и комьюнити, для прессы и инфлюенсеров и для рекламы.

Что есть для игроков и комьюнити?

«Именно на основе страницы вашей игры в магазине люди принимают решение: купить её или нет».

Чем и как вы будете увлекать комьюнити? Самое главное — это страница игры в игровом магазине, о её качественном наполнении и оформлении нужно позаботиться в первую очередь. Чтобы собрать комьюнити, желательно также сделать страницы игры в социальных сетях. Нельзя публиковать по одному посту в месяц, т. к. в скором времени их никто уже не будет читать, даже если в группе очень много подписчиков.

Чтобы успешно всё это сделать, маркетологу нужно заранее составить контент-план, в котором будет чётко указано, что, когда и где публиковать, чем развлекать аудиторию. Для комьюнити ваша игра начинает медленно «умирать», если в группе не делаются посты хотя бы два раза в неделю.

«Комьюнити не прощает одной вещи — пустоты».

Что есть для прессы и инфлюенсеров?

Их внимание очень важно. Пресса не даёт прямых продаж, но даёт широкий охват и повышает узнаваемость вашей игры, что впоследствии конвертируется в покупки. Для работы с прессой нужно иметь пресс-кит и пресс-релиз. Пресс-кит — это краткое описание игры, скрины, арты, логотипы и трейлер в хорошем качестве. Чтобы ваш пресс-релиз хотя бы прочитали, он должен быть по-настоящему классным: найдите изюминку своей игры и акцентируйте на ней внимание.

Внимательно выбирайте каналы и стримеров, с которыми будете работать. Ищите и используйте возможности расширить аудиторию, чтобы как можно больше людей поиграло в вашу игру.

Что есть для рекламы?

Рекламу нужно выбирать по имеющемуся бюджету: если большой — можно экспериментировать, пробовать разные форматы рекламы и продвижения, если маленький, то лучше найти 1–2 наиболее эффективных канала, которые принесут максимальную пользу.

По итогам ревизии вы сможете выбрать эффективную стратегию выхода на рынок. Например:

1. «Анонс пока не поздно»: анонсируем игру сейчас, чтобы успеть за месяц набрать хотя бы какую-то аудиторию.
2. «Apex method»: анонс в день релиза и отсутствие маркетинга до этого момента. Сосредоточение усилий на дне релиза, когда за несколько дней нужно «выложиться» по максимуму. Стратегия хороша для мобильных игр.
3. «Помогите, кто чем может». Подходит для тех, у кого уже есть комьюнити, у которого можно попросить помочь с набором аудитории. Но нельзя пытаться реализовать несколько стратегий одновременно, выбор зависит от платформы игры, её жанра и многого другого. Вам нужно выбрать только один путь выхода на рынок.

4. Планирование. Это самый важный этап, без которого не получится двигаться дальше. На этом этапе составляется маркетинговый план проекта, не только до момента релиза, но и после. Ваш план будет постоянно меняться — это нормально, но он обязательно должен быть.

5. Исполнение. Самое главное — придерживаться составленного плана и решать текущие задачи. В процессе нужно вести учёт активностей, чтобы понимать, куда вы двигаетесь и анализировать всё то, что уже сделали. Аналитика должна быть у вас до релиза. Если понимаете, что план сложно реализовать — меняйте его. Это живой документ.

«Игроки не готовы терпеть ваши недоделки и ошибки: они уйдут в другую игру».

Вы проделали большую работу, осталось три дня до часа Х. В это время нужно провести ещё одну ревизию на основе маркетингового плана, проверить готовность всей команды, составить максимально подробный чек-лист релиза. И следите за тем, чтобы билд игры был стабилен!

Ваша главная задача в день релиза — идти строго по чек-листу, последовательно выполняя все пункты. Важно следить за первыми реакциями игроков и оперативно давать комментарии. Помните главное: паниковать нельзя, нужно действовать по плану. После релиза вам нужно изучить первую аналитику и сделать выводы: что сделано плохо, а что хорошо. В зависимости от результатов корректируйте маркетинговый план.

Следующий этап — оперирование игры, но это уже совсем другая история.

«Создание игр — это искусство! Но это ещё и тяжелый труд. Ну а так как результаты труда позволяют участникам процесса получать доход от вложенных ресурсов, то это ещё и хороший бизнес. Так что игровая индустрия — это, на наш взгляд, одно из лучших мест, где можно творить, самореализовываться, развиваться и зарабатывать!»

Event Loop (цикл событий) — один из важнейших аспектов в JavaScript, знание которого позволяет писать более эффективный код. В статье мы рассмотрим, как работает основной поток в JavaScript и как он обрабатывает асинхронные функции.

Долгое время я писал код на JavaScript, не до конца понимая, как он работает под капотом. В принципе, для того чтобы кодить на JavaScript, знать принципы его работы изнутри и не нужно, но это сделает ваш код лучше и позволит взглянуть на некоторые вещи в языке под другим углом.

Весь код в JavaScript выполняется в одном потоке, т. е. за один раз может обрабатываться только что-то одно. С одной стороны, это полезное ограничение, так как оно позволяет нам не задумываться об особенностях работы с параллелизмом. С другой стороны, мы постоянно должны контролировать код и заботиться о том, чтобы синхронные операции (бесконечные циклы, запрос данных по сети) не блокировали наш поток.

В большинстве браузеров у каждой вкладки свой цикл событий, это позволяет изолировать вкладки друг от друга, и если одна зависнет, другие продолжат работать. В противном случае одна зависшая операция могла бы нарушить работу всего браузера во всех вкладках.

По факту окружение может одновременно управлять большим количеством «циклов событий» для обработки API-запросов. WebWorkers также имеют свой цикл событий.

JavaScript-разработчик должен знать, что его код всегда выполняется в одном цикле событий, и следить за тем, чтобы не заблокировать его.

Блокирование Event Loop

Любой код, который будет долго выполняться прежде чем вернёт управление в основной поток, блокирует выполнение любого JavaScript-кода на странице. При этом также блокируется пользовательский интерфейс, и пользователь не может с ним взаимодействовать (кликать, прокручивать страницу и т. д.).

Почти все операции ввода/вывода в JavaScript являются неблокирующими — сетевые запросы, операции с файловой системой в Node.js и т. д. Исключением являются блокирующие операции, и именно поэтому в JavaScript так популярны обратные вызовы (callbacks), а в последнее время всё чаще начинают использовать Promise и async/await.

Стек вызовов

Стек вызовов — это очередь LIFO (Last In, First Out).

Цикл событий непрерывно обрабатывает стек вызовов в поиске функции, которая должна быть обработана. При этом он добавляет любой найденный вызов функции в стек вызовов и выполняет каждый по порядку.

Если вы знакомы со стеком вызовов в отладчике или консоли браузера, то пример далее будет вам понятен. Браузер ищет имена функций в стеке вызовов, чтобы сообщить вам, какая функция инициирует текущий вызов:

Примеры работы с Event Loop

На небольшом примере мы рассмотрим, как работает Event Loop:

После выполнения этот код выведет:

В принципе, как и ожидалось.

Давайте подробно разберём, как этот код обрабатывается через Event Loop. Когда код выполняется, первым вызывается foo(), внутри foo() первой вызывается bar(), а затем baz().

В этот момент стек вызовов выглядит так:

Цикл обработки событий на каждой итерации проверяет, есть ли в стеке вызовы, и если да, выполняет их:

Этот процесс продолжается до тех пор, пока стек не станет пустым.

Порядок выполнения функций

В примере выше нет ничего специфичного: JavaScript анализирует код и определяет порядок вызова функций.

Давайте посмотрим, как мы можем изменить порядок вызова функций, сделав так, что определённая функция будет вызвана последней. Для этого мы выполним вызов нашей функции посредством browser API:

setTimeout(() => {}, 0);

Рассмотрим следующий пример:

Результат выполнения этого кода для некоторых может стать неожиданным:

Когда этот код выполняется, сначала вызывается foo(). Внутри foo() мы сначала вызываем setTimeout, передавая bar в качестве аргумента, а временным интервалом указываем 0, чтобы вызов произошёл настолько быстро, насколько это возможно. Затем мы вызываем baz().

На этом этапе стек вызовов выглядит следующим образом:

Порядок вызова функций в этом случае будет выглядеть так:

Далее мы рассмотрим, почему так происходит.

Очередь сообщений (The Message Queue)

Когда вызывается setTimeout, браузер или Node.js запускают таймер. Когда время таймера истекает (в нашем случае это произойдёт немедленно, так как мы указали 0 в качестве временного интервала), наша callback-функция будет помещена в очередь сообщений.

В очередь сообщений также помещаются события, инициируемые пользователем (клик, нажатие клавиш на клавиатуре, движение мышки, сетевые запросы, такие как fetch), а также события, генерируемые DOM, например onLoad.

В первую очередь Event Loop обрабатывает всё, что содержится в стеке вызовов, и только после этого начинает обрабатывать содержимое очереди.

Нам не нужно ждать, пока такие функции, как setTimeout, fetch или другие выполняют свою работу, поскольку они предоставляются браузером и живут в своих потоках. Например, если вы установите время ожидания setTimeout равным 2 секундам, вам не придётся ждать 2 секунды — ожидание происходит в отдельном потоке.

Очередь заданий (ES6 Job Queue)

ECMAScript 2015 представил концепцию очереди заданий, которая используется в Promises (также представлена в ES6/ES2015). Это способ выполнить результат асинхронной функции как можно скорее, а не помещать его в конец стека вызовов. Обещания, которые разрешаются до завершения текущей функции, будут выполняться сразу после текущей функции.

Это своего рода VIP-очередь, обработка которой имеет приоритет по отношению к обычной очереди.

Пример:

Результат:

В этом большая разница между Promises (а также async/await, который построен на Promises) и привычными асинхронными функциями через setTimeout() или другие API-платформы.

Надеемся, статья поможет вам разобраться с работой Event Loop в JavaScript, включая работу с потоками, очередями событий и API браузера. Для наглядности мы рассмотрели несколько примеров и то, как их можно оптимизировать с точки зрения производительности.

Крупные компании всё чаще проводят внешние хакатоны, привлекая специалистов и просто креативных людей со всего мира. Поиски решения новой задачи или свежего взгляда на давнюю проблему проходят в условиях напряжённой и одновременно вдохновляющей атмосферы. Отчасти дух инноваций и креатива и стал одной из причин популярности подобных состязаний. Внутренние хакатоны тоже не отстают и заменяют старый, весьма затратный и не всегда оправдывающий себя тимбилдинг. Двойная польза: коллеги не только подружились и встретились в неформальной обстановке, но и решили задачу, до которой в повседневной рабочей рутине руки могли так и не дойти.

Более того, некоторые организаторы стараются сделать необычными сами хакатоны: делают их тематическими, помещают участников в непривычные локации или условия, расширяют географию или ограничивают используемые технологии. Как минимум это выделяет хакатоны из массы других и привлекает к ним внимание, а как максимум — помещает участников в ещё более стрессовые, даже экстремальные ситуации, чем побуждает выкладываться на полную катушку. Мы расскажем о хакатонах, которые удивили нас больше всего.

Хакатон в поезде

В прошлом году Беларусь и Латвия организовали совместный хакатон: он стартовал в Минске и проходил в поезде Минск — Рига. Идея, со слов организаторов, была в том, чтобы исследовать и сблизить стартап- и бизнес-экосистемы двух стран. Специально для хакатона к поезду прицепили дополнительный вагон, в котором ехали участники и менторы. А в Риге на перроне их встречал министр экономики Латвии. Участники побывали на мастер-классах и менторских сессиях, узнали о том, как создать бизнес-модель, выявить спрос и найти инвесторов. Побывали в инновационном кластере Рижского технологического университета, коворкингах People Work и банка Swedbank. Кстати, это не первый хакатон подобного рода: группа британских железнодорожных компаний и Департамент транспорта Великобритании в 2015 году организовали Hacktrain. Сто пятьдесят человек — разработчиков, инженеров, дизайнеров и предпринимателей — приняли участие в хакатоне в поезде с целью улучшить железнодорожную систему Великобритании. Поезд шёл из Лондона в Йорк, состязание длилось 48 часов. Призовой фонд составил 25 000 фунтов стерлингов, а авторы лучших идей получили шанс представить свои проекты министрам и высшему руководству железнодорожных компаний.

Хакатон в самолёте

Ещё один необычный хакатон проходил во время перелёта из Гонконга в Лондон. Организаторы мероприятия Hack Horizon задались целью усовершенствовать опыт путешествий в целом, создав новые решения клиентского сервиса. Hong Kong International Airport (HKIA), Heathrow Airport, Travelport, Skyscanner, MTR и Regal Hotels объединились, чтобы осуществить этот необычный полёт и расширить прежние границы бизнеса путешествий. Всего 32 разработчика, дизайнера и предпринимателя были выбраны из почти 700 заявителей со всего мира. В зависимости от набора навыков, участников разделили на команды от 3 до 5 человек и предложили создать инновационное решение для отелей и аэропортов прямо на борту самолёта Британских авиалиний. У ребят в распоряжении были лучшие технологии туриндустрии и API нужных сервисов. Они также имели возможность получить совет и поддержку от приглашённых менторов и экспертов. В результате за 72 часа участники создали 8 прототипов решений наболевших проблем, которые возникают в путешествии. Среди идей были: система безопасного трансфера багажа на базе блокчейн, смарт-часы, построенные с использованием глубинного обучения, которые персонализируют опыт пассажира в аэропорту, цифровой сервис для родителей, организующих длительное пребывание своих детей за границей. Hack Horizon погрузил участников хакатона в настоящее путешествие и дал им возможность получать быструю обратную связь от путешественников, чтобы они смогли сфокусироваться на реальных слабых местах путешествий.

Пивной хакатон

В апреле 2018 года в Цюрихе и Райнфельдене прошёл пивной хакатон Beerhack. Одним из главных партнёров и организаторов была крупнейшая швейцарская пивоваренная компания Feldschlösschen. Задания были направлены на решение вопросов транспортировки, упаковки и технологического процесса в ходе производства пива. Всего в состязании приняло участие 66 человек. А трое победителей получили призы: по 3000 швейцарских франков и шанс пройти трёхмесячный курс по реализации своего стартапа от ещё одного организатора, Swiss Startup Factory Accelerator. Интересный факт: за время мероприятия было выпито 400 кружек пива.

Highkathon

Как можно догадаться из описания, этот хакатон напрямую связан с запрещёнными веществами. Но нет, разработчики не были накурены… скорее всего. Просто главными спонсорами выступили компании, занимающиеся производством, распространением или популяризацией марихуаны в США и Канаде. В ходе хакатона GrowUp Cannabis Hackathon, который впервые состоялся год назад, в сентябре 2018 года, соревнующиеся команды программистов, дизайнеров и инженеров искали идеи и решения для отслеживания, покупки, формирования отчётов, идентификации штаммов, верификации, интеграции с индустрией развлечений и многого другого. В жюри, конечно, сидели топ-менеджеры ведущих компаний в индустрии коноплеводства, а финалисты хакатона отправились в cannabis-friendly тур.

Хакатон для комиков

Десятый юбилейный Comedy Hack Day — гибрид хакатона и открытого микрофона — прошёл в январе 2016 года в Сан-Франциско. На нём собрались представители двух, пожалуй, самых активных комьюнити в интернете: комики и программисты. С поправкой на то, что комики интересовались технологиями, а программисты жаждали какого-нибудь несерьёзного мероприятия. По результатам двухдневного мозгового штурма команды презентовали мобильные приложения, а сами презентации были больше похожи на стендап-шоу. Так, победителем стала команда, создавшая приложение, которое помогает поделить чек в ресторане на всю компанию, основываясь на гендерном и расовом неравенстве в доходах. Другие команды предлагали решения, позволяющие оценить угол раздвинутых ног мужчины в общественном транспорте и определить, менспреддинг ли это; тиндер для тех, кто хочет поделиться пиццей; адблок, который заменяет рекламу на фото человека, за которым вы следите в соцсетях, и множество других не менее интересных приложений. Уникальным хакатон сделал и тот факт, что по его итогам разработчики собрали 0 $ венчурных инвестиций.

Хакатоны уже давно перестали быть средой исключительно для технарей. Они усложнились и превратились в нечто универсальное, применимое не только в банковской сфере, IT и телеком, но и в урбанистике, медицине, благотворительности, маркетинге, e-commerce, производстве. В нестандартных, а иногда и стрессовых условиях даже обычного «классического» хакатона рождаются решения и идеи, которые никогда не пришли бы в голову разработчику, сидящему в комфортном офисном кресле в расслабленной атмосфере. И этим польза хакатонов не ограничивается.

Плюсы хакатонов

• Возможность научиться чему-то совершенно новому. Да, возможность есть всегда, и каждый может ей воспользоваться вне хакатона. Но в атмосфере полного погружения и креатива вы не просто узнаёте новое, но и вдохновляетесь и заражаете своей тягой к инновациям всех вокруг.
• Отличный способ проявить себя и найти классного работодателя. Не секрет, что с помощью хакатонов компании нередко ищут себе новые таланты. И HR-хакатоны, которые также стали трендом 2019 года, несут в себе идею абсолютно нового поиска сотрудников и превратились в мероприятие, сильно отличающееся от старого доброго рекрутинга. HR может не только заметить нужных ему специалистов, но и увидеть их в работе с участниками команды.
• Возможность встретиться с новыми людьми. Где же ещё, как ни на хакатоне вы сможете встретить себе подобных, столь же увлеченных новыми идеями и их воплощением людей. И дело не только в знакомстве с потенциальными коллегами и работодателями, вы можете познакомиться с человеком, который вдохновит вас на новые проекты или сам предложит создать один из них.
• Командный дух. Он заразителен настолько, что устоять не получится. Даже если регулярным выходам в свет вы предпочитаете так же регулярно почитывать любимую книжку наедине с самим собой и чашечкой свежесваренного капучино. Никто не сможет остаться в стороне, все идеи нужны и важны, любые предложения могут сработать. Хакатоны, перестав быть частью IT-сообщества, сами превратились в крупное сообщество, лишённое каких-либо условностей. Даже не имея опыта, скажем, в маркетинге, но имея пару неординарных идей, вы сможете поучаствовать в хакатоне или даже выиграть, разделив победу с верной командой единомышленников.

Начинающий разработчик часто не задумывается, для чего предназначена программа и как она будет использоваться в будущем. У многих на первый план выходит соответствие стандартам качества кода, а не то, как этот код будет использоваться в реальной жизни.

Если постановщик задачи недостаточно опытный или у него нет времени вникать в бизнес-процессы, может возникнуть ситуация, когда в тестовом режиме программа работает корректно, а при переходе в продуктивную версию демонстрирует кучу ошибок и недочётов. Разберёмся, что нужно учитывать начинающему программисту, чтобы разработка оказалась полезной для конечного пользователя.

Шаг 1: Доверяй, но проверяй

Начинающие разработчики часто реализуют «хорошие» алгоритмы, которые прекрасно работают с «правильными» данными. Они не обращают внимание на поведение программы, когда в качестве исходной информации поступают «неправильные» данные. А именно это, как правило, первым делом и случается, как только программа начинает работать в продуктивной среде.

Учесть абсолютно все возможные ситуации программисту, конечно, сложно, но работать в этом направлении необходимо. Алгоритм должен иметь проверки в каждом блоке кода и генерировать для пользователя сообщения с указанием предупреждений или ошибок в данных.

Шаг 2: Встаньте на место пользователя

Ещё одна сложность может быть связана с пользователями программы. Любой пользователь, даже имея чёткую инструкцию по работе с программой, всегда может нажать такую комбинацию кнопок или ввести такие данные, которые сломают «хороший» алгоритм, если он не имеет защиты.

Для этих целей на крупных проектах часто есть тестировщики или программные средства автоматического тестирования. Возникает вопрос, что делать, если этого нет.

Разработчику представить себя на месте пользователя на самом деле не так трудно, как может показаться. Пользователи тоже люди и способны совершать ошибки. Нужно не полениться и нажать на все подряд средства навигации, а также ввести некорректные данные во все возможные поля.

Шаг 3: Комментируйте логику кода при его написании

Сложно приучить себя писать код программы и сразу же объяснять его логику в комментариях. Здесь необходимо пояснение: не нужно расшифровывать каждую строку и очевидные вещи вроде инициализации значений переменных, но назначение небольших блоков кода можно легко описать одной строкой текста.

В большинстве случаев достаточно будет одного пояснения на каждые 10–20 строк кода, это сильно упростит последующую поддержку и модификацию приложения.

Шаг 4: Ничего не откладывайте на потом

Разработчики могут сами создавать себе неявные проблемы при работе над многодневной задачей, когда сознательно пропускают неосновные блоки в коде. Например, расширенные проверки данных перед их обработкой или логирование там, где это необязательно. Это впоследствии может помешать разобраться с возникающими ошибками в программе.

Такие вещи выглядят не слишком существенными на фоне других задач. Создаётся ощущение, что их можно пропустить и вернуться к ним позже. Самое трудное — осознать, что потом может не наступить. После тестирования и исправления дефектов на доработки часто просто не остаётся времени. Не стоит пропускать или откладывать что-либо в реализации алгоритма, особенно если работа над ним занимает больше одного дня.

Шаг 5: Сохраняйте спокойствие и выдержку

Нередко мы попадаем в ситуации, когда времени в обрез: авралы бывают у всех. Спешка в разработке приводит к тому, что программа на выходе способна запускаться и выполнять некоторые действия, но имеет серьёзные провалы в структуре.

В лучшем случае код может содержать кучу «мусора», оставшегося от попыток решения алгоритмических проблем. А в худшем — программа может просто не быть в достаточной степени отлажена и протестирована, чтобы справляться со всем спектром возложенных на неё бизнес-процессов.

Это обязательно приведёт к необходимости часто дорабатывать программу из-за постоянно возникающих инцидентов в продуктивной среде. Необходима трезвая оценка своих возможностей и спокойная реализация без паники и страха что-то не успеть.

Как мы это делали: взяли список самых дорогих компаний Рунета по версии Forbes, добавили компании из списка крупнейших IT-компаний России по версии CNews, собрали адреса офисов и проанализировали заказы, которые доставляли туда в этом году. Если у компании несколько офисов, как, например, у Яндекса, мы делали консолидированный рейтинг. В итоге у нас получился список товаров, которые курьеры Ozon чаще всего привозят в офисы к разработчикам.

Кофе

Абсолютный лидер в списке самых популярных среди разработчиков товаров. В капсулах для кофемашин, в зёрнах, молотый и растворимый — в Лаборатории Касперского, Wargaming, Wildberries и других компаниях кофе в различных его видах заказывают чаще, чем что-либо ещё.

Батончики

В каждой пятой компании из списка протеиновые и энергетические батончики — хит продаж. Любовь к батончикам, например, объединяет команды Ozon и Сбертеха. Только в наш офис вместе с ними заказывают тонизирующую жевательную резинку, а в офис банка — пальчиковые батарейки.

Товары для животных

Как ни странно, корм, различные лакомства и пакеты для выгула собак занимают почётное третье место по количеству заказанных разработчиками товаров. При этом наибольшей популярностью пользуются консервы для кошек со вкусом индейки, их чаще всего заказывают в QIWI и 2ГИС, а в Сбербанке и Авито в списке самых популярных — лакомства для щенков и пакеты для выгула собак.

Наушники

Сколько бы программисты не ругали опен спейсы, так работа идёт быстрее, и именно поэтому в большинстве офисов IT-компаний нет лишних стен. Самый простой способ сосредоточиться — наушники, самый популярный формат — вакуумные вкладыши с защитой от внешнего шума. А чаще всего наушники заказывают в офис Mail.ru — 150 пар вакуумных наушников наши курьеры доставили на Ленинградский проспект в этом году.

Итак, чем можно порадовать программиста:

• протеиновыми и энергетическими батончиками;
• кофе — в зёрнах, капсулах для кофемашины или даже растворимым;
• сюрприз: книгами по развитию эмоционального интеллекта и искусству переговоров — несмотря на то, что в этом году мы отвезли в офисы разработки всего 22 книги, именно такую литературу заказывают чаще всего (впрочем, возможно, это проделки менеджеров).

Развитие виртуализации и облачных технологий, а также широкое распространение методологий гибкой разработки и DevOps-практик позволило создать новый подход к разработке ПО — микросервисную архитектуру (MSA — Micro-Service Architecture). В то время как в традиционной модели отдельные модули могут представлять собой тяжеловесный монолитный софт, в MSA программное обеспечение состоит из множества лёгких модулей, каждый из которых выполняет одну простую функцию. Это соответствует принципам UNIX-подобных ОС — «Do one thing and do it well». Сам микросервис — это изолированный фрагмент кода, направленный на решение одной задачи. То есть процесс разработки ПО превращается в наслаивание «кирпичиков», из которых строится полноценный «дом», и «строительство» таким образом упрощается.

Для того чтобы обеспечить работоспособность микросервисов, упростить управление ими, а главное — изолировать друг от друга, их «пакуют» в контейнеры. Контейнер — это оболочка, в которой размещено всё необходимое для успешного запуска и работы конкретного микросервиса. Несколько разных контейнеров может запускаться в рамках одной операционной системы, но при этом каждый из них работает со своими программными библиотеками и зависимостями. Сбой одного контейнера не приводит к каким-либо последствиям для других, к тому же его можно практически мгновенно перезапустить на другом сервере в кластере.

Чтобы оптимизировать и автоматизировать процесс управления контейнерами, используется специальное программное обеспечение — оркестратор.

Мировая практика показывает, что при разработке web-приложений сегодня целесообразно применять облачный (Cloud-native) подход с использованием комплексных продуктов по работе с контейнерами. Поэтому именно сейчас необходимо задуматься о том, как в вашей компании разрабатывают, внедряют и обслуживают все бизнес-системы. Сегодня практически промышленным стандартом для запуска контейнезированных микросервисов стал Kubernetes — остальные игроки занимают лишь определённые узкие ниши, их процент очень мал.

Решение на базе этого инструмента за последние несколько лет стало крайне востребованным благодаря широким возможностям кастомизации. Помимо этого, Kubernetes может быть настроен и запущен практически на любой аппаратной платформе: на bare-metal, виртуальных машинах и в облаке.

Откуда ноги растут

Словом kubernetes в древнегреческом языке называли человека, управляющего кораблем. Через изящную аллегорию раскрывается суть технологии, «рулящей» контейнерами. В 2006, задолго до существования Kubernetes, двое инженеров Google начали работу над проектом Control groups (cgroups, группы управления). Решение выделилось из функционала самого ядра Linux, который делает возможной изоляцию ресурсов ОЗУ, ЦПУ, сетевую среду и дисковый ввод/вывод в коллекцию процессов.

Следующим этапом стал выпуск собственной системы с открытым исходным кодом от Google под названием lmctfy (Let Me Contain That For You — позвольте мне содержать это для вас). Инструмент должен был стать альтернативой LXC (Linux Containers) для работы с контейнерами приложений на серверах Google. На тот момент lmctfy, LXC и Docker занимали на рынке одинаковое положение. Чтобы избежать подобных пересечений, Google остановил все разработки lmctfy в 2015. В том же году поисковый гигант опубликовал документ «Крупномасштабное управление кластерами в Google при помощи Borg». Код внутреннего проекта Borg был выложен в открытый доступ, дальнейшее развитие привело к широкой популярности — проект получил внешнее название Kubernetes и с тех пор успел стать фактически промышленным стандартом в управлении контейнерами на базе Docker.

Стоит также отметить, что Docker не остался единственно возможным инструментом для контейнеризации приложений. В 2016 году организация The Linux Foundation совместно с крупными игроками индустрии запустила проект открытых стандартов для среды выполнения контейнеров — Open Container Project (сегодня известен как Open Container Initiative). Проект преследовал цель объединить конкурирующие на тот момент Docker и CoreOS в единый стандарт. В то же время компания Red Hat начала создание собственного решения для запуска контейнеров, опубликовав его в сети под названием OCID (Open Container Initiative Daemon). Уже тогда проект ставил перед собой задачу «реализовать стандартный интерфейс исполняемой среды для контейнеров в Kubernetes», впоследствии получив название CRI-O — Container Runtime Interface. Сегодня Kubernetes поддерживает обе технологии. Разработчики от этого только выиграли, получив разнообразие свободных продуктов и конкуренцию сред выполнения контейнерных приложений.

Kubernetes, безусловно, не единственная система с такими возможностями, но именно этот продукт остается сегодня лидером благодаря широкой поддержке сообщества Open Source разработчиков. Кроме того, многие вендоры используют Kubernetes для создания проприетарных систем на его основе.

Контейнеры — наше всё

Контейнеры могут работать как в физическом окружении, так и в виртуальной среде. Второй вариант становится всё более распространённым, особенно с учётом востребованности контейнеризированных сервисов в «облаках». Контейнеры относятся к виртуализации на уровне операционной системы, используют единую ОС, изолируя процессы друг от друга и ограничивая выделенные для них ресурсы.

Как правило, один контейнер обслуживает один микросервис — этим обеспечивается гибкость всей программы. Например, система приёма заказов в интернет-магазине собирает данные и передает их на обработку — это одна функция, которую обрабатывает один контейнер. Если количество пользователей на сайте резко возрастёт, администратор сможет увеличить число аналогичных микросервисов, обслуживающих функционал работы с пользователями, и таким образом избежать остановки работы онлайн-магазина: в том случае, если один из контейнеров перестанет отвечать, другие продолжат работу, а пользовательская нагрузка будет перераспределена между оставшимися.

Для сложных приложений количество контейнеров исчисляется сотнями, и ими нужно управлять. Для этого применяются ранее упомянутые оркестраторы, благодаря которым обеспечивается автоматическое развёртывание и управление жизненным циклом контейнеров.

Именно эти задачи и решает Kubernetes, освобождая администратора от рутинных задач по масштабированию пользовательских сервисов, позволяя динамически управлять ресурсами кластера по заданным правилам. При ручном управлении за масштабирование контейнеров либо был вынужден отвечать конкретный человек, либо приходилось изобретать какие-то собственные скрипты. Рабочий день этого сотрудника состоял из непрекращающихся ручных манипуляций с контейнерами. А в больших проектах речь идёт уже о сотне таких контейнеров. Система оркестрации берёт эти задачи на себя, выполняя их быстрее, эффективнее и снимая человеческий фактор.

Помимо прочего, система оркестрации определяет:

• где и как разместить контейнеры на имеющихся ресурсах;
• как их масштабировать;
• по каким признакам останавливать, переносить и перезагружать;
• какие именно вычислительные ресурсы и в каком количестве выделять.

Kubernetes задаёт конфигурацию приложения, устанавливает правила доступа пользователей к сервисам внутри контейнеров, а также автоматически мониторит их состояние. Таким же образом происходит диспетчеризация серверных ресурсов — это обеспечивает каждый контейнер необходимым количеством вычислительных мощностей. Сделать это вручную крайне сложно (а для больших приложений из сотен контейнеров невозможно в принципе), поскольку изменение нагрузки происходит постоянно, и диспетчеризация осуществляется в реальном времени.

Ещё одно преимущество такого подхода — возможность создать группу контейнеров с общими разделами и управлять ей как единым целым. Например, если ваша веб-служба работает с помощью 5 контейнеров, которые собирают и обрабатывают данные, всеми ими можно управлять как единым объектом — так называемым pod. Отдельные наборы pod, представляющие собой целое приложение, объединяются в единый объект — Deployment, которым легче управлять благодаря оркестратору.

Kubernetes обеспечивает высокую доступность систем. В каждой конфигурации есть как минимум один (для production сред — несколько, обычно три) узел управления (Master-node), который распределяет задачи, хранит конфигурации, осуществляет планирование и мониторинг. Также Kubernetes позволяет создавать ещё более надёжные конфигурации, в которых сервисы узлов управления будут распределены между независимыми инфраструктурными узлами — Infra-node. Рабочие узлы (worker-nodes) выполняют полезную нагрузку, непосредственно запуская контейнеры с вашим приложением. Если один исполнительный узел даёт сбой, кластер продолжает работать, а «пропавшие» контейнеры автоматически перезапускаются на других рабочих узлах.

Контейнеры в силу своей архитектуры обычно запускаются достаточно быстро, так что повторная загрузка не создаёт дополнительных задержек. При этом Kubernetes «из коробки» поддерживает такие важные составляющие любого современного сервиса, как балансировка нагрузки и обновление сервисов без простоя — rolling-update. Это гарантирует, что при его обновлении не будет даунтаймов.

Наконец, средства оркестрации дают возможность использовать в качестве кластера не только ваши собственные ресурсы, но и публичные облака. Это удобно, если вам, например, нужно использовать для разработки сторонние мощности, а итоговую систему запускать в своем ЦОДе. Вы работаете в публичном облаке, а когда нужно, переносите написанное приложение к себе — для этого достаточно осуществить миграцию всех контейнеров в корпоративную ИТ-инфраструктуру.

Ничто не идеально

При всех достоинствах у Kubernetes есть определённые ограничения. Например, не всегда целесообразно размещать в контейнерах СУБД — это зачастую не даёт никакого положительного эффекта. Дело в том, что такие системы медленно запускаются и очень ресурсоёмкие. В отличие от веб-сервисов, они не встраиваются в общую парадигму контейнеров. Кроме того, традиционным СУБД часто необходимы решения по репликации данных для их надёжного хранения. Эти задачи Kubernetes не решает, оставляя их системным администраторам.

В системе оркестрации существует большое количество функциональных особенностей, которые нужно учитывать, чтобы правильно «завернуть» приложения в контейнер. Необходимо хорошо понимать DevOps-подходы, чтобы подготовить среду и сами приложения. Только когда разработка и администрирование в достаточной степени интегрированы друг с другом, использование инструментов наподобие Kubernetes приобретает смысл. Иначе вы столкнётесь с большой дополнительной работой, которая может принести пользу в будущем, но в настоящем ничего не даст.

Здоровье и спорт

Поддерживать здоровье сотрудников нужно любыми способами, начиная с недешёвого ДМС и заканчивая недорогими, но важными мелочами вроде вкусных витаминок, мёда в качестве альтернативы сахару и свежего лимона для любителей чаепитий в офисной кухне. Ещё одним приятным моментом станет, например, бесплатная страховка от клещевого энцефалита или парковка для велосипедов около здания компании. Неизменным спросом пользуется корпоративная скидка на посещение сотрудниками тренажёрных залов.

Бесплатное такси

Корпоративное такси для заработавшихся допоздна сотрудников — меньшее, что компания может сделать для трудоголиков. Такая забота вне всяких сомнений будет оценена по достоинству, так как многие айтишники настолько увлекаются работой, что теряют счёт времени. Неплохо также оплачивать такси в командировках и поездки по городу, связанные с рабочими вопросами. Это сэкономит время и нервы ваших специалистов.

Подарки

Кто же их не любит? Дарить подарки можно по поводу и без. Это могут быть брендированные сувениры или футболки, а также подарки на дни рождения, день компании и другие праздники. Обязательно нужно радовать сотрудников (в том числе и удалённых) новогодними сюрпризами и, конечно же, нельзя забывать про их детей. Детский новогодний утренник с вручением сладостей приведёт малышей в полный восторг. Как говорится, путь к трудолюбию сотрудника лежит через улыбку его ребёнка.

Конференции

Участие сотрудников в IT-конференциях тоже является приятным бонусом. Ежегодно в России и за рубежом проводятся десятки крупных мероприятий, в рамках которых специалисты общаются и делятся друг с другом опытом. Когда компания берёт на себя оплату перелёта, проживания и участия в подобных конференциях, она убивает сразу двух зайцев: повышает квалификацию сотрудников, а также позволяет им сменить обстановку и развеяться.

Профессиональное развитие

Прокачивать профессиональные навыки и учиться чему-то новому можно не только на конференциях. Хорош тот работодатель, который готов вкладываться в развитие своих сотрудников. Вот почему создание внутри компании центра профессиональных компетенций — отличная идея. Для айтишников можно и нужно организовать уроки английского языка (это особенно полезно при общении с зарубежными клиентами), а также подбирать индивидуальные планы развития, включающие в себя курсы повышения квалификации и всевозможные тренинги.

Зона отдыха

IT-специалистам обязательно нужен уголок, где они могут расслабиться и привести мысли в порядок. В каждой крупной компании есть кухня/лаунж-зона/чилаут, где сотрудники не только обедают и потребляют неприлично большое количество кофе, но и общаются друг с другом на отвлечённые темы. Неплохо оборудовать это помещение комфортными диванами, проектором, игровой консолью с гарнитурой виртуальной реальности и музыкальными инструментами для самых творческих технарей.

Корпоративные скидки

Карта корпоративных скидок — ещё один способ сделать жизнь айтишника более приятной и финансово выгодной. Она обеспечит ощутимые скидки в кафе и барах, которые любят посещать IT-специалисты, скидки в многочисленных магазинах, автомастерских, парикмахерских и салонах красоты, в кинотеатрах и других не менее важных местах.

Развлечения и хобби

Руководству следует поощрять увлечения своих сотрудников. Если кто-то из DevOps-отдела увлекается картингом, почему бы коллективу не принять участие в дружеском заезде? Хотят несколько программистов создать музыкальный коллектив — устроим концерт для коллег. Участие в спортивных марафонах, походы на кинопоказы под открытым небом, интересные мастер-классы, уютные вечера настольных игр — если люди совместно отдыхают, эффективность их командной работы ощутимо повышается.

Хорошее оборудование

Айтишник без железа — существо крайне беспомощное. Для повышения настроения и производительности работы IT-специалистов стоит баловать новыми железяками. Хочешь видеть больше кода — держи второй монитор, хочешь быть более мобильным — вот твой новый MacBook, чтобы ты мог кодить на ходу. Медленно работает программное обеспечение — купим тебе скоростной SSD-накопитель. Важно понимать, что подобные вложения в итоге многократно окупятся и положительно скажутся на лояльности сотрудников.

Социальная активность

Мир не станет добрее без нашей помощи. Руководство компании должно всячески поощрять стремление сотрудников к социальным инициативам, приносящим пользу обществу, природе, бездомным животным и всем тем, кому нужна поддержка. Засадить сквер саженцами деревьев, собрать корм и лекарства для зоозащитной организации не так сложно. Это не только сделает мир чуточку лучше, но и позволит айтишникам почувствовать, что они внесли свою лепту во что-то очень важное.

Разумеется, не каждая IT-компания может себе позволить создать для сотрудников условия на одном уровне с digital-гигантами вроде Яндекса, Mail.ru и «Лаборатории Касперского». Работники таких компаний могут получить беспроцентный жилищный кредит, имеют постоянный доступ к массажным кабинетам и «уголкам социопата», где можно отдохнуть от шума опенспейсов. Тем не менее, нужно постоянно искать свой собственный уникальный подход к сотрудникам, чтобы они ощущали комфорт, могли плодотворно трудиться, чувствовали собственную ценность и значимость. Возможно, однажды даже Яндексу будет, чему поучиться у вашей компании.

Что такое хакатон и как возник этот термин

Термин хакатон возник в 1999 году от слияния слов «хакер» и «марафон». Разработчики тогдашних гигантов OpenBSD и Sun Microsystems устроили (отдельно друг от друга) что-то наподобие форума, куда съехались программисты из разных стран, чтобы пообщаться друг с другом. То есть это был клуб по интересам.

Сейчас клубность, конечно, осталась, все коммуникативные находки тоже. Но сегодня в хакатонах больше конкретики. На них собираются программисты, чтобы создать новый продукт, продвинуть свежие идеи, программы или внести улучшения в приложения, технологии, фреймворки и инструменты разработки. Устраиваются хакатоны по криптографии, ОС, мобильным приложениям, дизайну, user experience, validation и многому другому. Хотя программирование, конечно, остаётся главной задачей.

Чаще всего хакатон длится двое суток или чуть больше. Чтобы помочь участникам сфокусироваться на определённых идеях, заявляется тематика хакатона. Скажем, Sun во время своей конференции JavaOne в 1999 году объявил задачу — написать на языке Java программу для поддержки нового устройства Palm V, которая бы использовала ИК-порт для связи с другими пользователями Palm.

К тому же у участника появляется возможность поработать с технологиями большой компании и попробовать в них свои силы. Чем чёрт не шутит, может быть, твоё технологическое решение понравится компании, и ты получишь предложение о сотрудничестве.

Ну а в целом основные атрибуты хакатонов — это не самая правильная еда и бессонные ночи. И ещё — это очень весело. Всегда чувствуется азарт и челлендж, как в спорте, когда тебе важно победить в том числе и для того, чтобы доказать, что твой проект лучше, чем десятки других. Здоровый дух соперничества никто не отменял.

Как провести хакатон

У нашей компании большой опыт проведения внутренних хакатонов. Более 10 проектов, сделанных на наших хакатонах, попали в продакшн, а их разработчики стали частью команды. В этом году мы провели такой конкурс уже в четвёртый раз и впервые решили запустить и внешний онлайн-хакатон Wrike Work, Unleashed 2019. Он будет идти больше месяца и соберёт программистов из 11 стран. Рассчитываем привлечь тех, кто слышал и знает о нашей SaaS-платформе для управления проектами и командной работой, хочет предложить идею по улучшению продукта и выиграть один из призов. Собираемся применить весь наш предыдущий организаторский опыт.

Делимся 10 советами, которым мы будем следовать.

Главное — смысл

Проводя хакатон, вы должны хорошо понимать, для чего это делаете, как будете использовать полученный опыт и результаты. Потому что программисты не дураки, и если вы организовали хакатон с единственной целью целью — собрать е-mail участников и потом засыпать их спам-письмами, то вас быстро раскусят.

Мы, например, хотим получить новые идеи по развитию нашей платформы. Возможно, свежий взгляд позволит сделать новый поворот в развитии, откроет горизонты, которые нам не видны. Возможно, кто-то из участников станет нашим единомышленником, партнёром или коллегой.

Ценные призы и спонсоры

Вы должны точно знать, чем ваш хакатон интересен участникам. Они потратили своё время и силы, что вы можете предложить взамен?

1. Пространство для общения: существует стереотип, что разработчики — социопаты и ни с кем не общаются. Это, конечно, не так. И хакатон даёт специалистам возможность пообщаться в сугубо профессиональной среде, насыщенной духом свободы творчества.
2. Возможность попробовать себя в новой роли: на хакатоне участник может протестировать свои возможности, при этом не меняя место работы и ничем не рискуя. Плюс это возможность освоить новые языки программирования или такие хайповые темы, как машинное обучение или Google API, которыми нет возможности заниматься на работе.
3. Призы: программисты — люди занятые, у всех есть работа. И каждый участник должен понимать, что время на хакатоне не будет потрачено зря, что в финале его ждёт денежный приз или ещё что-то значимое. За само участие, конечно, не платят. Да и призовые фонды в виде одного iPhone и 5 футболок специалистам не очень интересны. Если хакатон проводят крупные компании, то они предусматривают солидные призы.

Поэтому вам, как организатору, надо начать с привлечения спонсоров, чтобы сделать призовой фонд и создать комфортные условия для участников. Нужна площадка, где всё будет проходить, еда, нужно обеспечить комфорт большой группе людей в течение суток — спальные мешки или что-то ещё. То есть спонсоры нужны не только денежные. И ваша задача — сделать хакатон интересным и для них, а не только для участников-программистов.

Чёткие правила состязания

Нужны чёткие правила проведения хакатона: условия конкурса, критерии оценки работ, процедура награждения победителей. Люди должны получить прозрачную и исчерпывающую информацию о том, что нужно для участия. Необходимо детально прописать в правилах, какие есть ограничения на использование технологий, инструментов, библиотек и какие результаты хакатона принимаются, а какие нет. Представьте себе: человек поучаствовал в хакатоне, двое суток просидел над проектом, а потом оказывается, что ему нельзя было использовать какую-то технологию. Это никому не понравится, поэтому определите все правила заранее.

Мы, например, стараемся никак не ограничивать участников. Единственное условие — использовать нашу платформу (браузерное расширение), отдельное приложение, которое базируется на API, мобильное приложение. В качестве представленного проекта ждём ссылку на репозиторий с рабочим кодом и видео-презентацию проекта.

Авторитетное жюри

Решите, как будет определяться победитель и кто будет в составе жюри, чтобы при подведении итогов не возникало недоразумений. Нужно понимать, кто выиграет и почему. Если у вас есть чёткие критерии оценки, хорошо иметь в составе жюри экспертов, которые могут эти оценки дать.

Тайминг

Помните о расписании мероприятия: у хакатона должно быть начало и конец. То есть вы объявляете точную дату и время открытия и закрытия конкурса. Если это онлайн-хахатон, то нужно поставить чёткую дату и время, когда вы начинаете принимать заявки, чтобы люди понимали, на что им ориентироваться. Распишите весь тайминг. Например, сколько времени отводится на презентацию, чтобы люди обязательно уложились (обычно это 5–7 минут). За пределы этого времени выходить нельзя, потому что выступающего остановят, и он не сможет продемонстрировать полностью свои результаты.

Жеребьёвки, лекции и прочие ивенты

Для офлайн-мероприятий важны ивенты: например, промежуточные жеребьёвки или ещё какие-нибудь активности. Это необходимо, чтобы раззадорить участников. Люди склонны закапываться в работу, особенно программисты, иногда их нужно взбодрить, может быть, даже посреди ночи. Когда ты кодишь 12 часов подряд, мозг вырубается, и ничего хорошего не получается.
Во время хакатонов ближе к полуночи мы проводим жеребьёвку команд, определяем в каком порядке ребята будут презентовать свои проекты. Это важная штука. Не очень хорошо попадать на питч-сессию последними, потому что все уже устанут и будут хуже воспринимать. Во время жеребьёвки команды могут пообщаться, иногда пошутить, намекнув, мол, а мы уже всё сделали. Конечно, в реальности ни у кого ещё ничего не готово, но соперники начинают нервничать.

Можно в перерывах между сессиями делать встречи с менторами или экспертами в той области, в которой ребята работают. Люди могут послушать лекции или задать вопросы экспертам и получить те знания, которые в другом месте они бы не смогли получить.

Бытовые условия

Подумайте про бытовые условия (здесь речь об офлайн-мероприятии), чтобы участникам хакатона было комфортно работать. Следует помнить о проветриваниях: работать и думать 24 часа подряд, а то и 48, не очень-то полезно, а если не будет хватать кислорода, то мозг будет испытывать голодание и тормозить. Так что проветривать помещения нужно очень хорошо.

Интернет должен быть быстрый и надежный, подумайте и о резервном канале на случай сбоя. Если, конечно, у вас не хакатон без интернета, когда хотят проверить, что человек может сделать без него за 24 часа.

Кофе, орешки, углеводы

Не забывайте, что людей два дня надо будет кормить. Проводя хакатоны внутри компании, мы заранее составляем примерное меню и отправляем его участникам. Ну и смотрим, что ребята предлагают сами: это могут быть суши, свежие овощи, вегетарианская еда. Опыт показывает, что лучше отказаться от пиццы, кока-колы и тому подобного. Во-первых, если человек будет сутки или двое питаться пиццей, то ему будет не очень хорошо. Во-вторых, жирная пища вызывает сонливость: её переработка отбирает ресурсы у мозга. А вот быстрые углеводы для работы мозга полезны и они быстро усваиваются — снеки, брейн-бары, шоколад, чай, кофе, соки. Не забудьте про завтраки для тех, кто остаётся работать на ночь: каши, мюсли, соки, полезные злаковые печеньки.

Иногда надо спать

Для тех, кто остаётся на ночь, нужно организовать лежачие места, чтобы можно было расслабиться и отдохнуть. Просто сидеть 12–20 часов подряд очень сложно. Если у вас офлайн-хакатон и люди находятся несколько дней в замкнутом пространстве, то приготовьте хотя бы матрасы, если нет возможности поставить диваны. У людей должна быть возможность принять лежачее положение и расслабиться.

Роли имеют значение

И напоследок важный совет для участников хакатона, который хорошие организаторы обычно включают в памятку. Решите заранее, кого вы возьмёте в команду и у кого какая в ней будет роль, чтобы заранее понимать, в какой ситуации, на кого и как можно положиться. Особое внимание уделите тому, кто и как будет презентовать ваш проект, и лучше организовать несколько репетиций накануне питча, чтобы точно попасть в отведённый временной слот и максимально полно донести свою идею до членов жюри.

В заключение

Отнеситесь к проведению хакатона ответственно, если вы строите планы на дальнейшее сотрудничество с IT-комьюнити. Ваша репутация в дальнейшем будет играть на вас. Разработчики будут вас знать с положительной стороны и передавать по сарафанному радио, что у вас все чётко, честно и душевно.

Настя, Senior Test Engineer, QA division manager

Совет 1: спрашивайте!

Пожалуй, первый и очень очевидный совет — не бойтесь спрашивать. Задавать вопросы — важное умение, одно из самых полезных в будущем, на мой взгляд. Кстати, спрашивать можно не только своих прямых товарищей по проекту / виду деятельности, но и коллег из смежных областей: тестировщиков, менеджеров, аналитиков. Иногда случайно полученное знание оказывается ключом к пониманию более серьёзных проблем. Кроме того, человеческий опыт — ценнейшая штука, о многих вещах нельзя узнать из книг. Со временем приходит понимание этого.

Совет 2: записывайте!

Появилась мысль о том, что можно сделать в проекте? Сохраните. Пришла в голову идея, как можно усовершенствовать свои навыки? Запишите. Потом можно пересмотреть эти заметки и почерпнуть что-то важное, а может, понять, что вы уже чего-то достигли. В кризисные моменты такие «сохранёнки» помогают вспомнить, почему вы вообще выбрали то, чем занимаетесь.

Совет 3: вдохновляйтесь!

Ещё одна штука: найти нефинансовую мотивацию. Когда человек решил «войти в айти» ради относительно высоких зарплат, не интересуясь областью как таковой, это очень заметно. Нет ничего плохого в финансовой составляющей, но это не должно быть единственным движущим фактором. Если глаза не горят, то никакие нули в трудовой книжке не смогут их зажечь.

Совет 4: играйте!

Полезно всё превращать в игру, недаром геймификация — одна из лучших техник обучения. Пусть навыки станут ачивками, сложности проектов — уровнями, а трудности на пути — драконами, которых надо победить. Тут срабатывает банальный человеческий азарт, да и с таким подходом даже скучные на первый взгляд вещи становятся куда более весёлыми и увлекательными.

Совет 5: рассказывайте!

Кроме того, хорошая практика — рассказывать другим о том, что делаешь и учишь. Кому — не так важно: это может быть младший брат или сестра, родители, которым интересно, чем вы там занимаетесь, друзья не-айтишники, а может быть, другой стажёр или новичок. Надо стараться донести информацию максимально точно, но просто, чтобы человек без опыта примерно понял, о чём речь. Есть такая поговорка: кто ясно мыслит, тот ясно излагает. Но это работает и в другую сторону: научившись ясно излагать, человек структурирует и укладывает знания в своей голове, и это помогает ему самому лучше разобраться в предмете.

Антон, web-разработчик

Совет 6: читайте!

Первые свои скиллы я развил именно благодаря литературе. Сначала будет сложно даже с базовыми вещами, но не стоит опускать руки. Когда случались такие моменты, я конспектировал непонятные главы в тетрадь и повторял их про себя по памяти. Необходимо дать мозгу время обработать массив новой и сложной для него информации. Через какое-то время всё само уложится и усвоится, главное — не отчаиваться.

Отдельным подпунктом идёт документация в оригинале: original mode предпочтительнее — и потеря информации меньше, и прокачка языка сильнее.

Совет 7: отдыхайте с пользой!

Чаще всего, когда приходишь после работы домой, хочется отдохнуть — поваляться на диване, повтыкать в YouTube, почитать что-нибудь перед сном… Отдыхайте с умом! Возлежа на диване, разбирайтесь в issues на GitHub; предпочтите новому эпизоду сериала полезное выступление коллеги по цеху; вместо подсчёта овец щёлкайте в уме алгоритмические задачки — всё это незаметно тренирует мозг, увеличивает базу знаний, и вы даже не замечаете, как прокачиваетесь!

Совет 8: дерзайте!

Скорее всего, потребуется время и не одна попытка для получения первого оффера. Я попал на первую работу после 7 неудачных попыток, но их может быть и гораздо больше, это абсолютно ничего не значит. Главное — всегда держать в голове, что когда-то непременно будет именно то самое собеседование.

Василий, Java-разработчик

Совет 9: слушайте с умом!

Я бы посоветовал фильтровать информацию и иметь своё мнение, оставаясь при этом гибким. Умение работать с информацией особенно много значит на первых порах: информации много, источники разные, точки зрения противоречивые… И пока до конца не усвоил фундаментальные вещи, кажется, что всё существенно; пока сам не попробовал несметное количество технологий и не понаписал велосипедов, уровень других разработчиков представляется нереально крутым. Это нормально, это проходит ? Важно критически относиться к информации, рассматривать проблему с разных точек зрения, а в качестве ориентира можно выбрать позицию более опытных товарищей, которые уже доказали свой авторитет на практике. Это совсем не технический навык, но удивительно важный в разработке.

Совет 10: учите матчасть!

Ещё я бы посоветовал изучать фундаментальную теорию по книгам, а по современным веяниям смотреть доклады. Кажется, что вот такие фундаментальные знания не особо важны для решения практических задач, но, как правило, те, кто изучил достаточно, выдают куда лучшие решения рабочих задач.

Андрей, JS-разработчик, JS division manager

Совет 11: изучайте основы!

Устройте себе ликбез по компьютерной грамотности. Проштудируйте устройство компьютера и принципы его работы. Убедитесь, что понимаете принципы работы ОС. Подружитесь с алгоритмами. Проработайте академические основы: ООП, функциональное программирование, алгоритмическая сложность и т. д. Читайте книги прикладного характера: «Совершенный код», «Искусство алгоритмизации» и т. д.

Совет 12: прокачивайтесь!

Никогда не переставайте учиться. Жизнь программиста как жизнь учёного: всё время необходимо изучать новое, иначе выйдешь в тираж. Старайтесь не только читать, но и практиковать новые навыки и знания. Курсы — отличный способ с помощью небольших статей и практических заданий изучить новую технологию. Дальше — только практика и стремление к совершенству.

Павел, старший web-разработчик

Совет 13: общайтесь!

Учиться разбивать задачи на простые составляющие — навык, который позволяет решить любую сложную задачу, даже если она на первый взгляд кажется невыполнимой.

Эффективный джуниор — это максимально общительный человек, ведь ему нужно постоянно консультироваться с тимлидом. Но сначала джуниор сам проводит анализ задачи, разбивает её на части, придумывает несколько вариантов решения, думает, гуглит то, чего не понимает. А уже потом приходит к тимлиду и задаёт вопросы, верное ли решение он предлагает — чтобы не тимлид за джуна решал, а сам джун. Затем следует отчётный период, когда тимлид проверяет работу джуна, смотрит, как идёт работа.

Важно уметь не только работать самостоятельно, но и просить о помощи, если непонятен какой-то конкретный момент. Не уходить в себя.

Как видите, чтобы быстро освоиться в новой для себя IT-сфере, достаточно искреннего желания разобраться, не стоять на месте, быть самостоятельным в профессии. Начало — уже половина дела, и с каждым следующим шагом будет становиться всё легче. Удачи всем, кто пробует! Желаем стать суперпрофи своего дела!

Для начала стоит пояснить, что такое ретроспектива и зачем мы здесь собрались. Ретроспектива — это обзор неких событий с высоты прошедшего времени. Ретроспектива как инструмент руководителя позволит понять, как прошёл спринт (итерация, квартал, год), чему научились, на чём споткнулись и что надо улучшить, чтобы стать более успешными в будущем. Сколько будет событий, каких и с высоты какого времени смотреть, решают индивидуально при планировании мероприятия.

Ретроспектива поможет:

• найти узкие, проблемные места в рабочем процессе или рабочей атмосфере;
• определить, на каких этапах рабочие процессы наиболее уязвимы, а значит, понять, над чем стоит работать более внимательно;
• оценить, насколько успешны ваши идеи по решению проблем;
• проанализировать, повторяются ли проблемы из итерации в итерацию, или же все попытки исправить положение приводят к ещё большим потерям.

На ретроспективе обычно собирается вся команда, насколько бы распределённой она ни была. Заранее определяется ведущий ретроспективы, который её готовит, координирует и фиксирует договорённости. Ведущим может быть как непосредственный руководитель отдела (департамента, компании), так и специально обученный приглашённый человек. Ведущего ретроспективы принято называть фасилитатором.

Для начала обозначим краткий план мероприятия:

• подготовка участников;
• подготовка ведущего;
• проведение ретроспективы;
• контроль выполнения договорённостей.

Теперь давайте разберёмся, зачем нужны все эти этапы подготовки.

Шаг 1. Подготовка участников

Когда проводить ретроспективу и какие вопросы задавать?

Например, мы хотим узнать результаты прошедшего квартала, первого в году. Логично, что готовиться к ретроспективе стоит в конце этого же первого квартала, пока свежи все мысли, эмоции и переживания.

Следующий момент, требующий внимания до встречи, — это список вопросов. Это могут быть стандартные «что мы сделали хорошо?» и «что мы сделали плохо?» или другие насущные вопросы, которые могут прийти в голову. Например, можно узнать, какая в команде атмосфера. Не исключено, что кто-то ответит «у нас всё круто, твердая пятёрка», а кто-то из этой же команды поставит троечку с натяжкой. Вот вам и повод хорошенько всё обсудить.

Ещё несколько примеров вопросов

Стандартным для нашей команды является вопрос «кто вам помогает в работе?». Вопрос на первый взгляд странный, но он способствует сплочению коллектива, выявлению наиболее инициативных членов команды и их моральной мотивации. Вот только задавая такой вопрос, будьте готовы, что официальный лидер не обязательно будет таковым в глазах подчинённых.

Можно также узнать противоположное мнение: «кто вам мешает в работе?». Тут тоже стоит ожидать разброса в ответах. Это может быть чересчур общительный коллега или непосредственный начальник, который то и дело просит какие-то отчёты, или угрюмый представитель компании-партнёра, с которым, хотите вы того или нет, а надо общаться.

Точно не стоит спрашивать «кто виноват?». Как бы вам ни хотелось получить ответ на этот вопрос, задавая его вот так напрямую, вразумительного ответа вы не получите. Чего вы точно добьётесь, так это перекладывания вины и ответственности, нездоровую атмосферу в команде и тяжёлый осадок обид. Задавая вопросы, разбирая ответы и проводя саму встречу, стоит настроить себя на то, что все выложились по максимуму и сделали всё, что от них могло зависеть.

Превентивные вопросы

Я рекомендую использовать ещё один небольшой лайфхак при подготовке к встрече. Чтобы в процессе ретроспективы точно придерживаться намеченного плана, не забыть ни одного вопроса и услышать всех, я задаю некоторые вопросы заранее, до самой встречи с помощью гугл-формы. На заполнение даю примерно два дня, чтобы точно нашлось время, а дедлайн ставлю минимум за полдня до начала события, чтобы успеть прочесть ответы.

Какой от этого профит, спросите вы, если всё равно все соберутся и будут обсуждать то же самое? Не все люди умеют или любят разговаривать с другими. Не все могут сразу сформулировать свою проблему: будут рассказывать длинную предысторию, где в самом конце, возможно, промелькнёт то, что человек хотел сказать. Может случиться и так, что это будет попытка найти фантомную проблему там, где её нет, с аргументацией: «не знаю, что точно, но всё как-то не так». Время — деньги, поэтому я даю шанс людям предварительно высказать все мысли и эмоции на бумаге, сэкономив команде силы на ретроспективе.

Шаг 2. Подготовка ведущего

Прочитав ответы, нужно убрать из них воду и эмоции, сконцентрировавшись на сути проблемы. Всю конкретику и мысли по делу я собираю в отдельной вкладке в общей таблице с ответами на форму. На встрече мы проходим по выделенным вопросам, не тратя время на долгие рассказы, и приступаем сразу к сути. В той же таблице я делаю третий лист — «Регламентируем предложения». Как раз его мы и будем заполнять в процессе ретроспективы.

Для проведения вашей первой ретроспективы этой подготовки будет достаточно.

Подготовка второй и последующих ретроспектив

Необходимый этап при проведении второй и всех последующих ретроспектив — «Ретроспектива ретроспектив». Надо проанализировать, поднимались ли на прошедших ретроспективах проблемы, указанные в текущих ответах. Если что-то повторяется в том или ином виде, то стоит посмотреть, какие решения были приняты ранее. Если на какой-то момент проблема была решена, стоит попробовать тот же самый подход и теперь. Если прошлый вариант не подошёл и проблема актуальна — самое время для нового брейншторма.

Как вспомнить прошедшие ретроспективы и их итоги?

Разумеется, не стоит надеяться на свою память, ни один человек не в состоянии запомнить все нюансы, тем более если прошёл год или больше. Тут нам на помощь приходит прекрасная таблица PDCA (цикл Деминга), которую нужно завести сразу после первой ретроспективы.

Мы её немного доработали, поэтому табличка состоит из пяти колонок:

1. «Суть» поднятой проблемы. Желательно тезисно, чтобы при беглом просмотре было ясно, о чём идёт речь.
2. «Plan» — планирование решения или возможные варианты развития событий.
3. «Do» — что в итоге было сделано из запланированного.
4. «Check» — здесь мы фиксируем, к чему привели наши действия.
5. «Act» — есть несколько вариантов перевода этой части цикла, например «воздействие» или «корректировка». Это своеобразный итог всей строки.

Здесь можно писать короче, чем в остальных колонках:

• если проблема решена, можно написать «Выполнено»,
• если не решена, но выбранный путь кажется верным, можно написать «Продолжай»,
• если же вы ни на шаг не приблизились к решению проблемы, пишите «Всё пропало». Эту грустную формулировку можно заменить на локальный мем, мы предпочитаем использовать открытый призыв — «Думай дальше…».

Шаг 3. Проведение ретроспективы

Все собрались в назначенном месте или в скайп-чате. Теперь нужно соблюсти небольшой регламент и озвучить, по какому поводу собрались. Лучше ещё разок напомнить, что сегодня мы обсуждаем проблемы, возникшие в первом квартале текущего года. Это поможет участникам ретроспективы настроиться на нужный диапазон воспоминаний и откинуть то, что было до или после.

Порядок выступающих

Всё зависит от масштабности вашего мероприятия. Если вы небольшая команда, которая работает над одним общим проектом, то порядок не важен. Можно по мере поступления ответов, в алфавитном порядке и тому подобное. Если у вас несколько проектов, то собирайте людей в проектные группы, а порядок распределяйте по принципу выше.

Итак, все организационные вопросы решены. Давайте начнём ретроспективу.

Как это обычно происходит?

Ведущий опирается на выписанные им выдержки из ответов. Он озвучивает суть проблемы и задаёт вопрос тому, кто её описал.

Что спрашивать?

Если проблема была изложена слишком коротко, можно попросить рассказать подробнее. Если суть ясна, то можно предложить человеку рассказать, почему, на его взгляд, так случилось и можем ли мы как-то повлиять на эти факторы. Если человек выражает реализуемую идею, то стоит её зафиксировать. Даже если кажется, что другого варианта просто не существует, стоит спросить мнение остальной команды. Если у кого-то есть свежая мысль, её обязательно надо обдумать всем коллективом.

Бытует мнение, что решить чужую проблему гораздо проще, чем свою. Потому что ваши проблемы на поверку могут показаться коллеге решаемыми, стоит только использовать другой, не совсем стандартный для вас подход. Свои же проблемы на то и свои, мы с ними живем, мы о них думаем, мы с ними сроднились и не хотим их отпускать.

Как фиксировать информацию?

Когда участники высказывают идеи, ведущий фиксирует их в колонке «Plan». Если вариантов по решению конкретной проблемы больше нет, можно выбирать наиболее оптимальный вариант, на взгляд всей команды.

Кстати, после того, как вы определились, выбранный вариант тоже нужно зафиксировать. Для этого нам понадобится третий лист ретроспективы — «Регламентируем предложения» («Наши планы», «Сделай так», «Итоги» и тому подобное). Именно сюда выносим согласованные предложения, назначаем ответственного и ставим контрольный срок исполнения.

Не забудьте, что сроки по каждому пункту надо обсудить с ответственным. Даже если речь идёт о разговоре с дизайнером и это дело пяти минут, всё равно ставьте срок. Это позволит не забыть о порученной задаче. Конечно, одной записи на листочке может быть мало. Ведь все люди что-то забывают, но к этому мы ещё вернёмся.

Остались вопросы?

Когда проблемы закончились, и по каждой есть план действий, обязательно спросите: «Кто хотел бы высказаться о чём-то ещё»? Возможно, у человека была мысль, но его перебили, и мысль так и осталась мыслью.

Убедившись, что мнения высказаны, мнений больше нет, приглашайте всех посмотреть тот самый третий лист, который вы так усердно заполняли. Его должны прочесть все и либо устно подтвердить то, что увидели своё задание и срок выполнения, либо отметиться в документе или скайп-чате. Кроме того, ведущему ретроспективы тоже свойственно ошибаться, поэтому это ещё и командная проверка написанного.

На этом ретроспективу можно считать состоявшейся и расходиться. Не забудьте поблагодарить всех коллег, принимавших участие. Но не стоит ставить на этом точку. Ведь только сейчас и начинается решение существующих проблем и продвижение на пути к успеху.

Шаг 4. Контроль выполнения договоренностей

Ведущий ретроспективы должен отдельно написать себе список и конечный срок выполнения принятых решений. В свой календарь, ежедневник, доску канбан, смотря чем вы пользуетесь. Это нужно для оперативного контроля за решением поставленных задач. За пару дней до дедлайна я уточняю у ответственного, не забыл ли он о своём поручении. Бывает так, что задача уже выполнена, и сотрудник вот-вот собирался рассказать о результате. А бывает, что в ответ вы слышите «ой» и видите сверкающие пятки сотрудника. Значит, вы поступили правильно, спросив заранее и напомнив о задаче.

А что если принятое решение оказалось невозможно выполнить?

Например, ответственный за него человек уволился или просто до задачи так и не дошли руки. Тогда стоит вписать решение этого вопроса в свои задачи — повесить стикер на доску или создать задачу в Jira, например. Тогда вы точно о ней не забудете и рано или поздно придёте к её решению.

Выводы

Кому нужна ретроспектива?

Ретроспектива — это важная и нужная часть вашего продвижения на пути к глобальной цели. И тут совершенно не важно, разрабатываете ли вы модное приложение для блогеров или у вас строгий банковский продукт. Особенно на ретроспективу важно обратить внимание тем компаниям, которые выбрали для себя разработку в стиле Agile и двигаются короткими итерациями. Так вы точно не свернёте с намеченного пути и вовремя заметите, если где-то проседаете по срокам и ваш критический путь увеличивается.

Что будет, если не проводить ретроспективу?

Любите бродить вслепую, без понимания, насколько ваша стратегия верна и через какое время она приведет вас к успеху, — не тратьте время на ретроспективу.

Есть меткая цитата Сократа, которую любили повторять Ломоносов и Пушкин: «Народ, не знающий своего прошлого, не имеет будущего». Хотите учиться на своих ошибках с первого раза и перестать наступать на одни и те же грабли, ретроспектива — ваш выбор.

Да, возможно, кому-то это покажется скучным и занудным мероприятием. Но в целом, всё зависит от команды. Заодно вы сможете узнать, какая у вас царит атмосфера. Кто с кем больше соглашается, кто кого стесняется, и чем вообще занимаются люди, когда кто-то говорит: внимательно слушают или отстранённо смотрят в окно. Согласитесь, не всегда удаётся вот так собрать всех в одном помещении и заставить говорить на одну и ту же тему.

В заключение хочется напомнить, что ретроспектива — это полезный, но далеко не единственный инструмент развития проекта и поиска проблем. Многолетний опыт, в том числе наших проектов, показывает, что максимальную отдачу от ретроспективы получают те команды, которые уже навели порядок в своих оперативных процессах и могут себе позволить выдохнуть, обернуться назад и спокойно разложить результаты своей работы по кирпичикам.

В начале карьеры далеко не каждый программист понимает, какой формат работы ему подходит. В результате он часто меняет места работы, пока не находит идеальную компанию. Куда и почему лучше идти работать — в небольшой стартап, в компанию, которая создает софт для себя, или в команду, специализирующуюся на разработке для сторонних организаций?

Найти идеальные условия, в которых бы хотелось работать изо дня в день, — главная задача программиста. Чтобы понять, какая обстановка вам ближе, рассмотрим несколько распространённых бизнес-стратегий.

Небольшие группы людей, которые работают над собственным проектом

Обычно команды стартапов состоят из руководителей и менеджеров по продажам. При этом на проекте обязательно есть один или два технически грамотных специалиста или даже программиста, которые отвечают за общую организацию разработки продукта и распределяют задачи между привлечёнными фрилансерами.

Если программиста берут в команду на фултайм, значит его оценивают, как важный актив. От него будут ждать полного погружения в проект и большой отдачи. Соглашаясь на такой формат работы, специалист должен быть готов к тому, что общий результат будет зависеть от его умения «сколотить команду» и заставить её трудиться. Фрилансеры обычно слабо организованы и не представляют себе, как выстроен целостный процесс разработки продукта. Их нужно постоянно контролировать: формулировать задачи, устанавливать сроки, корректировать действия.

Фултайм-разработчик в стартапе выполняет задачи, связанные с построением архитектуры ПО, а также занимается технической реализацией идей руководства и менеджеров по продажам. Это прекрасная возможность развить потенциал IT-специалиста. Особенно, если он уже приобрёл достаточный опыт работы в профессии и горит желанием создавать новый продукт. Работа идеально подойдёт программисту, которому нравится общение не только с «коллегами по цеху», но и с менеджерами. Это поможет развить управленческие навыки.

Главный плюс таких команд в том, что здесь обычно приветствуют внедрение новых подходов, технологий, языков разработки и фреймворков. Можно экспериментировать и учиться, развивать навыки оперативного решения нестандартных задач.

Звучит заманчиво, однако статистика неумолима: многие стартапы быстро исчезают. Команда растрачивает инвестиции, но так и не находит экономически эффективного применения своему продукту. Программисту нужно быть готовым к нестабильности: частой смене курса, нерегулярной оплате труда. А главное, понимать, что реальные пользователи могут никогда не увидеть проект, в который вложено столько сил и ресурсов. Пожалуй, это основной недостаток стартапов.

Компании, которые делают проекты на заказ

Иногда стартапы окончательно разочаровываются в своей бизнес-идее, но, сохранив костяк персонала и получив хороший опыт разработки, начинают брать проекты на заказ. Появляется стабильное финансирование, формируется более-менее постоянный коллектив. Но и здесь не всё гладко. Рынок диктует свои условия: почти всем клиентам полностью готовый продукт нужен «ещё вчера». К тому же работа с заказчиками всегда стрессовая: придётся запастись терпением, научиться обосновывать свою позицию, работать с возражениями.

Для программиста начинается рутина. Сегодня он занят своим проектом, а завтра всеми силами пытается помочь коллегам, которые не успевают сдать продукт в срок. Ну а в редкие свободные минуты приходится заниматься оценкой временных затрат на очередной потенциальный проект и работать не с кодом, а с таблицами Excel. Новые технологии приветствуются, только если они помогают сократить объём рутины и автоматизировать стандартные процессы. Посидеть и обдумать эффективность кода получается редко. Перфекционистам в такой обстановке придётся нелегко.

И всё же есть свои плюсы: программист научится делать всё. Конечно, поначалу будет тяжело переключаться с бэкенда на фронтэнд, а в перерывах проектировать базы данных. Зато появится шанс сделать наработки на будущее — накопить множество шаблонов проектов-заготовок под любые задачи. Ещё один плюс: работая в таком ритме, придётся постоянно следить за развитием актуальных языков и фреймворков.

Компании, которые работают над собственным экономически успешным проектом

Чаще всего такой продукт создаётся годами. Закономерно, что компания-разработчик накапливает огромный legacy-код своего продукта — неповоротливый и скучный, но стабильный и предсказуемый.

Программисту не придётся делать что-то в спешке: все задачи — глубокие, на внимание. Процессы давно отлажены. Нужно лишь кропотливо внедрять интеллектуальную функциональность, улучшать производительность, заниматься масштабированием продукта. Запускать тесты и продумывать мониторинг. Именно здесь разработчику пригодятся фундаментальные знания алгоритмов и математики. Будет лучше досконально изучить какое-то одно направление или фреймворк и использовать его максимально эффективно.

Работая над живым и масштабным проектом с тысячами пользователей, можно приобрести уникальный опыт. Например, научиться создавать алгоритмы машинного обучения или качественно анализировать Big Data. Это прекрасный фундамент для успешной и долгосрочной карьеры.

Наконец, это оптимальный вариант для интроверта: не нужно отвечать на внезапные вопросы клиентов и менеджеров. Текучки персонала в таких компаниях почти нет, и коллеги могут стать «второй семьёй».

Компании, которые работают над собственными проектами и параллельно делают работы на заказ

Компания, успешно развивающая собственный крупный продукт, может похвастаться опытными руководителями, грамотными исполнителями и мощной технологической базой. Это позволяет бизнесу расширяться и брать в разработку сторонние проекты. Чаще всего такую бизнес-стратегию выбирает тот, кто хочет снизить риски за счёт диверсификации.

Для компании внешние проекты — прекрасная тестовая площадка. Здесь можно «обкатать» новые технологии, а затем внедрить их в собственный продукт. Для программистов клиентские заказы — возможность периодически переключаться с поддержки основного проекта на разработку нового.

Проекты, которые нужно разрабатывать «с нуля», привлекают в штат молодых разработчиков и помогают опытным сотрудникам выйти за рамки привычных технологий, освоить что-то новое.

В компании, которая специализируется на внешней и внутренней разработке, раскрыть свой потенциал сможет и новичок, и профессионал. Ведь у программиста всегда есть возможность заняться тем, что ему интересно. И для этого вовсе не обязательно менять место работы.

Вместо заключения

Задумываясь о трудоустройстве, честно ответьте себе на вопрос, какой путь вам ближе: участие в стартапе, многозадачность и постоянная динамика или стабильная команда и работа над фундаментальными задачами, анализ больших данных, поддержка проектов с историей и возможность стать высококвалифицированным специалистом?

Идеальный вариант, когда темп и подход компании сочетаются с темпераментом программиста и его представлениями об идеальной организации процесса разработки.

Микросервисная архитектура набирает обороты, многие хотят повторить опыт Netflix и создать надёжное и великолепно масштабируемое приложение.

Основные требования к микросервисной архитектуре можно свести к двум — скорость и надёжность. Поэтому главная задача, которую старались решить создатели Micronaut, — сделать его более легковесным, чем Spring Boot, и тем самым более быстрым.

Разберёмся подробнее, что из себя представляет данный фреймворк, какие у него преимущества и как создавать на нём микросервисы.

Для эффективного создания микросервисов в фреймворк уже включён HTTP-сервер и контейнер зависимостей, создающийся во время компиляции.

На заре развития микросервисов не существовало никаких готовых решений и фреймворков, однако с совершенствованием облачных технологий повышались требования не только к архитектуре, но и к самим сервисам, работающим в облаке. Сообщество разработчиков старалось создать решения, которые смогли бы сэкономить то, за что облачные провайдеры берут деньги, — процессорное время и память.

Был поставлен под сомнение основной инструмент бизнес-фреймворков — рефлексия, которая используется для инъекции зависимостей и генерации различных прокси-классов на лету. Подобные технологии требуют большого количества ресурсов от виртуальной Java-машины, поэтому они влекут за собой проблемы с производительностью — чрезмерно большое количество действий во время старта и использование памяти в рантайме сильно влияет на запуск.

Создатели фреймворка Micronaut решили пойти другим путём: вобрав в своё творение лучшие практики уже существующих решений, они добавили новый контейнер DI/AOP, который внедряет зависимости во время компиляции, а не во время выполнения. Тем самым львиная доля зависимостей разрешается ещё до запуска приложения. То есть ещё до запуска приложения фреймворк Micronaut просканирует весь код на наличие аннотаций, попытается сгенерировать дополнительные классы, необходимые для правильного исполнения кода, и наполнит ими свой контекст.

Так как в Micronaut всё это произойдёт ещё до старта приложения, время запуска и потребление памяти не находятся в прямой зависимости от количества кода, в отличие от рантайм-фреймворка Spring Boot, который повсеместно использует рефлексию.

Платформы IoC на основе рефлексии загружают и кешируют данные для каждого отдельного поля, метода и конструктора в коде. Таким образом, по мере того как ваш код увеличивается в размере, увеличиваются и требования к памяти.

Сами разработчики считают основополагающими следующие принципы разработки фреймворка:

• использовать рефлексию только в самых «безвыходных» случаях;
• избегать прокси;
• максимально оптимизировать время старта;
• максимально уменьшать занимаемую память.

Так как Micronaut задумывался изначально как фреймворк для облачных приложений, вместе с ним идёт «джентльменский» набор нативных облачных решений для создания полноценной инфраструктуры: поддержка паттернов Service discovery и Circuit Breaker, трассировки запросов, распределённого логирования, балансировки нагрузки, асинхронных очередей — Kafka и RabitMQ, реактивного HTTP и стандартов JWT и OAuth2.

В этом материале будет показано, как быстро реализовать всю эту мощь всего в пару строк.

Для начала нужно создать проект. По ссылке это можно сделать быстро, подключив все нужные зависимости.

HTTP-сервер

В Micronaut включён быстрый, гибкий и высокопроизводительный HTTP-сервер Netty. Достаточно пары строк, чтобы запустить приложение и начать обрабатывать запросы.

Пример программы «Hello World» ниже:

Всё выглядит точь в точь, как если бы программа была написана с использованием Spring.

Создать клиентский запрос так же просто:

Как мы видим, в нашем случае необходимо просто создать интерфейс, описывающий клиентские вызовы, а фреймворк уже во время компиляции сгенерирует нужный класс для сетевого взаимодействия.

Но Netty реактивный, поэтому создатели рекомендуют писать контроллер и клиент следующим образом:

И для клиента:

Service Discovery

Фреймворк уже поддерживает популярные решения Eureka и Consul.

Чтобы добавить свой сервис в Eureka, даже не нужно добавлять аннотации в предыдущий пример, достаточно подключить зависимость runtime: "io.micronaut:micronaut-discovery-client"

И прописать в конфигурации параметры сервера:

Если установлена переменная окружения (EUREKA_HOST), будет использована она, в противном случае соединение будет устанавливаться с локальной машиной.

Балансировка нагрузки

Когда регистрируется несколько экземпляров одной и той же службы, Micronaut предоставляет форму «циклического» распределения нагрузки, по очереди запрашивая доступные экземпляры, чтобы гарантировать, что ни один экземпляр не будет перегружен или использован не достаточно эффективно. Это форма балансировки нагрузки на стороне клиента, когда каждый экземпляр либо принимает запрос, либо передаёт его следующему экземпляру службы, автоматически распределяя нагрузку между доступными экземплярами. Такое распределение происходит в целом без дополнительных ресурсозатрат.

Micronaut также предоставляет нативную поддержку Netflix Ribbon. Для запуска балансировщика на стороне приложения необходимо выполнить пару простых действий.

Добавить зависимость compile "io.micronaut.configuration:micronaut-netflix-ribbon"

И указать настройку для Ribbon:

Circuit Breaker

При взаимодействии с другими службами в распределённой системе неизбежно наступит момент, когда удалённый сервис временно перестанет работать или будет отвечать ошибкой на любой запрос. Micronaut предлагает ряд инструментов помогающих восстановить связь. Например, любой метод в Micronaut может быть аннотирован с помощью @Retryable, чтобы применить настраиваемую политику повторов к методу. По умолчанию будет выполнено три запроса к другому сервису с перерывом в одну секунду. Количество попыток соединения и время ожидания между попытками можно настроить:

Но данные параметры лучше не менять, а находить причины задержек.

Более сложной формой @Retryable является аннотация @CircuitBreaker. Она не позволит конкретному сервису начать постоянное «бомбардирование» удалённого сервиса запросами, давая ему время восстановиться. То есть после нескольких неудачных попыток отправки запроса, следующие запросы будут сразу возвращены с ошибкой.

Трассировка запросов

Поддержка Zipkin уже внедрена во фреймворк. Для её добавления не нужно никакого дополнительного кода, всё уже сделано создателями.
Добавляем в файл настроек:

И можем начать собирать информацию о наших микросервисах.

Работа с брокерами сообщений

Так как в микросервисном мире очень важен обмен асинхронными сообщениями, фреймворк нативно поддерживает такие решения как Kafka и RabiitMQ. Рассмотрим взаимодействие с первым. Добавляем зависимость в сборку:
compile 'io.micronaut.configuration:micronaut-kafka'

И настроим адрес сервера в YML-конфигурации:

Всё, мы готовы работать с одним из быстрейших асинхронных брокеров сообщений в мире.

Создаём клиент, который будет отправлять сообщения в очереди:

Фреймворк создаст класс, который мы можем забрать из контекста и отправить сообщение:

Принимать сообщения так же просто:

Мониторинг активности

При запуске приложения на основе микросервисного архитектурного решения важно знать, в каком состоянии находятся все микросервисы. Для этого в Micronaut уже из коробки реализованы эндпоинты, по которым можно получить информацию о сервисе:

Вывод

Таким образом, Micronaut уже из коробки поддерживает множество инструментов, сильно упрощающих жизнь создателю любого микросервиса, а его отчасти инновационный подход к созданию контейнера бинов и разрешению зависимостей во время компиляции даёт ему неоспоримое преимущество перед главным конкурентом — Spring Boot.

По работе я много общаюсь с интернами и джуниорами — вчерашними студентами, которые приходят в проектные команды из университетов. Устраиваются, конечно, инженерами, а опыта у них нет. На протяжении многих лет я замечал, что проблемы, с которыми они сталкиваются на первых порах, одни и те же.

Я решил рассказать о некоторых важных моментах, которые приходится обсуждать едва ли не с каждым, кто пока не занимался никакими проектами, кроме учебных. Я специализируюсь на .NET, но эти советы вполне применимы к любому языку, хоть к Java, хоть к Python. Ведь все мы должны сделать одно и то же: написать, протестировать, зарелизить и поддерживать.

Оценка требований

Вспоминаю себя студентом: едва получив задачу, я садился кодить. Думаю, это нормально, а уж для студента просто естественно — кидаться в бой, как только вручили условие.

Но лучше вначале задуматься о том, чего от вас хотят — неважно, лабораторная это или ваша часть коммерческого проекта. Важно внимательно прочитать условия задачи и выслушать комментарии руководителя или старшего коллеги.

Многие ребята, в том числе талантливые, хорошо справляющиеся с любыми учебными заданиями, быстро схватывают суть и думают, что отлично поняли, что нужно сделать. Они двигаются дальше, концентрируются на деталях, а когда приходят спустя два дня (хорошо) или неделю (хуже), выясняется, что созданный ими код не работает или работает не так, как требуется.

Поэтому не стесняйтесь задавать вопросы. К сожалению, в наших школах и университетах люди привыкают: если ты что-то спрашиваешь, все думают, что ты ничего не понимаешь. Но на работе уточнить все, даже казалось бы, очевидные, детали критически важно. Никто над этим смеяться не будет, коллеги всё вам охотно расскажут.

Когда вы уяснили задачу и даже нашли примерное решение — поделитесь им, расскажите алгоритмы, которые пришли вам в голову. Реакция старшего коллеги сразу подтвердит или опровергнет вашу догадку, даст почву для дальнейшего исследования. Вообще делитесь своими идеями. Это тоже противоречит школьному стереотипу: отличникам категорически нельзя давать списывать. И многие молодые инженеры по привычке боятся рассказать, что они придумали. Но только получив отзыв на свой вариант решения, вы расширяете картину мира — возможно, это позволит посмотреть на задачу с другой, как раз нужной вам, стороны.

Узнайте об ограничениях — в реальном проекте это может оказаться чуть ли не самым главным. Спросите, сколько данных будет поступать на вход приложения, какая планируется нагрузка. Такая информация поможет и при проектировании решения, и при его сдаче.

Ещё один совет: делайте блок-схемы. Признайтесь, вы ведь их не рисуете? Я знаю, многие уверены, вся эта сортировка «пузырьком» — просто глупости. На самом деле, в будущем это поможет вам, поскольку схематичное описание решения позволит очень быстро донести до коллег вашу идею.

Что проще: изобразить схему с тремя блоками и связями между ними или исписать половину листа А4? К тому же, картинку проще воспринимать, а читать длинные тексты никому не хочется. Обратите внимание на UML — язык, на котором можно писать и физические модели базы данных, и концептуальные модели, и диаграммы последовательности вызовов, и многое другое.

Оценка сложности

Об оценке сложности часто забывают, а вспоминают, только когда при выходе в продакшен сваливаются огромные объёмы данных и система проседает по производительности.

Основываясь на блок-схемах, диаграммах последовательности вызовов и компонентов, существующих ограничениях вы можете оценить сложность задачи.

Разработка

Главный вопрос: как писать? Один проджект-менеджер выразился довольно точно: «надо писать без багов всегда». И здесь самое главное: naming convention и code style.

Naming convention (соглашение об именах) необходимо, чтобы код было удобно читать. Это может быть не совсем понятно в случае с лабораторной или курсовой, но обычно работать приходится в команде. И кодом владеют все разработчики, а не только тот, кто сейчас пилит отдельный компонент системы. А соглашение об именах позволяет легко понять, что написал твой коллега.

Той же цели служит и Code style (стандарт оформления кода) — стиль оформления кода, необходимый для унификации. Программный код, разработанный разными людьми, должен читаться так, как будто его написал один программист. Поэтому, придя в проект, в первую очередь, нужно понять, какие naming convention и code style здесь используют. Помните, что строгое следование им — ещё и знак уважения к коллегам, который они обязательно оценят.

Var — хорошая практика, которая позволяет любому разработчику читать код с листа. Тем не менее многие компании делают для проектов собственные конвенции.

Но для запускающегося проекта проще всего взять готовые конвенции. Сейчас многие сообщества и компании их публикуют, есть даже целые библиотеки, где можно проверить код на ошибки стиля.

В своих примерах Microsoft продаёт велосипеды, а я буду считать налоги.

Пишите простой код! Элементарный совет, следовать которому очень сложно. Если инженер не до конца продумал решение задачи, не смог сделать декомпозицию (не разбил задачу на составные части) — в методе мы видим 500 строк кода. Это не так страшно, но важно вернуться назад и подумать над декомпозицией ещё раз.

Почему код должен быть простым? Сейчас код есть только у вас и, возможно, преподавателя. Потом им будет владеть большая команда, которой нужно разбираться в его нюансах с максимально возможной скоростью.

Чтобы код стал проще, нужно ввести слабую связанность компонентов.

Представьте, вы написали сложный код, вернулись, разбили на составные части.

В примере с налогами у меня есть некий класс, который считает сумму налога. Я разбил на класс, который представляет работника, и на класс, который в зависимости от адреса или другой логики возвращает процент налога — это пример слабой связанности.

Но можно ввести дополнительные элементы, например, интерфейс для класса taxEvaluator для employee.

Что такое IoC?

Этот паттерн называется Inversion of control. В микросервисах слабая связанность приводит к масштабированию системы. Когда у нас есть интерфейс, мы можем изолировать наш основной класс с логикой и протестировать его.

Ещё здесь не хватает комментариев. Комментарий — это важный и полезный элемент работы. Когда вы пишете сложный алгоритм, то комментарии помогут понять, что там вообще происходит, особенно они важны для регулярных выражений. Я пишу регулярное выражение, а через 15 минут забываю, что оно делает.

Проверяйте аргументы — это частая проблема молодых инженеров: они уверены, что всё написали чётко и в проверках написанное ими не нуждается. Но это не так!

В этом примере мы выбрасываем исключение, но не всегда должны это делать.

Вообще исключение — это особая тема. Чтобы понять, что с ним делать, можно почитать «Программист — прагматик» Дэйва Томаса и Энди Ханта. Книга старая, но очень интересная, там хорошие и здравые идеи, когда выбрасывать, когда нет, когда считать, что это ошибка бизнес-, а не программного уровня. Но у нас tax evaluator = null — это ключевая функциональность и без неё мы работать не можем, поэтому выбрасываем исключение.

Когда к нам приходит пустой объект с работником — employee — то мы вновь ничего не можем сделать, так как на этом завязана вся логика.

Исключения надо обрабатывать

«Try catch» необходимо использовать либо с типизированными исключениями, либо когда мы не знаем, какое исключение прилетит. Надо залогировать, но ни в коем случае не возвращать такие конструкции.

Мы «глотаем» исключения, и поэтому никогда не увидим их в логах. И как будто всё хорошо и работает, но если будет проблема, мы не сможем её поймать. Исключения нужны, но используйте их очень аккуратно.

Можно убрать «try catch» и обработать исключение как бизнес-кейс и логировать. Записывайте в логи ход выполнения ваших алгоритмов и программ, потому что во время разработки ваш софт доступен через дебаггер и вы всегда можете посмотреть, что происходит. Но когда исключение уходит туда, куда у вас нет доступа, то только логи могут вам помочь.

Unit test

Разработчик должен писать юнит-тесты. Понятно, почему этим не занимаются, но писать их стоит. Посмотрите на методики написания юнит-тестов — когда вы будете делать собственные, то будете иначе проектировать ваши решения, программы и задачи.

Потому что как раз разбиение и декомпозиция — это первый шаг к тому, чтобы начать писать юнит-тесты, но и сами юнит-тесты вас будут двигать к декомпозиции.

Сборка, деплой, конфигурация

Что мы делаем, после того как написали что-то? Мы делаем сборку, потом собранные элементы где-то храним, затем деплоим.

Это цикл жизни от момента создания до деплоя, и этот код будет использовать конечный пользователь. Я написал, какие инструменты могут быть использованы: создать автоматическую сборку можно с помощью PowerShell и msbuilt; хранить — в ProGet, и дальше мы можем деплоить полученные пакеты. Это немного сложно.

Работа над ошибками, изменение требований

Мы всё поняли, всё запрограммировали, протестировали, отдали, а заказчик говорит: всё не то.

Что делать? Возвращаться к самому началу и спрашивать: что не то? Если изменились требования — уточнить их и прорабатывать дальше.

Что почитать?

• Брайан У. Керниган, Деннис М. Ритчи «The C Programming Language» — достаточно старая. Она произвела на меня большое впечатление. Во многом не про язык программирования, а про верный майнд-сет.
• МакКоннел «Code Complete»— маст рид.
• Дэйв Томас, Энди Хант «The Pragmatic Programmer».
• Альфред Ахо «Data Structures and Algorithms» — занудная, всегда, когда читаю, засыпаю. Да, она читается сложно, но она очень классная.
• Джон Влисидис, Ральф Джонсон, Ричард Хелм, Эрих Гамма «Design Patterns» — книга для тех, кто планирует писать на объектно-ориентированных языках программирования. Она тоже задаёт правильный майнд-сет. Когда я читал, то ничего не понял, но когда начал работать, перечитал, и книга начала помогать.
• Мартин Фаулер «Catalog of Patterns of Enterprise Application Architecture» — про архитектуру приложений. Фаулер внёс огромный вклад в индустрию, написал разные паттерны, на основе которых создано много софта, те же ORM (object relation mapping).

Совершенствовать качество продукта, каким бы он ни был — от мобильных игр до софта для запуска ракет в космос, — с каждым днём всё важнее для бизнеса. И главную роль в этом играют именно специалисты по обеспечению качества. Все они делятся по самым разным профессиональным уровням и направлениям, но цель у их одна — проверить и обеспечить стандарты выпускаемого продукта.

Человеку со стороны может показаться, что все «специалисты по тестированию» занимаются одинаковыми скучными задачами, но это не так. Разберёмся, чем на самом деле занимаются профессионалы-тестировщики и какое место занимают в команде.

Что такое QA, QC, тестирование и кто такой тестировщик

Тестирование охватывает весь цикл разработки и включает в себя планирование, проектирование, создание и выполнение тест-кейсов. Сейчас мы кратко поговорим о каждом из них.

Схематически отношения между QA, QC и тестированием можно представить так:

QA (англ. Quality Assurance) — обеспечение качества продукта — это, собственно, весь комплекс процессов, обеспечивающих качество, наиболее обширное понятие. QA интегрировано во все этапы разработки: от описания проекта до тестирования, релиза и даже пост-релизного обслуживания.

Специалисты QA создают и реализуют различные тактики для повышения качества на всех стадиях производства: подготовка и установка стандартов, анализ качества, выбор инструментов, предотвращение ошибок и постоянное усовершенствование процесса.

QC (англ. Quality Control) — контроль качества продукта — это часть комплекса QA, которая отвечает за анализ результатов тестирования, поиск ошибок и их устранение. QC ориентирован на проверку конкретного продукта, в него входят различные процессы, такие как анализ кода, технические обзоры, анализ дизайна, тестирование и прочее.

Тестирование — это уже непосредственно процесс проверки результатов работы на соответствие установленным требованиям. А тестировщик — это специалист, который занимается такой проверкой. Он тестирует компоненты продукта или весь продукт целиком на предмет ошибок или неточностей разработки. Тестирование — один из ключевых процессов в системе обеспечения качества.

Специализацию тестировщиков можно разделить по направлениям: тестирование безопасности, производительности, юзабилити; а также по методам написания тестов: ручное и автоматизированное тестирование.

Сейчас большинство компаний устроено таким образом, что тестировщиками в них работают в основном сотрудники на начальном этапе карьеры — то есть это junior-специалисты по тестированию. Они выполняют проверку софтов по готовым тест-кейсам. Специалисты более высокого уровня (тест-аналитики, автотестеры, менеджеры по тестированию) помогают им на других этапах разработки.

Карьера тестировщика: варианты развития

У тестировщика практически в любой компании есть три пути развития карьеры: вертикальный, горизонтальный и смежный.

Вертикальное развитие

Первый вариант — развиваться в сфере обеспечения качества по иерархии, то есть уходить в управление проектами или командой.

В каждом сегменте тестирования существуют свои грейды, которые определяют уровень специалиста: junior, middle и senior. Руководителем всех специалистов является test-lead или team-lead в зависимости от специфики компании. На некоторых проектах может быть также отдельный инженер по качеству, head of QA.

Из начинающего специалиста тестировщик может дорасти до любого из уровней, главное — постоянно держать себя в тонусе. Азы профессии освоить не трудно, а вот развиваться дальше и на каждом этапе приобретать новые знания уже гораздо сложнее. Конечно, всё зависит от человека, но, например, от junior до middle возможно дорасти в среднем за год.

Горизонтальное развитие

Второй вариант — развиваться как специалист и прокачивать hard skills, а в дальнейшим благодаря ним можно будет выбрать наиболее интересное направление. Тестировщик может стать автотестером или специалистом по тестированию юзабилити, безопасности, производительности. При этом есть профессионалы, которые могут совмещать оба варианта.

Чтобы выбрать более узкое направление, нужны приличные знания программирования и другой технический бэкграунд. В небольших компаниях бывает так, что за все описанные выше направления ответственен один специалист. Ему поручают и нагрузочное тестирование провести, и автотесты написать, своеобразный человек-оркестр — этот подход распространён, хотя и не совсем верен.

Спрос на автоматизированное тестирование

Автотестирование, если говорить о навыках специалиста, требует большей квалификации, а следовательно и оплачивается выше, чем ручное тестирование. Многие компании пришли к выводу, что автотесты для рутинных процессов, например прохождения регрессий, во многом выгоднее, чем ручное тестирование. Они стараются нанимать сотрудников, которые пишут автотесты на те процессы, которые ранее проверялись ручными тестировщиками (а то и вообще не проверялись).

Если оценить рынок вакансий, то именно автотестеры сейчас пользуются огромным спросом, да и и уровень заработной платы у них выше. Хотя с моей точки зрения, противопоставлять ручное и автоматизированное тестирование неправильно, поскольку и то и другое решает в итоге одну задачу.

Сегодня специалистов по автоматизированному тестированию ищет большинство компаний на рынке, причём как в команды по мобильной разработке, так и в тестирование бэкенда, фронтенда и других сфер. Даже начинающий специалист, имеющий базу, надолго без предложения работы не останется. Особенно, если он умеет ещё и развернуть всю инфраструктуру тестирования.

Переход в смежные сферы

Третий путь развития тестировщика — переквалификация в смежную специальность. Принято считать, что тестирование — это своего рода простая точка входа в IT и из него гораздо легче переходить в другие технические направления. Поэтому иногда специалисты по тестированию решают попробовать себя в других IT-профессиях. Так, например, тестировщик может стать продакт-менеджером, бизнес-аналитиком, разработчиком и даже дизайнером. На самом деле это не так просто, как кажется, — понадобятся дополнительные знания, желание развиваться, время на обучение и поиск работы.

Как стать тестировщиком

Вариантов, как освоить профессию тестировщика, сейчас достаточно много. Можно самостоятельно учиться по книгам, статьям и видеоурокам из интернета, устроиться на стажировку в компанию, где на практике покажут, что нужно делать, а также пойти в учебное заведение, которое готовит таких специалистов.

Однако в вузах нет специальности «тестировщик». Если рассматривать государственное образование, то проведение тестов изучается только в рамках программирования. Минус в том, что практики при обучении в вузе всё равно не получить, если не работать параллельно на реальных проектах.

При самостоятельной подготовке освоить навыки на базовом уровне можно за несколько месяцев, а после попробовать устроиться на junior-позицию по ручному тестированию в небольшую компанию. Таких вакансий сейчас много. В первое время вам будет трудно, поскольку придётся освоить множество инструментов на практике и понять специфику проведения тестов и разработки программного обеспечения.

Другой вариант — устроиться в IT-компанию на стажировку, скорее всего, неоплачиваемую, чтобы учиться в процессе работы. Конечно, поначалу вам не доверят работу специалиста полностью, зато у вас будет возможность с самого начала общаться с профессионалами и учиться у них.

Третий, и, на мой взгляд, наиболее простой способ прийти в сферу тестирования — пройти специализированные курсы. Они есть есть в онлайн- и офлайн-форматах, краткие и максимально полные, бесплатные и платные — выбор программ действительно большой. В этом случае подготовка значительно упрощается, поскольку не нужно выбирать актуальные материалы из общедоступных источников, есть возможность консультироваться у преподавателей, а зачастую есть ментор или куратор, который поможет разложить знания по полочкам. Я сама преподаватель курса по тестированию и могу сказать, что студентам всегда очень сильно помогает возможность общаться по разным практическим вопросам.

Ещё один важный и не совсем очевидный плюс курсов в том, что они дополнительно дисциплинируют и забросить учебу становится сложно: всегда есть четкое расписание занятий, домашние задания, пример других студентов. Это своеобразный волшебный пинок, которого обычно так не хватает при самостоятельном обучении.

Если говорить об обучении уже практикующего специалиста, например, ручного тестировщика, то здесь тоже немало вариантов: от специализированных курсов до самостоятельного изучения языков и инструментов, которые понадобятся в новом направлении. Как пример, если интересно тестирование веб-приложений, можно начать с изучения Selenium или Katalon Studio и Java.

Если вы уже работаете в компании, в которой есть отдел автоматизации, узнайте у коллег, на каком языке они пишут и с каким стеком технологий работают, изучите их на базовом уровне и просите небольшие задачи для себя. Конечно, если такое приемлемо в вашей компании.

Ещё один интересный вариант для тех, кто не знает, что именно ему понадобится, — попробуйте автоматизировать собственные рутинные процессы и разобраться, чего не хватает в знаниях.

Обеспечение качества сейчас — бурно развивающаяся перспективная сфера, особенно в России и СНГ, и это очень радует и вдохновляет постоянно развиваться в этом направлении.

Что такое SQL?

Если коротко, это мощный инструмент для анализа и преобразования данных, который позволяет разработчикам обращаться к различным базам данных.

И если мы хотим анализировать данные — нам нужно их откуда-то получать, а получаем мы их, как правило, из баз данных. Не всегда это видно невооружённым взглядом, но читаем ли мы новости, переводим деньги со счёта на счёт, запрашиваем выписки по счёту, делаем покупки в интернет-магазине или просто знакомимся с ценами конкурентов — всё это мы делаем, обращаясь к различным базам данным.

И вот перед тем, как мы получаем привычное «читабельное» представление нужной информации, данные извлекаются из хранилищ. И чаще всего это происходит именно с использованием SQL. В широком смысле SQL не является языком программирования, хотя и существует такое устоявшееся заблуждение. На самом деле он больше похож на самую обычную английскую речь.

Кто такие аналитики данных и с чем они работают?

Аналитики данных — своего рода экспериментаторы, которые владеют инструментарием для соединения потоков данных из различных источников, а также выдвигают гипотезы и проверяют их. Вот тут-то им и нужны базы данных и язык, позволяющий точно формулировать к ним запрос. Правильное получение исходных данных — это искусство, гарантирующее высокую вероятность того, что в поведении исследуемых объектов установятся причинно-следственные связи. Именно качество данных позволяет выбирать наиболее подходящие гипотезы.

Помимо SQL, аналитику данных необходимо знать инструменты статистического анализа данных: это и узкоспециализированные пакеты — SPSS, Statistika, и различные языки программирования — SAS, R, Python, обладающие функциональностью для анализа и визуализации данных, и совсем легковесные решения типа Gretl. А самый популярный набор инструментов у аналитиков, это, пожалуй, Python + SQL.

Часто нужно представить данные наглядно и понятно для бизнеса, а иногда и самому оценить, какие факторы, влияющие на данные, являются значимыми, а какие нет, какие причины отклонений созависимы. Когда необходимо строить прогнозы, аналитики вместо того чтобы работать напрямую с базами, работают с датасетами (таблицами данных) с помощью различных пакетных решений.

При этом в каждой индустрии свои стандарты анализа, зависящие от чувствительности данных: для госструктуры набор инструментов будет одним (исходя из жёстких ограничений доступов), для НКО — другим, для диджитал-стартапа — третьим.

Откуда брать данные и что делать с SQL командами?

В организациях есть свои хранилища данных и при необходимости к ним можно получить доступ. Это происходит и при разграничении прав пользователей, и при работах по разработке баз данных. С помощью Python, зная адрес сервера и данные для подключения к нему, можно импортировать нужные библиотеки и писать запросы уже внутри используемой программы.
Примеры библиотек: для ODBC — pyodbc, PostgreSQL — psycopg2, MySQL — mysql.connector и т. д.

Ваша программа-«получатель данных», в свою очередь, может находиться внутри облачного решения на основе jupiter notebook. А к полученным данным вы примените дальнейшие выкладки и/или построите графики (как минимум, библиотеки: pandas, numpy, matplotlib и т.д.).

Аналитические функции

Считается, что в базах данных каждая строка запроса должна обрабатываться независимо от других. Практика диктует нам иные задачи, в которых часто необходимо группировать строки и вычислять для них общие показатели, используемые для оценки признаков строк внутри группы.

Примеры:

• вычислить частоту общения друзей друг с другом (например, необходимо определить максимально близкие контакты внутри выделенных кругов): тогда мы будем искать процентные соотношения длительности переговоров, частоты переписок и телефонных разговоров, количество географических пересечений, посещений общих ресурсов и т.д.,
• сравнить зарплаты сотрудников внутри отделов, вычислить рейтинги,
• узнать топ-N заказчиков в сечении по услугам или продуктам,
• узнать загруженность соседних точек продаж и т. д.

На помощь приходят аналитические функции SQL — мощный инструмент, который помогает разгрузить клиента от большого объёма процедурного кода, СУБД — от сложных и порой малоэффективных запросов, уменьшить время на разработку и получить при этом желаемый результат.

Функции для статистических расчётов включают в себя как стандартные агрегирующие функции (используются для получения обобщающих значений), так и расширения, характерные для конкретных СУБД.

Рассмотрим примеры, основанные на классическом тренировочном датасете Postgres.

Мы хотим обслуживать без очереди пассажиров, входящих в топ-5 по суммарному чеку за перелёт. Для этого вычисляем и выводим определённый список, чтобы спланировать дальнейшую работу:

На неделю получили примерно такой список:

Рассмотрим наш запрос внимательнее. Что тут есть:

1. Предложение over — то, что как раз-таки синтаксически отличает оконную функцию от обычной или агрегатной функции.
2. Внутри over-предложения partition by указывает, что строки нужно разделить по группам или разделам, объединяя в соответствии с указанным в нём выражением (подобно group by на уровне запроса, за исключением того, что его аргументы всегда являются просто выражениями, а не именами выходных столбцов или числами).
3. Оконная функция вычисляется по строкам, попадающим в один раздел с текущей строкой.
4. Указание order by определяет порядок, в котором оконная функция обрабатывает строки раздела.

Оконные функции общего назначения в большинстве СУБД позволяют узнать:

• номер текущей строки в её разделе;
• ранг: относительный/абсолютный, с пропусками или без;
• значения: в первой/последней или n-ой строке;
• значение соседа текущей строки со смещением вверх/вниз

Для Postgres оконные функции:

• row_number() — номер текущей строки в её разделе, начиная с 1;
• rank() — ранг текущей строки с пропусками; то же, что и row_number для первой родственной ей строки;
• dense_rank() — ранг текущей строки без пропусков; эта функция считает группы родственных строк;
• percent_rank() — относительный ранг текущей строки, вычисляется по формуле: percent_ rank = (rank - 1) / (Nстрок - 1);
• cume_dist() — относительный ранг текущей строки: (число строк, предшествующих или родственных текущей) / (общее число строк);
• ntile(число_групп) — ранжирование по целым числам от 1 до значения аргумента так, чтобы размеры групп были максимально близки;
• lag(значение [, смещение [,значение_по_умолчанию]]) — значение для строки, положение которой задаётся смещением от текущей строки к началу раздела;
• lead(значение [, смещение [,значение_по_умолчанию]]) — значение для строки, положение которой задаётся смещением от текущей строки к концу раздела;
• first_value() — значение, вычисленное для первой строки в рамке окна;
• last_value() — значение, вычисленное для последней строки в рамке окна;
• nth_value() — значение, вычисленное для n-oй строки в рамке окна.

Если же мы говорим об агрегатных функциях, то они работают как оконные тогда и только тогда, когда за их вызовом следует предложение over; в противном случае они останутся обычными агрегатными.

Таким образом, на основе нескольких точных запросов аналитик может самостоятельно написать техническое задание на рекомендательную систему или сделать MVP для проверки продуктовых гипотез без привлечения специалистов по машинному обучению.

Больше пяти лет я занимаюсь бизнес-процессами. В особенности процессами технической поддержки, которую мы оказываем коммерческим и государственным компаниям. Например, я слежу, чтобы уровень качества IT-обслуживания соответствовал международным стандартам. Я программирую и работаю с документацией — пишу регламенты и процедуры, описываю процессы, выпускаю инструкции.

Всё это время я неосознанно «перетаскиваю» общие принципы программирования в работу с документами. Это помогает мне не делать бесполезные «спагетти-простыни» и писать внятные рабочие документы с ясной структурой, даже если документация очень объёмная и должна часто меняться в соответствии с изменениями в компании и все её части должны быть связаны воедино, чётко объяснять, как что-то работает. Возможно, мои приёмы помогут и вам.

Принципы работы с текстом

DRY — Don’t repeat yourself. Не повторяйся

Если вы вставили один и тот же блок в 10 разных регламентов и что-то меняете в нём, то у вас образуется 10 одинаковых мест, куда нужно внести одинаковые изменения. Вероятность забыть об этом тоже растёт, даже если вы пользуетесь бессмертным «Ctrl+C» — «Ctrl+V». Особенно в последней паре документов.

В программировании такие блоки выделяют в отдельные функции, классы, а в работе с документами повторяющиеся элементы нужно выносить в отдельные разделы или документы и давать ссылки на них.

KISS — Keep it simple, stupid. Не усложняй

Посмотрите вокруг: люди привыкли к простоте. Интуитивно понятные интерфейсы и всплывающие подсказки в приложениях. Принцип одного окна в IT-обслуживании. Засилье коротких статей и обучающих видео в Интернете. Той же простоты они ждут и от рабочих документов.

Этот принцип я обычно использую как маркер. Если описание процесса слишком сложное — нужно упростить процесс. Если инструкция к приложению слишком замысловатая — надо доработать приложение.

Обычно это проще и дешевле, чем писать сложную документацию, заставлять каждого нового сотрудника её читать, понимать и учиться действовать по ней. А ведь потом ещё нужно будет вносить изменения в документацию.

YAGNI — You ain’t gonna need it. Тебе это не понадобится

Это продолжение принципа KISS. Обычно я применяю его, когда собираюсь создать универсальное решение с заделом на будущее. Проблема в том, что такое решение — само по себе усложнение. Не факт, что в будущем оно понадобится. Обычно нет смысла создавать всеобъемлющее описание бизнес-процессов направления, которое только сформировалось и активно развивается. Практика показывает, что будущее внесёт серьёзные коррективы.

Но здесь важно разумно подходить к вопросу. Есть вещи, изменение которых дорого обходится. Их как раз нужно готовить с заделом на будущее. В программировании эту работу относят к архитектуре приложения, а в документации просто сразу говорят: «Это нам не понадобится». И в будущем с трудом навёрстывают упущенное.

Принципы работы со структурой

Чем объёмнее становится документация, тем сложнее поддерживать её актуальность. Изменение одного документа влечёт за собой каскадное изменение остальных, логическая целостность ломается, структура требует очередной переработки. К счастью, для программирования это стандартная проблема, и за прошедшие десятилетия выработались общие принципы написания легко поддерживаемого кода. Часть из них можно применять и к документам.

SRP — Single Responsibility Principle. Принцип единственной ответственности

Яркий маркер нарушения принципа — наличие побочных действий. Например, метод класса отвечает за отправку клиенту уведомления о новом заказе в интернет-магазине, но при этом ещё и обновляет текущий баланс клиента.

То же самое справедливо и для документации. Например, в регламент регистрации обращения клиента не нужно впихивать что-то «заодно»: принципы вежливого общения с клиентами, краткое описание self-service портала и т. д.

Нельзя рассчитывать, что такая информация будет усвоена или сотрудники запомнят, к какому документу нужно обращаться, чтобы её получить. Зато это запутывает документ, лишает структуру чёткости и требует дополнительного времени для актуализации. Если вы действительно хотите напомнить о вежливости при общении с клиентом, вставьте в регламент ссылку на соответствующий документ (вспомните о DRY).

Соблюдение принципа позволяет делать документы короче. Их название соответствует назначению, а чтение не вызывает неприятных сюрпризов. Их проще прочитать за раз. И не забыть, с чего документ начинался.

SLAP — Single Level of Abstraction Principle. Принцип единого уровня абстракции

Является логичным продолжением принципа единственной ответственности (SRP).

Применение принципов KISS и SRP побуждает писать небольшие, простые и понятные документы. Но эти документы нужно собрать в такую же простую и понятную структуру. Здесь помогает выделение и соблюдение уровней абстракций.

Например, очевидно, что нет смысла пытаться поместить в один огромный документ объёмную документацию вроде описания системы менеджмента качества. Намного логичнее разбить его на уровни абстракций и сделать для каждого уровня разные документы — верхнеуровневое описание системы, описание каждого процесса и т. д.

При этом важно соблюдать принцип единого уровня абстракций и относить информацию только к нужному уровню. Если вы пишете верхнеуровневое описание, не надо вдаваться в детали работы конкретного процесса. Не тот уровень абстракции! Оставьте эту информацию для описания процесса. Этот принцип дополняет SRP, заставляя автора контролировать не только то, за что отвечает документ, но и на каком уровне в иерархии он находится.

LoD — Law of Demeter (Don’t talk to strangers). Закон Деметры (Не разговаривай с незнакомцами)

Если применить закон к документации, то каждый документ:

• Должен обладать ограниченным знанием о других документах, т. е. «знать» только тех, которые имеют к нему непосредственное отношение.
• Должен взаимодействовать только с известными ему документами-«друзьями» и не «разговаривать» с незнакомцами.
• Обращаться только к «друзьям».

Например, процесс управления IT-инцидентами взаимодействует с процессом управления проблемами напрямую, а с процессом управления изменениями — только через управление проблемами. Тогда в описании управления инцидентами можно ссылаться на описание управления проблемами. А вот ссылаться на описание управления изменениями не надо.

Итого

Указанные выше принципы сильно помогают мне при написании документации по процессам, в создании регламентов, процедур и инструкций. К сожалению, это лишь небольшая часть рекомендаций по управлению качеством кода, поэтому заинтересовавшимся рекомендую самостоятельно углубиться в тему. Из неё можно извлечь много полезного. При этом важно помнить, что эти принципы не являются законами. В Интернете много спорят об их правильном использовании и часто злоупотребляют ими. Поэтому, пожалуйста, не впадайте в крайности. И не забывайте о здравом смысле.

Об облачных услугах до сих пор существует множество мифов. Самые стойкие связаны с информационной безопасностью корпоративных данных и риском несанкционированного доступа инсайдеров и конкурентов. Дыма без огня не бывает: репутацию всему облачному рынку подмочили хостинг-провайдеры и бесплатные файлообменные сети, не обеспечивающие в должной мере защиту своих облачных сред. Чего только стоят истории массовых утечек данных из ICloud и хакерские взломы Dropbox.

По данным InfoWatch, несмотря на то, что общее количество утечек информации растёт, это всё реже происходит из-за недостаточно защищённых технических каналов, в том числе сетевых. Это говорит о том, что большинство провайдеров используют надёжное оборудование и наилучшие решения в области безопасности. Тем не менее, сегодня значительная доля зарегистрированных утечек вызвана действиями недобросовестных сотрудников самих компаний, которые пользуются облачными услугами.

Чужие против своих

В облаке за счёт высокой степени контроля доступа к инфраструктуре снижается риск утечек, вызванных человеческим фактором. Данные хранятся на удалённом сервере в зашифрованном виде, и из него не так-то просто изъять информацию и передать её третьим лицам. Доступ к святая святых облака — ЦОДу — ограничен и надёжно контролируется различными техническими средствами вплоть до биометрической идентификации сотрудников провайдера, имеющих право проходить в здание дата-центра.

Локальная инфраструктура многих компаний защищена менее эффективно, и это становится причиной множества инцидентов. Основываясь на них, американский исследовательский институт Ponemon Institute пришёл к такому выводу:

Одними из ключевых причин утечек в компаниях являются: оставленные без присмотра компьютеры, потерянные носители данных и конфиденциальные данные, хранящиеся на ноутбуке.

Безопасность в облаке по всему периметру

Gartner считает, что по сравнению с корпоративными инфраструктурами, к 2020 году публичные облака будут сталкиваться с атаками на 60 % реже. Это ещё раз подтверждает мысль о высоком уровне безопасности облачных сред, которые включают такие средства защиты, как системы обнаружения и блокирования DDoS-атак и системы межсетевого экранирования. Также для поиска уязвимостей во внутренней инфраструктуре используется автоматизированная система мониторинга, система контроля целостности и аудита событий безопасности. На регулярной основе проводятся различные сканирования для обнаружения новых, постоянно появляющихся уязвимостей. Для заказчика данные системы позволяют обеспечить должный уровень защищённости. Если требуются специфичные сервисы, например сканирование web-ресурсов на наличие уязвимостей и защита web-приложений в облаке или полная защита от DDoS-атак, их можно получить за дополнительную плату.

Безопасность для самых важных данных клиентов — персональных данных

Согласно федеральному закону №152 для хранения персональных данных (а это фактически любая информация, по которой можно идентифицировать конкретного человека) должен обеспечиваться определённый уровень защищённости этих данных. В случае размещения персональных данных в облачной инфраструктуре, нужно не только соблюдать требования по безопасности самой облачной платформы, но и дополнительно к этому внедрить сертифицированные средства защиты системы для самой ИСПДн.

Как это реализуется на практике?

Строится многоступенчатая архитектура, которая включает в себя периметровые средства для мониторинга и контроля доступа к платформе, средства для её защиты и разграничения виртуальных сегментов заказчиков, а также антивирусы для всех компонентов платформы. Поверх этого внедряются системы, необходимые для информационной безопасности приложения, которое используется для хранения и обработки данных. Но самое важное — все применяемые средства должны быть сертифицированы ФСТЭК или ФСБ. Наличие аттестата у облачной платформы говорит о том, что она соответствует требованиям регулятора в части систем хранения персональных данных до третьего уровня включительно.

Кстати, нас часто спрашивают, где хранить и обрабатывать данные первого и второго уровня защищённости, например базу с медицинскими данными более 100 тыс. граждан Российской Федерации. Ответ простой — необходимо мигрировать систему на выделенное оборудование в ЦОД. Дело в том, что сейчас ни один из гипервизоров, используемых в составе облачных платформ популярных российских провайдеров, не сертифицирован и формально не может использоваться для размещения персональных данных первого и второго класса. До тех пор, пока ситуация не изменится, мы рекомендуем реализовывать информационные системы с персональными данными 1 и 2 уровня защищённости на выделенном оборудовании в надёжном дата-центре.

Кому доверить свою защиту?

В России работают порядка 10 облачных провайдеров, ориентированных на оказание услуг крупному бизнесу, и несчётное количество компаний, которые размещают в своих облаках инфраструктуру и сервисы для SMB и физических лиц. Естественно, первая категория предлагает более дорогие, кастомизированные услуги и строит платформы на базе надёжных решений, так как любые утечки и другие инциденты информационной безопасности могут привести к финансовым и репутационным рискам. Подобные компании детально прописывают правила работы в строгом SLA и могут подтвердить высокую степень защищённости рядом документов. Это и уже упомянутый сертификат соответствия облачной платформы требованиям ФЗ 152, и сертификат ISO/IEC 27001 — международного стандарта по информационной безопасности, и сертификат PCI DSS. Немаловажно также наличие полного комплекта сертификатов уровня Tier III от Uptime Institute (включает Tier III — Gold Certification of Operational Sustainability). Это говорит о грамотно выстроенных процессах эксплуатации дата-центра.

К слову, сертификация по стандарту PCI DSS хоть и регламентирует в первую очередь работу с платёжными картами и переводами, но также свидетельствует о высоком уровне защиты. Этот документ подтверждает не только наличие необходимых средств информационной безопасности, но и формализует организационные моменты — требования к сотрудникам, к их действиям в случае инцидентов. Отдельно он регламентирует требования к регулярности проведения «проверочных» мероприятий — различных тестов на проникновение, которые уважающий себя облачный провайдер устраивает один-два раза в год. Всё это помогает в том числе снизить влияние человеческого фактора, но уже на стороне поставщика облачных услуг и его команды.

Сферу IT любят за интересные задачи, хорошие зарплаты, плюшки-бонусы, отличные офисы или, наоборот, за возможность удалёнки. Но диплом о высшем образовании не гарантирует, что вам легко достанется желаемая должность. Вуз даёт основу и старт, всё остальное зависит от вас самих. В этой статье рассказываем, что можно и нужно делать начиная с первого курса, чтобы найти работу мечты во время учёбы или сразу после выпуска.

За 2018 год мы взяли в команду десять студентов и выпускников, провели две практики и два курса семинаров по бэкенд и фронтенд разработке. В 2019 году придут ещё двенадцать практикантов. Рекомендации в этой статье — это наш опыт и критерии, по которым мы отбираем ребят в команду.

Определитесь с направлением

Время, когда разработчик сам делал прототипы, придумывал дизайн и писал код, ушло. Сегодня ценятся узкие специалисты: фронтенд и бэкенд-разработчики, аналитики данных, тестировщики, технические писатели, продакт-менеджеры и прочие. Выбор огромный! Чтобы понять, что вам ближе, читайте книги и блоги с опытом разработчиков, отмечайте интересное, участвуйте в хакатонах, сделайте проект, в котором все роли возьмёте на себя — от прототипа до бэкенда. Никто не говорит, что это навсегда, в любой момент своей карьеры вы можете заняться чем-то новым.

Иногда разработчики делают бесплатные вводные занятия к платным курсам. Например, у Яндекс.Практикум можно пройти двадцать часов обучения по трём специальностям: веб, фронтенд и аналитик данных.

Помните: чем раньше выберете направление, тем сильнее прокачаетесь. Вы будете готовы к работе больше, чем среднестатистический выпускник.

Изучайте технологии и прокачивайте навыки самостоятельно.

В вузе преподают на Windows, хотя её век ушёл, SQL всё ещё из 1999, а на дворе 2019. Догонять разницу всегда придётся самому. Ниже несколько актуальных технологий:

• Подходы к разработке: экстремальное программирование, система непрерывной интеграции CI и система контроля версия Git.
• Языки программирования, фреймворки и библиотеки: С ++, Python, JavaScript, TypeScript, Angular, React и др.
• Технологии: LXD, Docker-контейнеры, кластеры Amazon и Google Cloud, мониторинг Docker Swarm.
• Навыки тестирования: ручное, автоматизированное, нагрузочное, приёмочное, AB, SHADOW, TDD и т. д.
• Прочее: работа в команде, оценка и декомпозиция задач, методы управления проектами Scrum и Kanban, KPI.

Технологий — море, а их сочетаний ещё больше. Знать всё невозможно, но иметь представление полезно как минимум, чтобы поддерживать разговор с бэкенд разработчиком, если вы занимаетесь фронтендом, и наоборот.

Как учиться самому? Когда в вуз приходят преподавать разработчики из IT-компаний, не пропускайте. У каждого инструмента есть мануалы и документация, гуглите. В свободном доступе можно найти записи полноценных курсов, например, Технопарка Mail.ru Group и МГТУ им. Баумана. Если есть возможность платить за обучение, загляните на Coursera, Академию Яндекса и Geekbrains. Учитесь даже тогда, когда едете в автобусе. В приложении Sololearn, например, вы найдёте краткие курсы почти по любому языку программирования с тестированием, практикой, сертификатами и даже ачивками.

Если есть вопросы и сомнения, всегда можно попросить совета у старших товарищей.

Помните: программа вуза несовершенна, ответственность за знания только на вас. Выберите направление, создайте план, по которому постепенно будете осваивать инструменты, языки и т. д.

Делайте проекты

Теория — это важно, но каждую изученную технологию, даже самую небольшую фичу, необходимо закреплять качественной практикой. В конце концов, вам нужен именно опыт разработки и проекты, которые можно показать работодателю.

Где брать проекты? Лабораторные или курсовые работы — отличное поле для практики. Помимо этого, делайте сайты или разрабатывайте приложения для друзей и знакомых, а если никто не просит — фантазируйте. Пишите компьютерные игры, это и увлекательно, и полезно, так можно попробовать себя в сложных дисциплинах: разработке физических движков или работе с 3D-графикой. Собирайте команду на хакатоны или проходите курсы, результаты которых можно добавить в портфолио. Например, в Хекслет вы можете выбрать специализацию и за полгода обучения получить четыре реальных проекта.

На старте кода в стиле «работает, и ладно!» не достаточно, вникайте в особенности, ищите примеры на GitHub, GitLab или Medium. Изобретайте «велосипеды», так вы быстрее разберётесь в предметной области. В каждом проекте, изучая новую технологию, бросайте себе вызов. Не стоит стесняться тренировать инструменты, которые в спецификациях значатся «под разработкой» или «экспериментальное».

И только когда будете быстро делать проекты, почти не обращаясь к Google, Toster и StackOverflow, — можно пытаться зарабатывать. Идите на биржи фриланса и в агентства города.

Помните: пока вы спите и отсиживаетесь на парах, кто-то кодит и прокачивает портфолио.

Учите английский язык

Бо́льшая часть технической документации — на английском. Учебники и другую профессиональную литературу переводят с запозданием или не переводят вообще. Кроме того, на английском больше информации, и найти решение по англоязычному запросу проще. У ПО обычно несколько языковых версий, неплохо бы их понимать, а иногда и общаться с пользователями. Кажется, уже этих причин достаточно, чтобы захотелось подтянуть английский язык!

Как учить? Здорово, если в вузе хорошо преподают английский и у вас не осталось проблем со школьных времён. Если нет, можно пойти на курсы или заниматься с преподавателем по скайпу, читать книги, статьи и документацию ко всем технологиям только в оригинале. Сначала придётся проверять в словаре каждое слово, но постепенно это пройдёт. И самая приятная часть — играйте на ПК и консолях без перевода и смотрите видео в оригинале. Это даст результат! В идеале нужно подтянуть уровень до В2 (средне-продвинутый) или С1 (продвинутый) и подтвердить это сертификатом.

Помните: без английского в IT совсем никуда. Хорошая новость — многим технический английский даётся легче, чем разговорный или деловой.

Прокачивайте soft skills

Сейчас в IT принято делить навыки на «жёсткие» (hard) и «гибкие» (soft). Первые — это профессиональные умения для решения технических задач: владение C++, Java, JavaScript, например. Ко вторым относят коммуникации, целеполагание, стресс-менеджмент, лидерство.

Зачем нужны гибкие навыки? Как минимум затем, чтобы общаться с командой и доносить до неё информацию. А ещё, чтобы планировать время и задачи, ставить эффективные цели, быть ментором и управлять эмоциями. Soft skills помогут выступать на конференциях, рассказывать о технических победах и продуктах, над которыми вы работаете.

Помните: сегодня большинство продуктов разрабатывают в командах. Быть командным игроком, который не умеет слушать, задавать вопросы и доказывать свою точку зрения, очень сложно. Вуз — отличное место, чтобы начать прокачивать гибкие навыки.

Станьте частью профессионального сообщества

Оставаться всегда «на волне» вам помогут новости из мира IT, статьи и переводы обо всём, что связано с разработкой. Их можно найти у Tproger и на Хабре, читайте регулярно. Подписывайтесь на сообщества IT-компаний, чтобы получать полезные материалы, информацию о стажировках и приглашения на мероприятия. Не ограничивайтесь местными компаниями и помните, что сейчас IT-специалисты нужны не только разработчикам, но и банкам, и мобильным операторам и т. д. Они ездят по стране с хакатонами в поисках талантов. Локальные сообщества — ещё один источник знаний и связей.

Помните: вы хотите работать в IT, где изменения происходят очень быстро, а конкуренция очень высокая. Вы должны постоянно развиваться и вращаться в сообществе.

Общайтесь с работодателями

IT-компании, как правило, на виду у студентов, им нужны лучшие кадры. Они ходят в университеты на ярмарки вакансий, приглашают на практику, читают лекции и ведут семинары. Отмечайте такие компании, составьте список интересных работодателей.

Создайте резюме на HeadHunter с тегом «Начало карьеры», тогда вам будут приходить подборки вакансий для начинающих специалистов. Из них как минимум можно понять, чего именно ждут работодатели. Откликайтесь и ходите на собеседования. Просите тестовое задание и отнеситесь к нему серьёзно, это ценный опыт. Если не получилось с первого раза, попросите дать вам обратную связь о плюсах и минусах решения, чтобы сделать выводы и прокачать слабые стороны. Кроме того, что вас запомнят, вы получите опыт прохождения собеседований и в будущем не будете волноваться.

Кстати, даже если открытой вакансии или объявления о наборе на практику нет, всё равно напишите письмо менеджеру по персоналу и отправьте резюме. Мы иногда берём людей, если они впечатлили, даже когда не планировали искать специалиста.

Помните: присматриваться к работодателям и вакансиям нужно с первых курсов. Ваша работа на период учёбы — подготовить себя к требованиям рынка.

Будьте честными

Да, вначале кажется, что опыта недостаточно. Это нормально! Указывайте в резюме те навыки, которыми действительно владеете, и те технологии, с которыми работали, и на каком уровне с ними знакомы. На собеседовании обязательно об этом спросят, и преувеличить не получится. Лучше честно сказать, с чем не сталкивались и о чём не знаете.

Помните: работодатель понимает, что вы начинающий. На собеседовании он хочет понять, впишитесь ли вы в команду и для какого из его проектов подойдёте.

Меня часто спрашивают, нет ли у меня знакомых разработчиков. Обычно ищут middle/senior, чтобы он пришёл и сразу с первого дня начал тащить тонущий проект. Да, я понимаю, бывают ситуации, когда человек нужен на 1–2 месяца, но чаще всего речь идёт о постоянной занятости. Когда я предлагал поискать человека с горящими глазами, но с небольшим опытом, и дать ему возможность вырасти, то обычно получал ответ: «Некогда учить / пусть другие учат / зачем его развивать, если он все равно уволится?» Но ведь чтобы достичь хорошего уровня в знании Java, человеку без подготовки нужно несколько лет, да и в университетах этот язык, как и многие другие, не преподают на достаточном для промышленной разработки уровне. Откуда же взяться хорошему специалисту?

Я не разделяю такое мнение, этот подход кажется мне неэкологичным. Нельзя всё время брать из окружающей среды ресурсы, не вкладываясь в их восполнение. К счастью, сейчас многие уже поняли, как решить уравнение с нехваткой айтишников. И как правило, это компании, которые не гонятся за мимолётной выгодой, а нацелены на устойчивый рост в стратегической перспективе. Распознать их можно по трём ключевым признакам.

Собственные стажировки и образовательные программы

Программы стажировок и обучения внутри компании требуют больших затрат ресурсов, но они выгодны для всех сторон. Стажёры получают возможность дополнить свои знания и начать работать — кстати, это же мотивирует их выкладываться на полную, чтобы выделиться на фоне других ребят. Такие программы хорошо подходят, чтобы познакомиться с предметной областью и почувствовать культуру компании. Работодатели во время таких стажировок могут «заточить» специалистов конкретно под свои требования и сразу же закрыть несколько вакансий схожего профиля.

Собственные обучающие программы есть у многих компаний. Мы в банке проводим годовую программу стажировки So DGTL со множеством digital-направлений и различные трёхмесячные школы: Java, SQL, DWH и другие. Принцип у них общий: это работа внутри команды банка, погружение в реальные задачи (иногда в тестовой среде) при поддержке ментора — эксперта в данном направлении.

Кандидаты проходят через несколько этапов отбора — заочно и у нас в офисе. В течение всей программы мы следим за развитием кандидатов, помогаем и поддерживаем. Недельными «спринтами» ребята двигаются к выпускному, который обычно проводится после 2–3 месяцев обучения. В конце мы получаем специалистов начального уровня, но зато идеально соответствующих нашим требованиям и высоко мотивированных работать в нашей компании. Как итог, примерно 80 % каждого набора продолжают работать с нами на постоянной основе после окончания программы.

Постоянное развитие

Природа человека такова, что он хочет постоянно решать всё более сложные задачи и изучать новые технологии и подходы. Если дать сотрудникам возможность проходить обучение без отрыва от рабочих процессов, это позволит развивать их компетенцию и долгое время сохранять лояльность к работодателю на высоком уровне.

У нас в банке есть собственные дистанционные форматы обучения и подписки на внешние курсы, проводятся регулярные профессиональные клубы и мастер-классы. Мы запускаем внешние митапы, а перед ними отбираем выступления на внутренних встречах. Для каждого сотрудника выделяется бюджет и объём рабочих дней, которые можно потратить на обучение.

Это отражается и на продуктах. Гибкие подходы к разработке поддерживают принципы continuous learning, которые подразумевают непрерывное получение новых знаний о рынке, клиентах и их поведении, новых технологиях, трендах и паттернах.

Доступность образования позволяет бесшовно встроить его в рабочий процесс, и тогда сама привычка учиться становится частью культуры.

Участие в митапах, сообществах, конференциях

Для меня участие в митапе — это отличная возможность отвлечься на некоторое время от текущих задач и узнать о современных трендах в разработке от коллег по цеху. Участвуя в митапах в роли докладчика, всегда чувствуешь, что твоя тема интересна многим, и это вдохновляет двигаться дальше в этом направлении.

Выступления дают докладчику возможность развивать свои soft skills, а также расширить профессиональные связи среди экспертов. В такой среде можно соотнести свой уровень с текущим состоянием отрасли, понять, какими навыками ещё нужно овладеть, а что из опробованных кем-то методов взять на вооружение прямо сейчас. Компании это позволяет стать более узнаваемой и популярной среди будущих соискателей.

Самому подготовиться к выступлению бывает сложно: всегда хочется, чтобы кто-то посмотрел со стороны, а то и дал «волшебного пинка». Конференции проводятся в рабочее время в разных городах, и билеты иногда недешёвые. Так что без поддержки работодателя поехать бывает трудно. И в то же время, если компания об этом заботится, участие в конференциях помогает чувствовать себя нужным и мотивирует делиться знаниями с коллегами, чтобы самим сделать что-то такое же крутое, как кейсы из услышанных докладов.

Мне кажется, чем больше компаний начнут следовать данным принципам, тем быстрее снизится дефицит разработчиков и айтишников в целом. А значит, рынок будет развиваться быстрее, и на нём появится больше классных продуктов.

Когда я начинала свою карьеру в разработке, многие запросы пользователей, аналитиков и руководителей проектов казались мне непонятными и странными. За последующие годы я прошла несколько этапов карьерного пути: после разработчика была архитектором, аналитиком, руководителем проекта и аккаунт-менеджером. Это помогло мне взглянуть на потребности заказчиков с других ракурсов, и многие запросы бизнеса оказались понятными и обоснованными.

Я хочу поделиться опытом и рассказать, как руководителю правильно погрузить проектную команду в контекст заказчика, сделать потребности бизнеса или отдельных пользователей понятными, а проблемы — решаемыми. Под руководителями проекта я подразумеваю в том числе и тех руководителей, которые выстраивают коммуникацию между заказчиком и проектной командой — владельцев продукта, аккаунт-менеджеров.

Шаг 1. Оцениваем текущую ситуацию

Для начала необходимо понять, как команда видит цели и задачи проекта. И сразу плохая новость: если коллега сам пришёл с уточняющими вопросами, это может быть тревожным сигналом о том, что непонимание накопилось не только у него, но и у всей команды. Внимательно понаблюдайте за происходящим: что говорят о проекте? Задают ли вопросы вам? А вашим коллегам? А друг другу? Часто люди до последнего стараются разобраться в проблеме самостоятельно, но при этом внутри них копится недовольство проектом, клиентом или руководством. Причин, почему вопросов не задают вовремя, может быть множество. Некоторые думают, что их посчитают глупыми или некомпетентными. Другие стесняются спросить, необщительны или считают, что коллеги должны им все рассказать или догадаться, что они чего-то не понимают.

Конечно, в компаниях, где корпоративная культура построена на взаимовыручке и доверии, сотрудники более расположены к обсуждению тем, которые их волнуют или вызывают непонимание. Но даже в этом случае руководителю проекта лучше работать на предупреждение деструктивных ситуаций. Его главная задача — соблюдать обязательства перед заказчиком и при этом поддерживать комфортную и продуктивную атмосферу в коллективе.

Чтобы понять, что происходит внутри проекта, проводим личную встречу с каждым членом команды и просим его ответить на следующие вопросы:Как он понимает цели и задачи проекта?Как он понимает свои собственные цели и задачи?Какие цели он считает приоритетными: свои, проектной команды, пользователей, заказчика или те, которые определяет его проектная роль?Кому он задает вопросы и отчитывается о результатах своей работы? Кого считает руководителем?Что он считает успешным результатом своего труда?

Ключевые слова здесь — «с каждым». Без индивидуального общения картина будет неполной. К встрече нужно подготовиться заранее, учитывая особенности и личные предпочтения человека.
На что стоит обратить внимание:

Место. Одному комфортнее обсуждать рабочие вопросы на обеде, другой чувствует себя спокойнее в тихой переговорной, а третьему удобнее перекинуться парой фраз за кофе на корпоративной кухне.

Время. Человек, с которым вы общаетесь, должен быть в рабочем состоянии. Так что не назначайте встречи жаворонкам на конец дня, а совам — на раннее утро.

Личный настрой. На встречу нужно идти с желанием узнать что-то новое о человеке и о проекте. Если вам не интересно чужое мнение и вы не готовы слушать, лучше не тратьте рабочее время. Если обсуждение проходит «для галочки», то люди интуитивно это понимают, поэтому с таким подходом открытого диалога не получится. Вам расскажут «правильную» или корпоративно одобряемую версию событий или вообще ничего толком не объяснят.

Проведение встречи. Больше слушайте, задавайте вопросы, интересуйтесь, старайтесь услышать, что вам хочет сказать человек. В процессе встречи можете делать записи, если боитесь что-то упустить, но постарайтесь не писать постоянно.

Подведение итогов. После встречи выделите время, чтобы зафиксировать цели проекта, которые озвучил вам коллега, и его личные стремления. Лучше сделать это сразу, пока свежи воспоминания. Я рекомендую фиксировать формулировки человека дословно, чтобы не потерять исходного смысла. Приведу примеры из личной практики. Посмотрите, насколько различаются формулировки целей разных сотрудников, работающих в одном проекте: «сделать отчеты по ценным бумагам для трейдеров»; «сделать проект в срок и уложиться в бюджет»; «удовлетворить требованиям ТЗ»; «удовлетворить требованиям пользователей». Аналогично и с постановкой личных целей: «освоить новую технологию»; «научиться понимать аналитика»; «делать работу, и чтобы никто не трогал»; «найти много багов».

Шаг 2. Составляем «карту местности»

Все результаты встреч переносим на «карту местности»: рисуем организационную диаграмму, структуру коммуникаций, обозначаем функции и задачи каждого сотрудника и другие важные нюансы. Если схема организационной структуры выглядит понятной, то либо в проекте всё хорошо, либо вы что-то упустили. Чаще схема выглядит запутанной. Приведу пример из реальной практики.

На картинке изображены люди, цвета пиктограмм соответствуют разным функциям (аналитика, разработка, тестирование, владение продуктом). Стрелочки показывают, кто кому подчиняется, по мнению руководителей и самих сотрудников.

Шаг 3 (или 0). Описываем внешний контекст: задачи заказчика и продукт

Если вы руководите проектом с его старта, этот шаг должен быть первым. Но более распространенная ситуация — долгоживущий продукт с периодической сменой руководителей. В этом случае правильнее сначала изучить существующие материалы по продукту и затем сравнить их с задачами заказчика, выяснить, чего хотят конечные пользователи, с какими проблемами они сталкиваются, а также подумать над способами их решения.

Существует масса практик, которые помогают разрабатывать продукт: фиксировать информацию от пользователей, создавать описания продукта, проверять гипотезы. Приведу самые распространенные, расположив их сверху вниз по степени увеличения детализации создаваемых описаний продукта:

• Canvas Business Model,
• Глубинные/пользовательские интервью,
• Customer Journey Map,
• Customer Development,
• Service Design,
• Story Map,
• User Story,
• Jobs-To-Be-Done.

Все эти практики можно применять в продуктовой разработке, при этом три последние подходят для использования в заказной разработке.

В проекте, где уже есть прототипы или какие-то версии продукта, будут некоторые описания продукта. Если вы делаете продукт с нуля, то они должны сформироваться в ходе работы проектной команды.

Шаг 4. Определяем различия между желаемым и действительным

Вам нужно сопоставить желаемую и реальную ситуацию в проекте по двум направлениям:

• продукт,
• организационная структура внутри команды.

Продукт

Ожидания заказчика и сам продукт часто описываются при помощи разных методологий. Поэтому универсального способа для поиска несоответствий между такими описаниями нет. Для решения этой задачи вам придётся применить аналитический подход и сопоставить эти описания вручную. Итогом работы должен стать перечень различий. Он ляжет в основу плана конкретных изменений в проектируемом или уже созданном продукте.

Организационная структура

На данном этапе нужно создать схему желаемой организационной структуры, опираясь на схему, которая получилась после шага 2.

Отдельно для всех типов деятельности и каждой роли нужно описать функции, которые будет выполнять человек. После этого сравните вашу точку зрения с мнениями членов команды. Различия обязательно найдутся, поэтому на заключительном этапе работы с организационной структурой важно подумать о том, как объяснить сотрудникам необходимость преобразований и их новые функции.

Если тимлиды будут не в курсе вашей загруженности, то увеличат количество задач, а это приведёт к выгоранию. Возможно, вы захотите лично обратиться к кому-то из членов команды. Например, вы пожелаете, чтобы разработчик взял на себя функции тимлида.

Постарайтесь, чтобы человеку было приятно услышать ваше предложение. Не стоит формулировать его так: «Вася, к тебе все ходят с вопросами по технической части и уточняют, что делать. Давай ты будешь руководить ребятами?». Гораздо лучше сказать: «Василий, мы видим, что ты стал экспертом по продукту, умеешь принимать взвешенные технические решения и доносить их до команды. Как ты относишься к тому, чтобы узаконить эти функции? При новом распределении нагрузки часть времени ты будешь тратить на координацию группы, а часть — на разработку». Так вы обозначите сильные стороны человека, покажете, что видите его заслуги и оцениваете их по достоинству, и при этом зададите все необходимые вопросы, не загнав человека в угол.

Сотрудник может отказаться от вашего предложения, это его право. В таком случае вам нужно будет вернуться к пересмотру организационной структуры.

Важный момент. Персональное предложение сначала нужно обсудить с человеком лично. Только после этого можно будет озвучить принятое решение всей команде. Сотруднику будет не очень приятно узнать, что его назначают тимлидом, на общей встрече.

Шаг 5. Доносим контекст до команды

Всю собранную информацию нужно не просто осмыслить, а передать в работу команде. И тут важно выбрать метод, подходящий именно вашим коллегам: общие статусы, индивидуальные встречи, презентации, воркшопы или что-то ещё. Здесь вам помогут данные, которые вы зафиксировали на этапах 1 и 2.

Чаще всего описания продукта по требованиям заказчика готовит только часть команды. Это могут быть: владелец продукта, аналитик, руководитель проекта, архитектор или ведущий разработчик, UX/UI-дизайнер. Поэтому тех, кто подключается к проекту уже после создания описаний, необходимо оперативно ознакомить с актуальной повесткой. И нет, это не значит прислать ссылку на хранилище тучи файлов.

Здесь все ситуативно. В моей практике наибольшую эффективность показали регулярные презентации о продукте для всей команды. В нашем случае это ежемесячная часовая встреча, на которой руководители рассказывают о том, в каком состоянии на данный момент находится продукт, что из прошлых планов удалось реализовать и какие наработки планируются в будущем. Как и во всякой встрече, залог её успешного проведения — предварительная подготовка. О том, как подготовиться ко встречам, можно почитать в этой статье. После мероприятия важно собрать вопросы и оперативно дать на них ответы.

Однако для некоторых команд такие форматы оказываются совершенно нерабочими и приходится подбирать другие варианты. Мои коллеги, руководители проектов, иногда устраивают воркшопы для крупных команд, чтобы под руководством опытного тренера сформировать единое описание продукта. Здесь стоить отметить, что такие воркшопы могут проводиться как для создания описаний, так и в случае знакомства сотрудников с материалами, подготовленными частью команды проекта.

Вариант воркшопов особенно продуктивен, когда проект только стартует, а также если в команде больше таких людей, которым самостоятельное осмысление задачи и вариантов ее решения помогает убедиться в необходимости ее выполнения.

Очень рекомендую записывать общие встречи и воркшопы на видео, чтобы новые сотрудники могли ознакомиться с материалами. Это не отменит индивидуальных встреч, но поможет коллегам получить предварительную картину происходящего и сократит время на персональное погружение.

Существует множество других форматов передачи знаний. Чтобы выбрать правильный инструмент, можно обратиться к специалистам по внутренним коммуникациям вашей компании, если такие имеются.

Шаг 6. Контролируем все организованные процессы

Если вы успешно прошли предыдущие шаги, то вам удалось наладить работу над проектом. Каждый член вашей команды знает свои цели и задачи, понимает свой вклад в общее дело и то, какой результат нужно получить. На этом этапе руководителю важно не убирать руку с организационного пульса. Недопонимание внутри коллектива и при общении с заказчиком возникает постоянно, поэтому необходимо вовремя отслеживать разногласия и возвращать рабочий процесс в продуктивное русло.

2018 год стал переломным для технологии блокчейн. С одной стороны, все мы видим стремительное падение биткоина, снижение хайпа вокруг блокчейнизации всего и вся.

Компания Gartner в новом Hype Cycle (2018) поместила технологию блокчейн в зону «разочарования». С другой стороны, платформы повзрослели технически и организационно, много гипотез уже протестировано. Компании поняли, что технология полезна — меняет процессы в работе (о некоторых из них расскажу ниже), помогает сократить издержки, позволяет поднять сам бизнес на новый уровень и так далее. Но вот точное понимание, какие процессы того стоят, а где можно обойтись старыми добрыми (и более дешёвыми) решениями, пока не сформировалось.

Помочь бизнесу разобраться в его потребностях и в том, как наложить их на актуальную практику блокчейна, берутся немногие. Тиражировать решение — задача довольно распространённая, а вот изобретать нечто новое не так просто.

В конце 2018 года КРОК и команда блокчейн-фреймворка Exonum компании Bitfury объединили усилия и создали центр блокчейн-компетенций для коммерческого сектора. Задача центра — ускорить процесс практического и разумного внедрения блокчейна в практику разных бизнесов. Вместе мы обсуждаем кейсы и оцениваем рентабельность использования распределённого реестра для самых разнообразных задач. Например, сейчас мы трудимся над промышленной сферой — нужен ли блокчейн для учета выработки агрегатов и работ, проведённых с ними, и какие подходы здесь оптимальны.

О результатах скоро расскажем, а пока давайте посмотрим, где блокчейн успешно применяют уже сегодня.

Деньги в кассе

Первой сферой, заинтересовавшейся ценными качествами блокчейна, стали финансы. Работа с деньгами требует анонимности, защиты от искажения информации, часто — взаимодействия с удалёнными клиентами. Личные встречи в банках уходят в прошлое, современный мир требует гарантии защиты данных на любых расстояниях. И тут блокчейн спасает.

Проведение операций с использованием блокчейн-технологий создаёт комьюнити, где люди доверяют друг другу, видят всё, что происходит с деньгами или активами и уверенны, что никто из участников цепочки не сможет вносить правки без ведома других. При этом географическая удалённость вообще ничего не меняет. Весь мир можно объединить в закрытое и защищённое сообщество. Безусловно, это прорыв. С другой стороны, анонимность может стать проблемой, ведь сложившиеся практики борьбы с отмыванием денег здесь уже не сработают — сложно отследить транзакции. Поэтому криптовалюты стали излюбленным инструментом теневого сектора экономики и предметом пристального внимания регуляторов.

На помощь регуляторам, компетентным органам и финансовым институтам с расследованиями подобных транзакций в сети Биткоин создаются такие инструменты, как Crystal. В финансовом секторе также можно выделить проект Ассоциации ФинТех «Цифровые банковские гарантии», который запущен на блокчейн-платформе Мастерчейн. Инициатором проекта выступил банк ВТБ, а разработка системы велась при участии КРОК. Размещение информации о выданных банковских гарантиях в распределённом реестре Мастерчейн позволяет банкам и их клиентам получать достоверные сведения в режиме реального времени и снижает риски фальсификации данных.

Дальше — больше

Производители, ритейлеры, поставщики стали применять блокчейн для управления цепочками поставок. Удобно, когда весь цикл создания продукта и его поступления к конечному потребителю — как на ладони. Начиная с того, чем удобряли помидор, до момента, когда вы покупаете в магазине у дома томатную пасту, сделанную из этого помидора. Поставка сырья, переработка, транспортировка, фасовка, продажа — любые этапы при оправданном внедрении блокчейна становятся доступными. Безусловно, в реальности отслеживать путешествие томата до нашего стола пока никому в голову не пришло. Просто потому что такая банка томатной пасты обошлась бы дорого. Но вот облокчейнить некоторые критически важные для бизнеса процессы вполне можно. Например, в транспортно-логистических структурах подобная необходимость есть: что, когда, кому, каким путем, с какими условиями хранения было доставлено. Особенно когда речь идёт о скоропортящемся дорогом грузе, об отслеживании крупных партий или, наоборот, об эксклюзивных отправлений.

Примером в этой отрасли стала блокчейн-платформа TradeLens, созданная корпорацией IBM и компанией Maersk — мировым лидером в сфере контейнерных перевозок. TradeLens — это цифровая торговая площадка, глобальная логистическая экосистема, которая используется множеством торговых партнёров для сотрудничества и общего управления транзакциями, причём без ущерба для конфиденциальности. К слову, Министерство транспорта РФ планирует внедрить блокчейн-платформу TradeLens в российские морские перевозки в партнёрстве с Maersk и ФГУП «Морсвязьспутник». Тестирование проекта пройдёт в Большом порту Санкт-Петербурга. По подсчётам специалистов, внедрение блокчейна поможет грузовладельцам сократить расходы на 10 млрд рублей.

Проверка подлинности

Среди очевидных отраслей, где блокчейн облегчит жизнь бизнесу, — авторское право, борьба с контрафактом и пиратством, подтверждение личности. И в большинстве случаев речь идёт о сохранности и отслеживании изменений крайне ценной с коммерческой точки зрения информации. Тут расходы на разработку и внедрение блокчейн-продукта очень даже обоснованы. Например, возможность отслеживать подлинность ювелирных украшений и произведений искусства станет серьёзным препятствием для распространителей подделок и контрафакта, ущерб от деятельности которых измеряется десятками миллионов.

Это аналогично авторскому праву на произведения: создание баз с использованием блокчейна поможет бизнесу в кадастровых, земельных, наследственных и других юридических вопросах. Отслеживание права и поиск истины в делах имущественных благодаря блокчейну могут стать настолько элементарными, что загрузка судебных органов значительно уменьшится.

Существуют сервисы (децентрализованные реестры), позволяющие создавать уникальные цифровые идентификаторы и сертификаты для подтверждения авторства и подлинности. Кроме защиты произведений, наличие таких идентификаторов позволяет обеспечить надёжный механизм передачи права владения от автора к покупателю или коллекционеру, учитывая все юридические аспекты.

Сегодня вы можете подтвердить своё авторское право, например, на сервисах Proof of Existance, Emernotar.io. Кстати, с прошлого года в России авторские права с использованием блокчейн-технологий подтверждает акционерное общество Единый депозитарий результатов интеллектуальной деятельности (ЕДРИД).

Принцип работы подобных сервисов един: загружаемый файл хешируется, а результат (хеш) заносится в блокчейн. Для проверки авторства проводится повторная операция хеширования и получившийся хеш сравнивается с хешем, хранящимся в блокчейне. Совпадение гарантирует, что данный файл был внесён в блокчейн в конкретный момент времени.

Другое интересное применение блокчейна — компьютерные игры. С развитием многопользовательских игр огромными темпами растёт и рынок связанных услуг — начиная с «лут-боксов» и заканчивая различными «скинами» для виртуальных предметов. Оборот от продажи внутриигровых предметов только компании Valve превышает 4 миллиарда долларов за 2017 год при оценке всей игровой индустрии в 128 миллиардов долларов. И вот тут информацию о вашем криптокотике за 12 тысяч долларов или новой «шкурке» для автомата хочется отдать в надёжные руки блокчейна — ведь по статистике 1 из 8 предметов крадут.

Кроме того, на блокчейне можно построить рынок уникальных внутриигровых товаров, когда игрок получает сертификат о том, что такой предмет есть только у него.

Голосование

Блокчейн — прозрачная технология, в которой невозможно подменить данные, поэтому она может упростить и процесс голосования. Знаковой датой для блокченизации выборов стало 7 марта 2018 года, когда в Сьерра-Леоне прошли президентские выборы. Правда, блокчейн использовался лишь для верификации бумажных бюллетеней. В организации процесса помогла швейцарская компания Agora, которая разрабатывает цифровые технологии для голосования. Гарантами прозрачности процедуры тогда выступили Красный Крест, Высшая техническая школа Лозанны и Университет Фрайбурга.

Рассматривать блокчейн можно и при проведении менее масштабных выборов — внутрикорпоративных или клиентских опросов. Например, акционеры компании могут отдавать свои голоса за инвестирование в те или иные проекты, жильцы дома — высказываться на тему обустройства дворовой территории.

При использовании блокчейна будет сохранена достоверность сведений. Однако важно понимать, что специализированные сервисы для голосования на основе блокчейна взимают внушительную комиссию с организаторов выборов или с участников. Создание такого инструмента для опросов компании тоже обойдется не в тысячу рублей. Поэтому важно сначала грамотно оценить расходы и профит, который вы получите в итоге.

Благотворительность

У блокчейна большие шансы на успех в благотворительной сфере. Существует немало благотворительных фондов и проектов, как и людей, готовых передавать им средства. Но вот уровень доверия к организациям такого рода — вопрос неоднозначный.

Решение верить или нет спонсор принимает практически интуитивно, а то, как организация распорядится деньгами, всегда остаётся на её совести. Ведь все мы понимаем, что отчёты подделываются, фото редактируется, а видео монтируются, да и вообще, ещё знаменитый Остап Бендер знал 400 сравнительно честных способов отъёма денег у населения. И благотворительность в его арсенале, к слову, тоже мелькала. Люди хотят видеть, на что были потрачены пожертвованные ими средства и какую пользу принесли.

Блокчейн-идеи в сфере благотворительности уже реализуют. Например, в обращение ввели виртуальные баллы (наподобие токенов), которые можно использовать для бартера. За определённое количество таких токенов любой желающий может предоставить фонду помещение или найти группу волонтеров на мероприятие. Кроме того, баллы можно приобрести за реальные деньги, которые пойдут на нужды организации. Компания-разработчик может заняться созданием системы для обращения таких виртуальных баллов и войти в партнёрскую сеть, поддержав честную и прозрачную благотворительность.

К слову, в 2013 году американка Конни Галлиппи основала фонд BitGive, который стал первой зарегистрированной некоммерческой организацией, использующей биткоины для сбора пожертвований. Пользователи, направляющие криптовалюту на благотворительность, могут следить за расходованием средств в режиме реального времени. Фонд также сотрудничает с Medic Mobile, сообществом медицинских работников, где блокчейн помогает в проектах по привлечению средств для своевременного лечения детей, страдающих от недоедания. Другой пример — работа фонда Electronic Frontier Foundation (EFF). Эта благотворительная организация занимается защитой гражданских свобод в цифровом мире и интернете. Здесь криптовалюту направляют на исследования в области политики, судебных процессов, связанных с интернет-деятельностью, на разработку ПО и прочего.

Блокчейн в вашем бизнесе

Кейсов много, но как понять, нужен ли блокчейн именно вам? Просто ответьте на несколько вопросов:

1. В рамках вашего бизнес-процесса действия выполняет множество независимых участников?
2. Эффективны ли посредники? Доверяете ли вы им?
3. Есть ли необходимость доверять данным системы или выполняемым в ней действиям?
4. Нужна ли усиленная безопасность для обеспечения целостности системы и данных?

Если хотя бы на один вопрос вы ответили «нет» — внедрять блокчейн в ваш бизнес ещё рано, можно обойтись традиционными решениями. В противном случае рекомендую начать с небольшого пилота для проверки гипотезы.

К 2030 году вклад промышленного «интернета вещей» в мировую экономику составит 14,2 трлн долларов, подсчитали аналитики из Accenture. Цифровая трансформация промышленности сократит издержки, повысит производительность труда и конкурентоспособность бизнеса.

Растущая отрасль промышленного «интернета вещей» (Industrial IoT, IIoT) привлекает внимание венчурных и индустриальных инвесторов. Несколько лет назад компания SAP создала фонд размером 2 млрд евро для инвестиций в «интернет вещей», одно из ключевых направлений которого — виртуализация цепей поставок с помощью интеллектуальных датчиков и машинного обучения. В феврале 2019 года китайская Alibaba Group инвестировала 13 млн долларов в немецкий IIoT-стартап Konux, который повышает пунктуальность поездов и пропускную способность железных дорог за счёт предиктивного планирования техобслуживания. Аналогичные решения будут востребованы во всех странах, развивающих скоростной железнодорожный транспорт, в том числе в России.

Промышленный IoT — это сложный рынок с относительно высокой планкой входа, поэтому стартапам нужно как можно раньше искать технологических партнеров и индустриальных инвесторов, которые не только обеспечат финансирование разработок, но и поделятся своей экспертизой.

Ключевые тренды IIoT в 2019 году: беспилотный транспорт и логистика, специализированные отраслевые решения и безопасность. В этих сферах нас ждут самые интересные стартапы и самые большие инвестиции.

В области транспорта и логистики появятся новые примеры, где «интернет вещей» разворачивают для развития транспортных сетей, оптимизации управления и сбора данных. Понять масштаб можно, посмотрев на китайский проект G7 Networks — в декабре 2018 года эта компания, специализирующаяся на IoT в логистике, привлекла 320 млн долларов. Решения в логистической сфере связаны с внедрением RFID-сенсоров для управления цепями поставки: этим, в частности, занимается, компания Alien Technology, в которую инвесторы вложили уже больше 330 млн долларов. Среди других интересных примеров — стартап Vnomics с его технологий учёта расхода топлива в реальном времени для транспортных компаний.

В свою очередь, внедрение специализированных отраслевых платформ повысит гибкость бизнеса. К примеру, предприятия ЖКХ будут использовать умные счётчики, системы аналитики сбоев и машинное обучение для прогнозирования пиков потребления — такие решения повысят безопасность предприятий и качество услуг. Один из таких стартапов — канадский Osprey Informatics — развивает платформу для оптимизации расходов энергетических компаний и уменьшения вреда окружающей среде. В прошлом году компания привлекла 2,75 млн долларов венчурных инвестиций.

Наконец, промышленный «интернет вещей» повысит безопасность производства. Массовое внедрение сенсоров в добывающей промышленности и в других отраслях с высокой степенью риска снизит вероятность несчастных случаев. Стартап Petasense выпускает датчики и программное обеспечение на основе машинного обучения, они измеряют уровень вибрации промышленного оборудования, предсказывая возможные отказы.

В России наиболее востребованными должны стать решения в области безопасности: как применение «интернета вещей» для охраны труда, жизни людей и общественного порядка, так и средства защиты самого «интернета вещей». При этом самые привлекательные для инвесторов проекты будут появляться на стыке IoT и искусственного интеллекта или блокчейна.

Так, «интернет вещей» входит в топ-3 популярных технологических сфер среди проектов, которые поступают к нам на оценку. Почти 70% из них — это стартапы, посвящённые именно IIoT. В тройке, кроме «интернета вещей», искусственный интеллект и Big Data (делят первое место), а также машинное обучение.

Один из примеров использования «интернета вещей» для решений в области безопасности — разработанная в России платформа Nexign IoT Platform, которая связывает всю IoT-экосистему предприятия. Сейчас платформу используют в нефтегазовой промышленности и энергетике для оптимизации контроля качества, расходования и транспортировки ресурсов. Кроме того, платформа от Nexign позволяет бороться с мошенничеством благодаря анализу поведения устройств и данных «интернета вещей», которые передаются в реальном времени. К примеру, так можно предотвращать кражи «умных» автомобилей.

Одна из причин привлекательности рынка промышленного «интернета вещей» для инвесторов в том, что в нём есть место для самых разных компаний — от разработчиков нишевых платформ до глобальных ИТ-гигантов, от провайдеров облачных сервисов до консультантов по цифровым стратегиям. Крупные российские компании уже начали инвестировать в IoT: в 2018 году «Ростех» разработал первый отечественный чип для «интернета вещей», а «Мегафон» представил специальный тариф для управления IoT-устройствами.

Проект гидрохимического мониторинга Байкала, разработанный специалистами «Ростеха» и «КорКласса» (входит в «ИКС Холдинг»), показывает, как можно использовать возможности «интернета вещей» не только для производственной, но и для экологической безопасности. Автономная система контроля представляет собой два плавающих буя, оснащённых датчиками и модулем интеграции с аппаратно-программным комплексом «Безопасный город». Система позволяет контролировать химический состав озера, анализируя концентрацию в воде различных веществ, и параллельно измеряя температуру воды, Ph, чистоту, проводимость и ряд других параметров.

Сегодня рынок промышленного «интернета вещей» в России только начинает развиваться. По данным Высшей школы экономики, облачные сервисы применяют 23% российских компаний, а RFID-технологии — только 6% (для сравнения: в Южной Кореи проникновение RFID в бизнесе достигло 42%). Перед стартапами в области IIoT открыт огромный рынок, а каждый успех в этой сфере повышает конкурентоспособность российской промышленности.

Существуют три основных направления для программистов: фронтенд, бэкенд и мобильная разработка.

• С фронтендом выбор очевиден. Здесь «рулит» JavaScript. Для этого языка создано множество мощных фреймворков. Также для разработки интерфейсов обязательно понадобится знание HTML и CSS.
• В бэкенде по-прежнему актуален C++, хоть некоторые и торопятся списать его со счетов. Также в топе здесь Java и C#. Обратите внимание и на перспективные Kotlin, Golang и Python.
• В области мобильной разработки всё зависит от платформы. Если IOS, то Swift, а если Android, то, в основном, Java. Развиваются и новые направления по созданию приложений с применением веб-технологий: HTML и JavaScript + CSS.
• Наконец, если планируете работать с базами данных, то обязательно нужно изучать SQL.

Создайте хорошую основу

Несмотря на холивары по этому поводу, математика поможет грамотно разложить в голове разработчика базовые вещи. Алгоритмика прекрасно развивает мышление, поэтому тоже must-have. К тому же на собеседованиях в крупнейших компаниях любят спрашивать про алгоритмы, так что без этих знаний туда попасть нереально.

Сегодня в университетах насильно дают студентам определённый язык. К сожалению, иногда программисты так на нём и останавливаются.

Я считаю, что знакомство с ЯП лучше начать с С или С++. Они помогут сформировать базу, понять основные принципы, и браться за другие языки будет уже гораздо легче.

Прокачивать одно направление или постепенно освоить несколько — выбор каждого. Некоторые компании специально ищут фулстек-разработчиков, которые совмещают фронтенд и бэкенд. Быть этаким человеком-оркестром выгодно, если занимаешься фрилансом.

Гармоничное развитие получится, если выбрать одно направление и один язык. А после достижения достойного уровня можно подтянуть и дополнительные ЯП.

Следите за лидерами рейтингов

Популярные языки – те, что на слуху. Даже люди, далёкие от программирования, наверняка слышали о Java, C++ и Python. Топовые ЯП периодически меняются местами в двадцатке, но состав их стабилен и отражает реальную картину. Выбрать себе язык из этого списка — неплохая идея.

Рейтинги составляют на основе поисковых запросов. И тут стоит учитывать погрешности. TIOBE отслеживает, как часто пользователи искали название ЯП. Но ведь вбивая слово «python», юзеры могут подразумевать не только язык, но и змею.

Индекс PYPL более показательный. Чтобы попасть в зачёт, запрос должен содержать помимо имени ЯП слова «tutorial», «documentation» и т. п. Но и здесь есть минусы: программисты с хорошим знанием языка редко гуглят документацию.

Точно не стоит браться за технологии, которые умирают. Visual Basic, Delphi, Паскаль — это уже история, карьеру на них не построишь. Даже если пока ещё довольно легко можно найти работу со знанием Objective-C, скоро Swift вытеснит его. Поэтому если хотите создавать современные приложения, выбирайте современный ЯП.

Недавний пример: в прошлом году к нам в школу пришёл программист, который овладел ActionScript и писал на нём флэш-игры. Но эта индустрия окончательно затухла и специалист был вынужден переучиваться на Java.

Изучайте предложения на рынке

Лучший способ понять, знание каких ЯП сегодня приветствуется, — посмотреть сайты вакансий. Там же можно узнать и «вилку» предполагаемой зарплаты. HH даже ведёт блог на эту тему, ежегодно публикуя статистику.

Средние показатели для популярных языков будут примерно одинаковы. Оклад будет зависеть от того, как договоришься, но тенденции тоже стоит учитывать.

Владение редкими ЯП, например Clojure, Erlang, Scala, зачастую оплачивается выше, но и работу с ними найти сложнее. Поэтому советую осваивать их как дополнительный скилл. К тому же при изучении популярного языка можно обратиться за помощью и разъяснениями к сообществу. С новыми ЯП эта функция работает хуже.

«Любимчик» российского рынка и лидер по числу вакансий по-прежнему 1С. Оклад у junior-разработчика с ним, возможно, будет выше, чем с теми же Java и С#, но при этом потолок — ниже. Так что не гонитесь за цифрами c самого начала. Думайте о перспективах и росте.

Посмотрите, какие специалисты требуются в компании, где вы хотели бы работать. Если это enterprise-разработка и банковский сектор, то в топе наверняка будет Java. Гиганты вроде Mail.Ru Group, «Лаборатория Касперского» и «Яндекс» предпочитают C++.

Планируете заниматься НИОКР и нейросетями, ваш язык — Python, мечтаете попасть в Microsoft — С#.

Google активно продвигает Golang. Это легковесный язык, перспективный, хайповый, который прекрасно ложится на тренды по созданию микросервисной архитектуры. Спрос на него больше, чем предложение.

Получайте удовольствие

Напоследок пример из личной практики. Прошлой осенью я за пару дней с нуля изучил Python. Конечно, поверхностно. Только ради того, чтобы поучаствовать в хакатоне по искусственному интеллекту, где машинки на поле таранили друг друга.

В итоге занял лишь 51-ое место и не получил даже футболки. Однако наспех полученных навыков хватило, чтобы заслать стратегию и посоревноваться. Кстати, всего там было 200 игроков, так что моё выступление не было полным провалом.

Выводы я сделал: Python мне не по душе, а не оказаться в числе замыкающих мне помог опыт в программировании на других языках. Это было, как минимум, весело!

Так что не стоит зацикливаться на одном языке. Попробуйте другие и поймёте, какой «в руку ляжет».

Поверьте: писать на том, что нравится, гораздо приятнее, да и получается лучше. За этим подтянется и финансовое благополучие. Если, возвращаясь домой из офиса, вы пишете программы «для себя», значит, профессию выбрали правильно.

Сегодня мы поговорим о работе с классами в JS. Думаю, что все, кто интересуется разработкой, слышали про объектно-ориентированное программирование (ООП). Эта парадигма программирования в настоящее время одна из самых популярных. И сейчас мы узнаем, как она реализуется в языке JS. ООП — очень обширная тема, в ней много понятий, поэтому данная статья не будет исчерпывающей. Мы разберём только основные моменты, не сильно вдаваясь в понятия и термины.

Сперва нужно разобраться с двумя основным идеями ООП — классом и объектом. Класс можно представить как чертёж, то есть проект чего-то, ещё не созданного, а объект — как воплощённый в жизнь чертёж. Если проводить параллель со строительством, то чертёж будущего дома — это класс, а построенный дом — объект.

Сразу хочу отметить, что в JS нет ООП как такового. Вместо него используется прототипно-ориентированное программирование — один из стилей ООП. У него есть отличия, но сейчас я их опущу.

Раньше, в ES5, работа в такой парадигме сводилась к написанию функции конструктора, а затем к неудобным манипуляциям со свойствами этой функции.

В ES6 был добавлен сахарок для работы с прототипами (для удобства буду называть их «классами»). Появились разнообразные команды для удобной разработки, которые скрывают под капотом все те «старые» команды из ES5.

Мы напишем простенький калькулятор, придерживаясь прототипно-ориентированного программирования. Такой пример познакомит вас с данной парадигмой, но не раскроет всех её преимуществ. Это я к тому, чтобы те, кто только начинает работать с JS, не сочли прототипное программирование чем-то непонятным и усложняющим разработку.

Создадим «класс» и объявим в нём конструктор (constructor). В конструкторе создадим две переменные: numberA и numberB. This — это указатель на текущий «класс». Если говорить проще, то теперь объявленные переменные будут доступны везде внутри «класса».

В итоге получится следующее:

Этот калькулятор будет хранить два значения «по умолчанию» и использовать их при работе, если не указано иное.

Наш маленький калькулятор будет поддерживать 4 основные операции. Поэтому создадим метод add(), который будет суммировать переданные ему аргументы. А если таковых нет, то калькулятор просуммирует те самые значения по «умолчанию».

Я не буду добавлять различные проверки вроде «числа ли переданы?», «не на ноль ли делим?» и т.д. Остановлюсь только на том, что должны быть переданы два аргумента, либо будут использоваться значения по умолчанию.

Вот так будет выглядеть метод сложения:

По аналогии с ним напишем методы для вычитания, умножения и деления. Единственное отличие — знак между операндами.

После создания всех методов «класс» приобретёт следующий вид:

Основная часть работы сделана. Осталось «создать экземпляр класса» и протестировать методы на работоспособность. Объявим константу calculate и присвоим ей новый объект. Посмотрите на пример, чтобы всё стало ясно:

Команда new используется для создания нового «экземпляра класса». Значения по умолчанию в этом примере — 72 и 39. Их мы передаём в «класс» как аргументы в обычную функцию. По сути, «класс» это и есть простая функция с некоторыми отличиями.

После описанных выше действий вызовем все четыре метода, передав в некоторые из них аргументы. Проверим, корректно ли они работают:

Да, всё правильно. Только в случае передачи двух аргументов, метод использует их. В остальных случаях используются значения по умолчанию.

Сегодня я познакомил вас с прототипно-ориентированным программированием в JavaScript. Да-да, несмотря на то что ключевое слово для создания прототипа — class, это всё те же прототипы. Именно поэтому я брал слова «класс» и «экземпляр» в кавычки.

И этот чайник на самом деле существует! Более того, в Германии его даже всё ещё можно купить. А оригинал хранится в Музее истории компьютеров в Калифорнии.

Как появился чайник из Юты?

На заре становления компьютерной графики в университете Юты работал исследователь Мартин Ньюэлл. Ему нужен был какой-то привычный объект из реального мира, чтобы тестировать на нём визуализацию. Что-то не слишком простое и не слишком сложное. И при этом очень знакомое, чтобы легко понять, насколько графика близка к оригиналу. Так совпало, что разговор про это зашёл за чаем, и жена Мартина, Сандра, предложила использовать их чайный сервиз. В итоге в цифровой мир был перенесён не только чайник, но и чашка, блюдце, ложка. Но именно чайник стал таким популярным.

Идею с чайником подхватил Джеймс Блинн (да, именно тот, из модели освещения Блинна-Фонга) и сделал первые качественные визуализации. Другие исследователи могли взять ту же модель и попробовать получить похожий результат. Позже, конечно, задача отрисовки чайника перестала быть задачей в принципе, но его стали применять для проверки материалов, теней и других эффектов.

Почему реальный чайник выше, чем его модель?

Потому что пиксели были не квадратные. На мониторах того времени модель чайника казалась слишком большой по высоте. И его специально «сплющили» в 1,3 раза, чтобы стало похоже на настоящий. Со временем характеристики мониторов улучшились, а чайник менять не стали, так как именно в такой версии он уже использовался везде.

Почему именно чайник? Чем он хорош?

Чайник имеет округлую поверхность, содержит седловые точки, может отбрасывать тень сам на себя, у него есть отверстие в ручке, и его легко показать даже без текстуры. Проще говоря, на нём можно проверить очень много вещей из компьютерной графики, хотя сам объект при этом не такой сложный.

Больше можно узнать из «Википедии», но лучше читайте англоязычную версию. В русскоязычной даже название перевели как «Чайник Юта» (если у вас есть права для переименования, пожалуйста, сделайте это).

Первая часть статьи будет о том, что нужно, чтобы стать так себе QA-инженером, вторая — что нужно, чтобы стать хорошим QA-инженером, третья — где это всё брать.

Что нужно, чтобы стать так себе QA-инженером

Английский от Intermediate, любые курсы QA, практика в IT-компании. Готово, вы восхитительны.

Что нужно, чтобы стать хорошим QA-инженером

Для начала стоит понять, ваше ли это. Я бы выделил несколько основных особенностей работы и черт характера, чтобы заниматься тестированием.

Техническая эрудиция

«Technical savvy», как иногда пишут в вакансиях, и желание разбираться в технологиях. Вы должны интересоваться тем, как что работает, как что устроено внутри. Это понимание сослужит хорошую службу в будущем и обычно идёт в связке с необходимым хорошему тестировщику любопытством.

Вы когда-нибудь ставили и настраивали Linux — для себя, чисто из интереса? Пытались разобраться, как работает блокчейн? Делали друзьям сайт на WordPress? Если нет, попробуйте и проследите за своей реакцией. Интересно ли, подстегивают ли сложности найти решение, покопаться в Google и на форумах? Когда конечный результат не тот, появляется ли желание докопаться и сделать, чтобы всё начало работать как надо? Если вы ответили «да», скорее всего, тестирование вам подходит.

Disclaimer Внимательный и искушённый читатель скажет, что я сейчас описал админа/девопса, но хороший тестировщик, на мой взгляд, обязан иметь желание и возможность и разбираться во внутренностях продукта, и уметь настроить (перестроить, почистить, твикнуть, заморозить, залить данными) тестовое окружение.

Ориентированность на пользователя и бизнес

Есть хорошая шутка про тестировщика, который заходит в бар, и лучшее продолжение для клиента.

Так вот, первое — про бездумный перфекционизм, второе — про то, чтобы всегда держать в голове образ пользователя, понимать, какие задачи он будет решать, в каких условиях, где ему будет удобно, а где — не очень, какими нестандартными методами он может решать свои задачи, как наше приложение будет встраиваться в общую экосистему и рутину пользователя.

В вакансиях часто пишут «ориентированность на детали, перфекционизм». Они нужны, но только если правильно сфокусированы.

Умение структурировано думать и писать

Проведите мысленный эксперимент: представьте, что вам нужно описать, как тестировать центральный замок автомобиля. Вы начнёте писать, например, «открыть, закрыть», но есть же разные состояния: «открыть уже открытое», «закрыть уже закрытое», — или разные точки воздействия: можно открывать брелком, ключом, кнопками изнутри. А сигнализацию надо тестировать? А автоблокировку дверей на скорости? В тестировании существует ряд методик и техник, помогающих правильно разбивать тесты на группы, выстраивать правильную иерархию, проверять достаточность тестовых сценариев, но даже с ними важно уметь думать структурно.

Умение работать с большими объёмами данных и быстро учиться

В работе вам скорее всего понадобится навык работать с большими и плохо структурированными объёмами информациями (также известными как «спецификация», «техническое задание», «корпоративная база знаний»), быстро понимать как работает сложная (и не всегда логично написанная) система и быстро получать базовые знания в абсолютно разных областях. Если ваш проект про управление финансовыми портфелями — придётся разобраться в финансах, если про управление складом — в логистике и т. д. Хороший способ проверить себя — взять и успешно пройти какой-нибудь курс на coursera.com по незнакомому и фундаментальному предмету, желательно на английском.

Умение говорить с людьми на неприятные темы

Очень много и очень хорошо говорить.

Существует распространённый стереотип, что тестировщики и программисты недолюбливают друг друга как копы и федералы из американских фильмов. Это неправда.

В основном в IT все хорошо понимают ценность работы друг друга и относятся с уважением, прилететь может скорее за некомпетентность или халатность. Но вам всё равно придётся часто и много рассказывать людям, что нужно доработать то, что они сделали, или что шампанское лучше пока спрятать — продукт нельзя выпускать, есть проблемы. В критических ситуациях эти новости вы будете повторять несколько раз в день. Вас поймут, но вам самим будет тяжеловато. Нужно уметь не выгорать в таких ситуациях и быть максимально корректным.

Нужно уметь всё и сразу?

Итак, чтобы стать хорошим QA-инженером, нужно иметь активную склонность к технологиям, уметь встать на сторону пользователя, структурировать информацию и писать хорошие документы, а ещё нужно быть мастером переговоров.

Тут можно возразить, что я описываю явно не стартовую позицию. Это правда, но дела на рынке обстоят так, что к стартовым позициям в QA часто предъявляют требования на вырост. Есть распространённое мнение, что QA — такой лёгкий способ начать работать в IT, ничего не зная и не умея. QA-сообщество эту идею отвергает и может не на шутку оскорбиться за её озвучивание (см. первые два мифа тут), но есть нюанс.

На младших позициях (интерн — джун, первый год работы) тестирование — это работа, которая действительно скорее всего будет сложной, но не требующей большого объёма специальных навыков или знаний. А вот дальше уже сложнее, приготовьтесь много учиться.

Большинство компаний ищет людей, которые смогут перейти на этот следующий уровень и будут стараться отсеять людей, которым интересно «просто оказаться в IT». Либо они будут проверять мотивацию расти дальше именно в разрезе QA, либо знания, необходимые для перехода на следующую позицию. Поэтому и учиться имеет смысл на вырост.

Итак, что поможет, и где искать информацию?

1. Высшее образование, лучше техническое, но в принципе, любое. Высшее образование обычно развивает навык создавать в голове сложные структуры, работать с большими объёмами информации в сжатые сроки и делать много работы с отложенным результатом, иногда не самой интересной.
2. Книги, если читать их вдумчиво и пытаться применить знания на практике. Хорошее упражнение здесь — взять книжку Савина «Тестирование Дот Ком», а ещё словарь и силлабус ISTQB. Выбрать какой-нибудь портал или приложение, которое вы будете тестировать. Дальше читаете Савина, одновременно ищете определение всех терминов в словаре/силлабусе и пробуете всё описанное на практике. Кроме Савина хорошо бы почитать ещё:Стив Круг «Не заставляйте меня думать».Майкл Дж. Хернандес, Джон Вейскас «SQL-запросы для простых смертных. Практическое руководство по манипулированию данными в SQL».Карл Вигерс «Разработка требований к программному обеспечению».
3. Практика — краудтестинг, практикантские программы в разных IT-компаниях или домашний проект. Хорошо бы вместе с обучением тестированию начать разбираться и в программировании, сейчас довольно много хороших онлайн-курсов, часто бесплатных.
4. Интернет — есть много хороших ресурсов про тестирование или про IT в целом и тестирование в частности:Основной портал по QA и тестированию.Статьи на Tproger, посвящённые тестированию.Статьи на «Хабре», посвящённые тестированию.

Каждому Java-разработчику будет очень полезно понимать, что из себя представляет JVM, как в неё попадает код и как он исполняется. Статья больше подойдёт новичкам, но найти в ней что-то новое смогут и более опытные программисты. В статье вкратце описано, как устроен class-файл и как виртуальная машина обрабатывает и исполняет байт-код.

Основной задачей разработчиков Java было создание переносимых приложений. JVM играет центральную роль в переносимости — она обеспечивает должный уровень абстракции между скомпилированной программой и базовой аппаратной платформой и операционной системой. Несмотря на этот дополнительный «слой», скорость работы приложений необычайно высока, потому что байт-код, который выполняет JVM, и она сама отлично оптимизированы.

Рассмотрим схему работы JVM более подробно.

Структура class-файла

Напишем простейшее приложение и скомпилируем его. Компилятор заботливо создаст файл с расширением class и поместит туда всю информацию о нашем мини-приложении для JVM. Что мы увидим внутри? Файл поделён на десять секций, последовательность которых строго задана и определяет всю структуру class-файла.

Файл начинается со стартового (магического) числа: 0xCAFEBABE. Данное число присутствует в каждом классе и является обязательным флагом для JVM: с его помощью система понимает, что перед ней class-файл.

Следующие четыре байта class-файла содержат старший и младший номера версий Java. Они идентифицируют версию формата конкретного class-файла и позволяют JVM проверять, возможна ли его поддержка и загрузка. Каждая JVM имеет ограничение версии, которую она может загрузить — более поздние версии будут игнорироваться. Как видно на примере файла выше, у нас major версия 0x34, что соответствует Java SE 8. Для Java SE 11 будет значение 0x37.

С девятого байта идёт пул констант, в котором содержатся все константы нашего класса. Так как в каждом классе их может быть различное количество, то перед массивом находится переменная, указывающая на его длину, то есть пул констант представляет из себя массив переменной длины. Каждая константа занимает один элемент в массиве. Во всём class-файле константы указываются целочисленным индексом, который обозначает их положение в массиве. Начальная константа имеет индекс 1, вторая константа — 2 и т. д.

Каждый элемент пула констант начинается с однобайтового тега, определяющего его тип. Это позволяет JVM понять, как правильно обработать идущую далее константу. Всего зарезервировано 14 типов констант:

Например, если тег указывает, что константа является строкой, JVM получает значение тега 1 и обрабатывает следующее за тегом число как длину массива байт, которые необходимо считать, чтобы получить нужную нам строку полностью.

Прочитав блок с константами, JVM переходит к следующим двум байтам — флагам доступа, которые определяют, описывает этот файл класс или интерфейс, общедоступный или абстрактный, является ли класс финальным.

Имена класса и его родительского класса хранятся в массиве констант, на которые указывают последующие 4 байта в файле.

Немного иначе обстоят дела с интерфейсами. Так как класс может наследоваться от множества интерфейсов одновременно, то хранить необходимо массив ссылок на пул констант. То есть за определением класса и его родительского класса идёт число, характеризующее размер массива интерфейсов, и сам массив. Все возможные значения кодов представлены ниже.

Подобную структуру имеет и следующий блок — Fields.

Этот блок начинается с двухбайтового параметра количества полей в этом классе или интерфейсе. За ним идёт массив структур переменной длины. Каждая структура содержит информацию об одном поле: имя поля, тип, значение, если это, например, финальная переменная. В списке отображаются только те поля, которые были объявлены классом или интерфейсом, определённым в файле. Поля от родительских классов и имплементированных интерфейсов здесь не присутствуют, они задаются в своих class-файлах.

Далее мы переходим к самому важному месту в любом классе — его методам, именно в них сосредоточена вся логика любой программы, весь исполняемый байт-код.

Ситуация абсолютно аналогична описанным выше полям. В массиве переменной длины содержатся структуры, в которые входит полное описание сигнатуры метода: модификаторы доступа, имя метода и его атрибуты, которые также представляют из себя структуру, так как их может быть множество и каждый из них может принадлежать разным типам.

В последнем блоке идёт дополнительная мета-информация, например имя файла, который был скомпилирован. Она может присутствовать, а может и нет. В случае каких-то проблем JVM просто игнорирует этот блок.

Мы рассмотрели структуру файлов и готовы перейти к следующей части — загрузке class-файла в JVM и последующему выполнению байт-кода из этого класса. В качестве закрепления полученных знаний по структуре class-файла можете воспользоваться встроенным декомпилятором Java и посмотреть результат его выполнения с ключами -c -verbose (javap -c -verbose TestJava.class).

Загрузка классов

Теперь, разобравшись с общей структурой файла, посмотрим, как JVM его обрабатывает.

Чтобы попасть в JVM, класс должен быть загружен. Для этого существуют специальные классы-загрузчики:

1. Bootstrap — базовый загрузчик, загружает платформенные классы. Этот загрузчик является родителем всех остальных классов и частью платформы.
2. Extension ClassLoader — загрузчик расширений, потомок Bootstrap-загрузчика. Загружает классы расширений, которые по умолчанию находятся в каталоге jre/lib/ext.
3. AppClassLoader — системный загрузчик классов из classpath, который является непосредственным потомком Extension ClassLoader. Он загружает классы из каталогов и jar-файлов, указанных переменной среды CLASSPATH, системным свойством java.class.path или параметром командной строки -classpath.
4. Собственный загрузчик — у приложения могут быть свои собственные загрузчики.

Главный класс приложения всегда загружается системным загрузчиком, остальные же классы могут быть загружены различными пользовательскими загрузчиками. Стоит упомянуть, что имя загрузчика создаёт уникальное пространство имён, то есть в программе может существовать несколько классов с одним и тем же полным именем, если они обрабатывались разными загрузчиками.
Поэтому каждый загрузчик делегирует свои полномочия родителю, то есть перед поиском класса для загрузки он попытается узнать, не был ли загружен нужный класс раньше.

После загрузки класса начинается этап линковки, который делится на три части.

1. Верификация байт-кода. Это статический анализ кода, выполняется один раз для класса. Система проверяет, нет ли ошибок в байт-коде. Например, проверяет корректность инструкций, переполнение стека и совместимость типов переменных.
2. Выделение памяти под статические поля и их инициализация.
3. Разрешение символьных ссылок — JVM подставляет ссылки на другие классы, методы и поля. В большинстве случаев это происходит лениво, то есть при первом обращении к классу.

Класс инициализируется, и JVM может начать выполнение байт-кода методов.

JVM получает один поток байтовых кодов для каждого метода в классе. Байт-код метода выполняется, когда этот метод вызывается в ходе работы программы. Поток байт-кода метода — это последовательность инструкций для виртуальной машины Java. Каждая инструкция состоит из однобайтового кода операции, за которым может следовать несколько операндов. Код операции указывает действие, которое нужно предпринять. Всего на данный момент в Java более 200 операций. Все коды операций занимают только 1 байт, так как они были разработаны компактными, поэтому их максимальное число не может превысить 256 штук.

В основе работы JVM находится стек — основные инструкции работают с ним.

Рассмотрим пример умножения двух чисел. Ниже представлен байт-код метода:

На Java это будет выглядеть так:

По листингу выше можно заметить, что коды операций сами по себе указывают тип и значение. Например, код операции iconst_1 указывает JVM на целочисленное значение, равное единице. Такие байт-коды определены для самых часто используемых констант. Эти инструкции занимают 1 байт и введены специально для повышения эффективности выполнения байт-кода и уменьшения размера его потока. Подобные короткие константы также присутствуют и для других типов данных.

Всего JVM поддерживает семь примитивных типов данных: byte, short, int, long, float, double и char.

Если бы мы хотели положить в переменную а другое значение, например 11112, то нам пришлось бы использовать инструкцию sipush:

Данные операции выполняются в так называемом фрейме стека метода. У каждого метода есть некоторая своя часть в общем стеке. Таким образом в нашем главном потоке исполнения программы создаются множество подстеков на каждый вызов метода. Более наглядно это представлено на картинке ниже:

В каждом стек-фрейме хранится массив локальных переменных, который позволяет сохранять и доставать локальные переменные, как мы сделали в примере выше, поместив значения 1 и 5 в переменные 1 и 2. Стоить отметить, что здесь компилятор также оптимизировал байт-код, используя однобайтовые инструкции. Если бы переменных в нашем методе было много, использовался бы код операции сохранения значения вместе с указанием позиции переменной в массиве.

Чтобы достучаться до пула констант класса и получить нужное значение, используются инструкции lcd и lcd_w. При этом lcd может ссылаться только на константы с индексами от 1 до 255, поскольку размер её операнда составляет всего 1 байт. Lcd_w имеет 2-байтовый индекс, поэтому может ссылаться на более широкий диапазон индексов.

Вызовы методов

Java предоставляет два основных вида методов: методы экземпляра и методы класса. Методы экземпляра используют динамическое (позднее) связывание, тогда как методы класса используют статическое (раннее) связывание.

Виртуальная машина Java вызывает метод класса, выбирая его на основании типа ссылки на объект, который всегда известен во время компиляции. С другой стороны, когда виртуальная машина вызывает метод экземпляра, она выбирает метод для вызова на основе фактического класса объекта, который может быть известен только во время выполнения. Поэтому для вызова методов используются разные инструкции: invokevirtual и invokestatic. Данные функции ссылаются на запись в пуле констант в виде полного пути к необходимой функции. Виртуальная машина снимает нужное количество переменных со стека и передает в метод.

Возвращаемое методом значение кладётся на стек. Типы возвращаемых значений методов указаны ниже:

Циклы

Осталось рассмотреть последнюю часто используемую конструкцию языка — циклы. Посмотрим, во что превратится код, представленный ниже:

Байт-код:

Каждый раз на стеке оказывается два числа, которые сравниваются, и если i > 9999, происходит выход из цикла. При этом для создания цикла используется конструкция на основе goto, которая запрещена в самом языке Java, хотя ключевое слово и зарезервировано.

Заключение

Изначально байт-код интерпретируется в большинстве JVM, но как только система замечает, что некоторый код используется очень часто, она подключает встроенный компилятор, который компилирует байт-коды в машинный код, тем самым значительно ускоряя работу приложения.

Таким образом, мы поверхностно рассмотрели жизненный цикл байткода в JVM: class-файлы, их загрузку и выполнение байт-кода и базовые инструкции.

За расцветом ICO в 2017 году, который сейчас часто сравнивают с «бумом доткомов», последовал стремительный спад интереса инвесторов к этой форме привлечения средств. Это вызвано высокими рисками ICO, ведь в большинстве стран мира отсутствует правовое регулирование этой сферы. Интересы инвесторов никак не защищены, правовое положение цифровых активов законодательно не определено, а отношение регуляторов продолжает оставаться скептическим. Поэтому ICO как способ привлечения инвестиций всё больше уступает STO (security token offering).

Security token offering: подходы и риски

В случае с STO статус цифровых активов определён точнее, так как размещаемые токены по характеристикам схожи с ценными бумагами, которые имеют достаточно развернутое правовое регулирование.

Тем не менее, STO и сегодня воспринимается с долей осторожности, т. к. ни в одной стране мира нет системного законодательного регулирования размещения секьюрити-токенов, которое основывалось бы на продолжительной правоприменительной практике. Но несмотря на недоверие регуляторов и участников рынка к криптоактивам, в некоторых странах стараются решить эту проблему на государственном уровне. Ведь национальное законодательство можно привести в соответствие с современными технологиями, чтобы привлечь в экономику новые инвестиции.

Blockchain-остров: новое законодательство Мальты об STO

ICO и STO используются в основном в стартапах, связанных с IT, поэтому на Мальте недавно приняли закон о создании специализированного государственного органа — Malta Digital Innovation Authority (MDIA). Он занимается регулированием и контролем рынка STO как «особой» области современной экономики. MDIA устанавливает процедуры, которые необходимо соблюдать эмитентам токенов и тем, кто взаимодействует с участниками рынка.

Другим законом Мальты — Virtual Financial Assets Act (VFAA) — регулируются вопросы, непосредственно относящиеся к процедуре проведения STO. Закон выделяет следующие виды DLT-активов:

1. Виртуальный токен — токен, ценность и применение которого ограничены приобретением товаров или услуг. Он используется исключительно на платформе или в сети платформ, на которой был выпущен.
2. Финансовый инструмент. Перечень активов, подпадающих под это понятие, указан в Законе Мальты об инвестиционных услугах (Investment Services Act) и включает в себя перечисленные в законе ценные бумаги, производные инструменты, инструменты денежного рынка и иные прямо предусмотренные законом активы.
3. Электронные деньги.
4. Виртуальный финансовый актив. В соответствии с законом VFAA, под виртуальным финансовым активом понимается цифровая запись в любой форме, которую используют в качестве средства расчёта или накопления. При этом она не может быть виртуальным токеном, финансовым инструментом или электронными деньгами.

В случае если DLT-актив подпадает под последнюю категорию, эмитент актива, желающий провести его размещение (Initial VFA Offering), должен получить лицензию в специализированном государственном органе — MFSA (Управление финансовых услуг Мальты). Для получения такой лицензии необходимо обратиться к VFA-агенту — лицу, зарегистрированному в MFSA и уполномоченному осуществлять взаимодействие между заявителями и MFSA. Также агент проверяет, соответствует ли заявитель установленным законом требованиям.

Помимо регулирования процедуры Initial VFA Offering, закон VFAA устанавливает требования к whitepaper. Документ должен быть датирован, содержать все пункты, изложенные в специальном приложении к закону, а также заявление совета директоров с подтверждением соответствия требованиям VFAA. Текст whitepaper должен быть составлен на английском языке (перевод на иные языки возможен, но не обязателен). Кроме того, в дальнейшем любые предлагаемые в ходе размещения условия должны соответствовать whitepaper.

STO по законодательству Эстонии

В настоящий момент Эстония является одной из наиболее популярных стран для проведения ICO. Это не в последнюю очередь связано с тем, что государство старается обеспечить комфортные условия для предпринимательства в целом. Например, упрощает процедуру регистрации компании, уплаты налогов и т. п. Также это связано с относительно проработанным подходом государства к криптоактивам и возможностью просчитывать плюсы и минусы выхода на ICO в рамках данной юрисдикции.

В соответствии с рекомендациями, опубликованными Финансовой инспекцией Эстонии (Estonian Financial Supervision Authority — EFSA), первоочерёдным для ICO является анализ прав, предоставляемых токенами. Необходимо определить, считаются ли они ценными бумагами в соответствии с законом о рынке ценных бумаг. Токены признаются таковыми в случае, если они могут быть переданы на основании одностороннего волеизъявления либо если они предусматривают для участника право голоса или ожидаемую прибыль в отношении своих инвестиций.

Если токены признаны ценными бумагами, необходимо определить, является ли их размещение публичным. Закон Эстонии о рынке ценных бумаг предусматривает ряд случаев, когда размещение публичным не является (предложение только для квалифицированных инвесторов, имеющее ограничение по сумме и т.п.). Если размещение не подпадает под данный перечень, оно признаётся публичным и должно соответствовать установленным требованиям. В таком случае, в зависимости от вида ценной бумаги, необходима подготовка и регистрация в EFSA проспекта предложения. Регистрация проспекта, как правило, занимает от трёх до шести месяцев. За нарушение требований о регистрации проспекта эмиссии законодательство Эстонии предусматривает ответственность вплоть до уголовной. Также размещение токенов в ряде случаев может подпадать под действие законов о кредитных учреждениях и об инвестиционных фондах. В таком случае компании-эмитенту необходимо иметь специальные лицензии и разрешения. Кроме того, при определённых условиях разрешение для инвестирования в токены-ценные бумаги требуется и для инвестора.

В рекомендациях отмечается, что эмитенту необходимо соблюдать общие нормы о рекламе и не вводить людей в заблуждение в отношении характеристик товара или услуги.

Заключение

В целом действующее законодательство Мальты и Эстонии, несмотря на декларируемый «дружественный» статус по отношению к криптоактивам, выдвигает достаточно серьёзные и не всегда легко реализуемые требования к ним. Вместе с тем, процедура размещения прописана подробно и понятно. Это позволяет эмитенту составить представление о юридических рисках и быть относительно уверенным в том, что у государственных органов в будущем не будет претензий. Также это позволит планировать затраты финансов и времени, что не всегда возможно в большинстве юрисдикций, которые, не имеют развернутого правового регулирования процедуры ICO/STO.

Классический контракт — это устное или письменное соглашение с набором условий. В современном мире выполнение условий контракта гарантирует государство. Если одна из сторон не соблюдает условия соглашения, суд определит правонарушителей и обяжет их нести ответственность. Такие контракты постоянно встречаются в быту: при аренде квартиры, страховании автомобиля или трудоустройстве.

С классическими контрактами связаны и трудности. Составлять текст документа должен специалист, иначе в условиях соглашения могут остаться пробелы и неточности. Юристы любят использовать профессиональную лексику, которую тяжело понять обычному человеку. Ещё один важный нюанс — наличие судьи, который разрешает споры между сторонами соглашения. К тому же, само по себе судебное разбирательство требует времени и денег.

До определённого момента такой формат соглашений оставался наилучшим.

Что такое смарт-контракт?

С переходом к цифровым методам общения, хранения и обработки информации появился фундамент для новой формы контрактов. В 1996 году Ник Сабо разработал концепцию самоисполнимых цифровых контрактов. Автор назвал их «смарт-контракты» (от англ. smart contract — умный контракт). Согласно определению Ника Сабо, смарт-контракт — это набор описанных в цифровой форме обещаний, включающий набор протоколов, по которым стороны выполняют свои обещания.

В отчёте Сената США за 2018 год сказано:

Термин «смарт-контракт» может звучать по-новому, но сама концепция уходит корнями к базовому договорному праву. Обычно судебная система выносит решения по договорным спорам и обеспечивает выполнение условий соглашения, но имеют место и другие арбитражные методы, особенно для международных транзакций. В случае со смарт-контрактами программа сама исполняет контракт, встроенный в код

Оригинальный пример прообраза смарт-контракта из работы Ника Сабо — торговый автомат. Человек опускает в автомат монету, и автомат выдаёт напиток или шоколадку. Это взаимодействие — сделка, которая подразумевает покупку товара за установленную сумму. Отличие этой ситуации от классического контракта в том, что автомат самостоятельно выполняет условия сделки: если прошла оплата, механизм выдаёт товар.

Чтобы система была безопасной, максимальная сумма средств в автомате не должна превышать затраты на взлом.

Смарт-контракты на блокчейне

Реальное практическое применение смарт-контрактам нашлось с появлением технологии блокчейн. Децентрализованные системы на основе блокчейна — та среда, в которой выполнение смарт-контракта не зависит от третьего лица, а его код нельзя произвольно изменить. Вне такой среды смарт-контракт будет просто программным кодом.

Важный параметр смарт-контракта на блокчейне — полнота по Тьюрингу. Простыми словами, полнота по Тьюрингу — это возможность системы выполнить любую вычислимую функцию. То есть Тьюринг-полной будет система, которая может выполнить любую компьютерную программу.

Блокчейн Bitcoin использует неполный по Тьюрингу язык программирования Script. Bitcoin поддерживает простые смарт-контракты с мультиподписью (для выполнения действия нужны цифровые подписи нескольких участников), удержанием средств на установленное время и так далее.

Блокчейн Ethereum работает со смарт-контрактами на Тьюринг-полном языке программирования Solidity. Solidity позволяет создавать более сложные алгоритмы, но такие смарт-контракты гораздо сложнее проверить на наличие уязвимостей.

Разработчик и популяризатор блокчейн-технологий Джимми Сонг отметил:

Выполнение кода в Тьюринг-полном контексте — хитрая штука, которую тяжело анализировать. Обезопасить Тьюринг-полный смарт-контракт так же сложно, как доказать, что в компьютерной программе нет багов.

Кроме Bitcoin и Ethereum, существуют специализированные платформы для работы со смарт-контрактами: Aeternity, EOS, Hyperledger Fabric, Stellar и другие. Такие платформы отличаются от названных выше пропускной способностью и стоимостью обработки транзакций, алгоритмом консенсуса и позиционированием.

Зачем нужны смарт-контракты?

С одной стороны, смарт-контракт — это просто программный код, обычное приложение как калькулятор, мессенджер или видеоигра. С другой стороны, смарт-контракт — это фундаментальный элемент любого распределенного приложения (distributed application или DApp), которое работает в среде без доверия и централизованной власти вроде администратора веб-сайта или государства. То есть смарт-контракт исполняет всё тот же программный код, но этот код нельзя произвольно изменить или воспрепятствовать его исполнению без вмешательства в работу всей сети. Это базис для любого децентрализованного приложения, особенно если имеет место обмен ценностями: деньгами, товарами, правами.

В централизованной платежной системе вроде гигантов Visa и Mastercard есть администрация, которая разрешает возможные споры, поддерживает работу серверов и взимает комиссию с платежей. Администрация может блокировать неугодные ей транзакции или перенаправить платёж на собственный счёт. Репутация системы пострадает, а администрацию такой компании будут преследовать по закону за мошенничество, но с технической точки зрения ничто не мешает таким манипуляциям. В децентрализованной системе ни у кого нет такой власти, а смарт-контракт подчиняется только заранее заложенным в него правилам.

Где можно применять смарт-контракты?

Согласно анализу Deloitte 2016 года, клиринг в торговых операциях и цепочки поставок — первые кандидаты на внедрение смарт-контрактов. Среди других перспективных областей исследователи назвали здравоохранение, страхование, медиаиндустрию, энергетику, ведение архивов и голосование.

Клиринг

Это безналичные расчёты между сторонами за товары, услуги или ценные бумаги с учётом взаимных обязательств. Клиринг подразумевает множество согласований между банками и юридическими или физическими лицами. Клиринговой компании нужно учесть все взаиморасчёты между клиентами, чтобы минимизировать движение денег между счетами и сумму комиссий за переводы.

Например, если Алиса должна заплатить Бобу 100 $ за ремонт компьютера, Боб должен заплатить Крису 150 $ за юридические услуги, а Крис должен заплатить 100 $ Алисе за дизайн сайта, всё, что нужно сделать, — перевести 50 $ от Боба Крису, и все будут в расчёте. Именно такими взаиморасчётами и их оптимизацией занимаются клиринговые компании, только в большем масштабе.

В реальном мире такая деятельность связана с комплексным документооборотом и ведением учёта множества сущностей и транзакций. Это дорого и долго, а из-за сложности процесса возникают ошибки и дополнительные задержки. Клиринговые компании и их клиенты могут использовать блокчейн-реестр для учёта транзакций и взаимных обязательств, а система смарт-контрактов обеспечит автоматическое проведение платежей и фиксацию данных в распределённом реестре. Согласно исследованиям Santander InnoVentures, к 2022 году внедрение блокчейна и смарт-контрактов может снизить ежегодные инфраструктурные затраты на 15–20 миллиардов долларов США.

Цепочки поставок

Смарт-контракты и блокчейн — актуальное решение для обслуживания цепочки поставок от сырья до готовых продуктов. Чаще всего сопроводительная информация для каждого из этапов хранится в отдельных базах данных, а бумажные документы до сих пор приходится пересылать физически. Чтобы собрать один ноутбук, кому-то нужно добыть нефть и металлы, из которых кто-то сделает пластиковый гранулят и нужные сплавы, которые впоследствии превратятся в детали и попадут в сборочный цех. На каждом из этапов нужно передавать и подписывать документы, высылать счета, переводить деньги и т. д. Всю эту информацию можно объединить в одном реестре, чтобы всем сторонам были доступны документы, история транзакций и поставок. Смарт-контракты позволят автоматически распределять платежи после согласования и получения нужных цифровых подписей. Кроме того, в цепочку поставок на блокчейне значительно проще добавлять новых участников вроде поставщиков и перевозчиков.

Здравоохранение

Блокчейн и смарт-контракты позволят создать единый безопасный реестр медицинских записей. Учитывая деликатность информации, доступ к записям можно ограничить смарт-контрактом с мультиподписью: если пациент и его лечащий врач согласны показать информацию другому специалисту, они поставят цифровые подписи и система откроет доступ указанному человеку. Объединение в один реестр поможет вести научные исследования и анонимные опросы, а если учёные решать наградить тех, кто делится информацией, смарт-контракты — оптимальный способ обеспечить выплату по факту передачи информации.

Интернет вещей

В интернете вещей (Internet of Things, IoT) безопасность и неизменяемость блокчейн-реестра вместе с возможностями смарт-контрактов позволят наладить прозрачные механизмы взаимодействия и обмена ценностями между гаджетами вроде умных холодильников, смартфонов, термостатов и автомобилей. Умный электромобиль может одной транзакцией инициировать оплату за электричество и смарт-контракт активирует зарядное устройство. Права владения этими гаджетами тоже можно фиксировать в блокчейне, а значит, пользователь сможет продать или подарить устройство не покидая блокчейн-сети и без привлечения третьих лиц.

Медиаиндустрия

Для правообладателей и создателей контента актуальна проблема роялти — платы за использование интеллектуальной собственности. Здесь смарт-контракты можно использовать для прозрачного распределения средств.

То же самое относится и к другим областям, где нужно обеспечить учёт и прозрачное проведение платежей без доверия между сторонами: страхованию, энергетике и так далее. Для голосования и ведения государственных архивов блокчейн и смарт-контракты — возможность оптимизировать доступ к данным и авторизацию участников, будь то архив земельного кадастра или избирательный процесс.

Проблемы смарт-контрактов

Оракулы

Одна из основных технических преград полномасштабному внедрению блокчейн-реестра и смарт-контрактов — необходимость создать эффективные и надёжные оракулы. Оракулы — это внешние агенты, которые отвечают за достоверность предоставленной информации извне.

Блокчейн-реестр — изолированная среда, внутри которой с помощью криптографических доказательств и протоколов консенсуса все участники могут проверить истинность тех или иных данных. Но для широкого применения этим системам нужно получать информацию из внешнего мира: подтверждать факт получения товара, идентифицировать участников, получать биржевые сводки и так далее. Такая информация поступает в систему через оракулы.

Оракулами могут быть:

• измерительные приборы вроде термометра или датчика освещенности;
• конкретные участники сети, которые оказывают услуги блокчейн-системе;
• децентрализованные системы с собственными механизмами консенсуса, построенные поверх основного реестра.

В некоторых случаях, как в блокчейне Aeternity, оракулы интегрированы с основным блокчейном и работают в рамках одного механизма консенсуса с остальной сетью. Пользователи сети посылают оракулам запросы посредством транзакций на блокчейне, а оракулы отвечают им соответствующей он-чейн транзакцией. Вопрос и ответ остаются в реестре, а остальные пользователи могут сверяться с этими данными.

Юридическая сила

Другая проблема — необходимость в новой регуляторной среде, которая учитывала бы возможности блокчейна и определила юридическую силу смарт-контрактов и внесенных в реестр данных, таких как права владения недвижимостью или предметами.

Недоверие к блокчейну

Блокчейн-технологии развиваются уже около десяти лет, если считать точкой отсчёта whitepaper Bitcoin, но в сравнении с другими технологиями и методиками, задействованными в современной финансовой системе, блокчейн остается молодой и не до конца зарекомендовавшей себя технологией. Из-за этого консервативные участники рынка относятся к нему скептически.

Выводы

Уже сейчас многие традиционные банки и ведомства экспериментируют с блокчейн-технологиями и смарт-контрактами и инвестируют в проекты в этой отрасли. По мере того, как проекты вроде Augur, Aeternity и Oraclize решают проблему оракулов и совершенствуют технологию, всё больше государственных структур и бизнесов будут внедрять распределённый реестр и смарт-контракты для оптимизации своей работы и прозрачного учёта.

Смарт-контракты уже сейчас могут заменить значительную часть существующего документооборота. Любые типовые соглашения о страховании или передаче имущества можно реализовать как смарт-контракты. Однако для нестандартных случаев традиционные контракты останутся основным элементом соглашения. В роли базиса для распределённых приложений и аналога обычной компьютерной программы для распределённой среды смарт-контракты скорее всего будут использоваться практически повсеместно.

Цифровая трансформация, новые возможности digital-инструментов и архитектуры современных ИТ-систем создают парадигму современных технологий (New IT — так называет её компания Accenture). Она включает в себя самые продвинутые технологии (облака, ИИ, аналитику данных, машинное обучение и т. д.) и процессы (Agile, DevOps и Design Thinking), а также подразумевает несколько стадий трансформации сложной ИТ-инфраструктуры крупных компаний. Одним из первых шагов к её реализации становится адаптация слоя ИТ-микросервисов на базе существующих legacy-платформ.

В статье рассказываем, как работать с микросервисами, поддерживая развитие старой ИТ-инфраструктуры и создавая гибкость её новых элементов в максимально эффективном ключе.

Микросервисы для большого ИТ-будущего

Термин «микросервисная архитектура» (Microservice Architecture) обрёл популярность в последние несколько лет. Это способ разработки приложений через объединение независимо развёртываемых ИТ-сервисов. Такой подход позволяет построить вокруг сложившихся бизнес-процессов и потребностей автономный сервис. Благодаря использованию стандартных протоколов взаимодействия, например HTTP-вызовов через API и брокеров сообщений, микросервисы могут быть написаны на разных языках программирования и использовать различные технологии хранения БД.

При традиционном подходе к созданию ИТ-системы по принципу «монолита» управление больше фокусируется на технологиях. Команды формируются по технологическому принципу — разработчики, администраторы БД, аналитики данных и т. д. Такой подход вызывает серьёзные трудности при реализации бизнес-функциональности в ИТ-систему, поскольку их нужно производить через кросс-командное взаимодействие.

Микросервисы позволяют формировать независимые (agile) кросс-функциональные команды с фокусом на определённой бизнес-задаче вместо технологии. Такие команды самодостаточны, хорошо сфокусированы, используют те подходы и технологии, которые максимально эффективны в конкретном случае и позволяют переключиться с «проектного управления» на «продуктовое».

В микросервисах каждый элемент выполняет только одну функцию и может быть независимо от других сервисов «донесён до production», поэтому, чтобы внести изменения в решение, не нужно перестраивать весь алгоритм. Если возникает необходимость в обновлении, перестройке, отладке и других коррективах, то достаточно осуществить их на конкретном участке ИТ-системы. Например, если необходимо добавить новый способ доставки или оплаты на сайте интернет-магазина, для этого достаточно внести изменения в один модуль.

В реальности добавление новой функции или процесса так или иначе затрагивает остальные, но принцип микросервисной архитектуры позволяет выпускать готовые релизы в разное время и даёт каждой команде возможность работать в собственном ритме. То есть параллельно могут разрабатываться две функциональности, например поиск и способы доставки, при этом изменения в одном могут происходить хоть каждый день, а изменения в другом требуют больше времени — например из-за того, что релиз должен быть синхронизирован с запуском бизнес-процессов. В рамках микросервисного подхода на это уходит примерно одна неделя с выводом в фазу production.

По сути, микросервисы — это слой между существующей ИТ-инфраструктурой и клиентской частью интерфейса. Его можно с успехом применять практически в любой области и для решения самых разнообразных задач. Также при выборе стратегии ИТ-развития компании в пользу полного отказа от «коробочного» подхода, микросервисы могут стать надёжным и эффективным ядром новой digital-платформы для успешного роста бизнеса в 21 веке.

6 главных преимуществ микросервисной архитектуры

1. Новое качество масштабируемости. При возникновении соответствующей потребности не нужно масштабировать всю систему, разбирая её до основания, — достаточно внести необходимые изменения только на определённом участке.
2. Повышение стабильности. Поскольку микросервисы независимы друг от друга, сбои и дефекты в одном из них никак не влияют на работу остальных, система функционирует с минимальными сбоями и простоями.
3. Упрощение. Вместо единого и сверхсложного массива ИТ, компании работают с более управляемой архитектурой, где каждый компонент отвечает за свою функцию.
4. Мультиплатформенность. Микросервисы могут работать на любом устройстве, а также в on-premise и облачных средах.
5. Повторное использование. Микросервисы могут перепрофилироваться для других целей и задач после начального запуска.
6. Возможность использовать разные технологии. Agile-команды в компаниях могут работать как небольшие стартапы, не ограничиваясь одной определённой платформой или технологией благодаря микросервисам. Через микросервисы организации могут объединять различные технологии для создания действительно лучшего из всех возможных решений на настоящий момент, что значительно ускоряет внедрение инноваций.

Трудности внедрения микросервисов

По сравнению с «монолитами» микросервисы открывают следующий уровень гибкости операций через создание новых бизнес-процессов вокруг уже существующих legacy-систем. Именно поэтому сегодня многие нацелены на микросервисную трансформацию — её преимущества слишком очевидны.

Однако существует ряд подводных камней при реализации такого перехода.

Сохранение целостности компании

Главный вызов — не утратить полезные наработки, накопленные данные и опыт прошлых лет, сохранив капитальные инвестиции в ИТ-инфраструктуру прошлого поколения. То есть компания должна ускорить своё развития и «не развалиться» в процессе трансформации к современному подходу.

Большое количество микросервисов

Когда компании необходимо 10–20 микросервисов, их адаптацией и развитием управлять не так сложно. Но если организация требует для своих задач внедрения 100+ микросервисов, появляется ранее не существовавший класс задач. Как избежать дублирования функциональности, сохранить масштабируемость и управляемость, а также не допустить превращения новой архитектуры в такой же монолит, от которого изначально пытались уйти?

Для организаций эти вызовы и их различные формы и складываются в современное IT, когда от подхода «строим то, что позволяет система» делается качественный скачок к «развиваем систему таким образом, чтобы у нас появлялись новые возможности для перестройки бизнеса». Компания, которая осознаёт необходимость адаптации микросервисов, нацеливается не на рост прибыли, трафика и других количественных KPI, а на глубинные изменения, при которых рост KPI — органическое следствие общей трансформации.

Баланс гибкости и хаоса

Третья проблема микросервисов — высокий уровень гибкости при работе над развитием платформы. Это необходимое условие микросервисного подхода, но если его не контролировать, резко возрастает риск развития хаоса в архитектуре системы. Разобраться в принципах устройства такого «хаоса», возникшего в рамках работы по микросервисным проектам, — зачастую отдельный ИТ-проект. Правильнее с самого начала работы ограничить рамки, пусть даже это немного отложит выпуск первой функциональности, чтобы потом не потратить несколько месяцев на демонтаж «окаменелостей» из микросервисов.

Переход к микросервисам в рамках концепции enterprise agility — это также вопрос корпоративной культуры, которая помогает сохранять необходимый баланс свободы и контроля.

Свободное творчество и практический эффект совместимы только при культурных сдвигах в работе компании. Архитектура, процессы, персонал — все необходимые факторы для развития микросервисов должны выстраиваться в комплексе.

Время и результаты

Перевод ИТ-ландшафта организаций на новую архитектуру не происходит за одну ночь. Как раз наоборот, иногда для этого требуется довольно длительное время, в каких-то случаях — целые годы. Мало какие вещи в современном мире настолько же сложны, как современные ИТ-системы, адаптированные к бизнес-моделям компаний, а также конкретные способы их привязки друг к другу. Тем не менее, несмотря на общую трудоёмкость демонтажа legacy-систем, полагаться на «олдскульные» ИТ в эпоху, когда парадигма New IT развивается семимильными шагами, — значит обрекать бизнес на медленную агонию. Отсюда и вытекает потребность в микросервисной архитектуре.

Продвинутые микросервисные архитектуры в их образцовом исполнения представлены сегодня в таких компаниях, как Google, Amazon и Netflix. Так, Amazon вносит изменения в свои продукты каждые 11,6 секунд, а Netflix постоянно проводит выборочные отключения вычислительных узлов для проверки влияния подобных аварий на общее качество продукта, получаемого абонентами.

Очевидно, что более консервативным организациям подобный переход только предстоит осуществить. Они совмещают старую архитектуру и новейшие подходы к развёртыванию приложений, что в терминологии Gartner называется Bimodal IT — что-то вроде переходной фазы, сочетающей элементы legacy и современных IT-систем.

Между тем, в последующие 10–20 лет legacy-модели должны быть полностью заменены на новейшие решения компаниями, которые хотят сохранить свою конкурентоспособность. В этой перспективе микросервисы и монолитные системы могут сосуществовать как привитая ветвь и ствол дерева, на котором ей предстоит прорасти и в будущем заменить собой отмирающую основу. Такой подход позволяет гарантировать, что корневая система останется незатронутой и медленно, но верно, перейдёт от старого владельца (legacy-систем) к новому (микросервисы и парадигма New IT).

Начинающим предпринимателям кажется, что самое сложное — запуск стартапа. На самом деле, основные трудности связаны с ростом. Только одна компания из девяти выходит на устойчивый рост и становится прибыльной, подсчитали аналитики из Bain & Co. 85 % руководителей компаний-неудачников признают, что причиной кризиса были не действия конкурентов, а внутренние проблемы.

Сценарии кризиса

В разных стартапах кризис роста проявляется по-разному. Можно выделить три основных сценария: перегрузка, стагнация и падение. Перегрузка обычно вызвана недостатком управленческого опыта у основателей, которые слишком многое на себя берут. По данным Startup Genome Report, 74 % интернет-стартапов закрываются из-за слишком быстрого масштабирования и раздутого штата. В результате страдает качество сервиса и компания теряет клиентов. Чтобы справиться с таким кризисом, стартапу нужно сосредоточиться на внутренних коммуникациях и стандартах, упростив систему управления и повысив качество продукта.

Стагнации подвержены как молодые стартапы, так и устоявшиеся компании. В какой-то момент руководители теряют связь с реальностью, перестают чувствовать рынок, после чего компания уже не может оправдать доверие клиентов. Когда с таким кризисом столкнулась Cisco, компания сократила время разработки продуктов и вывела на рынок новые решения в области виртуализации, что позволило ей ответить на вызовы со стороны Amazon, Huawei и других конкурентов. Netflix, занимавшийся когда-то рассылкой DVD по подписке, успел пересмотреть стратегию, сосредоточившись на стриминговом сервисе и создании собственного контента — в результате его доход приблизился к $16 млрд.

Еще один сценарий кризиса, падение, может быть обусловлен как внутренними (например пересмотр бизнес-модели или вывод на рынок нового продукта), так и внешними причинами (например появление сильного конкурента или революционной технологии). Классический пример выхода из падения — возвращение в Apple Стива Джобса, который возродил в забуксовавшей компании дух стартапа, сократил перегруженную продуктовую линейку и вывел новые продукты. Обратный пример — Nokia, которая потеряла лидерство на рынке из-за неспособности развиваться и реагировать на действия конкурентов.

Сохранить дух стартапа

В отличие от состоявшихся компаний с прочной корпоративной структурой, успехи и неудачи стартапа в основном связаны с личностью основателей. Исследование Bain & Co. показало, что руководители чаще всего называют причиной неудач недостаток ресурсов, невозможность сфокусироваться и организационную запутанность.

Чтобы преодолеть кризис роста, основателю (или команде фаундеров) прежде всего нужно заметить эти симптомы и найти способ их преодолеть. Хорошо, если основатели смогут расти вместе со своим стартапом, но чаще они начинают тормозить его развитие, отказываясь адаптироваться к меняющимся условиям. Среди компаний, которые преодолели кризисы роста, сохранив при этом дух стартапов и ментальность своих основателей, — Google, IKEA и AB InBev. К примеру, пивоваренная корпорация AB InBev не тратит деньги на шикарные офисы и предпочитает нанимать молодых сотрудников.

Найти ментора

Эффективный способ справиться с кризисом роста — расширить управленческую команду, пригласив опытного менеджера, который будет не просто отрабатывать зарплату, а искренне «болеть» новым бизнесом. Бурный рост российского образовательного стартапа SkyEng начался после того, как к команде присоединился Александр Ларьяновский с опытом работы в Яндексе и других крупных компаниях.

Привлечь инвестиции

Мощным импульсом для развития стартапа становится привлечение финансирования. Привлечь внимание потенциальных инвесторов можно на хакатонах, конференциях и конкурсах стартапов.

Чтобы не спровоцировать кризис, нужно искать инвесторов, которые понимают корпоративную культуру стартапа и готовы не только вкладывать в него деньги, но и делиться своими компетенциями. Больше шансов найти такого «старшего брата» не из числа венчурных инвесторов, для которых стартап будет одним из множества проектов, а в среде индустриальных инвесторов, которые будут помогать молодой компании развиваться.

Кризис как путь в будущее

Путь к успеху для любого стартапа будет тернистым. В истории бизнеса не было примера компаний, которым удалось бы избежать кризисов в процессе развития. При этом часто именно от руководителей зависит, сможет компания выбраться из кризиса и продолжить развиваться или встретит бесславный конец. Для успешных руководителей компаний характерны готовность к изменениям, смелость в принятии решений и способность учиться.

Рассказывает Иван Бируля, директор по безопасности «СёрчИнформ»

Есть такой класс решений в информационной безопасности — DLP-системы, которые защищают от утечек информации. Любая подобная система должна быть очень умной: контролировать максимум каналов передачи информации, которыми пользуется человек на рабочем месте (от электронной почты до файлообменников) и уметь эту информацию анализировать.

Уважающие себя коллеги по цеху умеют это делать, мы тоже. Но отрасль хочет новых возможностей. В идеале — прочесть мысли человека за рабочим компьютером, и если он оказался зловредным инсайдером — запустить сигнал тревоги. В сфере это называется «прогнозировать пользовательское поведение».

Часть вендоров в этой «гонке вооружения» пошли по пути развития технологий UEBA или UBA. Правда пока это совсем не то, чего хочет заказчик. По сути это комплекс статистических отчётов, и они предполагают большое количество ложноположительных реакций. В итоге главная задача — автоматизация человеческого труда — не выполняется. Сотрудник ИБ-службы получает сигнал, что, мол, поведение пользователей вдруг резко изменилось: болтают в мессенджерах, работают непродуктивно, шлют сотни писем. Потирает было руки, что обнаружил супер-инцидент, а оказывается, что один из менеджеров пришёл на работу в сильном подпитии, и весь коллектив это событие дружно обсуждает.

Так что волшебной кнопки «найти инсайдера» пока не вышло, а все технологии, которые предъявляются на многочисленных профильных конференциях, существуют на уровне концепта.

Мы как разработчики DLP-систем, конечно, тоже мечтали эту кнопку создать. Как подступиться к этой задаче, подсказал случай.

Внимание — «чёрный ящик»

Однажды меня попросили выступить на конференции, где я рассказал, как использую специальный метод диагностики сотрудников — профайлинг. Эту методику используют израильские спецслужбы и сотрудники аэропортов, чтобы быстро и с минимальными ошибками выявлять возможных нарушителей. Аудитория живо отреагировала и предложила провести «следственный эксперимент». Глава «СёрчИнформ» Лев Матвеев открыл переписку в Skype и предложил по ней описать сотрудника. Я продиагностировал сотрудника как эгоцентричного и самовлюбленного, ярко выраженного истероида. Профилирование попало в цель.

Метод признали жизнеспособным и… сложным в реализации. Ведь где на каждую компанию найти столько профайлеров, особенно если в ней не десятки или сотни, а тысячи сотрудников?

Но мы не отказались от идеи: появилась гипотеза, что профилирование — и есть тот инструмент анализа пользовательского поведения, который ожидали увидеть ИБ-специалисты. Рассуждали так: если самый значимый ресурс для профайлинга — речь, в которой человек проявляет характер и особенности личности, то почему бы не взять накопленную в DLP-системе переписку в качестве «сырья» для анализа? Эту идею мы и стали развивать в проектной группе.

Слова — в код

«Я участвовал в трёх проектах по оцифровке опыта человека и сам руководил одним. Только мы занимались оцифровкой не текста, а эмоций и голоса. Тогда у нас не было достаточного материала для правильного анализа. Его тогда вообще ни у кого не было, поэтому мы продвигались медленно, тоскливо и почти безрезультатно, — вспоминает научный руководитель направления профайлинга Алексей Филатов. — Получив приглашение присоединиться к работе над автоматизацией профайлинга, я подумал, почему бы не вложиться мозгами и знаниями. Анализ текста в профайлинге в целом хорошо разработан, текста для анализа было более чем достаточно и в компании понимали, как с ним работать. Я понял, что на этот раз всё может получиться».

Опыт, репутация и связи Алексея Филатова в профессиональных кругах позволили генерировать и проверять идеи по автоматизации вместе с коллегами и соратниками, посвятившими психолингвистике десятилетия научной карьеры.

Филатов отверг первоначальное предположение о том, что под каждый психотип нужно сформировать лексический словарь. По значимости анализа словарь — точно не первый и даже не второй фактор. Придя в команду, он сформировал новый подход, в котором гораздо более важным было не что говорит человек, а как: какие части речи использует, как составляет фразы, какую применяет морфологию и т. д.

Таким образом было сформировано техническое задание для разработчиков. В общем виде: им нужно было создать такой алгоритм, который бы вытаскивал из письменной речи значимую информацию, очищая её от «шума», и высчитывал профиль (психотип) человека, паттерны его поведения.

С техническим заданием в руках мы с разработчиками прошли, кажется, всё: отрицание, злость, торг, депрессию и принятие. От «невозможно» и «ничего непонятно» до «возможно, но не так, как вам нужно», «ничего не получится — расходимся» и «всё готово — давайте тестировать».

«Мы искали формулу, которую смогли бы оцифровать быстро, без больших трудозатрат и главное — получить на выходе не «филькину грамоту», а валидные результаты», — рассказывает Алексей Филатов. Исходная формула для расчёта профиля (как в письменной речи проявляется тот или иной психотип) у него была. Дело было за её доработкой и реализацией на практике.

Чем больше выборка — тем лучше результат. Для определения лучшей формулы брали накопленные переписки собственных сотрудников, прогоняли их через программу, собирали статистику, корректировали формулы. Данные сравнивали с результатами тестирований и профайлами, которые по людям вручную выстраивали профессиональные профайлеры — я и Алексей Филатов.

Таким образом находили самые точные алгоритмы вычисления и дорабатывали формулы. Следующий круг тестирования проводили на доверенных клиентах, которые дали согласие на участие в эксперименте. Несмотря на то, что это был только тест, результаты его вызвали одобрительные отзывы у участников.

Ещё приходилось проводить много тестов на минимальное количество лемм (неизменная исходная форма слова), на котором можно было проводить адекватный и точный анализ текста. Начинали с 50–60 тысяч лемм, уменьшали с шагом в 5 000. В итоге пришли к выводу, что минимальное достаточное количество лемм — 20 000.

Модуль нормализует и анализирует текст по более чем 70 критериям не только исходящие письма, но и переписку в Skype, Viber, WhatsApp, Lync, Telegram, других мессенджерах и социальных сетях.

Где спотыкались

Сложной с технической точки зрения оказалась задача нормализовать текст, очистив его от «шума», то есть от элементов, которые не несут смысловой нагрузки и не имеют ценности для анализа.

Простой пример — цифры, а ещё латиница, опечатки, картинки, лишние знаки препинания. Со знаками, правда, уже сложнее. Точку в конце предложения вроде бы ставят все, это «пустой» знак, а вот наличие и количество запятых, наоборот, значимый параметр. В то же время в Skype-переписке или социальных сетях точку почти все игнорируют, и была проблема в том, чтобы научить модуль «видеть» предложения. В процессе разработки было перепробовано множество алгоритмов по очистке текста от «шумов».

Ещё одна сложность заключалась в том, чтобы вычленить из переписки неформальное общение и анализировать тексты, в которых сотрудник выходит за рамки профессиональных и должностных обязанностей. Первый источник, который мы подключили к модулю, — почта. Это был провал, потому что люди писали исключительно сухие деловые письма и профиль выстраивался некорректно.

Какие ваши доказательства?

Но как ни странно, технические проблемы оказались не столь значительны, как вопрос о графическом представлении результатов. Разногласия в команде появились уже на стадии обсуждения эскизов интерфейса. «Команда достаточно долго искала наилучшее графическое решение и интерфейс. Например, выражение параметров в моей голове выглядело совсем иначе, чем сейчас», — объясняет Алексей Филатов. Свои предложения и корректировки вносил и коммерческий отдел, которому было важно, чтобы продукт был прост и понятен клиентам.

Дизайнер работал в авральном режиме, пересмотрели десятки вариантов. Критике подвергался каждый элемент: визуализация индекса личностных качеств, известная в команде проекта как «батарейка», пиктограммы для обозначения базовых ценностей и уровня амбиций, блок с рекомендациями. Всё дело в том, что менеджеры смотрели на модуль глазами клиентов, а не узких специалистов по профайлингу.

Один из первых прототипов психологического профиля личности

Интерфейс «КИБ Сёрчинформ ProfileCenter», который вышел в релиз

Подход к модулю исключительно с позиций профайлинга и психодиагностики привёл к ещё одной более серьёзной проблеме — терминологии. В первой версии мы ввели параметр «азартность». Но для большинства людей это слово означает «приверженность к азартным играм». Тогда как в психологической науке термином «азартность» обозначают вовлечённость в некий процесс.

Из-за разночтений в терминологии альфа-версия вызвала неоднозначную оценку, так что в финальной версии отчёта появились определения и краткие пояснения терминов. Дело оставалось за малым: объяснить, почему расчёт модуля и личное мнение о человеке не всегда совпадают.

Мы не всегда воспринимаем окружающих такими, какие они есть, а наш модуль показывает, какой человек в действительности. Например, модуль охарактеризовал топ-менеджера как конфликтного человека, но председатель совета директоров не согласился с выводами: «Это полная ерунда! Это самый дружелюбный человек». Естественно, с главой компании не каждый рискнёт конфликтовать, но это не значит, что с другими сотрудниками не будут возникать конфликтные ситуации. Общаясь друг с другом, люди часто надевают маски. Человеку в принципе не свойственно демонстрировать истинное лицо широкому кругу людей.

Что дальше

Точность результатов готового модуля профайлинга эксперты оценивают в 75–80 %. Как бы то ни было, для задачи, решения которой никто до сих пор не предлагал, это хорошие показатели и огромное достижение. Главное, что этого достаточно, чтобы решать задачи бизнеса. Летом 2018 года, спустя всего три месяца после релиза, состоялась первая продажа нашего решения. Как выяснилось, клиент приобрёл модуль не только чтобы контролировать сотрудников, но и для поощрения. Так в многотысячной компании появилась возможность выявлять лояльных компании и эффективных сотрудников, тех, кто создаёт позитивный рабочий настрой.

Дальнейшее повышение точности может быть достигнуто за счёт подключения дополнительных модальностей.

«Остались красные флажки, за которые мы пока не можем выйти. Чтобы создать психологический портрет максимально качественно, нужно 2–4 модальности: текст, мимика, интонации. Когда мы добавим в модуль анализ голоса, социальных сетей, клавиатурного почерка, качество реализации будет ещё лучше», — уверен Алексей Филатов.

Технически эти задачи решаются крайне тяжело. Каждый следующий процент точности расчёта нашего модуля даётся со всё большим трудом.

Пока идёт работа над усовершенствованием отчётов. Сейчас модуль может формировать около 78 000 вариантов расширенных профилей сотрудников, умеет определять риск-рейтинг пользователя, находить корреляции с инцидентами и поведением человека.

Далее модуль профайлинга будет запущен на английском, испанском и португальском языках.

Ежегодно ущерб российских компаний от киберпреступников составляет 116 млрд рублей. И это только те случаи, которые предаются огласке. Чаще всего компании стараются скрыть, что их системы были взломаны, а данные украдены. Ведь помимо единовременных финансовых потерь, успешные атаки в итоге приводят к падению репутации и котировок.

Создание системы информационной безопасности потребует от крупных компаний и корпораций серьёзных финансовых вложений: от дорогостоящего ПО до пентестов и программ Bug Bounty. Начинающий бизнес не может позволить себе таких расходов, а стартапы и вовсе пренебрегают безопасностью ради максимально быстрого выхода на рынок. Баланс стоимости программного продукта и его защищённости соблюсти не сложно, если придерживаться простых рекомендаций. Ниже – советы, как не прогореть на выстраивании стен и избежать банальных ошибок.

Проверенные решения

Хороший проект пишется безопасно с первой строчки кода. Рассуждать о том, какой язык программирования наименее уязвим, мы не будем, так как у каждого проекта свой путь к выбору инструмента проектирования и уникальная специфика. Общая рекомендация – пользуйтесь проверенными решениями. Если ошибка обнаружена на низком уровне языка программирования — это подвергает опасности весь проект целиком. Несмотря на то, что передовые технологии ускоряют разработку и делают её удобнее, из-за них могут возникнуть проблемы с надежностью и безопасностью. Небольшое запаздывание для бизнеса не критично, но и слишком отставать тоже не стоит. Пользуйтесь языками и решениями, динамично развивающимися и вышедшими из тестирования. Такой подход повысит стабильность вашей разработки, и вам не придётся менять платформу из-за критических недочётов языка, базы данных или другого компонента.

Защита пользовательских данных

Подсистема идентификации и аутентификации является одной из самых важных компонент, так как предоставляет доступ к пользовательскими данным. Нельзя проектировать продукт так, чтобы аутентификацию можно было пропустить в критическом месте или допускалась бы подмена параметров. Даже если вы работаете над приложением по поиску и созданию музыки, будет неприятно, когда злоумышленник сможет войти под именем пользователя, узнать о его предпочтениях, а тем более украсть сочинённые композиции.

Бережное отношение к данным и проверка их корректности — залог спокойствия и доверия клиентов. У всех современных приложений есть внутренняя валюта или иные способы монетизации. А для банковских продуктов безопасность — уж точно один из главных критериев оценки. Простая забытая проверка на знак в процессе передачи суммы от одного пользователя другому может привести к катастрофическим последствиям. Отрицательный знак в отправленных данных приведёт к обратной операции: средства со счёта получателя уйдут отправителю платежа.

В современном мире злоумышленники охотятся не только за деньгами, но и за персональными данными пользователей. Их раскрытие зачастую оказывается болезненнее, чем финансовые потери на счёте. Один из последних примеров: хакеры взломали сервис Quora.com и получили доступ к логинам, почтовым адресам и паролям ста миллионов пользователей. По оценке киберкриминалистов, уязвимость скорее всего скрывалась в недостаточно надёжной системе шифрования пользовательских паролей. Прямых финансовых убытков компания не понесла, но доверие пользователей потеряла.

Тестирование

Начинающие разработчики ПО всегда экономят время на тестировании, а иногда даже вносят модификации кода сразу на работающую версию сервиса. Помимо ошибок внутри кода, которые наверняка будут, могут возникнуть проблемы с логикой. Поэтому перед запуском проект нужно обязательно протестировать! Ошибки логики не очевидны и трудно предсказуемы. Бывает и так, что из-за мелкого программистского недочёта при получении доступа к одному файлу, пользователю открывается всё содержимое папки. В автоматическом режиме такую ошибку найти сложно, ведь функциональность она не нарушает, а вот проблем в безопасность добавляет массу.

Аналитика — всему голова

Обязательно настраивайте и постоянно поддерживайте в рабочем состоянии систему логирования. Это единственный способ, который позволит собирать данные о пользователях: как они обращались, зачем, с какой периодичностью, какого типа запросы посылали. Чем больше данных вы будете держать в своей аналитической системе, тем с большей вероятностью вам удастся вычислить злоумышленника при попытке взлома. Или, если атака окажется успешной, вы сможете понять, через какой вектор был нанесён удар. Если вы информированы о своих уязвимостях, то вы сможете их устранить.

Резервное копирование

Не забывайте о регулярных бэкапах. Ведь злоумышленники могут и не взламывать проект, а использовать его в качестве платформы для распространения вирусов: изменить некоторые данные на сайте или внутри приложения. Изначально запрограммированная система так и будет продолжать рассылать заражённый контент и, возможно, пожирать саму себя. Искать причины поломки в этом случае можно будет очень долго. Гораздо быстрее и надёжнее будет откатиться к безопасному состоянию кода.

Только после настройки систем логирования и бэкапирования можно выпускать сервис «к пользователям». Кроме того, системы мониторинга (IDS/IPS) помогут вам уберечь себя от последствий халатной работы администраторов информационных систем, а также помогут в тестах продуктов на наличие ошибок.

Защита и шифрование

Используйте шифрование пользовательских данных там, где оно уместно. Пароль пользователя, его персональная платёжная информация, а также конфиденциальная переписка должны храниться в зашифрованном виде. Но вот загруженные общедоступные данные шифровать не стоит, так как их расшифровка тратит ресурсы и не приносит пользы.

И последнее: не пытайтесь создать абсолютно неуязвимый код, так как, по нашему мнению, 100% безопасных проектов не бывает. Экстремальные ситуации или находчивые злоумышленники выводят из равновесия даже системы, которые изначально казались идеальными. Проводя аналогию с банковскими приложениями, можно сказать, что задача специалиста по IT-безопасности – сделать так, чтобы стоимость атаки многократно превышала прибыль, которую теоретически можно получить от взлома.

В начале прошлого года был утверждён план мероприятий по направлению «Информационная безопасность» программы «Цифровая экономика Российской Федерации». Реализация этого плана отразилась в частности в Законопроекте № 608767-7, который 14 декабря 2018 года был внесён на рассмотрение в Госдуму, а 7 февраля 2019 года ответственный комитет принял решение о представлении законопроекта в Совет Государственной Думы. И это несмотря на то, что у Правительства есть ряд вопросов по данной инициативе.

Развитие событий намекает на то, что скорее всего данный законопроект будет принят Госдумой. Попытаемся разобраться, что это за инициативы и чем они грозят рядовому пользователю.

Зачем это нужно

В пояснительной записке указано, что законопроект призван ввести «защитные меры для обеспечения долгосрочной и устойчивой работы сети Интернет в России, повышения надёжности работы российских интернет-ресурсов» с учётом «агрессивного характера принятой в сентябре 2018 года Стратегии национальной кибербезопасности США». Таким образом, законодатель пытается преподнести данную инициативу как подготовку к возможному отключению России от глобальной Сети, а не как изоляцию Рунета с целью ограничить свободы граждан.

Однако нет никаких гарантий, что технические средства, призванные якобы обеспечить независимую работу российского сегмента Сети, не будут использоваться и для блокировки неугодных зарубежных источников информации. По крайней мере, в действующей редакции законопроекта предусмотрены меры, позволяющие не только маршрутизировать трафик исключительно через внутрироссийские узлы связи, но и определять его источник и блокировать:

Предусматривается возможность установки на сетях связи технических средств, определяющих источник передаваемого трафика. Технические средства должны будут обладать возможностью ограничить доступ к ресурсам с запрещённой информацией не только по сетевым адресам, но и путём запрета пропуска проходящего трафика.

Пояснительная записка к проекту Федерального закона “О внесении изменений в некоторые законодательные акты Российской Федерации”

Каким образом ограничение неугодных ресурсов поможет стабилизировать работу Рунета остаётся загадкой.

Какие ещё страны ограничивают доступ к Сети

Россия не первой пытается взять под жёсткий контроль работу Сети. Среди стран, которые так или иначе регулируют и ограничивают потоки трафика в интернете, можно обозначить Китай, Северную Корею, Индию, Иран, Беларусь и ещё ряд других стран.

Отдельно стоит выделить Китай и Северную Корею. Китайский сегмент Сети хоть и не изолирован от глобальной, но эксплуатирует чуть ли не самую мощную систему фильтрации трафика, называемую Великий Китайский файрвол или Золотой щит. Северная Корея же практически полностью закрыла доступ к Глобальной Сети рядовым пользователям и создала свой «интернет» с мелодичным названием Kwangmyong (Кванмён). Что ж, если выбирать из двух зол, то путь Китая кажется более умеренным. 🙂

Чем это грозит рядовому пользователю

Пока эта инициатива вообще ничем не грозит. Даже когда законопроект будет принят, всё будет работать как и раньше. Ведь уже и сейчас с лёгкостью блокируются неугодные ресурсы, и скорее всего здесь ничего не изменится.

С точки зрения возможной изоляции всё просто: если Россию «отключат» от интернета, или она сама себя «отключит», то кроме того, что не будут работать некоторые зарубежные соцсети и мессенджеры, скорее всего возникнут проблемы в банковском секторе, работе IoT и ещё во многих не очевидных для простого пользователя вещах. Также исходя из опыта Северной Кореи (да и общей логики), доступ к российскому сегменту Сети будет ограничен для остального мира, что чревато убытками для российского бизнеса.

Что конкретно будут делать

Как и в более ранних инициативах по регулированию средств связи, обязательства по установке оборудования для реализации законотворческих идей лягут на плечи операторов связи (а через них и на рядовых пользователей):

Оператор связи, оказывающий услуги по предоставлению доступа к информационно-телекоммуникационной сети “Интернет”, обязан обеспечить установку в своей сети связи технических средств противодействия угрозам…

Проект изменений в Федеральный закон от 7 июля 2003 года № 126-ФЗ “О связи”

Исходя из того же текста законопроекта, операторы связи, собственники или владельцы технологических сетей связи, а также иные лица, имеющие номер автономной системы, в случае использования сети Интернет обязаны:

• корректировать маршрутизацию сообщений электросвязи по требованию федерального органа;
• для разрешения доменных имён использовать сервера, функционирующие на территории РФ;
• предоставлять в электронной форме в федеральный орган исполнительной власти информацию о сетевых адресах абонентов и их взаимодействии с другими абонентами, а также информацию о маршрутах сообщений электросвязи.

Как видим, информация для передачи в органы федеральной власти очень интересная.

Насколько высока вероятность воплощения этих планов в жизнь

Судя по стремительным темпам прохождения у законопроекта есть все шансы быть принятым в ближайшее время. Более того в бюджет уже начали закладывать затраты на реализацию данной законодательной инициативы.

Что в итоге

Даже у Правительства есть масса замечаний к законопроекту. Это говорит о том, что он ещё очень сырой и на первых порах его реализации исполнительная власть будет тренироваться, что несомненно может отразиться на удобстве рядовых пользователей, как это уже происходило с мессенджером Телеграм, при попытке блокировки которого был ограничен доступ к ряду добросовестных сервисов Сети. При этом полной изоляции от всемирной паутины ожидать скорее всего не стоит.

Контекст задачи

Когда ваш бизнес предполагает анализ статистических данных, поступающих из разных источников, вам требуется эти данные собирать, хранить, индексировать, трансформировать в другие данные, анализировать и т. д.

Часто бывает так, что масштаб проекта ещё недостаточно велик для внедрения крупных программных платформ наподобие Hadoop, и в этом случае вам помогут универсальные варианты на базе стандартных NoSQL-решений, которые позволят справиться с накоплением и обработкой данных среднего объёма.

К таким решениям, исходя из нашей практики, относится Elasticsearch.

Что такое Elasticsearch

Elasticsearch — это представитель кластерных NoSQL с JSON REST API.

Мы можем считать его и нереляционным хранилищем документов в формате JSON, и поисковой системой на базе полнотекстового поиска Lucene.

Аппаратная платформа — Java Virtual Machine.

Официальные клиенты доступны на Java, NET (C#), Python, Groovy, JavaScript, PHP, Perl, Ruby.

Elasticsearch разрабатывается компанией Elastic вместе со связанными проектами, называемыми Elastic Stack, — Elasticsearch, Logstash, Beats и Kibana.

Beats — легковесные агенты и отправители данных с различных устройств. Logstash собирает и обрабатывает данные зарегистрированных событий. За хранение и поиск данных отвечает Elasticsearch. Kibana визуализирует данные через web-интерфейс.

Сегодня Elastic Stack с успехом используется сервисами eBay, Adobe, Uber, Nvidia, Blizzard, Citibank, Volkswagen, Microsoft, SoundCloud, GitHub, Netflix, Amazon. Чем же привлекателен Elasticsearch в контексте поставленной задачи? Давайте разберёмся.

Простой выбор

Одним из пунктов технического задания в рамках нашего проекта было требование собирать и анализировать статистику примерно с 25 (+/- 5) тысяч различных устройств.

Аппаратные возможности, операционные системы, сетевые интерфейсы, типы и назначение устройств неоднородны — от смартфона и телевизора до инфраструктурного сервера.

Устройства находятся в отдельных зданиях (примерно 1500 зданий, в каждом от 10 до 20 устройств), обслуживаются однотипной, но изолированной от других зданий инфраструктурой.

Оценив поставленную задачу, мы поняли, что нам не нужна большая суперсистема, которую можно отнести к категории BigData и/или HighLoad. С другой стороны, любые привычные методы сохранения и обработки информации, такие как запись в текстовый файл или SQL-базу, не подходили из-за объёма и специфики данных, поскольку большая часть работы происходила с логами устройств. Сыграло свою роль и наличие дополнительной статистики, которую сообщают сервисы, запущенные на устройствах.
Также в нашем случае по оценке объёма входящих данных, скорости их поступления и озвученных задач аналитики не было необходимости отдельно строить OLTP- и OLAP-системы.

Другими словами, система предполагает сбор статистики, к тому же она обеспечивает некоторое накопление данных и показ этой истории в удобном и интересном для менеджеров и аналитиков проекта виде. В результате мы выбрали Elasticsearch как оптимальное решение.

Да и Elastic Stack в целом предназначен для решения такого класса задач.

А что, собственно, собираем?

Как говорилось ранее, устройства разные, а вот статистическая информация нас, как правило, интересует достаточно однотипная: температура и загрузка процессора, объём потребляемой памяти, время и режимы использования устройства, какие программы запускались, сетевой трафик, сколько задач выполнено, что в логи записано, какие ошибки зарегистрированы и прочие данные с устройства и об устройстве.

Что на базе собранной информации хотят получить аналитики и менеджеры?

Самый частый из встречающихся сценариев — он же был изначально озвучен в техническом задании — это сбор и хранение всей (сырой) статистики по всем устройствам и сервисам за последний месяц с последующей агрегацией по дням и группировкой по зданиям с «бессрочным» хранением полученного результата.

Raw-индексы перезаписываются каждый месяц новыми данными, Agg-индексы накапливаются по дням «бесконечно» (пока хватает дискового пространства).

Все остальные пожелания по группировке и разбивке данных, по аналитическим срезам, визуальному представлению и т. п. выполняются аналитиками и менеджерами самостоятельно с использованием как Kibana, так и Power BI.

Периодически некоторые данные, чаще всего новые, получаемые из исходных, выделяются в отдельную задачу предварительного расчёта, которая выполняется с помощью вычислительной платформы Spark «по расписанию» и сохраняется в ещё один Agg-индекс, откуда эти подготовленные данные попадают в сложные отчёты и т. д.

Немного фактов о системе

Elasticsearch, как выяснилось, прекрасно подходит для работы в пределах определённого объёма данных (2–10 терабайт в год, 20–30 миллиардов документов в индексах), а также хорошо интегрируется с кластером Spark.

Агенты (Beats) помогают на конкретном устройстве или конкретном сервере собрать информацию, которая интересует пользователей системы. С помощью этих агентов можно собирать разного рода данные: системную информацию Windows из журнала, логи операционной системы Linux, данные устройства на ОС Android, самим анализировать трафик с устройства, будь то TCP, HTTP и т. д.

Локальный для инфраструктуры каждого здания Logstash отлично справляется с отправкой данных, собираемых агентами устройств, в централизованный кластер Elasticsearch, а Kibana предоставляет удобный способ построения веб-отчётов.

Необходимые инфраструктурные ресурсы

В нашем случае используется Linux-кластер в составе 3–10 нод.

Нода — это 8 процессорных ядер, 16–32 гигабайта оперативной памяти, жёсткий диск размером 1–5 терабайт. Сеть 1 Гигабит.

Масштабируемость

Данная подсистема статистики может работать с любой сферой деятельности, где требуется сбор и анализ статистических данных среднего объёма. Это может быть обработка статистической информации с 1 000 и до 30 000 холодильников, мобильных устройств, ноутбуков, интерактивных панелей и т. д.

Когда устройств меньше, чем 1–3 тысячи, система избыточна, есть более простые решения. Количество в 10 000–30 000 единиц оптимально по объёму и скорости появления новых данных с устройств.

50 и более тысяч устройств повлекут за собой усложнение системы, и в этом случае надо выбирать другое решение.

Хотя, если мы воспринимаем 50–100 тысяч устройств как три сегмента по 15–30 тысяч, то можно просто запустить три подсистемы нашей статистики.

Основная идея заключается в том, что чем более изолированы «сектора», тем проще применить решение формата «три по тридцать».

Заключение

На примере проекта городского масштаба мы рассмотрели применение Elasticsearch для работы с большими данными, оценили его преимущества и целесообразность применения для задач, где массивные решения вроде Hadoop избыточны.

Вместе с развитием сферы Data Science растёт и востребованность в кадрах для этой отрасли. Как же стать специалистом в такой части анализа данных, как обработка естественного языка (Natural Language Processing)?

Кадровый рынок в этой сфере пока не очень большой. Хотя вакансий по Data Science кажется довольно много, задачи NLP встречаются в запросах работодателей достаточно редко. И в основном специалистов по обработке естественного языка ищут компании в крупных городах — Москве, Санкт-Петербурге, Новосибирске, Екатеринбурге. При этом работодателями выступают не только корпорации, но и небольшие коллективы разработчиков и даже стартапы. Так что в сегменте NLP для начинающих специалистов есть определённые перспективы.

Специальности и задачи по обработке естественного языка

Чтобы понять, как стать специалистом по обработке естественного языка, разберёмся сначала, какие задачи решаются в этой области и в каких сферах бизнеса эти решения востребованы.

Язык — это сложная совокупность различных уровней, таких как синтаксис, морфология, семантика, дискурс.

Для каждого уровня выделяются свои специфические задачи. Но на практике чаще всего задействуются несколько или все уровни языка. Например, классическими задачами синтаксиса и морфологии являются токенизация (деление текста на слова) и лемматизация (приведение слова к начальной форме). Есть задачи синтаксического анализа теста (парсинга), извлечения сущностей — например, имён и географических названий. С семантикой связаны задачи тематического моделирования (выделения тем в большой коллекции документов) и определения эмоциональной окраски. Уровень дискурса затрагивает задача суммаризации текста. Машинный перевод задействует все уровни языка. Распознавание и генерация устной речи также относятся к сфере NLP.

Следующий вопрос — кому нужны все эти задачи? Их упоминание можно увидеть в объявлениях о найме во многих сферах бизнеса. В частности, в обработке естественного языка заинтересованы контактные центры, которым требуется оперировать большим потоком входящих запросов: разбивать их на категории, определять темы, автоматически подбирать варианты ответов.

Интернет-магазины тоже ищут таких специалистов, потому что улучшают поиск по своим каталогам, внедряют диалоговые и рекомендательные системы. Есть запрос в сфере маркетинга и PR: исследовать освещение деятельности компании в медиа и отслеживать, какой образ создаётся у аудитории — позитивный или негативный. Таким же образом исследуют отзывы и комментарии в соцсетях.

Во многих сферах бизнеса используются чат-боты, например, они востребованы у банков, которые ищут специалистов по обработке естественного языка для своих собственных разработок.

Кроме таких компаний, которым нужны собственные системы под обслуживание своих бизнес-процессов, специалистов по обработке естественного языка ищут многие IT-компании сектора B2B. Они разрабатывают программные решения для продажи своим клиентам. В частности, независимо от отрасли, компаниям с большим потоком входящих документов и обращений могут быть полезны системы, оптимизирующие работу. Нужно распределять обращения по темам и отделам, выделять наиболее важные и негативные, ускорять перевод на другие языки и улучшать поиск по базе данных компании. Многим средним и крупным компаниями рано или поздно приходится сегментировать клиентскую базу.

Необходимые навыки для специалиста по NLP

Какие навыки нужны, чтобы освоить профессию специалиста по обработке естественного языка?

Нужно понимать, что обработка естественного языка состоит из нескольких компонентов: знаний о языке, знаний по математике и статистике и навыков в программировании. Причём математика и программирование важнее лингвистики.

Есть общие требования, которые работодатели предъявляют к претендентам на вакансии по NLP. К ним относятся: знание математики, теории вероятностей, статистики, знание сфер применимости, понимание плюсов и минусов различных семейств алгоритмов машинного обучения (таких как логистическая регрессия, различные алгоритмы кластеризации, нейронные сети, бустинг, случайный лес).

Специалисту по NLP нужно уметь работать с базами данных и знать SQL. Иногда требуются знания не только реляционных БД и соответствующих инструментов (PostgreSQL, MySQL, MS SQL, Oracle), но и понимание NoSQL-систем (Cassandra, Redis, MongoDB). Может понадобиться знакомство с фреймворками для работы с большими данными и с различными поисковыми движками.

Обязательным условием является знание структур данных.

Следующая категория навыков связана с языком: необходимо представление о морфологическом, графематическом, синтаксическом анализе. Нужно владеть алгоритмами и техниками, специфическими для задач обработки естественного языка, разбираться в таких вещах, как тематическое моделирование, информационный поиск, дистрибутивная семантика.

Какой язык программирования необходимо освоить? Тут нет однозначного ответа. Наиболее часто встречается запрос на Python, реже специалистам по NLP требуется знание R. Для разработки конечных решений программистам чаще всего нужны Java, C#/C++, Scala.

Наиболее часто встречается запрос на Python, реже специалистам по NLP требуется знание R.

Кроме того, есть набор технологий, с которыми нужно уметь обращаться. Это стек технологий Data Science для Python.

Базовые библиотеки для любого аналитика данных — pandas (для работы с данными в табличном виде), numpy (для работы с большими числовыми массивами) и scipy (для вычислений). Для визуализации могут понадобиться библиотеки matplotlib и seaborn. Для машинного обучения требуется знание основной библиотеки scikit-learn и других специфицированных библиотек (например, XGBoost и LGBM для градиентного бустинга). Для задач обработки естественного языка нужно разбираться в содержании специальных библиотек: nltk, StanfordNLP, spacy, gensim, bigartm, word2vec, fasttext.

Нужен опыт построения глубоких нейронных сетей с использованием фреймворков Tensorflow, Keras, PyTorch. И, конечно, желательно уметь работать с инструментами, рассчитанными именно на русский язык, такими как pymystem3, pymorphy — для морфологического анализа, Tomita parser, yargy — для извлечения фактов и сущностей. Кроме того, нужно уметь тестировать методы обработки текстовых данных и знать методики оценки качества моделей.

Конечно, это программа-максимум. В зависимости от конкретных задач работодателя может понадобиться тот или иной язык программирования, тот или иной стек технологий. Плюсом для разработчиков решений NLP является наличие собственных проектов на GitHub, а также сертификатов об участии в Kaggle и других соревнованиях по машинному обучению. Также от претендентов ожидают достаточного уровня английского, но это универсальное требование.

Смотрите также: Знакомство с Kaggle: изучаем науку о данных на практике

Где освоить профессию специалиста по NLP?

В вакансиях по NLP в большинстве случаев требуется профильное образование по информатике, вычислительной математике, физике или связанным областям. Иногда — не ниже магистратуры или специалитета.

Но есть и другие варианты: например, обучение в вузе по специальности «компьютерная лингвистика». Выпускником такой образовательной программы является Полина Казакова, Data Scientist в проекте IRELA, сотрудник Центра анализа больших данных МИСиС. Она занимается разработкой систем анализа данных для различных компаний, то есть как раз обработкой естественного языка.

«Я училась в Высшей школе экономики на программе “Фундаментальная и компьютерная лингвистика”, которая работает в рамках филологического направления, — рассказывает Полина. — Эта программа совмещает в себе теоретическую лингвистику, то есть фундаментальные научные знания о самом языке, и прикладные методы анализа данных, а также программистские навыки. Таким штукам мало где учат в России».

Кроме указанной программы по компьютерной лингвистике ВШЭ (которая также открыта в двух филиалах вуза), в России есть ещё несколько учебных программ по компьютерной лингвистике.

Магистратура по специальности NLP есть в СПбГУ на кафедре информационных систем в искусстве и гуманитарных науках. Несмотря на то, что кафедра относится к гуманитарному факультету, программа «Инженерия гуманитарных знаний» рассчитана на программистов.

В МФТИ на кафедре распознавания изображений и обработки текста факультета инноваций и высоких технологий (ФИВТ) действует магистратура по компьютерной лингвистике. Кафедра была основана в 2006 году компанией ABBYY.

В МГУ на филологическом факультете действуют программы бакалавриата и магистратуры по направлению «Фундаментальная и прикладная лингвистика».

В РГГУ открыта магистратура по этому же направлению с профилем «Фундаментальная и компьютерная лингвистика».

Стоит ли поступать на компьютерную лингвистику ради работы в NLP?

«Сама эта программа по компьютерной лингвистике преследует благую цель: совместить теорию с практикой, — говорит Полина. — У нас были теоретические дисциплины, связанные с синтаксисом, фонетикой, морфологией и прочим, и были попытки ввести точные дисциплины, такие как математический анализ, линейная алгебра, статистика, основы программирования и даже машинного обучения. А машинное обучение, как вы догадываетесь, в последнее время очень активно применяется в обработке естественного языка (хотя и не во всех задачах, кое-где до сих пор обходятся rule-based подходом).

Возвращаясь к программе, кажется, что идея прикольная — столько всего совместить. Но на практике получается, что в одинаковой степени дать два фундаментальных образования в одном не получается, поэтому у нас было очень неплохое фундаментальное лингвистическое образование и… была какая-то математика.

Наверное, этого достаточно для того, чтобы начать работать в области NLP, но дальше всё равно понадобятся более глубокие знания. После окончания бакалавриата я поняла, что мне не хватает фундаментальных знаний из основного курса математики. Поэтому сейчас я, например, самостоятельно занимаюсь матанализом и линейной алгеброй.

Мой совет людям, которые хотят заниматься обработкой естественного языка: идите на техническую специальность и параллельно изучайте какие-то лингвистические штуки, потому что на самом деле узкоспецифические знания о языке очень редко пригождаются в практических задачах машинного обучения. Особенно сейчас, когда есть нейросети, которые на большом наборе хорошо размеченных данных сами выводят все правила, которые лингвисты могли бы составить вручную. Можно сказать, что хорошая квалификация в лингвистике иногда может дать какой-то профит в NLP, но в большинстве случаев скорее нужна хорошая квалификация в машинном обучении. Так считаю не только я, но и мои коллеги-технари».

Идите на техническую специальность и параллельно изучайте какие-то лингвистические штуки

Кто же занимается разметкой текстовых данных для нейросетей и вообще для тренировки моделей машинного обучения?

«Это хороший вопрос. Разметка — это общая боль всех — и лингвистов, и специалистов по машинному обучению и обработке естественного языка», — говорит Полина Казакова. Хорошую разметку достаточного объёма получить непросто, для этого нужны люди, которые вручную будут размечать массив данных. И составлением методологии разметки текста должны заниматься как раз лингвисты. Например, для задачи токенизации они должны сформировать правила деления текста на слова (учитывая сложные случаи типа «диван-кровать», «какой-нибудь», «90-й год»). И после этого можно уже привлечь почти случайных людей, которые будут размечать текст в соответствии с заданными правилами. Кстати говоря, этой задачей — разметкой данных — могут заниматься стажёры, которые хотят дальше развиваться в направлении Data Science/NLP. Время от времени такие вакансии появляются.

Несмотря на всеобщую потребность в выпускниках технических специальностей, иногда в команды программистов и математиков требуются именно эксперты по языку. Полина вспоминает один такой случай: «У компании Samsung есть голосовой помощник, и недавно они начали в России активно набирать на работу именно лингвистов. Они занимаются распознаванием и синтезом речи, и взяли на работу мою однокурсницу — крутого фонетиста-теоретика, при том что у неё не было никакого опыта программирования и она не знала, что такое нейросети. Её взяли из-за специфических лингвистических знаний, но по моему ощущению, это исключительный случай».

Дополнительное образование в сфере NLP

Какое бы базовое образование вы ни получили — лингвистическое или математическое — вы всегда можете обнаружить, что каких-то знаний не хватает, тем более что NLP и Data Science активно развиваются. Как получить дополнительное образование?

Школа анализа данных (ШАД) — программа «Яндекса», обучение по которой работодатели часто упоминают в качестве преимущества потенциального кандидата. Как следует из названия, там даются основы машинного обучения и анализа данных. По формату школа больше похожа на полноценную магистратуру, чем на дополнительное образование. Программа рассчитана на два года, обучение — очное в вечернее время (филиалы есть в Москве, Минске, Екатеринбурге и Нижнем Новгороде) и заочное для иногородних студентов. В ШАД можно бесплатно поступить по конкурсу (что довольно сложно, конкурс большой), а в случае недобора баллов учиться платно — правда, только в Москве и только очно.

Записи лекций ШАД по некоторым предметам доступны для всех желающих. Некоторые из избранных курсов пригодятся будущему специалисту по NLP:

• Курс «Машинное обучение»
• Курс «Алгоритмы и структуры данных поиска»
• Курс «Дискретный анализ и теория вероятностей»

Чтобы дополнить свое образование, можно пройти онлайн-обучение, например, на платформе Coursera.

• Список курсов, рекомендованных НИУ ВШЭ магистрантам по компьютерной лингвистике, среди которых есть курсы по NLP и машинному обучению.
• Natural Language Processing — собственный курс по NLP от НИУ ВШЭ, который активно развивает направление онлайн-обучения.
• Machine Learning with TensorFlow on Google Cloud Platform — специализация (набор связанных курсов), разработанная компанией Google, на платформе Coursera. Входящие туда курсы можно изучать по отдельности, например, Sequence Models for Time Series and Natural Language Processing.
• Text Retrieval and Search Engines и Text Mining and Analytics — курсы, входящие в специализацию Data Mining в рамках программы Master of Computer Science in Data Science (MCSDS) от Иллинойсского университета (США). Курсы можно прослушать независимо.
• Natural Language Processing (NLP) и Speech Recognition Systems — курсы, входящие в программу Microsoft Professional Program in Artificial Intelligence на платформе edX.
• Professional Certificate Program IBM — профессиональная программа от IBM на той же образовательной платформе. Она состоит из 5 курсов: Deep Learning Fundamentals with Keras, Deep Learning with Python and PyTorch, Deep Learning with Tensorflow, Using GPUs to Scale and Speed-up Deep Learning, Applied Deep Learning Capstone Project.

Есть несколько вариантов обучения на российской платформе «Открытое образование». Особенность этой платформы в том, что она создана при участии ведущих российский вузов, все курсы доступны там бесплатно, но при этом есть возможность получить сертификат и зачесть прохождение этих курсов в своём университете. На зарубежных платформах часто курсы можно пройти бесплатно, но за сертификат придётся заплатить.

• «Анализ данных на практике» — курс от МФТИ, на котором кроме прочего рассматривается обработка текстов.
• «Аналитика больших данных» — программа от НИТУ «МИСиС», в рамках которой изучаются многие из требуемых для NLP технологий. Старт её намечен на февраль.
• «Наука о данных и аналитика больших объёмов данных» — обзорный курс от Санкт-Петербургского Политеха, частично посвящённый анализу текста. Запись на этот курс сейчас закрыта, как и на многие другие из приведенных выше, которые уже идут сейчас или недавно завершились. Но можно подписаться на обновления о курсе, чтобы не пропустить следующий набор.

Наверное, вы не раз искали в маркетах мобильное приложение по какому-то ключевому слову, скачивали вариант без громкого имени, делали в нём несколько действий, после чего благополучно удаляли. А вы задумывались, почему? Скорее всего, оно не соответствовало вашим ожиданиям, имело не самый интуитивно понятный интерфейс и будто «тормозило». Это вполне объяснимо, так как часто приложения с узнаваемым брендом — детище продуктовой разработки. А заказчики, не захотев тратиться или ждать, отправили пользователям сырой и недоработанный продукт.

В чём отличия заказной разработки мобильных приложений от продуктовой

Давайте разберёмся, в чём отличия продуктовой мобильной разработки от заказной и от разработки приложений в целом.

Продукт предполагает, что приложение бесконечно улучшается, меняется, при его модификации учитываются отзывы пользователей.

То есть одна из задач создания продукта — удовлетворённость целевой аудитории.

Заказной проект почти всегда ограничен бюджетом, временем, желанием «лишь бы уже сдать и успеть доделать другой проект».

И всё это очень напоминает сюжеты фильмов Тарантино: как всех обмануть, чтобы потом за это ничего не было.

Может ли это к чему-то привести?

Такое отношение к заказной разработке чревато потерей целевой аудитории, а вместе с ней и денег на дальнейшую работу с проектом. Да и оттока кадров, скорее всего, не избежать. Разработчики, которые ушли «от заказухи в проект» хвастаются, что теперь им работается гораздо комфортнее: нет постоянных переработок и очередных «хотелок», из-за которых приходится всё переделывать.

Но давайте оставим вопросы кадров HR-ам и поговорим о качестве разрабатываемых мобильных приложений.

Фичи

Вы замечали, как в продуктовой разработке внедряется функциональность? Сначала делаются базовые функции приложения, и уже после, от релиза к релизу к нему добавляются дополнительные модули и фичи. Причём перед тем, как приступить к реализации чего-то новенького, проводится анализ рынка и выясняется — а нужно ли это пользователю? Если нет, то принимается решение не тратить ресурсы на невостребованную функцию. Кроме того, всегда найдётся время на качественное тестирование. В крайнем случае сдвинут сроки релиза, но не допустят попадания недоделанного и непроверенного продукта к пользователям.

В заказной же разработке перечень функций часто диктует заказчик. И делает он это не основываясь на пользовательском опыте и анализе рынка, а просто потому, что «я знаю, что это гениально!» или «я у соседа такое видел». А аргумент, что сосед занимается продажей винтиков и гаек, а мы хотим людей клингонскому языку обучать, его не интересует. Также в заказной разработке часто встречаются накладки по времени и ресурсам — дата релиза уже запланирована, а iOS- или Android-разработчик внезапно ударился в буддизм, ушёл в горы, и заменить его, в общем-то, некем. Поэтому после экстренных поисков нового сотрудника мы получаем отставание от календарного плана в N дней, а фичи или даже основную функциональность приходится делать абы как, чтобы успеть в срок. Да и толком оттестировать приложение времени нет. И сырой продукт с багами уходит в маркеты. Как следствие — плохие отзывы, малое количество скачиваний, провальный для заказчика проект.

Юзабилити

Если в приложении нет вундервафли, но оно покрывает необходимые функции и удобно в эксплуатации — это лучше, чем если хитрых фич и «кружавчиков» много, но пользователь не может найти нужную кнопку или пункт в меню.

Есть довольно большой пользовательский опыт, который жизненно необходимо учитывать при разработке UIX. При этом следует помнить, что приложения должны быть нативными. Так что дизайнера, который рисует одинаковые компоненты для iOS и Android просто потому, что «нужно ж одинаково», гоните в Интернет или из проекта в зависимости от времени. Пользователь Android будет ядом самой гремучей змеи плеваться, если ему придётся выбирать время на iOS-ном барабане.

Приложения должны быть нативными. Дизайнера, который рисует одинаковые компоненты для iOS и Android, гоните в Интернет или из проекта.

Но есть и общие моменты, которые нужно учесть при реализации пользовательского интерфейса. И самый важный из них — старт приложения. Если пользователь видит белый экран, где ничего не происходит, а приложение в это время грузится, это очень смущает. Добавьте splash screen, причём без кучи текста — за несколько секунд его не успеют прочитать, и ощущение чего-то упущенного может остаться. Выберите что-то простое и лёгкое для восприятия.

Если в приложении предусмотрены поля ввода, крайне необходимо менять вид экранной клавиатуры. Если пользователь вводит e-mail, он не должен искать символ «@» на дополнительных вкладках. А если набирает номер телефона, предоставьте ему клавиатуру с цифрами и знаками «+», «*» и «#». Также правилом хорошего тона станет дублирование кнопок интерфейса «Ок» или «Далее» на экранной клавиатуре. А ещё учтите, что кнопка, спрятавшаяся за развёрнутой клавиатурой, действует на некоторых пользователей как красная тряпка.

Кнопка, спрятавшаяся за развёрнутой клавиатурой, действует на некоторых пользователей как красная тряпка.

Важный вопрос для проработки — как отображать ошибки, возникшие в приложении? Просто поставьте себя на место пользователя и подумайте: вам понятно, что произошло и что делать дальше? Если нет, то стоит переформулировать текст ошибки и описание дальнейших действий. И ни в коем случае не оставляйте системные ошибки и ошибки для разработчиков, которые введут пользователя в ступор. Придумайте заглушку или понятную обработку.

И последнее, о чём я напишу сегодня, — режим работы приложения офлайн. Если при потере интернет-соединения вашим приложением невозможно пользоваться, то как быстро вы потеряете аудиторию? Предусмотрите офлайн-режим для работы с частью функций, где это уместно.

Вывод

Есть ещё множество кейсов, которые мы не будем перечислять в этой статье.

Основной совет для разработки хорошего мобильного приложения такой: попробуйте посмотреть на своё приложение глазами пользователя. Вас что-то бесит? Кажется неочевидным? Тогда лучше пересмотреть реализацию или дизайн.

Конечно, при разработке продукта вы имеете гораздо больше времени и можете довести до ума даже незначительные мелочи. Но не стоит забывать, что «встречают по одёжке», и даже если ваше приложение не содержит в первом релизе какие-нибудь крутые фичи, им должно быть удобно и приятно пользоваться.

Исполнители, разрабатывайте любые мобильные приложения, будто это ваш продукт. В конце концов, отчасти так и есть. А заказчики, наберитесь терпения и не жадничайте там, где это неуместно. Сэкономив 100 тыс. рублей сейчас, вы можете потерять миллионы потом.

Этой осенью мне довелось собрать бота, который одновременно общается с пользователем голосом и показывает картинки в браузере. Оказалось, что это не так просто, поэтому я решил поделиться пошаговым руководством, демками и исходниками нашего робота. Его, кстати, зовут Павел, и он виртуальный рептилоид, который разыгрывал билеты на конференцию INTERCOM’18.

Почему не просто голосовой бот

Сделать обычного голосового робота было бы быстрее, но я не мог не реализовать мечту детства — повторить опыт создания легендарной игры девяностых «Позвоните Кузе». Если вы не помните, двадцать лет назад на канале РТР по утрам шла интерактивная передача, куда могли дозвонится дети со всей страны. После соединения телефон «становился» джойстиком, с помощью которого можно было управлять персонажем, наблюдая за процессом по ТВ.

Тогда это казалось мне магией. Сейчас я занимаюсь разработкой и понимаю, что для девяностых это и правда была магия: взаимодействие с интерфейсом игры с помощью телефона, да ещё и стриминг на всю страну. Итак, «Позвоните Кузе» — это отличный пример нетривиального пути взаимодействия с интерфейсом, который мы взяли за основу при создании своего бота.

Что умеет Павел

С 1 сентября по 11 октября Павел «жил» во всплывающем окне на сайте конференции и предлагал каждому посетителю сыграть с ним. Пользователь оставлял свой номер телефона, звонил на бесплатный номер Павлу, и сессия браузера синхронизировалась со звонком. Далее участник должен был голосом давать ответы на ребусы, которые видел на экране. Робот распознавал речь, а потом дарил скидку в зависимости от количества правильных ответов.

При этом, если указанный номер уже поучаствовал в розыгрыше, рептилоид выдавал ошибку: «Одна попытка в одни руки — таковы правила».

Можно посмотреть, как это работало, или пообщаться лично с Павлом, который специально для Tproger переехал на отдельную страницу. Кстати, из порядка 150 участников, сыгравших с нашим роботом, ни один не смог с первой попытки ответить верно на все вопросы. Но не стоит отчаиваться, многие позвонившие всё же справились с большей частью ребусов.

Как синхронизировать браузер и телефон

Есть несколько путей узнать, кто именно из пользователей, находящихся в данный момент на сайте, сейчас будет общаться с ботом:

• Авторизация. Если сайт предполагает авторизацию по номеру, синхронизировать сессию браузера с телефоном можно непосредственно в момент звонка.
• Уникальные номера. Можно закупить номера и предлагать каждому пользователю свой — это удобно, но слишком дорого.
• Пароль. Идентификатором может стать уникальный текст, который пользователь проговорит в начале звонка — бот распознает речь и свяжет сценарий с браузером.
• Уникальное действие на странице. И наоборот — пользователь может ввести в окне на сайте пин-код, который ему назовёт бот.
• Ввод телефонного номера на странице. В этом случае в качестве идентификатора используется сам номер — так мы и сделали.

Разберем подробнее, как это работает. Пользователь вводит номер, браузер отправляет запрос на бэкенд в http, бэкенд устанавливает Socket-сессию. Далее участник звонит на многоканальный номер, обозначенный на сайте. В облаке Voximplant запускается сценарий, который также отправляет запрос в бэкенд — есть ли сейчас зарегистрированная Socket-сессия с определенным идентификатором. Если нет — звонок прерывается, если же да — начинается игра.

Как устроен сценарий

Участник общается с ботом голосом: сценарий звонка отправляет http-запросы бэкенду, а бэкенд через Socket-сессию взаимодействует с пользователем. Так, бэкенд может показать картинку, вывести ответ пользователя на экран и, если участник выиграл, сообщить промокод.

Методы и код Павла

Событийная модель. Поскольку Voximplant использует JavaScript, у которого есть событийная модель, сценарий подключается прямо к телефонному номеру, и любой сценарий начинается с подписки на событие самого звонка. Именно в callback этого события мы пишем логику звонка: что говорить, как реагировать, записывать или не записывать звонок.

call.say() для синтеза. Чтобы робот говорил, используется метод call.say(), он принимает строку, которую нужно проговорить, и тип голоса, которым бот будет общаться с пользователем — наш Павел может говорить и женским, и мужским голосом. А вообще есть библиотека голосов, которые можно подобрать для своего бота.

Модуль Net для связи с внешним миром. Сценарий может связываться с бэкендом через модуль Net, который шлёт http-запросы (а они отлично парсятся).

VoxEngine.createASR для распознавания. Чтобы бот понимал, что говорит пользователь, и переводил речь в текст, используется модуль распознавания ASR. Здесь очень важно указать язык, который вы собираетесь распознавать.

Cheat: Помогаем роботу распознавать речь. Распознавание не всегда работает идеально, но есть выход — «скормить» машине словарь из ожидаемых слов. В этом случае нейросеть сначала пройдётся по заданному словарю и, если не найдёт совпадений, определит слово самостоятельно. В нашем случае было очень удобно загрузить правильные ответы.

Sharing is caring

Чтобы окончательно разобраться в принципе работы Павла, предлагаю самостоятельно покопаться в его исходниках. Можно развернуть рептилоида на своём устройстве или посмотреть сохраненные сценарии звонка и серверный скрипт, чтобы понять принцип написания подобного голосового бота. Там всё просто — немного Express.js и в продакшн.

Платформы непрерывной разработки и интеграции (CI/CD), по мнению Gartner, сегодня находятся на пике хайпа. Интерес к ним проявляют все отрасли, делающие ставку на модернизацию в цифровой перспективе. Предлагая всё более эффективные программные решения, CI/CD получает и свою долю критики. Евгений Филатов рассказывает о месте CI/CD в современной софтверной разработке и о перспективах её развития в ближайшие несколько лет.

Конвейер качественного кода

В современной экономике использование цифровых инструментов в бизнес-решениях играет определяющую роль. Вместе с ростом сложности высокотехнологичных платформ важным фактором становится бесперебойность работы критически важных ИТ-систем. Коснулась эта тенденция и разработки программного обеспечения.

На этапе разработки возможность непрерывного тестирования и доставки кода позволяет увеличить скорость и качество готовых решений. Непрерывное (несколько раз в день) слияние рабочих копий программного кода в общую основную ветвь и тестирование результатов оформилось в «концепцию непрерывной интеграции и доставки софта» (англ. Continuous Integration & Continuous Delivery или сокращённо CI/CD). Впервые её предложил Гради Буч в 1991 году.

Принцип действия CI/CD похож на конвейер: методика выполняет интеграционную функцию, включая различные типы автоматических тестов на каждом этапе, с последующей доставкой и развёртыванием завершённого кода в готовый продукт для конечного пользователя.

CI/CD-платформы, на базе которых реализуется концепция, поддерживают выполнение регулярной автоматизированной сборки проекта для оперативного выявления дефектов и решения интеграционных проблем. При стандартном подходе (каскадная разработка ПО или Waterfall-методика), где разработчики независимо трудятся над разными частями системы, стадия интеграции является заключительной, и при выявлении ошибок может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость работы и сделать её более предсказуемой за счёт раннего и непрерывного обнаружения и устранения ошибок и противоречий.

По своей сути концепция CI/CD реализует идеологию сращивания разработки и эксплуатации ПО (Development & Operations, DevOps) и соответствует основным принципам Agile в части рекомендаций по использованию автоматического тестирования для быстрой отладки рабочей версии софта.

Если Agile – это устранение зазора во взаимодействии заказчика и разработчика, а DevOps – снятие границ между разработчиком и администратором, то CI/CD – это воплощение стратегий и компонентов DevOps на практике.

Overhype 80 lvl

Сегодня CI/CD – самая хайповая методика софтверной разработки, которую стремятся применять практически для всех задач. Со временем, скорее всего, найдётся какая-то ниша, где CI/CD признают оптимальным инструментом со статусом «золотого стандарта», но и waterfall-метод при этом полностью тоже не исчезнет.

Сейчас можно говорить о том, что методика идеально применяется для любых задач, где ведётся новая софтверная разработка, особенно базирующаяся на микросервисной архитектуре.

Для внесения корректив в монолитные ИТ-системы без дополнительной доработки (например, крупные процессинговые системы для банков с релизами обновлений 3-4 раза в год) CI/CD не подходит, поскольку для таких задач требуется полная перестройка всей архитектуры.

Другой вопрос, что не везде даже новую архитектуру, создающуюся под новую систему, можно заточить под CI/CD. Пока что очевидный спектр задач для методологии включает в себя всё, что касается веб-разработки, e-commerce, омни-канальных решений, словом, всего комплекса frontend и middleware компонентов. Для существующих core-систем каскадная парадигма пока остаётся оптимальным выбором.

Особенности развёртывания CI/CD-платформы

Главная сложность перехода на CI/CD заключается в адаптации подхода, где на первом месте находятся процессы, а технологии – только на втором. Необходимо выстраивать новые процессы, определять новые роли людей, находить точки интеграции уже существующих и новых процессов. Смещение акцента с софта и «железа» на людей и организационные аспекты работы для многих становится серьёзным вызовом.

Второй момент – в CI/CD ответственность разработчика за конечный результат становится гораздо выше. Теперь он не просто пишет абстрактный код по ТЗ, а ещё и мгновенно его тестирует своими же силами. Отсюда вытекают более высокие требования к компетенциям специалистов.

В CI/CD разработчик не просто пишет абстрактный код по ТЗ, а ещё и мгновенно его тестирует своими же силами.

При этом не стоит путать классических «инфраструктурщиков», которые конфигурируют оборудование, заливают системное ПО и проводят настройку инфраструктурных компонентов системы, с новым поколением CI/CD-профилированных сотрудников. CI/CD-специалисты должны разбираться не только в инфраструктуре, но и в её надстройках – Kubernetes, TeamCity, Jenkins и другом платформенном ПО. Можно сказать, что в CI/CD-концепции поддержка платформы добавляется к стандартной поддержке ИТ-инфраструктуры компании.

Ещё одна особенность CI/CD сегодня – огромный выбор open-source программных инструментов, из которых формируются платформы. При этом в состав многих зарекомендовавших себя платформ входят всем известные и доступные инструменты. Специалисты по CI/CD обеспечивают оптимальную подборку имеющихся на рынке инструментов, ориентируясь на задачи проекта, а также на road map их развития в плане поддержки актуальности версий.

Выбрать именно те инструменты, которые оптимально подойдут для удовлетворения клиентских пожеланий и специфики проекта, – нетривиальная задача.

В целом реализация перехода на CI/CD – комплексный процесс, традиционно на этом пути компании сталкиваются с рядом сложностей. Например, при переобучении сотрудников пересмотр существующего рабочего процесса неизбежен, а это может вести к недовольству со стороны менеджеров.

Бонусы и profit

В CI/CD важен быстрый цикл обратной связи, позволяющий почти мгновенно определить, насколько качественными являются изменения в коде и функциональности продукта. При waterfall-подходе можно быстро вносить изменения в код, но без постоянных проверок выявление багов потребует гораздо больше времени и может произойти уже после начала коммерческой эксплуатации, причем таких «отложенных» багов в одном релизе может оказаться несколько.

Инструменты CI помогают быстро ответить на вопросы о причинах дефектов для каждого коммита, обеспечивая раннее выявление и устранение ошибок. CI/CD-платформа помогает не только оперативно тестировать, но и выводить новую функциональность для конечного пользователя таким образом, чтобы в случае выявления ошибки всегда существовала возможность либо быстро её устранить, либо «откатить» итерацию решения на шаг назад.

Одни ошибки в ПО могут содержать другие, которые включают в себя третьи и так далее. Чем больше ошибок накапливается, тем сложнее тестировать и находить их, что в результате может привести к неприятным последствиям. Между тем в CI/CD-разработке автоматизированные тесты в случае провала покажут, что именно нужно исправить. Конечно, для внедрения системы потребуется время, но это поможет разрабатывать софт максимально быстро и удобно.

Автоматизированные процессы помогают значительно снизить трудозатраты разных отделов предприятия. Без автоматизации CI/CD могут всплывать ошибки, вызванные человеческим фактором и необходимостью совершения ручных операций.

Главные плюсы CI/CD:
Скорость вывода новой функциональности от запроса клиента до запуска в эксплуатацию. CI/CD позволяет запускать обновления за считанные дни или недели по сравнению с целым календарным годом при классическом waterfall-подходе. Новые сервисы – новые конкурентные бизнес-преимущества. Появляется возможность не просто воспроизводить функциональность решений конкурентов, но и значительно опережать их в разработке и внедрении новых инструментов.
Возможность выбора оптимального варианта за счет оперативного тестирования и большего числа итераций. Отказавшись от работы над бесперспективными решениями, вы сэкономите ресурсы компании.
Качество итогового результата выше: автотестирование охватывает все аспекты продукта, что труднореализуемо при стандартном релизном подходе. Все ошибки и тонкие места выявляются и удаляются ещё на ранних этапах разработки.

Главные минусы CI/CD:Искушение перевести на Agile, DevOps и CI/CD сразу всё, что связано с корпоративными ИТ-системами, включая core-уровень, без приобретения первичного опыта. Это может серьёзно нарушить работу компании, особенно при плохой организации перехода на новую методологию.Поддержка должного уровня координации между CI и CD. Быстрые и качественные результаты от применения методики возможны только после длительной и тщательной настройки взаимодействия между командами DevOps, инженерами, scrum-экспертами и руководством компании. Самое сложное в CI/CD – человеческий фактор, налаживание здоровой командной работы, которую запрограммировать и автоматизировать невозможно.

Мода и дефицит

Важно понимать, что все методики и технологии являются не взаимоисключающими, а взаимодополняющими. Вопрос только в том, какая методология и технология займёт определённое место в общей ИТ-экосистеме.

Пока мода на CI/CD накладывается на дефицит специалистов. Внедрять методику с высоким уровнем качества в таких условиях недёшево. При этом нельзя сказать, что это как-то особенно дорого и недоступно по своей сути. В принципе, все необходимые инструменты на рынке присутствуют: софт для CI/CD не стоит космических денег. Обучиться CI/CD-методикам также возможно, в том числе и in-house специалистам компаний.

Другое дело, что бизнесу чаще всего просто некогда вдаваться во все тонкости, а тем более осваивать их на практике. В этой ситуации чаще всего окном CI/CD в компании становится новая задача, под которую привлекается профильная команда. После запуска проекта обнаруживается, что опыт, инфраструктура и платформа CI/CD применимы на других участках под прочие задачи компании. Так часто происходит в телекоме, ритейле и банках – первый проект становится «песочницей», где компетентные специалисты занимаются прототипированием, а затем итоги их занятий масштабируются на всю организацию.

Оптимальным критерием оценки правильности выбранной стратегии CI/CD-развития разработки является сравнение эффективности процессов с лидерами рынка, которые способны осуществлять интеграцию нового функционала, его тестирование и ввод в эксплуатацию в рамках 2–3 часов.

Подводя итог, CI/CD можно назвать лучшей методикой разработки софта под задачи современности, которая в своём развитии проходит через фазу отраслевого хайпа. Это не хорошо и не плохо – это просто стадия, которая обязательно закончится, и тогда мы увидим объективное место CI/CD в системе методологических подходов современной софтверной разработки.

Смотрите также: Кто такой DevOps и как им стать

Если вы хотели бы изучать блокчейн, но сомневаетесь, что на это стоит тратить время, обратите внимание на сферу применения этой технологии, которая становится всё обширнее. Помимо частных проектов, блокчейном серьёзно интересуются в государственных структурах, где прозрачность и контролируемость информации играет очень большую роль.

Популяризация блокчейна и стремительное развитие блокчейн-технологий приводит к перманентной нехватке квалифицированных блокчейн-разработчиков для создания новых решений. По данным экспертов Upwork, спрос на специалистов в области блокчейн-технологий значительно вырос за последнее время.

Созданный в качестве движущей силы первой криптовалюты, Биткоина, блокчейн сумел доказать свою полезность и в других направлениях. Технология распределённого реестра может помочь автоматизировать административные процедуры с участием государства, которые требуют внесения правовых записей в ряд реестров и регистров, касающихся прав собственности, гражданского состояния, подтверждения правоспособности, состояния здоровья. Технология может успешно применяться — и применяется — во многих отраслях:

1. Государственный документооборот (например, эстонская унитарная государственная электронная система, документооборот в ОАЭ).
2. Земельные кадастры (например, BitLand, ChromaWay, BitFury, а также единые блокчейн-реестры земельных участков в Швеции и Грузии).
3. Здравоохранение (ИТ-команда Guardtime, BitHealth, Prescrypt; разработка монолитной базы медицинских книжек для населения США и Нидерландов).
4. Бюрократические процедуры (e-Auction 3.0 — сервис электронных государственных тендеров и аукционов в Украине).
   Автомобили (HashCoins — разработка сервиса учёта транспортных средств на блокчейне Emer в России).
5. Образование (оцифровка и верификация документации об образовании позволит создать открытое и надёжное хранилище академической информации, неким примером является Coursera).
6. Юстиция (создание blockchain-базы данных судебных решений и исполнительных производств, иных систем учёта прав на различные виды имущества).

Кроме общегосударственного уровня, потенциалом обладают муниципальный и региональный:

• создание порталов общественного участия граждан в делах города — региона — страны;
• разработка единого реестра, сохраняющего сведения истории размещений муниципальных заказов;
• использование механизма для прозрачности в распределении льгот и субсидий, мест в детских лагерях и т. д.

Применение блокчейн-подхода перспективно в области голосований и выборов. Среди разработок:

• Греческий опыт введения системы электронного голосования E2E — она даёт возможность избирателю проверить время и факт отдачи его голоса за конкретного кандидата.
• Проведение внутрипартийного голосования в Техасе (при помощи Blockchain Technologies Corp).
• Австралийцы из NVB продвигают софт для блокчейн-голосования как «политическое приложение»: гражданин может проголосовать по любым политическим вопросам, дабы политики могли узнать мнение избирателей и прислушаться к нему.
• Индонезийская организация хакеров «Защити голос» основывалась, чтобы поместить в публичный доступ результаты выборов, продемонстрировав обилие фальсификаций. Гражданам предоставлялась опция проверки и подтверждения результатов со всех избирательных точек.
• «Голосование» на блокчейне для решения текущих коммерческих задач: например, держателями акций (биржа NASDAQ), а также тестирование системы e-proxy voting для владельцев облигаций (РФ).
• Предотвращение угроз и хакерских атак: блокчейн даёт возможность укрепить кибербезопасность из-за отсутствия единой точки отказа, неизменяемости реестра.

Опытному программисту, владеющему навыками работы с C++, JavaScript, HTML и CSS, разобраться в тонкостях работы с блокчейном будет не так уж сложно. А обилие задач и кадровый голод, о которых мы говорили выше, позволит ему забыть о периодах финансовой нестабильности и отсутствии серьёзных проектов.

Чем активнее развиваются IT-технологии в отдельно взятой компании, тем отчётливее становятся видны круги под глазами у сисадминов, которым приходится контролировать всё больше процессов и следить за здоровьем всё большего количества систем.

Задачу здорово облегчают инструменты мониторинга: условный Zabbix следит за инфраструктурой, а какой-нибудь 24×7 не даёт потерять клиентов в интернет-магазине.

Правда, в какой-то момент приходится с сожалением признать: мониторинга в вашей жизни стало слишком много. Причём «много» относится как к объёму однотипных средств, так и к их ассортименту, направленному на решение всевозможных задач.

Системы зонтичного мониторинга и управления событиями вывели мониторинг на принципиально новый уровень. Сравнивать их с нишевыми решениями не совсем корректно — они решают разные задачи, но переход к «зонтикам» определённо level-up для компании. Подобное ПО позволяет упростить работу технических специалистов за счёт создания единой системы управления IT-службой, включающей и поиск взаимосвязей между событиями, сгенерированными в системах разных типов, и прозрачную логику управления, и автоматизацию действий.

Зонтичных систем на рынке не так много, как, например, инструментов web-мониторинга, но сравнить есть что. Другой вопрос — как: помимо общих данных и каких-то отличительных особенностей каждого ПО, можно наметить внятные параметры оценки. Кстати, некоторые из них — например, поиск первопричин — можно встретить и в нишевых инструментах. Но касается это только продвинутых и мощных решений, а для зонтичного мониторинга подобные функции — что-то вроде обязательной программы.
Общие критерии сравнения выглядят примерно так:

• Способ установления связей между элементами. Здесь есть три варианта: ресурсно-сервисная модель, машинное обучение или всё вместе. Большинство систем выбирают машинное обучение (из представленных ниже продуктов только два имеют ресурсно-сервисную модель). Ресурсно-сервисная модель исключает неточности, связи отличаются чёткостью, но требует определённых усилий при первоначальной установке. При машинном обучении остаётся риск ошибки, а эффективно оно тогда, когда есть существенная статистика.
• Создание правил. Вещь незаменимая для приоритизации задач, и чем правила сложнее, тем больше открывается возможностей.
• Сложная аналитика (предсказания и постанализ). Предсказания сбоев, кажется, в дополнительных комментариях не нуждаются – предотвратить всегда лучше, чем исправлять.
• Шкала времени. Функция, которая встречается нечасто, но полезна тем, что позволяет вывести на экран инциденты с привязкой ко времени.
• Поиск первопричин. Возможность, которая позволяет 100 инцидентов превратить в 1 и устранить реальную проблему, а не её симптомы.
• Управление IT-службой. Создание рабочих групп и распределение зон ответственности — очень хорошо; возможность тонкой настройки и множество внутренних инструментов для взаимодействия — идеально.
• Охват. Полностью срабатывает постулат «чем больше, тем лучше». Чем больше видов мониторинга и конкретных инструментов можно собрать под зонтиком, тем выше эффективность работы.

С критериями определились, можно переходить к делу.

HP

Система выделяется на фоне прочих как раз наличием ресурсно-сервисной модели. Представляет собой эдакий конструктор со множеством модулей, покрывающих всевозможные задачи. А вот внешние интеграции не предусмотрены, что в каком-то смысле делает пользователя заложником системы. Требуется новая функция? Будьте любезны, приобретите новый модуль. Вместе с тем клиенты отмечают приличную функциональность и удобство интерфейса. В некоторых случаях недовольство вызывает работа техподдержки: в ответ на клиентский запрос компания может предложить обновить уровни поддержки. «Мы не обязаны переходить на премиальный план, чтобы получить ответ на вопрос», – вполне обоснованно негодуют пользователи.

IBM Tivoli

«Мощный и дорогой», – говорят одни. «Старая рабочая лошадка», – утверждают другие. Правы все: цена системы действительно высока, но в функциональности и надёжности ей не откажешь. Клиентам предоставляется свобода выбора: при желании можно использовать и внутренние модули, и внешние системы. Кстати, модули могут быть доработаны под требования заказчиков.

BigPanda

Одним из главных плюсов BigPanda являются открытые API, которые позволяют интегрироваться со множеством внешних систем. Продукт достаточно стабилен и надёжен, хотя некоторые пользователи замечали определённые задержки во время крупномасштабных инцидентов. Настройка относительно проста, а интерфейс понятен.

Работа технической поддержки, по мнению клиентов, достойна отдельных слов: специалисты отзывчивы к проблемам, активно взаимодействуют с заказчиком и проявляют гибкость к его требованиям.

Сервис-монитор

Отечественный продукт и вторая в списке система, имеющая ресурсно-сервисную модель. Придерживается политики максимальных внешних интеграций: заказчик может не только интегрироваться через существующие коннекторы (что важно – с бесплатным ПО), но и под заказ получить нужные, если их нет. Предлагает пользователям бесплатный пакет, что безусловно плюс. А вот отсутствие дашбордов в век визуализации и наглядности очки у продукта отнимает. Компания предоставляет услуги по внедрению и технической поддержке.

Pagerduty

Система держит курс на развитие BI-мониторинга. Отличается гибкостью и надёжностью, имеет обширные возможности внешних интеграций и внушительную библиотеку документации, которую пользователи называют «фантастической». На её изучение может уйти немало времени: первоначальные настройки часто кажутся совсем не «интуитивно понятными». Но клиенты утверждают, что только первые шаги трудные, дальнейшая же работа с инструментами не представляет сложности.

Monitis

Своим преимуществом Monitis считает простоту и наглядность. И это чистая правда. Однако достигается этот эффект за счёт упрощения функциональности: например, правила формируются на основе шаблонов с ограничением сложности.

Система больше заточена под web-мониторинг и со своими задачами справляется хорошо, но пользователи хотели бы видеть более расширенную функциональность – например, возможность глубокой аналитики. В сравнении с некоторыми конкурентами, имеющими больший функциональный потенциал, стоимость Monitis кажется завышенной.

редоставляет возможность бесплатного использования в течение 15 дней.

Zidium

Ещё один российский аналог, но в сравнении с конкурентами кажется очень уж примитивным – нет некоторых важных функций, интерфейс упрощен, охватывает далеко не все типы мониторинга. Строго говоря, основной функцией Zidium является мониторинг сайтов и приложений, хотя инфраструктурный мониторинг тоже выполняется. Предлагает заказчикам несколько вариантов: установку на своём сервере, бесплатный тариф с лимитами и развёртывание на оборудовании клиента.

И отдельно — об охвате:

Смотрите также: Огромная подборка инструментов сисадмина

Когда профессионалы, до этого работавшие по специальности, впервые дорастают до позиции руководителя, они сталкиваются с новыми видами деятельности, выполнению которых нигде не учились.

Представьте — только что вы чувствовали себя абсолютно уверенно на старой должности, ведь вы были примером для более молодых коллег, накопили огромный опыт, всегда могли дать дельный совет и отлично знали все нюансы своей работы. И вот вас повышают до руководителя отдела. Теперь требуются совершенно другие навыки, и уверенность в себе быстро испаряется.

Этот момент проходили почти все нынешние руководители, так как в подавляющем большинстве они не обучались управлению в университете, а вышли из тех, кто на своей позиции проявил себя как специалист, показал высокий уровень профессионализма и зачатки личных качеств управленца.

Я сам проходил этот путь, а затем многократно помогал его пройти своим подчинëнным. И наконец, следуя собственному совету, который вы увидите дальше в этой статье, решил систематизировать свой опыт и поделиться им с широкой аудиторией читателей.

Одним из навыков, которые новоиспечëнным руководителям даются сложнее всего, является навык делегирования, и рассказ здесь пойдëт именно о нëм.

Меня зовут Антон Попович. Более 15 лет я работаю в сфере IT, из них более 10 лет руковожу другими айтишниками. Последние несколько лет являюсь техническим директором — сначала наëмным в чужой компании, а теперь в собственном стартапе — лаборатории по исследованию искусственного интеллекта HINT Lab.

О важности делегирования

Многие боятся делегировать, потому что считают, что «сами всë сделают лучше». И небезосновательно — чаще всего, это действительно так.

Однако, делая всë самостоятельно, невозможно создать робота, написать социальную сеть или любую другую сложную систему. Сфера влияния, до которой можно «дотянуться», действуя в одиночку, весьма ограничена. Примеры систем, приведëнные выше, требуют для реализации

• и сочетания различных компетенций, которые редко присутствуют у одного человека,
• и такого объëма работы, который вряд ли можно выполнить без команды за разумное время.

Поэтому переход к делегированию, хоть и несколько снижает качество, но открывает безграничные возможности. Смысл делегирования — в масштабировании, в переходе на новый уровень достижимых целей.

Интересный факт: чувство гордости за собственный продукт не пропадëт от того, что существенную часть работы выполнили не вы, а ваши подчинëнные. Один из парадоксов заключается в том, что гордиться результатом как в полной мере своим будет и «Вася», который непосредственно выполнил работу, и менеджер, который руководил процессом, и владелец компании, который нанял этого менеджера, и инвестор, который вложил деньги в эту компанию и дал ей возможность существовать. Каждый получит свой серотонин, ощущая, что именно благодаря ему был реализован проект.

Что же касается самых первых результатов делегирования — они вас вряд ли порадуют.

Поначалу вам может показаться, что попытки делегировать отнимают кучу времени — столько, что сам бы уже 100 раз сделал (да ещë и с лучшим качеством). Но будьте мудрее — доверяйтесь не эмоциям, а математике и здравому смыслу. Чтобы наладить процесс делегирования, нужно единовременно вложить много ресурсов, но сделав это, вы будете получать экономию времени при каждой новой итерации. Рано или поздно наступит точка окупаемости, после которой выигрыш времени от делегирования станет положительным и будет только расти.

В спорных случаях, когда выгода от делегирования кажется сомнительной, произведите расчëты в прямом смысле слова, сравнив ожидаемые затраты времени на наладку процесса с последующим выигрышем на каждом повторении, помноженном на ожидаемое количество повторений. Не забудьте учесть в расчëтах возможные форс-мажоры и финансовый аспект. Если ROI от такой инвестиции времени ожидается положительным, то делегируйте!

Правила делегирования

Теперь опишу по пунктам правила, которыми я руководствуюсь при делегировании.

0. Устранение — автоматизация — делегирование

Перед тем, как начинать делегирование, я проверяю задачу по чеклисту, приведëнному строчкой выше.

Если немного копнуть, часто оказывается, что какие-то действия вообще не приносят полезного результата, а являются рудиментами решений, принятых когда-то давно, при других обстоятельствах. К примеру, в компании, куда я пришëл техническим директором, проводились еженедельные «отчëтные» митинги, а также ежедневные стендапы по SCRUM. На еженедельных митингах было скучно, так как ребята по второму разу повторяли то, что рассказывали на стендапах. Когда начали копать, выяснилось, что еженедельные митинги появились ещë до внедрения ежедневных, а потом их просто забыли отменить.

Вспомните теорию о том, что 20 % действий приносят 80 % результата, и критически проанализируйте, не относится ли процесс, который вы хотите делегировать, к наименее продуктивным, дающим только 20 % результата. Если это так, то просто отмените его.

Если же процесс оказывается нужен, то подумайте, можно ли его автоматизировать. Обратите внимание, что почти любой SaaS предоставляет API как альтернативу визуальному интерфейсу, поэтому автоматизировать можно гораздо больше процессов, чем кажется изначально.

И только если первые два варианта не подходят, стоит задуматься о делегировании.

1. Самостоятельная проработка

Некоторые видят делегирование как способ сплавить подчинëнному задачу, которую самому делать не хочется или не понятно, как. Однако, в таком случае не стоит ожидать хорошего результата и от делегирования.

Всë, что вы делегируете подчинëнным, вы должны уметь хорошо делать сами; понимать, как это действие стыкуется с другими процессами компании и быть лично знакомым со всеми граблями, которые могут возникнуть по ходу его выполнения. В конце концов, сможете ли вы дать компетентный совет, если что-то пойдëт не так, а вы и сами не понимаете, что происходит?

Делегирование — это освобождение себя не от самых сложных, а от самых простых дел.

Когда вы прекрасно понимаете все аспекты процесса, знаете, что может пойти не так, и легко выполните задачу сами, но на это у вас уйдëт больше времени, чем необходимо на постановку этой задачи подчинëнному, — смело делегируйте!

Причëм не так важно, что подчинëнный потратит на эту работу больше времени, чем вы. Мерилом в бизнесе является не время выполнения задачи, а деньги. Иногда финансовая экономия для фирмы по итогам делегирования сохранится уже за счëт разницы в ваших зарплатах, но даже если это не так, то, отказываясь от делегирования из соображений заботы о финансах компании, вы быстро станете критичным звеном, в решение которого будет упираться любая деятельность в вашей фирме. Поэтому, даже если в краткосрочной перспективе вы сэкономите какое-то количество денег, в будущем это окажет гораздо более существенное негативное влияние на финансовое состояние компании.

2. Описание процесса

Для начала я бы посоветовал тщательно расписать подчинëнному инструкцию и описать типичные грабли, которые могут встретиться ему на пути. Вопросов у него и так возникнет достаточно, но описанная на твëрдом носителе канва позволит ему гораздо лучше ориентироваться в проблемной ситуации, чем если бы вы описали нюансы голосом в момент, когда у него ещë нет опыта выполнения этой задачи и он может не до конца понимать, что вы говорите.

Я стараюсь описывать регулярно выполняемые мной процессы даже исключительно для себя, когда речь ещë не идëт ни о каком делегировании, просто чтобы самому затем идти по описанному процессу, а не вспоминать его из головы. Это помогает мне, во-первых, не забыть и не пропустить какое-то действие, а во-вторых, сосредотачиваться не на порядке шагов, а на том, что именно нужно сделать.

Когда происходят отклонения от нормального сценария, влияющие на алгоритм дальнейших действий, я тоже сразу их документирую. Это очень удобно и не только спасает от ошибок, но и помогает впоследствии значительно проще делегировать описанный процесс. Чем меньше неожиданностей случится при первых прогонах процесса подчинëнным, тем выше шанс, что делегирование с самого начала будет давать качественные результаты, а у подчинëнного сложится уверенность в себе — «ух ты, я всë могу», а не «я тупой, а тут всë так сложно».

Кстати, в последней ситуации вы можете усугубить дело, считая так же, и человек начнëт ко всем новым обязанностям подходить, чувствуя себя заведомо обречëнным на провал, что не пойдëт на пользу достижению цели. В ваших интересах позволить подчинëнному испытывать уверенность в себе.

В этом вам помогут следующие установки:

• Когда человек не видит очевидных отклонений от того, как должно быть, — он не тупой. Просто он не знает, как должно быть. Вы видите одну и ту же картинку при каждом запуске и сразу замечаете, если что-то идëт не так. Он же запускает процесс первые разы и понятия не имеет, чего ожидать. Например, индикатор «306 ошибок за последний час» может моментально дать вам понять, что случилась нештатная ситуация, а другому сотруднику не сказать ничего, потому что он просто не знает, сколько ошибок бывает в норме.
• Когда человек делает не то, что написано, и поэтому получает непредсказуемый результат, проблема может заключаться и в том, что он криво прочитал, и в том, что вы криво написали. Пока нет статистики в пользу одного из этих вариантов, их априорную вероятность следует считать равной и критически посмотреть на своë творение.
• Если человек совершает странные действия — держите в голове, что большинство людей искренне стараются делать как лучше (пока их энтузиазм не убивается несправедливым наказанием). Скорее всего, вы оба достаточно рациональны, а разница в решениях обусловлена разными вводными. Вместо обвинений в иррациональности, сравните ваши вводные и локализуйте те, что отличаются.

Если же человек задаëт слишком много вопросов, на которые он мог бы ответить и сам, просто спросите: «А ты бы сам как сделал?». Это заставит его подумать.

Вообще, я уже давно придерживаюсь концепции «трëх вариантов ответа»: человек, идущий с вопросом к начальнику, должен прийти с тремя вариантами ответа, один из которых он рассматривает как предпочтительный. Секрет в том, что при таком подходе 90 % вопросов решаются без необходимости у кого-то спрашивать, а оставшиеся 10 % уж точно заслуживают обсуждения.

3. Мотивация

Речь идëт ни в коем случае не о финансовой мотивации, а скорее о «гормональной». Один пример я уже приводил выше — когда человек видит, что новая деятельность ему даëтся с первого раза, он получает прилив гормонов счастья и чувствует себя хорошо. Я могу ответственно заявить, что впоследствии люди остаются в тех компаниях, где им нравится работать, а не в тех, где чуть больше платят. В качестве подтверждения приведу в пример тот же Яндекс, где традиционно зарплаты несколько ниже рынка, но текучка при этом низкая.

Другим примером гормональной мотивации является понимание смысла своих действий. Если сотрудник получает на вход не только алгоритм действий, но и понимание, как его часть задачи встраивается в более глобальный бизнес-процесс, какую окончательную цель он преследует и как от его действий зависит общий результат, то он понимает свою значимость для компании и будет мотивирован на получение качественного результата. За примером далеко ходить не надо — все знают, какой результат получается, если программист выполняет задачу по формальному ТЗ, не зная, для чего это делается.

В книге «Социальная психология» Дэвида Майерса приводятся результаты эксперимента, показывающего, что больше ошибаются не те, кто выполняет слишком сложную для себя работу, а те, кто выполняет слишком скучную.

Сотрудник, понимающий смысл своих действий, больше вовлечëн в процесс и допускает меньше ошибок, а также получает дозу окситоцина от чувства сопричастности к общему делу, что лучше любых тимбилдингов объединяет коллектив.

Кроме того, понимая общую картину, сотрудник сможет в большинстве случаев сам разобраться с возникающими по ходу дела мелкими проблемами.

Ещë одним хорошим мотиватором является положительная обратная связь по итогам. Если в результате деятельности, включавшей в себя работу вашего подчинëнного, был достигнут значительный результат, обязательно сообщите ему об этом, чтобы он осознал, что причастен к этому результату. Это будет и признанием того, что у него отлично получается его часть работы (дофамин), и того, что он значим для компании (серотонин). Такая обратная связь мотивирует человека делать лучше, больше и всячески развиваться.

Если же работа выполняется не так хорошо, как могла бы, — обратите внимание сотрудника и на это. Но критикуйте так, чтобы не отбить желание исправиться:

• критика должна быть направлена не на человека, а на его работу (проблема не в «тебе», а в «результате твоей работы»). Если проблема в человеке, коррекция результата требует изменения свойств личности. Если же проблема в результатах, они исправляются без коррекции личности. Второй тип критики воспринимается человеком значительно более лояльно;
• критикуйте конструктивно — опирайтесь только на факты, а не ощущения, и предлагайте, что и как можно сделать иначе, чтобы результат в следующий раз стал лучше.

4. Контроль

Контроль важен — в отсутствии контроля качество процесса медленно, но стабильно деградирует.

Если есть возможность выявить формальные критерии успешности процесса и отслеживать их, то лучше начать делать это сразу. Так не только вы будете видеть, как меняется со временем качество процесса, но и сам сотрудник, для которого через эти KPI (ключевые показатели эффективности) рабочий процесс в некоторой степени геймифицируется — ему самому будет интересно их улучшать. Важно, чтобы значения KPI, выбранные для сотрудника, находились целиком в сфере его влияния.

Если же из-за характера деятельности не удаётся определить формальные критерии еë успешности, то остаëтся изредка проводить выборочную проверку результатов и указывать сотруднику на обнаруженные проблемы. Помимо того, что сами проблемы будут решаться, такой формат держит сотрудника в тонусе — он знает, что проверка может произойти в любой момент и коснуться любых его результатов.

5. Переход от делегирования задач к делегированию ответственности

Понимание сотрудником смысла своей деятельности (о котором я писал выше), способствует проявлению его самостоятельности в более широком смысле. Например, если вы уже несколько раз делегировали офис-менеджеру запуск процесса обработки нового кандидата, когда видели новый отклик на размещëнную вакансию, передайте теперь ему ответственность самостоятельно отслеживать новые отклики. А впоследствии — вести всю работу с новыми кандидатами, включая размещение вакансии. Избавившись от необходимости продумывать работу с кандидатами, вы освободите больше времени, чем просто делегируя проведение собеседований.

Вместе с ответственностью важно передать и права, иначе у сотрудника не будет рычагов для реализации своей ответственности.

Например, если вы просите офис-менеджера отслеживать новых входящих кандидатов, предоставьте ему возможность выбрать способ, которым он будет это делать. Вы сами могли уже очень давно отказаться от любых пуш-уведомлений, а для него это может быть привычным вариантом отслеживания новых писем. И если вы навязываете ему отказ от пуш-уведомлений, то не имеете права потом критиковать за то, что он пропустил письмо.

Вы можете рекомендовать свой вариант и приводить аргументы в его пользу, но право окончательного выбора способа должно быть за исполнителем, несущим ответственность за результат перед вами. Ваше право выбора реализуется в другой момент — когда вы определяете, кого взять на работу и кому доверить возможность принятия собственных решений.

Помимо прочего, навязывание вашего варианта даëт возможность исполнителю саботировать процесс, объясняя любые провалы вашим неудачным выбором способа.

6. Отладка на метауровне

Когда процесс делегирован, наступает время отладки. Проблемы, безусловно, будут — вам следует заранее принять это как факт перед началом делегирования.

Каждый раз, когда в сфере вашей ответственности (которая, конечно, включает в себя сферу ответственности всех ваших подчинëнных) происходит проблема — устраняйте не только саму эту проблему, но и причину еë появления. А также, по возможности, причину появления той причины, и так далее, куда сможете дотянуться. Борьба с причинами, а не с симптомами, делает систему более устойчивой в будущем, ведь в результате одного события вы навсегда устраняете целый класс подобных проблем.

Приведу реальный пример из своей жизни. Админу была делегирована ответственность за поддержание работоспособности серверов. Утром я прихожу на работу и понимаю, что важный сервер лежит уже 4 часа, а мы стремительно теряем деньги.

1. Первым делом, конечно, мы восстановили работу сервера.
2. Интересуюсь у админа, как же так получилось, ведь бесперебойная работа сервера и моментальное реагирование на все отключения находятся в его ответственности.
3. Админ сообщает, что на такой случай он настроил уведомление на свой телефон, которое должно было разбудить его ночью, но сегодня оно почему-то не сработало.
4. Иду в сервис уведомлений и вижу, что он не оплачен. За своевременную оплату отвечает бухгалтерия.
5. Иду в бухгалтерию и узнаю, что бухгалтер в суматохе забыла его оплатить. Говорит, что впредь будет внимательней и больше не забудет.
6. Я спрашиваю, как они сейчас хранят информацию о том, когда что надо оплачивать, и получаю ответ, что регулярных оплат не так много, поэтому они просто держат в голове все даты регулярных платежей. Бухгалтер настаивает на том, что этот способ достаточно надëжный и менять ничего не требуется, просто единичный форс-мажор.
7. Прекрасно понимаю, что если один раз это произошло, то может произойти и в будущем. Особо пугает то, что текущий процесс не масштабируется и точно сломается при увеличении количества используемых сервисов.
8. Предлагаю завести регулярные напоминания на все оплаты в Google-календарь. Пусть напоминания приходят в тот момент, когда оплата уже должна быть совершена, но крайний срок ещë не наступил. Когда напоминание придëт, бухгалтер вспомнит, совершила ли она оплату к этому моменту, и если да, то просто проигнорирует его. Но если оплаты не было, это напоминание станет спасительным.
9. Бухгалтер сказала, что решение отличное и простое и она бы с удовольствием им пользовалась, просто ей это не приходило в голову.
10. Помогаю бухгалтеру настроить все напоминания и получаю обещание, что она таким же образом будет заводить напоминания на все новые сервисы, которые будут появляться в будущем. На всякий случай, пишу ей пошаговую инструкцию.

В итоге мы докопались до сути проблемы, и это, я уверен, спасло нас от множества повторений этого факапа в будущем. По результатам разбирательства был внедрëн более надëжный способ контроля регулярных оплат в бухгалтерии, а мы для дополнительной гарантии настроили на своей стороне уведомления на просрочку оплаты всех сервисов, которые срабатывают за сутки до их отключения — на случай, если бухгалтер запутается или сделает что-то не так.

Этот пример иллюстрирует, как я ищу причины случившихся проблем, а также показывает несколько других принципов, которым я призываю следовать:

1. Не заканчивать анализ, когда выяснилось, что причина проблемы находится за пределами отдела. В данном случае бухгалтеры просто оказались далеки от технологий и не смогли бы сами придумать надëжный способ гарантировать своевременность оплат, если бы мы, айтишники, им не помогли. Ищите решение, а не оправдание, ведь лучше работать в компании, которая находится в порядке и стабильно растëт, чем в компании, где вы всегда правы, но которая при этом скоро развалится.
2. Не опускать руки, когда человек отказывается от изменения процесса. Войдите в его положение, подумайте, почему он не хочет ничего менять, и попробуйте аргументировать, почему изменения оправданы. Но, как я уже упоминал выше, помните, что вы не можете безальтернативно навязывать свой вариант человеку, несущему ответственность, а можете только рекомендовать и аргументировать свою позицию.

7. Переход от реактивных дел к проактивным

Непрерывное развитие делегирования и ликвидация обнаруженных классов проблем ведëт к тому, что делегировать удаëтся всë больше. Значит ли это, что сперва вы освободите себя от перегруженности, а затем и вовсе от любой работы?

На самом деле, цель делегирования не в том, чтобы раздать все задачи и расслабиться. Значительно более продуктивная позиция — это делегировать все реактивные задачи, чтобы заняться проактивными.

Реактивными называются задачи, выполнение которых ожидается в качестве реакции на внешние обстоятельства — тикеты от руководства, случившийся форс-мажор, наступление определëнного момента времени (регулярные задачи — например, ежемесячная оплата сервисов). Пока вы держите реактивные дела на себе, вы не сможете в любой момент спокойно заболеть, уйти в отпуск или уволиться. Всë держится на вас. Хуже всего, когда несколько реактивных задач возникают одновременно — если вы до сих пор не можете их никому делегировать, вам придëтся сидеть на работе допоздна, доделывая их, даже когда все ваши коллеги и подчинëнные разошлись по домам.

Если же каждую из реактивных задач можно кому-то делегировать, то, по крайней мере, вы будете избавлены от адских дней переработки — задачи всегда могут быть равномерно и честно распределены между сотрудниками. Причëм это не значит, что когда возникает форс-мажор, вы должны его делегировать, а сами сидеть ковырять в носу или уйти домой. В каких-то случаях вы можете взяться за решение самостоятельно, но важно, чтобы была возможность отдать задачу кому-то другому на случай, если падает несколько таких дел одновременно, вы болеете или находитесь в отпуске или начинаете новый проект, и сейчас не лучшее время, чтобы переключаться на старый.

Ситуация стопроцентного делегирования на практике достижима с трудом, но к ней можно подобраться очень близко — настолько, что вовлечения в оперативные задачи на пару часов в неделю будет достаточно, чтобы в оставшееся время поддерживать автономность отдела.

И когда вы видите, что ваш отдел работает как отлаженный механизм без вашего участия, наступает магия. Вы можете планировать свой день по своему усмотрению. Выбирать дела не в порядке срочности прилетевших проблем, а в порядке стратегической важности для компании. Вы сможете сесть и спокойно подумать, что вы со своим отделом можете сделать, чтобы вывести компанию на новый уровень. Внедрить систему мониторинга бизнес-показателей? Оптимизировать затраты на инфраструктуру? Избавиться от угрожающего технического долга?

Таких важных дел в компании масса, но обычно они откладываются, так как всегда есть дела срочные. И когда число срочных дел уменьшается благодаря планомерной работе над ошибками, а оставшиеся распределяются между вашими подчинëнными, у вас, наконец, появляется время на то, чтобы заняться делами важными.

По своему опыту могу сказать, что этот момент наступает внезапно, и его сложно предвидеть. Последние несколько недель вы могли, каждый день перерабатывая, в суматохе решать различные проблемы, а сегодня прийти на работу и понять, что список реактивных дел пуст. Если вы прямо сейчас уйдëте домой — ничего страшного не случится и ничего не будет отложено до вашего возвращения. Всë, пришло время больших дел!

Если же над вами в компании ещë огромная вертикаль власти и стратегические дела решаются не на вашем уровне — подойдите к своему начальнику и скажите, что вы готовы взять на себя новую ответственность. Так происходит карьерный рост.

Вывод

Такой подход к делегированию выгоден всем сторонам в вашей компании:

• ваши подчинëнные развиваются, приобретают новые навыки и опыт, расширяют свои полномочия — в общем, профессионально растут;
• компания переходит на новый уровень организации трудовых процессов — снижается число форс-мажоров, улучшается переносимость знаний и процессов при смене кадров;
• вы переходите от ежедневной рутины к выполнению стратегических целей компании, можете брать более крупные проекты и расширять количество подчинëнных, потому что порядок в вашем отделе и возможность не проникать во все дела вам это позволяют.

Как делегировать процесс: порядок действий

0. Проверьте, нельзя ли от него просто отказаться, либо автоматизировать.
1. Выполняйте процесс самостоятельно, пока он не станет для вас рутинным.
2. По ходу дела документируйте основной алгоритм и все возможные отклонения от него.
3. Делегируйте выполнение процесса подчинëнному. Давайте обратную связь, хвалите, не судите строго.
4. Контролируйте качество выполнения процесса подчинëнным по автоматически собираемым метрикам, либо, если это невозможно, вручную.
5. Перейдите от делегирования отдельно взятой задачи к делегированию связанной с ней ответственности.
6. Обнаружив проблему, исправляйте не только еë симптом, но и причину, причëм старайтесь закапываться в поиск причины как можно глубже.
7. По мере освобождения времени от рутины, начинайте всë больше проактивно задумываться о важных делах.

Давайте представим ситуацию, когда вы и ваша команда пишете интересный и сложный код на JavaScript. Причём этот код в кратчайшие сроки нужно использовать в проекте. Если его функциональность действительно уникальна, то в процессе разработки и у вас, и у членов команды вполне резонно возникнет вопрос: «Как защитить код от копирования?».

Как защитить код: веб-сокеты, крипторы и обфускация

Разумеется, все мы прекрасно понимаем, что JavaScript выполняется на стороне браузера. И любой зашифрованный код всегда можно расшифровать, если знать принципы работы браузера. Поэтому можно попробовать лишь затруднить понимание данного кода, а это, в свою очередь, очень сильно помешает злоумышленнику модифицировать его под свои нужды.

Итак, есть несколько вариантов защиты кода:

1. Использовать веб-сокеты.
2. Использовать крипторы.
3. Сделать обфускацию кода.

Крипторы приводят код в нечитаемый вид, используя, как правило, base64 (что неизбежно приводит к увеличению объёма кода примерно на 30%). Затем к полученному результату прибавляется так называемая «соль» — набор символов, который при разборе кода функцией-дешифровщиком используется в качестве ключа. Ну а потом вся строка кода обычно выполняется через eval(). Проблема крипторов в том, что если понять принцип их работы, отсечь «соль» и декодировать, то сразу становится доступен весь код в его исходном виде.

Обфускаторы же изменяют сам код, вставляя между операторами нечитаемые символы, меняя имена переменных и функций на набор визуально непонятных символов. При этом объём кода также сильно увеличивается из-за вставки дополнительного псевдокода, а также замены символов на hex, когда любые символы переводятся в их hex-значения (например, латинская буква ‘e’ может быть записана как ‘\x65’, причём это прекрасно интерпретируется любым браузером). Можете посмотреть, как работает перевод в hex через любой сервис Text To Hex, например на Crypt Online.

Применение обфускаторов сильно усложняет дальнейшую отладку кода, поскольку это необратимый процесс. К тому же в некоторых случаях они могут повлиять на функциональность кода. Попробовать обфускаторы можно на любом сервисе обфускации, к примеру этом или этом. Также в Сети можно найти платные крипторы-обфускаторы, в настройках которых вы сможете указывать степень защиты, время жизни скрипта и прочее, при этом скрипт будет намертво привязан к вашему домену, т.е. для дешифровки будет использоваться уникальное для вашего хоста значение. Стоимость таких крипторов начинается от 45 $. Кроме этого, перед обфускацией вы можете предварительно минимизировать код, заменив все имена переменных и функций на их односимвольные синонимы. Отличный и очень популярный инструмент на Node.js — UglifyJS, который работает как в автоматическом режиме (скажем, через Gulp), так и в режиме командной строки.

Также есть всем известный Closure Compiler от Google, который кроме минимизации анализирует JavaScript-код, удаляет мёртвый код, переписывает и сводит к минимуму то, что осталось. Он также проверяет синтаксис, ссылки на переменные и типы и предупреждает об общих ошибках JavaScript. Имеет хорошо документированный API.

Кроме предложенных методов можно сделать следующее:

• использовать WebStorage и скрывать там JavaScript код;
• прятать часть кода в отдельном файле на сервере и вызывать его через XMLHttpRequest;
• использовать побитовые операторы для замены чисел на наборы скобок и знака ~;
• делать субституцию стандартных функций и методов JavaScript.

Всё это, разумеется, не станет стопроцентной защитой. Тем не менее чем сложнее процесс дешифровки, тем больше шансов, что после множества неудачных попыток любители копировать чужой код оставят ваш сайт в покое.

Зашифровка кода на примере JavaScript-калькулятора

Не так давно я разработал JavaScript-калькулятор для расчёта стоимости услуг, с большим количеством взаимосвязанных параметров. Руководство поставило задачу защитить данный скрипт от копирования, чтобы конкуренты не смогли использовать его на своих сайтах. Искал различные решения, ничего подходящего не нашёл, поэтому начал писать собственное. Представляю его ниже.

Обращаю ваше внимание на то, что любой код можно расшифровать, просто для этого нужно время. Поэтому данное решение, разумеется, не идеально. Тем не менее, чтобы его раскрыть, требуется время, внимательность и усидчивость. И это может оттолкнуть ваших конкурентов от идеи скопировать ваш скрипт. Большинство из них после нескольких неудачных попыток просто будут искать аналог похожего скрипта на других ресурсах.

По итогам работ в браузере вы увидите нечто такое:

При этом все зашифрованные скрипты будут работать корректно. Опытный взгляд программиста сразу визуально определит кодирование через base64. Но при попытке расшифровать строку любым base64 декодером, будет ошибка. Если вставить скрипт в alert (такой метод также рекомендуют на форумах для дешифровки кода), то результат также будет нулевым.

При этом никто ведь не знает, что здесь зашифрован именно скрипт. Это может оказаться какой-то параметр, текст или изображение. Через base64 можно зашифровать всё что угодно.

Поищем в коде функцию glob(), которой передаётся шифрованная строка. Вот она: glob=function(s){sfd(rty(s.substring(-~[])));

Видим ещё несколько функций sfd() и rty(). Ищем эти функции. Вот они:

На этом месте многие закончат попытки расшифровки и оставят ваш сайт в покое.

Рассмотрим алгоритм подробнее.

Как защитить JavaScript от копирования на своём сайте

Первым делом указываем в футере сайта путь на скрипт и тут же кодируем его:

В строке выше мы говорим интерпретатору PHP взять файл script.js, далее закодировать его через base64, прибавить строку ‘K’ и всё это записать в переменную $filebase64.

Добавление строки ‘K’ (это может быть любая латинская буква или комбинация букв или цифр) защищает нас от того, что желающий скопировать ваш скрипт расшифрует его с помощью alert() или онлайн-дешифратора. Ведь с дополнительными символами скрипт не будет работоспособен.

Затем где-то дальше в коде вызываем скрипт:

Пусть этот скрипт вызывается отдельно, подальше от других скриптов и ссылок на скрипты.

Далее где-то в файле с общими скриптами сайта, отдельно от других скриптов, вставляем вызов функций дешифровки. Вставлять можно независимо от других функций и библиотек.

Разбираем подробно что здесь происходит.

Наша основная функция glob() принимает один параметр s. Он сразу передаётся функции substring() с параметром -~[] (это равно 1 в зашифрованном виде), которая извлекает из s строку начиная с первого символа и до конца. Следовательно, если мы в PHP-коде в качестве строки прибавляли более одного символа, скажем три, то нам нужно будет в функции substring() указать 2+(-~[]). Либо путём шифрования цифр через побитовые операторы мы можем создать запутанную формулу, часть переменных которой мы можем прятать в cookies или sessionStorage, что сделает крайне затруднительным понимание того, какое количество символов необходимо отбросить для дешифровки кода.

Пример замены цифр через побитовый оператор ~:

• -1 можно заменить на ~[]
• 1 можно заменить на -~[]
• 0 можно заменить на ~~[]

Далее полученный результат принимает функция rty(). Эта функция представляет собой набор символов, в частности: this["\x61\x74\x6F\x62"];

Попробуйте ввести это в консоли браузера и вы увидите, что на самом деле делает эта функция. Например, вы увидите:

ƒ atob() { [native code] }

Т.е. набор символов — это зашифрованная функция atob(), которая, согласно описанию на MDN, декодирует строку, закодированную с использованием base64.

Результат декодирования получает функция sfd(). Она также представляет собой набор символов: this["\x65\x76\x61\x6C"];.

Вы уже догадались, что нужно сделать? 🙂 Выполните в консоли браузера и вы увидите:

ƒ eval() { [native code] }

Здесь, думаю, уже объяснять ничего не надо. Все мы знаем, что функция eval() выполняет скрипт, полученный из строки. «Плохая практика», как сказали бы многие, для обычного кода, но в нашем случае это безопасная и нужная функция для реализации нашей идеи. К тому же напрямую к этой функции пользователь не сможет получить доступ.

Наверное, вы задались вопросом, а каким же образом функции зашифрованы в наборе символов? Очень просто: набор символов — это текст, преобразованный в шестнадцатеричную систему счисления. Т.е. это текст в формате hex (hexadecimal), в котором можно зашифровать любые символы.

Таким образом, наша расшифрованная функция выглядит так (специально разбил по строчкам, чтобы было наглядно):

В итоге отбрасываем первый символ шифрованной строки (при этом символов может быть хоть 353, и об этом никто не сможет быстро догадаться), потом дешифруем, потом выполняем через eval().

Вы можете пойти и дальше. Если каким-то образом кто-то всё же расшифрует ваш скрипт, немного усложните его, чтобы людям было сложнее модифицировать его. Например, можно поговорить о побитовом операторе ^, c помощью которого можно творить чудеса. Например, a^b^b будет равно a. В качестве b может быть использован ключ, который мы зашифруем где-то выше…

Всё будет работать как и раньше, но собьёт с толку нехороших копипастеров.

За материал благодарим нашего подписчика Дениса Лисогорского

Согласно отчёту McKinsey в США наблюдается устойчивый дефицит специалистов по машинному обучению: спрос растёт на 12% в год, а предложение — лишь на 7%, в итоге в ближайшем будущем открытых вакансий будет на 250 000 больше, чем потенциальных претендентов. В России, по оценкам HeadHunter, число позиций для специалистов по машинному обучению и искусственному интеллекту в 2017 году выросло почти в 11 раз.

CTO в LoyaltyLab и спикер курсов Binary District Александр Кондрашкин составил поэтапный гид по изучению AI. Александр утверждает: «Вокруг машинного обучения сформировался ореол дикой сложности. Это так, если вы хотите делать открытия, разрабатывать новые алгоритмы и войти в историю науки, но если просто применять известные решения на практике — порог входа вовсе не большой». Практически все программисты обладают необходимой базой для построения карьеры специалиста по искусственному интеллекту.

Что нужно для старта

Абстрактное мышление

Машинное обучение вращается вокруг поиска закономерностей в данных. Data Scientist посвящает куда больше времени генерации гипотез, подготовке и проведению бесконечных экспериментов над массивами данных, чем проектированию архитектур сервисов и их отладке. В сознании специалиста дороги и перекрестки Яндекс.Карт превращаются в графы, а статистика по снятиям наличных в банкоматах — во временной ряд в аналитической системе. Без навыка представления обыденных вещей в абстрактном виде тут не обойтись.

Общая грамотность в математических дисциплинах

Карьера в машинном обучении требует общей грамотности в математических дисциплинах. Теория вероятности, линейная алгебра, математический анализ — предметы, которые преподают на первом курсе любой технической специальности — ещё один краеугольный камень Data Science.

Знание Python и основ backend-разработки

Третий базовый навык — программирование. Большую часть работы по Machine Learning выполняют на Python, но знание любого языка ускорит обучение.

На этапе работы с подготовленными моделями пригодятся навыки backend-разработки. Даже с поверхностными знаниями в этой области нейронную сеть куда легче превратить в удобный для использования микросервис.

Если у вас уже есть эта база, можно смело отправляться учить машины.

С чего начать

Путь будущего специалиста по Machine Learning отчасти повторяет историю развития отрасли и начинается с классических алгоритмов обучения с учителем и без, созданных ещё в прошлом веке.

Для начала годится и байесовский классификатор, и линейная регрессия, и деревья решений — простые, интуитивно понятные методы автоматической сортировки объектов. В отличие от капризных нейросетей, от них проще добиться положительной обратной связи, увидеть: «Ух ты, машинное обучение и правда работает!» — и получить мотивацию разбираться в теме дальше.

Через два-три месяца изучения основ синтаксиса и классических алгоритмов самое время перейти к нейронным сетям простой архитектуры — однослойным перцептронам. Следующий логичный шаг — заставить работать многослойную нейронную сеть, а после стоит обратить внимание на обучение с подкреплением.

Как, где и на чём учиться

Чтобы освоить базовые методы, из оборудования достаточно надёжного ноутбука с доступом в интернет. Начинающим редко требуется по-настоящему быстрое железо, а на крайний случай остаются сервисы Google, Amazon, Microsoft и других облачных провайдеров, сдающих мощности в аренду.

Курсы и тренинги

На образовательных площадках в сети опубликовано множество комплексных учебных программ на английском и русском языках.

Среди общедоступных выделяются курсы Яндекса, например, совместный проект с МФТИ: специализация «Машинное обучение и анализ данных» или «Advanced Machine Learning».

Один из самых популярных англоязычных курсов — «Machine Learning» Стэнфордского университета. Не так известны, но так же полезны и бесплатные программы «Intro to Machine Learning» и «Become a Machine Learning Engineer», которые предлагаются в Udacity.

Тем, кто хочет разобраться в нюансах применения Python для машинного обучения, стоит заплатить за «Data Science, Deep Learning and Machine Learning with Python» или «Python for Data Science and Machine Learning Bootcamp» на площадке Udemy. А для всех тех, кто хочет наладить обратную связь с преподавателями и получать знания очно, в Binary District открыт интенсивный практический курс по AI.

Практические задачи

Практиковаться можно и на самостоятельно придуманных задачах, но для учёбы такие эксперименты неэффективны. На то, чтобы собрать данные через API, очистить их и подготовить, уйдёт огромное количество времени и сил, которые можно потратить на усвоение знаний. Гораздо удобнее, когда всё придумано и сделано до вас. На образовательной платформе Kaggle публикуются задачи по машинному обучению с подробным описанием, заранее определёнными условиями и подготовленными датасетами.

Например, ставшие классикой задачи по предсказанию выживаемости пассажиров Титаника или цен на недвижимость в городе Эймс, штат Айова помогут досконально разобраться в классификации и регрессии, а распознавание рукописных цифр позволит погрузиться в работу с картинками через классическую проблему.

Что делать дальше

Стартовав почти с нулевого уровня, через полгода вполне реально устроиться на стажировку, а вскоре и на работу. Освоить нейросети сложных архитектур и ансамбли на рабочих задачах при поддержке коллег будет не так сложно, как в одиночку.

Впрочем, это не единственный способ проверить приобретённые навыки в бою. Если в вашей компании собрано достаточно много данных, стоит развивать культуру машинного обучения внутри, извлекать из баз дополнительную пользу и, вполне возможно, деньги.

Практикуйтесь, читайте, экспериментируйте и делитесь опытом — потолка в этой сфере нет. Дальнейший профессиональный рост в Data Science — результат ежедневного труда, следствие усложнения задач, общения с коллегами, участия в конференциях и погружения в бизнес-метрики. Любую модель можно сделать ещё немного лучше, но со временем придёт понимание того, когда дополнительный процент точности не стоит затраченных усилий и не принесёт пользы компании.

Конечно, ИИ не решит все проблемы человечества, и не отберёт у программистов работу. Но уже сейчас машинное обучение открывает широкие возможности, технологические и профессиональные перспективы.

Если вы недавно занимаетесь фрилансом или только планируете начать этот путь, полезно подробно изучить сферу и опыт работы других людей. Найти статьи, написанные фрилансерами, не составляет труда, но как видят такое сотрудничество сами работодатели? Антон, руководитель студии Grey-Fox, поделился своим взглядом на фрилансеров и дал пару полезных советов о том, на что стоит обратить внимание и какие фишки использовать, чтобы понравиться заказчику.

На сегодняшний день понятие «freelance» знакомо большей части людей. Для заработка по этой системе созданы отличные условия. Естественно, это удобно не только самим удалённым, так называемым «свободным» специалистам (хотя для многих понятие «свобода» и «фриланс» несовместимы), но и компаниям, которые серьезно экономят на заработной плате, аренде офиса и ещё тысяче мелочей.

Получается вполне взаимовыгодное, отвечающее современным требованиям и возможностям (что, пожалуй, даже важнее) взаимодействие. Кстати, несмотря на всю современность такого подхода, понятие «фрилансер» появилось и использовалось ещё с начала XIX века. Работа строилась по такому же принципу, но, естественно, без участия интернета. Самое известное из ранних упоминаний о термине встречается в романе «Айвенго». Так описывается наёмный воин, а если точнее, «вольный копейщик» (free lancer, free — «свободный», lancer — «копейщик»).

Работа с фрилансерами. Зачем она заказчикам?

Самая популярная причина для выбора фриланса — это, в первую очередь, желание свободы и независимости, так называемая модель заработка «с ноутбуком на берегу океана».

Следующая по популярности модель — начало карьеры. Многие начинающие специалисты отрабатывают навыки, получают опыт и наращивают профессионализм как раз за счёт задач, выполненных на фрилансе.Третья ролевая модель прихода во фриланс — подработка. Зачастую сильные и опытные специалисты находят дополнительные каналы заработка, выполняя задачи в свободное (или даже в рабочее) время.

Мотивы исполнителей весьма понятны, но для того, чтобы получать проекты, важно понимать и мотивы заказчиков. Чаще всего заказчики делятся на 3 типа, различающиеся по запросам и по ценности для исполнителя.

Частные лица

С этой категорией всё понятно: в основном сюда входят простые люди, которым необходимо выполнить задачу, в которой они некомпетентны. В основном такой тип заказчиков обладает самым размытым ТЗ во Вселенной и малым бюджетом. Работать с ними можно, но обычно это не приносит удовольствия и заработка ни в краткосрочной, ни тем более в долгосрочной перспективе. В этом сегменте можно встретить задачки, которые оплачиваются положительным отзывом или повышением рейтинга аккаунта исполнителя.

Компании, не связанные с разработкой

Второй тип — это компании, которые по своему основному виду деятельности не имеют ничего общего с веб-разработкой или другими услугами фрилансера. В основном они нанимают специалистов для личных целей — администрирование сайта, разработка макетов для акции, ведение блога и т. д. Этот вариант более заманчив для исполнителя, так как и вознаграждение выше, и есть большой шанс наладить постоянное сотрудничество.

Компании-разработчики (агентства, веб-студии и так далее)

В работе с этим типом самый высокий шанс регулярно получать проекты и высокое вознаграждение. Такие заказчики, по сути, перепродают услуги, которые покупают у вас, и при должном качестве очень высок шанс войти в доверие и получать проекты на регулярной основе.

Так как выполняемая вами работа является основным видом деятельности заказчика или её частью, такие компании обращаются на фриланс-биржу в трёх случаях:

1. Компания находится на первых ступенях развития и не может позволить себе офлайн-штат постоянных сотрудников. При таком раскладе вероятность регулярно получать заказы меньше, так как у самого заказчика на первых порах могут быть с ними проблемы. Кроме того, если они не могут позволить себе полноценный штат, возможно, и вам не смогут платить желаемую сумму.
2. Компания в данный момент имеет высокий объём задач и не может справиться своими силами. В этом случае шанс получить высокое вознаграждение выше, но есть опасность, что пик загрузки компании пройдёт и больше не повторится. Если же пик повторяется, компания переходит в 3-й вид взаимодействия с фрилансерами.
3. Компания нанимает классического аутсорс-сотрудника. В случаях, когда у компании существует спрос выше производственных мощностей, они расширяют штат либо за счёт сотрудников в офис, либо за счёт найма аутсорс-специалистов. Это самый благоприятный вариант, который позволит получать стабильный поток заказов и достойное вознаграждение.

Если вы нацелены на регулярное сотрудничество, постарайтесь на этапе переговоров определить тип заказчика, чтобы понимать, на что вы можете рассчитывать, и грамотно расставлять приоритеты.

Как заинтересовать заказчика

После того, как мы определились с видами заказчиков, их подтипами и причинами обратиться к фрилансу, необходимо способствовать их решению в вашу пользу. Я не буду подробно касаться банальных и стандартных критериев, таких как высокий уровень технических навыков в вашей сфере, грамотное портфолио и доступные цены. Поговорим о более второстепенных вещах, которые выделяют вас на фоне таких же профессионалов с хорошим портфолио и умеренными ценами.

Доказательства вашего профессионализма

Труднее всего убедить в оптимальности своей кандидатуры на первоначальном этапе, когда нет возможности доказать свои слова делом. Необходимо не только привлекательно представить портфолио, но и дать возможность убедиться в его подлинности. Например, предоставить контакты клиентов, которые могут положительно отрекомендовать вас (не бойтесь этого, не нужно давать домашний адрес и код от домофона, достаточно почты, имени и названия компании).

Помимо контактов можете просить у клиентов отзывы о работе и размещать их либо в своем портфолио, либо в сопроводительном письме. Даже настоящие отзывы зачастую выглядят фальшивыми, так что не пытайтесь придумывать их сами. Если отзывов нет — наберите пул как минимум из пяти и только после этого публикуйте.

Высшим пилотажем станет составление кейсов. В продаже практически любых услуг в интернете одним из ключевых факторов являются примеры работ, кейсы, портфолио и так далее. Задача кейсов — не только доказать, что успешные работы действительно есть (что тоже важно), не только познакомить человека с тем, как ведутся дела и реализуются проекты именно вами, но и постараться попасть в потребность клиента. То есть отобразить кейс, который схож с его ситуацией, и как бы сказать: «Я знаю, как решить вашу проблему, и уже решал её ранее». Для этого в резюме нужно разместить максимально разнообразные проекты, чтобы как можно больше потенциальных работодателей могли найти в них свою проблему и пример её решения.Не забывайте про подачу своего резюме и портфолио. Оформите его, не бойтесь потратить на это много времени — окупится. Используйте сервисы для формирования резюме, либо разработайте сайт, посвящённый вашей профессиональной деятельности. Изучите, как подают себя крупные компании, которые оказывают схожие услуги — у них можно многому научиться и многое перенять.

Коммуникация

Зарегистрируйтесь во всех возможных мессенджерах и социальных сетях, чтобы во время коммуникации с заказчиком он мог выбрать удобную ему систему. Это значительно ускорит и оптимизирует процесс коммуникации и, как результат, сделает вас более приятным подрядчиком. Установите все приложения для коммуникации на мобильный телефон и включите уведомления. Одна из основных проблем, с которыми сталкиваются студии, — долгие ответы. Это отличительная черта работы с фрилансерами, не будьте такими.

Способы оплаты

Те же принципы работают и со способами оплаты. Дайте заказчику возможность оплатить услуги удобным ему способом.

Будьте экспертом в своей сфере

Следите за новыми трендами и будьте на волне. Это вызывает доверие. Помните, что вы являетесь в первую очередь экспертом в своей сфере, а не просто руками, умеющими делать то, что скажут.

На каких условиях работать фрилансеру

После прохождения всех переговоров и согласований по вопросам, описанным выше, наступает момент, который зачастую является камнем преткновения. Я постараюсь описать выгодные для обеих сторон условия. Именно так мы работаем со всеми новыми подрядчиками. Рассмотрим взаимодействие с техническими специалистами — верстальщиками и программистами.

Первый вопрос для обсуждения — предоплата. Работодатель при первом контакте с фрилансером обычно боится отправлять предоплату (к сожалению, у каждого найдётся история, в которой исполнитель пропадал после получения предоплаты). В таком случае есть 2 варианта — отправить предоплату через «безопасную сделку» на любой фриланс-платформе, либо вести разработку на личном сервере. После презентации части проекта работодатели охотно отправляют предоплату, после чего исполнитель переносит данные на сервер заказчика, либо просто предоставляет бэкап.

В основном работа ведётся по схеме 50% на 50%. Первые 50% выплачиваются исполнителю после презентации половины заказанной работы, а вторые — после полного согласования выполненных работ. Главное, передавайте файлы только после получения оплаты. Это вполне логичное требование, так как после выполнения работы вам не имеет никакого смысла удерживать у себя файлы проекта. Если такое простое и весьма условное деление проекта на 2 части невозможно, установите порядок выплат, опираясь на план работ. Ставьте оплату после завершения каждого этапа разработки, но не стоит делать больше 5 таких этапов.

Помимо прочего, при первых проектах с новым специалистом будет вполне уместным ежедневный контроль со стороны заказчика. В основном проверяется сделанное за последние 1–2 дня, чтобы исключить, что проект будет сделан на скорую руку в последнюю ночь.

ТОП ошибок фрилансеров

В заключение пройдёмся по ТОП-5 ошибок, которые совершают фрилансеры при работе с компаниями.

Автоответы

Если вы используете фриланс-биржи для получения клиентов, не ленитесь самостоятельно читать техническое задание и писать ответ. Шаблонные автоответы отпугивают потенциальных заказчиков.

Долгое ожидание ответа

Тема, которую мы затрагивали ранее. Это настоящая боль при работе с фрилансерами. Будьте коммуникабельны и не тяните с ответом.

Затягивание сроков с воображаемой причиной

Часто в работе приходится слышать невероятные причины, по которым срываются сроки проектов. Важно понимать, что заказчика интересует только результат, а результат — проект не готов. Вместо того, чтобы придумывать оправдания, лучше скажите, когда проект будет готов, и сделайте всё возможное, чтобы сдать его раньше. Если вопрос о причине задержки всё-таки возникнет, просто скажите правду. Правда всегда работает лучше всего.

Только вебмани

Ошибка под условным названием «Только вебмани» — это отсутствие гибкости исполнителей в вопросах коммуникации, оплаты и в других аспектах. Вы должны не только хорошо выполнять свои прямые обязанности, но и обеспечивать приятное взаимодействие. Вам это только на руку.

Пропажа в последний момент

Самая жгучая боль в работе с фрилансерами — пропажа исполнителя. Думаю, не стоит объяснять, как это плохо и неприятно. Даже если вы понимаете, что не сможете реализовать проект, — сообщите об этом как можно раньше, чтобы заказчик успел найти нового исполнителя. Такой исход вполне оставляет вам шанс на продолжение сотрудничества в других проектах. Худшее, что вы можете сделать (и что очень часто случается), — в день сдачи проекта попросить отсрочку, потом ещё одну, а когда наступит дедлайн, просто не выйти на связь. Если не хотите допустить подобного развития событий, не откладывайте проекты в долгий ящик.

Заключение

Чтобы получать заказы на фрилансе, продумайте и изучите каждый аспект взаимодействия. Определите типы ваших потенциальных заказчиков. Поймите, какой тип заказчиков является вашей целевой аудиторией. Изучите их потребности и подстройтесь под них. Узнайте их опасения и развейте их.Сделайте достойную самопрезентацию. Не забывайте про множество мелочей, которые склоняют чашу весов в ту или иную сторону. На рынке с высокой конкуренцией слишком много похожих предложений, и всё решают детали. Сделайте процесс взаимодействия с вами комфортным и оптимизированным. И, конечно же, будьте профессионалом, ведь никакие ухищрения не помогут вам обзавестись постоянными клиентами, если качество ваших услуг будет низким.