Мнение

Вступление

Привет, Хабр. Недавно я получил оффер от Яндекса за один день и, не буду скрывать, я этому очень рад. Поэтому мне захотелось поделиться с сообществом своим опытом и мыслями относительно One Day Offer от Яндекса (в дальнейшем ОДО).

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

Что это

One Day Offer - это относительно молодое мероприятие. Яндекс активно начал его проводить лишь с весны этого года, поэтому оно только набирает обороты, но уже понятно, что формат будет жить и процветать. ОДО проводится по одному из ключевых направлений: фронту, бэку, мобилкам или аналитике. Помимо основной цели - поиск новых кадров - ОДО также служит доказательством, что в Яндекс можно попасть всего за день.

Лично я участвовал в ОДО для мобильщиков, поэтому буду рассказывать про опыт участия именно с точки зрения мобильщика :)

Контест

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

В моем случае контест состоял из двух задач: одна алгоритмическая и одна на платформу. По ощущениям, алгоритмическая задача была на уровне easy задач с литкода, так что с ней я справился примерно минут за 30. Правда потом потратил ещё 20 на попытку оптимизировать написанное, поскольку у задачи был follow up - написать решение, которое будет использовать константное количество памяти. Такое решение у меня написать не получилось, но это оказалось не критично. Перейдем к более интересному - задаче по платформе. Поскольку я Android разработчик, задание у меня было, что логично, по андроиду. Само по себе задание абсолютно не сложное, но очень интересное. Передо мной был код активити и нужно было перечислить все ошибки, допущенные в этих 30 строчках кода. Разбираться в коде я люблю, поэтому задание принесло мне сплошное удовольствие, и я сидел с ним все оставшееся время, дабы найти вообще все недочеты, которые там есть, и пояснить каждый. Не уверен, что нашел все, но, тем не менее, с заданием я справился и меня пригласили на ОДО.

Приветствие

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

На приветствии Дима Макаров (руководитель группы Android в Маркете) и Юра Кочарян (руководитель группы Android в Дзене) рассказали немного про Яндекс и провели для нас небольшую Q&A сессию. А ещё мы увидели вот такой вот интересный кадр

После приветствия началось первое собеседование - платформа. И мы плавно переходим к нему.

Собеседование по платформе

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

• Классы в Kotlin

• Clean Architecture in Android

• Способы хранения данных (простые и сложные вопросы)

• Жизненный цикл View и его API

• Intents

• Приоритеты OOM Killer

• Асинхронная работа в Android

• Serializable vs Parcelable

• Производительность базовых ViewGroup

• MV* паттерны

• RxJava

• WorkManager и Services

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

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

Собеседование по кодингу

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

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

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

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

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

Финалы

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

И уже через полтора часа после завершения финала я получил заветный оффер от Яндекса.

Заключение

Вот, как-то так и прошел мой One Day Offer. Также я нигде не упомянул, что на протяжении всего мероприятия на связи были рекрутеры Яндекса, которые сообщали фидбэк по собеседованиям и расписание, за что им отдельное спасибо. Ещё одним приятным бонусом стал промокод на Яндекс Еду, чтобы "ожидание обратной связи было приятным". В общем, мероприятие крутое, и я всем советую в нем участвовать. Надеюсь мой опыт и впечатления от ОДО будут полезны будущим кандидатам и помогут организаторам сделать это мероприятие ещё лучше.

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

В этом году я видел много шумихи вокруг популярного фреймворка CSS, Tailwind CSS. И подумал, что поделюсь некоторыми мыслями и опасениями по поводу этого фреймворка UI. Я приобрёл небольшой опыт написания CSS с подходом utility-first (полезность прежде всего), когда начал свою карьеру в разработке интерфейсов, несколько лет назад.

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

Вещи, которые я считаю интересными

Вам не нужно закрывать файл с HTML

Основной заголовок на официальном сайте Tailwind гласит:

Быстрое создание современных веб-сайтов, даже не покидая HTML.

Я согласен, что писать код в одном месте может быть быстрее, чем переключаться между разными файлами. Однако оставить в стороне свой HTML для меня не проблема. Это может помочь переключить контекст между разметкой и стилями. Разделение файлов HTML и CSS может помочь мне лучше сосредоточиться на выполнении поставленной задачи. Однако, когда разметка и стили смешиваются, когда вы работаете над сложным, многоязычным, отзывчивым сайтом и пользовательским интерфейсом с темами, всё может пойти наперекосяк.

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

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

Проектные ограничения

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

Именование классов CSS

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

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

То, с чем я не согласен

Tailwind не фреймворк utility-first

Подзаголовок на их веб-сайте сообщает, что CSS Tailwind:

Прежде всего утилитарный CSS-фреймворк, содержит такие классы, как...

Из увиденного я сделал вывод, что Tailwind это только утилитарный (utility-only) фреймворк. Может быть, название "только утилитарный" повлияет на то, как его воспримут новички? Я редко вижу какой-то сайт, использующий Tailwind и применяющий концепцию utility-first.

Длинный список классов может запутать

Обратите внимание на то, что я знаю о методе @apply. Рассмотрим пример из документации Tailwind:

<input  class="block appearance-none bg-white placeholder-gray-600 border border-indigo-200 rounded w-full py-3 px-4 text-gray-700 leading-5 focus:outline-none focus:border-indigo-400 focus:placeholder-gray-400 focus:ring-2 focus:ring-indigo-200"  placeholder="jane@example.com"/>

Это поле ввода с 17 классами CSS. Что проще: читать классы один за одним горизонтально или сканировать их сверху вниз? Вот так поле будет выглядеть стиль этого поля в файле CSS:

.c-input {  display: block;  appearance: none;  background-color: #fff;  @include placeholder(grey);  border: 1px solid rgba(199, 210, 254, var(--tw-border-opacity));  border-radius: 0.25rem;  padding: 0.75rem 1rem;  line-height: 1.25rem;  color: rgba(55, 65, 81, var(--tw-text-opacity));}.c-input:focus {  /* Focus styles.. */}

Я могу прочитать и понять, какие стили содержит это поле ввода, гораздо быстрее, чем в ситуации, когда сканирую HTML. Возможно, существуют плагины для редакторов кода, которые автоматически форматируют HTML-классы так, чтобы каждый из них располагался отдельно [на отдельной строке], но в DevTools браузера этого нет.

Я знаю о методе @apply, но каждый раз, когда я думаю о нём, я прихожу к выводу, что он противоречит основной концепции Tailwind. Вот тот же пример (поле ввода):

.c-input {  @apply block appearance-none bg-white placeholder-gray-600 border border-indigo-200 rounded w-full py-3 px-4 text-gray-700 leading-5 focus:outline-none focus:border-indigo-400 focus:placeholder-gray-400 focus:ring-2 focus:ring-indigo-200;}

Посмотрите на длину списка классов. Если в Tailwind в приоритете полезность, то почему в официальной документации Tailwind или в Tailwind UI мы редко видим @apply? Опять же, я вижу Tailwind как только утилитарный фреймворк.

Всегда нужно давать имена элементам

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

Привет, есть новости о bg-white w-full py-3 px-4?

На самом деле фраза будет такой:

Есть новости о дизайне поляризованной карты?

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

<person class="hair-brown length-[175] face-rounded"></person>

Код выше бессмыслица. Гораздо лучше такой код:

<person class="ahmad"></person>

Некоторые классы запутывают

Когда я только начинал использовать Tailwind, мне нужно было добавить класс, который отвечает за свойство align-items: center. Моей первой мыслью было воспользоваться align-center, но это не сработало.

Я посмотрел в документацию и впал в замешательство. Класс items-center добавит CSS-свойство align-items: center, где класс align-middle будет содержать vertical-align: middle. Чтобы запомнить их, требуется немного мышечной памяти.

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

Tailwind затрудняет настройку дизайна в браузере

Я занимаюсь как дизайном, так и frontend-разработкой, поэтому редактирование в браузере с помощью DevTools для меня крайне важно. С Tailwind работа в DevTools может стать сложнее. Скажем, например, я хочу изменить отступы для компонента. Когда я изменяю значение класса py-3, это влияет на каждый использующий его элемент страницы.

Единственный способ убрать его открыть меню .cls в DevTools, после чего класс можно будет переключить. Однако это не решает проблему. Что я могу сделать в этом случае? Добавить встроенный стиль через DevTools, а это мне не нравится. Проблема решится, если просто давать элементам названия. Добавлю к этому факт: общий размер файла полной сборки Tailwind составляет 12 МБ. Редактирование CSS в DevTools будет очень медленным.

Это означает, что разработка в браузере неэффективна. Недавно команда Tailwind выпустила компилятор JIT (just in time), удаляющий неиспользуемый CSS. Это мешает всей идее дизайна в браузере.

Я набрал back и получил длинный список всех доступных классов CSS. При JIT-компиляции таких подсказок не будет.

Tailwind неудобен для многоязычных сайтов

Чтобы вы больше понимали, добавлю: я работаю над веб-сайтами, которые должны работать как на английском (с направлением слева направо, LTR), так и на арабском (с направлением справа налево, RTL). Рассмотрим такой код:

/* LTR: left to right */.c-input {  padding-left: 2rem;}

В отдельном файле CSS для RTL стиль будет выглядеть так:

/* RTL: Right to left */.c-input {  padding-left: 0;  padding-right: 2rem;}

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

html[dir="rtl"] .ml-2 {   margin-right: 1rem; }

Для меня это не очень хорошее решение. Второй найденный плагин немного отличался от первого:

[dir="rtl"] .rtl\:text-2xl {  font-size: 1.5rem;  line-height: 2rem;}

Такой код может очень быстро выйти из-под контроля. Исследуя один веб-сайт, я заметил более 30 классов CSS.

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

Чтобы помочь в создании многоязычного веб-сайта, сейчас я использую Bi-App Sass. Вот пример:

.elem {  display: flex;  @include margin-left(10px);  @include border-right(2px solid #000);}

Код скомпилируется в два разных файла CSS. Файл ltr:

/* LTR Styles */.elem {  display: flex;  margin-left: 10px;  border-right: 2px solid #000;}

Подробнее о стилизации RTL читайте в этом руководстве от вашего покорного слуги.

Я не всегда работаю с шаблонами

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

Это не всегда так. Я работаю над простыми страницами index.html, где усилия в разделении на части или компоненты себя не оправдывают. В этом случае работа с Tailwind и редактирование CSS могут стать процессом, чреватым ошибками, поскольку вы даже не можете использовать функцию "Найти и заменить": она может пропустить некоторые другие элементы на странице.

Tailwind делает веб-сайты похожими

Команда Tailwind создала набор продуманных компонентов под названием Tailwind UI, которые легко настраиваются и готовы к использованию в вашем проекте.

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

Обычно, когда вы работа Tailwind UI, это означает, что у вас нет времени на создание индивидуального дизайна, поэтому вам нужно что-то, что можно быстро запустить, верно? И это хороший вариант применения, за исключением одной детали: применение Tailwind приведёт к тому, что многие сайты будут выглядеть похожими друг на друга, подобно тому, что было много лет назад с Bootstrap.

Некоторые свойства или особенности CSS использовать невозможно

К примеру, не включено свойство clip-path, и я полностью понимаю причину. Предположим, мы хотим включить его как компонент. Где мы должны написать код? Здесь:

<article class="block appearance-none bg-white placeholder-gray-600 border border-indigo-200 rounded w-full py-3></article>

Либо примерно так включить его в конфигурацию Tailwind:

// tailwind.config.jsmodule.exports = {  theme: {    clipPath: {      // Configure your clip-path values here    }  }};

Или же сделать следующее:

.card {  @apply block appearance-none bg-white placeholder-gray-600 border border-indigo-200 rounded w-full py-3;  clip-path: inset(20px 20px 50px 20px);}

Заключительные мысли

Может ли Tailwind оборачивать CSS в свои классы во время компиляции?

Представьте себе, что Tailwind появляется только во время компиляции. То есть вы пишете обычный CSS с именованием и всё такое, а умный компилятор преобразует ваш CSS в утилитарные классы. Это было бы воплощением мечты.

Утилитарные классы мощный инструмент, если не перестараться

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

Фронтенд довольно часто выбирают как точку входа в IT. Но фронтенд это не только внешнее оформление сайтов, но и работа с базами данных, а также внешними API. Фронтенд требует системной, комплексной подготовки. Если вам или вашим знакомым интересно это направление разработки можете присмотреться к нашему курсу о Frontend-разработке, где мы касаемся не только вышеупомянутых тем, но и разработки отзывчивых сайтов при помощи flexbox, работаем с методологией БЭМ и затрагиваем другие аспекты фронтенда.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

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

Огромных зарплат в те времена не было, компании по разработке ПО создавались романтиками в съемных комнатушках-офисах, в которых часто приходилось и ночевать. Кто-то не выдерживал и сдавался, кто-то создавал шедевры и богател, но в те времена никто не говорил, что люди получают зарплату просто так. Те времена подарили нам кучу программ, часть из которых остаются самыми популярными в своей сфере и по сей день (Например, MS Excel. Страшно думать, но до сих пор большинство инвестиционных банкиров используют для своих моделей именно MS Excel). Те времена подарили нам таких людей как Питер Нортон и Андерс Хейлсберг или Джон Кармак с Сидом Майером, если игры вам ближе.

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

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

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

Почему растет стоимость разработки? Ответ, на самом деле, тут прост и банален. Бизнес слабо понимает, что происходит в разработке, а разработка на самом деле работает сама на себя, делая то, что нравится, а не то, что надо, попутно внедряя в процесс кучу лишних людей. Разработчикам нравятся новые технологии, и они пытаются впихнуть их везде, где им дадут. Например, в моей текущей компании на хайпе стали внедрять BigData обосновывая это возможностью тонкой настройки бизнеса. Знаете, к чему это привело? Сотни миллионов денег были потрачены на то, чтобы сказать, что товары, которые покупают на точке в дорогом ТК в центре отличаются от товаров, покупаемых на окраине рядом с ЖД станцией. Серьезно? Вы потратили такой бюджет на то, чтобы найти факты, которые очевидны любому, кто занимался ритейлом? Другое прорывное решение касалось в определении людей, кто часто бывает рядом и предложении им семейных контрактов. О да, тут точно нужна BigData, без нее никак. Отдельная команда целый год пилила очень нужный в 2018 году блокчейн для голосовалок. Никто понятия не имеет, как его можно использовать в текущем бизнесе, но раз деньги выделяют, то почему бы и нет? Мы же не можем отставать по инновациям от Сбера? А Сбер не может отставать от Гугла?

Отдельно упоминания, безусловно, стоят микросервисы и контейнеры, которые пихают везде и вся. Попробуйте в 2021 году пойти на собеседование и сказать, что вы не понимаете, зачем нужны микросервисы. Вас поднимут на смех! Скажут: А как же хайлоад?, А как же независимые команды?, А как же отдельные стэки?.

Ты пытаешься выяснить, что же за хайлоад. На проверку оказывается, что там 200 запросов в секунду в пике. Ребята, Asp.Net Core + MVC + EF + PG держит 185 тысяч запросов в секунду single-query. Какой у вас хайлоад? И да, все еще забывают, что количество запросов к нагрузке также имеют очень маленькое отношение. В случае того же Твитера нет никаких бизнес-критичных запросов, мы можем ставить сотни одинаковых инстансов и проксировать запросы как душе угодно, никто не пострадает. Это вам даже не Букинг какой-нибудь, где на последний номер может быть несколько желающих.

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

Отдельная песня это возможность команде самой определять стэк, на которой ей удобно работать. Ну вы знаете, тот знаменитый подход, который приводит к командам на Java, Go, C++, Rust и NodeJS на одном бизнес-проекте. Причем вместе с несколькими SQL и NoSQL одновременно. Так ведь удобно потом нанимать разработчиков на каждый из стэков и поддерживать кодовую базу в актуальном состоянии. Так удобно следить за безопасностью сотен пакетов на каждый из фреймвороков. Так приятно, когда один и тот же код для интеграций с системами аутентификации или мониторинга повторяется на каждом фреймворке заново. Так удобно иметь отдельные конвейеры CI/CD и команду поддержки под каждый стэк. Нет, если вы Гугл и у вас есть десятки тысяч инженеров хорошей квалификации, которым по факту нечего делать, то подход имеет право на существование. Но если вы не Гугл, то зачем повторять худшие практики?

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

Я сам получаю деньги за то, что пишу код с 2006 года, в этом году будет 15 лет юбилея. И мне очень горько понимать, что моя любимая отрасль, которая подарила множество прекрасных продуктов, технологий или игр превратилась в огромного паразита, который воспроизводит сам себя и пытается высосать все соки. Сложно сказать, кто в этом виноват и когда свернули не туда. Факт состоит в том, что современное IT скорее тянет на дно бизнес, чем помогает ему развиваться. Все современные IT гиганты делали свое имя много лет назад при помощи других людей. Да, современный бизнес невозможен без IT. Но все забывают, что IT это прежде всего поддерживающее звено, а не основа мироздания. Какими бы не были прорывные технологии, условный Нетфликс все-таки будет оцениваться качеством контента.

Что делать?

Хотелось бы прояснить, почему вообще у меня пригорает на тему ситуации в IT. Как-то сложилось, что за свою жизнь я был активным пользователем IT продуктов. И уже не первый год, как я стал замечать, что качество продуктов, падает год к году. Яснее всего это видно, конечно же, в игрострое. Все идеи, которые успешно доят до сих пор появились лет 20-30 назад. MVP сего парада стал безусловно Warcraft 3: Reforged и Star Citizen. Однако нельзя сказать, что и в других отраслях таких проблем нет. Качество поиска Гугла стабильно падает. Фейсбук редизайнит так, что лучше бы вообще не трогал. И все это при том, что разработчиков в штате компаний все больше и больше.

В качестве решения накопленных проблем мне лично видятся следующие меры:

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

• Упрощение процесса разработки за счет более простых и эффективных бизнес процессов и прозрачной системы принятия решений;

• Использование в рамках компании стандартных стеков технологий и пакетов;

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

• Подбор оптимальной архитектуры под бизнес требования;

• Сокращение time-to-market за счет активного переиспользования кодовой базы, шаблонов и простой архитектуры;

• Сокращение людей не увеличивающих ценность продуктов, таких как скрам мастер, эджайл коуч и прочих.

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

А что Вы думаете о текущем этапе развития IT. Какие проблемы видите лично Вы, насколько они кажутся серьезными и как их лучше решать?

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

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

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

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

Нас сейчас интересует Россия.

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

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

Можно ли привлечь молодых специалистов при помощи примеров великих деятелей прошлого?

Для всех культур с высоким показателем Ориентация на будущее характерна способность быстро принимать и отказываться от существующих традиций в зависимости от сложившихся условий. Члены таких обществ испытывают слабое влияние истории на принятие собственных решений.

Часто эти особенности можно использовать во благо. Во многом благодаря легкости в отказе от традиций, Россия быстро вырвалась в лидеры по развитости банковской инфраструктуры люди легко отказались от традиции использования наличных денег в пользу более удобного безналичного расчета. По данным ЕЦБ только 21% всех расчетов местного населения проходит с помощью безналичных технологий, в то время как в России этот показатель достиг 60%.

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

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

Какими должны быть стимулы?

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

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

Такой вопрос, в какой из лабораторий, изображенных на рисунке выше, работает успешный ученый? Если человек из лаборатории слева будет получать большие деньги, чем человек из лаборатории справа, он будет чувствовать себя менее успешным. Когда я говорю о материальной обеспеченности я не обязательно подразумеваю, что необходимо увеличить финансирование лабораторий. Эту проблему можно решить исключительно организационными методами. Дело в том, что организации расходуют средства очень неэффективно. Финансово-хозяйственная деятельность в первую очередь направлена на выполнение плана, а уже затем на достижение результата.

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

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

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

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

Константин Новоселов

Третий аспект, актуальный в первую очередь для молодых специалистов, это возможность заработать себе имя в мировом научном сообществе. В США,молодой выпускник понимает, что работая в Лос-Аламосе сможет заработать себе имя.

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

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

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

Степан Гончаров, Социолог Левада центра

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

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

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

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

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

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

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

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

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

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

И это приводит нас к самому большому непониманию A/B-тестирования и его пользы в качестве научного инструмента: оно часто используется, например, в UX-дизайне, чтобы узнать, влияют ли небольшие изменения компоновки сайта на переходы пользователей или могут ли тонкие изменения затенения сделать рекламу более привлекательной. В результате оно приобрело репутацию инструмента улучшения доверительных интервалов для очень малых эффектов. И поскольку исследователи машинного обучения относятся к доверительным интервалам в лучшем случае как к вынужденному допустимому отклонению, фактическая значимость А/В-тестирования для исследований в области машинного обучения обычно упускается из виду.

Параллельное A/B-тестирование целиком относится к тестированию больших эффектов, особенно когда нет возможности жёсткого контроля схемы оценки.

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

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

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

Изменчивость в идентичных экспериментах. Источник: Robotics at Google (Робототехника в Google)

Если бы каждому эксперименту соответствовала другая модель, мы бы сказали, что эксперимент 7 примерно на 2% лучше, а эксперимент 5 примерно на 5% хуже. И у нас бы даже были достаточно жёсткие доверительные интервалы, чтобы убедить вас в этом. Но здесь не было никаких различий между экспериментами, все они были идентичными. Обратите внимание, что это не случай отсутствия данных: большее количество данных будет только сокращать доверительные интервалы, а не перемещать их положение относительно базового уровня. Такая необъяснимая изменчивость целиком попадает в неизвестные неизвестные окружающей среды. И эта установка так же проста, как и для реального эксперимента с роботом: во многих статьях по робототехнике сообщается об экспериментах с последовательной обработкой и гораздо большим потенциалом необъяснимой изменчивости, чем этот. Что ещё важнее, если бы мы не измерили эту повседневную изменчивость, мы бы даже не догадались о её существовании. Очень немногие исследователи когда-либо задумывались об измерении внутренней изменчивости в их экспериментальной установке в первую очередь, потому что, давайте посмотрим правде в глаза: так это работает, и из этого направления исследований могут поступать только плохие новости.

Урок здесь заключается в том, что при использовании этого конкретного экспериментального протокола мы определённо не можем доверять любой разнице производительности ниже 10% я даже не знаю, доверял бы ли я разнице в 10% без большой повторной проверки. Неужели это безнадёжно? Конечно, нет. Введите параллельное тестирование.

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

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

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

Это было выполнено без каких-либо изменений в экспериментальной установке, только с немного другим экспериментальным протоколом.

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

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

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

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

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

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

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

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

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

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

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

Для нас в области машинного обучения и робототехники настало время использовать те простые инструменты, которые делают невоспроизводимые исследования воспроизводимыми и научно обоснованными. Ни один из протоколов, которые я описываю здесь, не является особенно трудным для реализации, но они обещают улучшить реальную науку, упростить её и ускорить. А если вы хотите ускорить свой прогресс в области machine learning или data science приходите учиться к нам, а наши опытные менторы пояснят все сложные моменты, на которые при самообразовании вы бы потратили ценное время.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Многие люди, когда они впервые слышат термин Data Science, обычно в первую очередь думают о машинном обучении.

Так было и со мной. Мой интерес к data science возник потому, что я впервые столкнулся с идеей машинного обучения, которая показалась мне действительно крутой. Поэтому когда я начал искать место, где можно бы начать узнавать о data science, не трудно догадаться, откуда я начал. (Подсказка: оно рифмуется с bean churning.)

Это было моей самой большой ошибкой, которая привела меня к этой мысли:

Если вы хотите изучать data science, не начинайте с машинного обучения.

Просто поймите. Понятное дело, чтобы стать "полноценным" data scientist, когда-то придётся узнать о концептах машинного обучения. Но вы удивитесь, как далеко вы сможете продвинуться без него.

Так почему бы не начать с машинного обучения?

1. Машинное обучение - это только одна (и очень небольшая) часть data scientist'а

Data science и машинное обучение - это как квадрат и прямоугольник. Машинное обучение - (часть) науки о данных, но наука о данных не обязательно является машинным обучением, подобно тому, как квадрат является прямоугольником, но прямоугольник не обязательно является квадратом.

На самом деле, я бы сказал, что моделирование машинного обучения составляет только 510% работы data scientist'а, тогда как большая часть времени тратится в другом месте, о котором я расскажу позже.

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

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

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

Приведу несколько примеров:

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

• Метод главных компонент возможен только с идеями матриц и собственных векторов (линейная алгебра)

• Наивный байесовский классификатор - это модель машинного обучения, полностью основанная на теореме Байеса (вероятность).

Так что, я закончу двумя вещами:

1. Изучение основ облегчит изучение более продвинутых тем.

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

3. Машинное обучение - не ответ на каждую проблему data scientist'а

Многие data scientist'ы (в том числе и я) борются с этим. Возвращаясь к моей первоначальной мысли, многие data scientist'ы думают, что data science и машинное обучение идут бок о бок. Так что, когда они сталкиваются с проблемой, первое решение, которое они рассматривают - это модель машинного обучения.

Но не для каждой проблемы в data science требуется модель машинного обучения.

В некоторых случаях анализа с помощью Excel или Pandas вполне достаточно, чтобы решить возникшую проблему.

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

Так что мне тогда делать?

Если вы читали мою статью "Как изучить data science, если пришлось начать сначала", вы, возможно, могли заметить, что я предлагал изучить математику, статистику и основы программирования. Я всё ещё придерживаюсь этого мнения.

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

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

Вы должны научиться ходить, прежде чем сможете бегать.

Если вы хотите начать с каких-то осязаемых следующих шагов, то вот вам несколько идей:

1. Начните со статистики. Я считаю, что из трех строительных блоков наиболее важным из них является статистика. И если вы боитесь её, то data science, вероятно, не для вас. Я бы посмотрел курс Технологического института Джорджии "Статистические методы", или серию видео от Khan Academy.

2. Изучите Python и SQL. Чем лучше вы будете знать Python и SQL, тем легче будет ваша жизнь, когда дело дойдет до сбора, обработки и реализации данных. Я также был бы знаком с библиотеками Python, такими как Pandas, NumPy и Scikit-learn.Я также рекомендую вам изучить двоичные деревья, поскольку они служат основой для многих сложных алгоритмов машинного обучения, таких как XGBoost.

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

4. Изучите обработку данных. Она занимает до половины работы data scientist'а. В частности, узнайте больше о проектировании функций, исследовательском анализе данных и подготовке данных.

Спасибо за прочтение!

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

С учетом всего сказанного, желаю удачи в ваших начинаниях!

_{Автор фото обложки: Will Porada}

Original text Telecom (as We Knew It) Is Dead by Miguel Monforte | March 15, 2021.

Время от времени организация по стандартизации 3GPP удивляет всех смелыми шагами в выборе странных технологий. Так было с RCS, IMS и SIP. Когда они впервые объявили об эволюции ядра 5G как облачной архитектуры с HTTP в качестве основного протокола связи, это вызвало некоторое удивление специалистов.

С выпуском Release-15 исчезло все, что олицетворяло традиционные телекоммуникационные компании. Больше никаких специальных протоколов для повышения эффективности в периоды большого объема трафика. Больше никаких тестов на совместимость с различными поставщиками и новыми протоколами. Король телекоммуникаций мертв, и больше не будет: Да здравствует король! потому, что сегодня даже ребенок, использующий node.js, может построить ядро 5G на своем ноутбуке.

Добро пожаловать в будущее.

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

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

Исторически сложилось так, что некоторые из этих нововведений (например, SIP) применялись в телекоме без должной осмотрительности и позже были признаны непригодными для решений беспроводной связи. В качестве наиболее свежего примера HTTP оказался неоптимальным для доставки, когда дело дошло до сетей с негарантированным качеством (например, мобильных сетей, страдающих непрогнозируемыми потерями и задержками). В результате был разработан новый протокол HTTP/2. Однако специалисты довольно быстро осознали (многие в комитете H2 IETF до того, как он был широко внедрен), что HTTP/2 имеет свои собственные ограничения (они как бы просто переместили блокировку HOL в TCP на транспортном уровне, что означало, что потеря пакетов сделала ситуацию ... хуже). И вот, Google решил (снова) возглавить мир с помощью QUIC. В итоге это привело к стандартизации HTTP/3, который был построен на основе QUIC без потери существующей семантики HTTP/2.

Облачная среда, микросервисы, HTTP, автоматическое масштабирование, узлы edge - это больше похоже на архитектуру современного крупномасштабного поставщика контента, чем на платформу оператора связи. На самом деле, мы не говорим об эволюции существующих платформ в 5G, мы говорим о полной революции, когда мы, по сути, отбрасываем все телекоммуникационные знания и вместо этого используем новую стороннюю платформу. Хотя это вызовет воодушевление у маркетинговых команд, стремящихся объединить предложения с ТВ, потоковой передачей, рекламой, играми и т.п., это может стать кошмаром при работе с высокой нагрузкой по протоколам, далёким от телекоммуникаций.

Хотя ни у кого нет хрустального шара, чтобы заглянуть в будущее, было много признаков того, что рынку предстоят серьезные изменения. Каждый из этих признаков был простым повторением эволюции рынка после анонса Release-15. Не так давно Microsoft приобрела две давно существующие фирмы, чтобы внедрить компоненты телекоммуникационного стека в свое облако. Есть уверенность, что это просто вопрос времени, когда другие крупные облачные провайдеры заявят о своих преимуществах аналогичным образом. Мы можем наблюдать множество других тактических приобретений, например приобретение гигантом Amdocs компании Opennet, нишевого вендора имеющего при этом критически важный опыт облачных внедрений.

Как быстро Oracle, которая уже много лет смещает акцент на облачный бизнес, дополнит свою линейку решений 5G, чтобы составить конкуренцию Microsoft? Как Amazon и Google смотрят на своих конкурентов и будут ли они просто приглашать лучших в своем классе партнеров (как например делает Nokia) или начнут трансформироваться? Время покажет, но, похоже, у них есть огромное преимущество перед традиционными поставщиками и операторами связи. Почему? Потому что они являются экспертами в таких технологиях, как CI/CD, сквозная оркестровка сервисов, микросервисы на основе контейнеров, zero-latency cold starts serverless решений и многие другие современные концепции горизонтально масштабируемой инфраструктуры. Они вполне неплохо понимают, что нужно делать, чтобы добиться успеха в этом новом мире telecom-as-a-service, они создавали и адаптировали эту самую новую культуру и подходы. А традиционные производители телеком решений в этом смысле находятся в рядах догоняющих и еще не известно сумеют ли выжить, чтобы набрать нужную скорость.

Так каковы же последствия облакофикации мобильного ядра? Будет ли это способствовать быстрому внедрению бизнес-моделей, включающих упомянутые выше технологии? Увеличит ли это износ старых технологий в пользу ядра 5G, которое обрабатывает варианты использования во всех частях корпоративного бизнеса? Пока еще слишком много вопросов, чтобы прогнозировать конкретные результаты, но ясно одно. Скоро грядут серьезные изменения - они будут долгими и глубокими. И нам с вами повезло жить в интересные времена!

Видеоверсия статьи:

10 июня From Software наконец-то показала долгожданный геймплейный трейлер Elden Ring и объявила дату релиза. Если вспомнить, что игру анонсировали 9 июня 2019 года и кроме CGI-трейлера за два года мы не слышали об игре ровным счётом ничего, возникает вопрос: в чём был смысл столь раннего анонса?

Похоже, что такой подход к выпуску ААА-проектов становится нормой. Достаточно хотя бы вспомнить громкие анонсы The Elder Scrolls 6 и Starfield летом 2018 года и последующее гробовое молчание разработчиков по поводу примерной даты релиза и выхода сколь-нибудь вменяемого трейлера. И лишь на презентации состоявшейся 13 июня текущего года Microsoft и Bethesda наконец-то объявили дату релиза Starfield 11 ноября 2022 года, сопроводив анонс, опять же, не очень информативным трейлером.

Вспомним также The Last of Us Part II, которая вышла спустя четыре года после анонса; Days Gone анонсированную в 2016 году и вышедшую лишь в 2019; God of War 2018 года, анонсированную в 2014; S.T.A.L.K.E.R. 2; Fable 4; Beyond Good and Evil 2; ну и, конечно же, Cyberpunk 2077, которую мы ждали целых 7 лет.

Это проекты, которые первыми пришли мне на ум. Уверен, что вы сможете вспомнить и привести ещё десятки аналогичных примеров.

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

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

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

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

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

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

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

Не будем выпускать из вида и такие менее очевидные, но от этого не менее важные причины, как:

Возможность обсуждать свои проекты с друзьями, родственниками и знакомыми за пределами студии;

Упрощение найма талантливых людей в команду;

Налаживание деловых отношений с партнёрами и упрощение взаимодействия с коллегами из индустрии в целом.

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

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

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

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

Аргумент о том, что той же Bethesda пришлось анонсировать TES 6, дабы успокоить фанатов очень сомнительный. Прошло три года с момента анонса игры и до сих пор о ней не было ни одной новости по существу. А в январе этого года инсайдер, который ранее предсказал выход Half-Life: Alyx,сообщил, что ожидает релиз TES 6 не ранее 2026 года. Если Bethesda хотела успокоить своих фанатов столь ранними анонсами, то не думаю, что у неё это получилось. Скорее это сработало в обратную сторону.

Основной мой посыл состоит в том, что ранние анонсы игр неэффективны. И есть издатели, которые это хорошо понимают и доказывают эффективность противоположной стратегии. Например, такие серии как Battlefield, Call of Duty, Assassin's Creed и Far Cry, как правило, выходят спустя полгода-год после анонса и прекрасно продаются. Вообще, по себе замечаю, что чем короче ожидание анонсированной игры, тем больше удовольствия от неё я, в конечном счёте, получаю.

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