Future Bass
Future bass is a music genre that arose around 2006 in the United Kingdom, United States, France, Germany, Japan, China and Australia. It is a broad genre of music, comprising a wide variety of sounds and rhythms normally produced by a synthesizer. The genre was pioneered by Flume and Cashmere Cat and was popularized in the mid-2010s by artists like Mura Masa, Marshmello and Louis the Child. 2016 was seen as the breakout year for the genre.
Contents
Characteristics [ ]
Taking a lot of characteristics from trap and progressive house music, future bass is described as having a focus on a supersaw bassline.The sound waves are often modulated using automation or low-frequency oscillation controlling the cutoff of an audio filter (typically a low- or high-pass filter) or the level of the wave to adjust the waveform’s volume (to create a ‘wobble’). In addition, it is common to utilize a somewhat «twinkly»-sounding gradual rise in pitch during «risers» (pre-drop buildups of white noise), and arpeggio chords, vocal chops or vocoders. The drums consist of kicks and rapid-fire hi-hats that are taken from trap music.
Subgenres [ ]
Future trap [ ]
Future trap is a fusion between future bass and trap (which often features hard trap drops as opposed to often synth-laden future bass drops). DROELOE, RL Grime, Flux Pavilion and other producers have produced tracks of this subgenre.
Future core [ ]
Future core blends hardcore with the melodic content and sound design characteristics of future bass. It has been recognised as a genre among Japanese electronic music producers on SoundCloud since the release of the «FÜGENE» future core compilation album in early-mid 2017.
Kawaii Future Bass [ ]
Kawaii Future Bass («kawaii» coming from Japanese meaning cute) is another subgenre. Mostly bombarded by jazz chords, video game samples and anime samples. Hugely popularized by artists such as Snail’s House.
Зачем нужна выделенная Frontend Core команда и как мы внедряли дизайн систему
Всем привет, меня зовут Ростислав, я занимаю должность Front Lead в компании ДомКлик. Хочу поделиться с вами опытом создания Web Core команды и сразу ответить на следующие вопросы:
После года существования команды Web Core, у всех сложилось понимание, что в больших компаниях это необходимо, а в стартапах — не обязательно.
Безусловно. Изначально было сложно измерить и спрогнозировать выгоду от её создания, все расчеты, P&L были на словах, в цифрах — только примерные предположения. Спустя год мы можем посчитать сэкономленное время, профиты, и все расчеты говорят о том, что это было не зря.
Если у вас одна цель — создать дизайн систему и выпустить библиотеку компонентов под ключ, то возможно. Если же вы хотите это всё динамически развивать и расширять зоны ответственности команды, то это точно надолго.
Основное направление — дизайн система, но по ходу её разработки у нас появилось еще много интересных задач.
Предыстория
Создание Web Core команды началось с потребности разработать дизайн систему и библиотеку компонентов с последующей поддержкой и развитием, а также внедрить стандарты для frontend — разработки.
У нас в компании немало продуктовых команд, в каждой по несколько продуктов, состоящих из одного или нескольких веб-клиентов, которые могут содержать в себе виджеты и компоненты. Все веб-клиенты собираются в огромную экосистему ДомКлик, и, естественно, возникает вопрос о единообразии дизайна и UX-поведения всех элементов на страницах, чтобы клиент, переходя из продукта в продукт, понимал, что он в одной системе. И еще стоит вопрос об избыточных трудозатратах при разработке новой или доработке старой функциональности.
За всю историю ДомКлик было много попыток собрать библиотеку компонентов для их переиспользования во всех командах. Сначала пытались это делать в лояльном режиме: выделяли из своих проектов компоненты, которые можно переиспользовать, в отдельный репо и публиковали в npm-репозиторий. Затем компания энтузиастов решила собрать базу лучших компонентов в один проект со storybook, с единообразным API, и, по возможности, её поддерживать и дополнять. Но все эти попытки были тщетны до создания выделенной команды Web Core, у которой есть свои цели, обязанности и компетенции.
Дизайн-система и UI-KIT
Какие цели мы хотели достичь при создании дизайн системы:
Наша дизайн система будет состоять из таких элементов:
Дизайн
В ДомКлик уже было несколько версий дизайн систем, и теперь перед нашим дизайнером стояла непростая задача собрать самую актуальную и полноценную дизайн-систему. Самой большой проблемой было собрать все потребности использования каждого элемента, учесть все возможные состояния и условия, в которых он применяется. Про дизайн и проблемы, решавшиеся на этапе проектирования, нужно писать отдельную статью. Обозначу вкратце атомарность нашего UI-KIT.
Основа всей дизайн системы — гайдлайны.
На основе гайдлайнов строятся базовые элементы. А на основе базовых элементов строятся более сложные элементы.
По такому же принципу мы будем выстраивать нашу библиотеку компонентов, начиная с гайдлайнов и заканчивая сложными элементами.
Разработка
А теперь перейдём к проектированию. Библиотеку компонентов мы разрабатываем на React — стандарте ДомКлик. Будем использовать Typescript для статической типизации, что помогает удобно использовать наши компоненты. Почему нельзя взять готовую библиотеку компонентов и просто интегрировать в нее нашу дизайн-систему? Во-первых, это тяжеловесные библиотеки, которые повлияют на производительность ваших продуктов. Во-вторых, вам постоянно будет не хватать их функциональности и придется их постоянно дорабатывать.
Перед началом разработки мы задали себе несколько задач:
Версионирование
Мы будем итеративно разрабатывать наши компоненты, улучшать их, добавлять новую функциональность. Вероятно, у нас будет меняться дизайн. Работаем мы по SemVer, т.е. фиксы и улучшения производительности мы выпускаем в патч-версии; добавления нового API и возможностей — в минор-версии; смена API для работы с компонентом, дизайна и его поведения — в мажор-версии.
Есть несколько способов поставки библиотеки компонентов конечному потребителю — продуктовым разработчикам.
Самый популярный вариант: один пакет UI-KIT, который ставишь целиком в проект и в дальнейшем обновляешь его при появлении новой версии. В этом случае должен безукоризненно работать tree shaking, иначе при сборке проекта мы получим даже те зависимости, которые не используем.
Достоинства:
Недостатки:
Второй вариант — каждый компонент UI-KIT как отдельный пакет. В этом случае каждый отдельно взятый компонент версионируется по SemVer.
Достоинства:
Недостатки:
Мы выбрали второй вариант, потому что это менее болезненный путь для наших продуктов. В дальнейшем мы планируем выпустить один npm-пакет, который включает в себя все пакеты для тех команд, которым не страшно обновлять всё и сразу.
Мы будем работать в монорепозитории, потому что одни компоненты переиспользуют другие компоненты. Как мы будем управлять версионированием? Мы решили сравнить два наиболее подходящих инструмента для данной задачи: Lerna и RushJS.
Если смотреть на статистику, то Rush — наименее популярная библиотека. Так почему же мы выбрали её? Lerna была очень непредсказуемой и магической, нигде не было нормально описано, как она работает. Процесс релиза был недетерминирован. В Rush это сделано более системно: благодаря change-файлам ты всегда видишь, что поедет в релиз, и библиотека автоматически генерирует читабельные changelog, на основе которых бампит версии так, как тебе нужно. Также Rush работает с Git как надо. В целом эта библиотека показалась более зрелым инструментом, поэтому мы выбрали её.
Вот как мы работаем с Rush:
Сборка
Для сборки наших компонентов в формате ESM и ESNext с поддержкой tree-shaking мы используем Rollup, и ожидаем релиза Webpack 5, в котором нам обещают отличную поддержку этой функциональности. Чтобы у нас во всех пакетах была идентичная сборка и мы могли бы ее поддерживать и улучшать, мы можем везде ссылаться на один файл с конфигурацией. Но мы пошли дальше: создали библиотеку, которая этим занимается. Она гибкая, масштабируемая, и её можно использовать в других проектах для своих нужд. В ней уже соблюдены некоторые стандарты нашей компании: browserlist со списком поддерживаемых браузеров, сборка стилей, оптимизации для сборки библиотек и многое другое. Наши компоненты можно использовать в SSR-приложениях, при этом мы расширили поддержку старых версий NodeJS, собирая наши пакеты еще и в CommonJS-формате.
Стили
В наших компонентах мы используем CSS-модули и Sass как препроцессор.
О чем стараемся не забывать при этом подходе:
Переиспользуемые правила. Стараемся дедуплицировать стили и выносить переиспользуемые правила в пакет styles-framework, который включает в себя цвета, типографику, брейкпоинты, сброс стилей и много полезных миксинов. Другие команды могут его использовать в отрыве от библиотеки компонентов.
Вы можете сказать, что для этих целей отлично подойдет CSS in JS. Не буду спорить, возможно, мы к этому придем.
Иконки
Многие задаются вопросом, каким способом предоставлять SVG-иконки. Изначально мы попробовали выгружать их на CDN по отдельности, но в этом случае получали перерисовку контента и много потоков скачивания. При использовании спрайта потребитель получает огромную (и тяжеловесную) портянку иконок, из которых он может использовать только несколько. Поэтому мы решили предоставлять React-компонентами, которые содержат в себе инлайново SVG-иконки. При сборке релиза запускается скрипт, который перегоняет SVG-файлы в IconComponent, заменяя все свойства fill на currentColor и применяя SVG-oптимизацию, поэтому нашим иконкам легко изменить цвет, задав его родителю.
Кроссбраузерность
Если вы поддерживаете старые версии браузеров и у вас десятки продуктов, вы тоже можете озадачиться такой проблемой, как полифилы. Их вы можете встретить везде: в используемой open-source библиотеке, в пакете, разработанном коллегой из другой команды, и, конечно же, в библиотеке компонентов. В итоге получается, что есть много веб-клиентов, собирающихся с полифилами для стабильной работы во всех браузерах.
Некрасиво, верно? Поэтому мы создали сервис полифилов, который не только позволит убрать их из приложений, но и в зависимости от сегмента браузеров отдавать набор тех полифилов, которые необходимы для стабильной работы приложения.
В зависимости от заголовка user-agent сервис отдает тот или иной набор полифилов. Мы выделили три набора для трех сегментов браузеров.
Размеры наборов составляют непосредственно:
В итоге мы получаем:
Внедрение
Чтобы ваша библиотека компонентов удовлетворяла все потребности потребителей, нужно учесть следующие моменты:
Витрина компонентов
Вся полезная информация о наших компонентах будет представлена на витрине компонентов.
Здесь мы можем увидеть список всех наших компонентов, информацию по ним, показать все их состояния и возможности.
Тут мы можем увидеть нашу историю изменений. Эта информация берется из файлов CHANGELOG.md, которые генерируются с помощью Rush.
В секции Readme выводится информация из файла Readme, там можно увидеть информацию об установке компонента и перечисление всех его свойств.
Численность и состав
Изначально наша команда состояла из двух frontend (React)-разработчиков, одного дизайнера и одного product owner’а. Сразу хочется пояснить необходимость PO в команде. Человек с этой ролью не только выстраивает процесс и координирует работу команды, но и формирует позиционирование всей дизайн-системы, собирает потребности от других команд для дальнейшего внедрения в UI-KIT и исследует пользовательский опыт с интерфейсами, построенных на наших компонентах, для улучшения UX/UI. С увеличением кодовой базы, численности и масштабности компонентов мы расширились до пяти разработчиков, и не планируем на этом останавливаться.
Заключение
На дизайн системе список активностей команды Web Core не заканчивается. Мы также создаем омниканальные виджеты, такие как навигация по сайту, выбор региона и т.д. Стараемся выработать правила для стандартизации всей кодовой базы в нашей компании. Разрабатываем библиотеки для сбора метрик, авторизации и регистрации. И этот список можно дополнять и дополнять. Я надеюсь, что вы почерпнули что-то новое для себя и своей команды. Очень буду рад обратной связи! Всем спасибо!
Что ждет EdTech? 10 трендов в онлайн-образовании на 2021 год
Рассказываем, какие прогрессивные образовательные идеи уже стоит внедрять в онлайн-продукты: о них вот-вот заговорят!
Вертикальное расположение видео
Изменился опыт потребления контента. Пользователи учатся не с десктопа или планшета, а с телефона. Для таких курсов эффективнее делать вертикальный контент. Это так же привычно для пользователя, как чтение сообщений и постов в ленте.
Что это значит для инфобизнеса. Отрабатывать интерес к курсам, которые создаются сразу под вертикальный формат. Двигайтесь в сторону создания коротких образовательных форматов. Уже появляются онлайн-школы, например, Mobile.School, где все построено на микрообучении, а видео-уроки в вертикальном формате.
Включение искусственного интеллекта в оценку результатов обучения
Искусственный интеллект будет все больше входить в область оценивания, что обеспечивает большую объективность при проверке. Это оценивание не только знаний студентов, но и работы преподавателей. Максимальный уход от человеческого фактора в оценке компетенций и независимость оценки.
Что это значит для инфобизнеса. Подумайте над вариативностью обратной связи. Менторская поддержка, ответы тьюторов, онлайн-проктеринг, когда учащийся в режиме реального времени под прицелом веб-камер сдает итоговую работу.
Индивидуализация контента
Крупные платформы работают как завод: нет предельной индивидуализации контента. При этом инструменты по созданию образовательного контента упростились и удешевились. Достаточно знаний и хорошей камеры телефона.
Что это значит для инфобизнеса. Помнить, что доверие к человеку выше, чем доверие к бренду. Учитывать тренд на изменение подхода к самообразованию: теперь пользователь выбирает, у кого учиться, а не где учиться. Сильные эксперты будут рассматривать создание собственных частных школ без привязки к крупным игрокам рынка.
Создание ценностного контента
Отголосок предыдущего тренда. Почему люди будут покупать курс по фитнесу у блогера с 2000 подписчиками? Ценности этого человека, которые он транслирует через социальные сети, совпадают с ценностями того, кто у него этот контент покупает.
Что это значит для инфобизнеса. Личная связь преподавателя и студента, которая возможна для малого бизнеса, — серьезный драйвер развития. Это стоит учитывать при создании программы.
Нативный продакт-плейсмент внутри курса
Не столько нативная реклама, сколько средства и инструменты, за счет которых учащийся обретает нужные компетенции. Допустим, внутри онлайн-курса по выпечке преподаватель готовит с помощью определенной кухонной утвари. Показывает, как с помощью инструментов максимально хорошо делать кондитерские изделия.
Что это значит для инфобизнеса. Использовать продакт-плейсмент как дополнительный способ монетизации онлайн-курса и выбирать те бренды, продукты которых решают задачи курса.
Если вас заинтересовал этот тренд и вы хотите узнать больше, здесь мы рассказываем, как зарабатывать на продакт-плейсменте.
Платформы под разные сегменты онлайн-школ
Если у эксперта есть компетенция, не нужно сверх знаний, чтобы создать образовательный контент. Это же демонстрирует ТикТок, Инстаграм: фильтр наложил, анимацию сделал — контент готов. Стоимость производства, за счет новых платформ взаимодействия с пользователем и инструментов создания контента, сокращается.
Что это значит для инфобизнеса. Курсы от обычного пользователя не сильно проигрывают по качеству, чем курсы от крупных компаний. Стоит выбирать платформы, заточенные под конкретный продукт: например, появились платформы для языковых школ.
Новый уровень геймификации
Уходят рейтинги с очками, форматы курсов видео + тест. Работают механики, которые вшиваются в образовательную траекторию. Модели вовлечения через конкурсные механики. Допустим, пасхалки, благодаря которым открывается новый секретный курс или дополнительный урок.
Что это значит для инфобизнеса. Прописывайте сценарий курса. У Teen.Study, например, школьные уроки больше похожи на захватывающий сериал: они используют комиксы, секретные коды, пасхалки. По данным платформы, дети в 6 раз лучше фокусируются на прохождении урока.
Курс на creator economy
Если человек уходит на фриланс или становятся самозанятым, он вынужден самостоятельно заниматься своим образованием на конкурентном рынке. Происходит переход от образования внутри компании к самообразованию. Растет уровень личной осознанности: тебе не говорят, где учиться, ты выбираешь сам.
Что это значит для инфобизнеса. Эксперты выходят на рынок в обход онлайн-школ. Когда автор создает продукт на крупной площадке, как правило, контент в дальнейшем не актуализируют, часто нет никакой обратной связи. Это легко исправить при запуске собственного онлайн-курса, не для крупной платформы.
LTV важнее CAC
Показатель LTV (прибыль, которую приносит один клиент за все время) становится важнее CAC (стоимость привлечения клиента). Задача микро-школы — довести до результата, чтобы аудитория оставалась внутри экосистемы. Эксперты, которые создают курсы на онлайн-платформе CORE, отмечают рост LTV, по сравнению с их предыдущим опытом создания онлайн-курсов.
Что это значит для инфобизнеса. Задача автора — не продать один курс, а выстроить серию различных курсов под разную целевую аудиторию: сегментировать, классифицировать, давать более высокую индивидуализацию во время образовательных программ. То, чего не могут сделать крупные школы.
The Sharing Economy
Экономика совместного потребления — значимый тренд. В образовании он реализуется в совместном создании преподавателями контента. Методисты могут выступать сборщиками курсами на аутсорсе: делиться наработками и методиками.
Что это значит для инфобизнеса. На образовательной платформе CORE реализована такая модель, когда преподаватели могут делиться друг с другом материалами, своими курсами. Из материалов коллег создавать собственные онлайн-продукты. Таким образом, можно быстро и просто создавать востребованный контент, делиться опытом в профессиональной среде.
На что обратить внимание?
Рынок детского образования. В регионах на дополнительное образование родители, в среднем, тратят 7 500 рублей в месяц. В Москве — 22 000 рублей в месяц.
Тренд, который активно развивается за рубежом, но к нам придет чуть позже, — это Diversity and Inclusion.
С одной стороны, будут появляться курсы, связанные с левой либеральной повесткой: вокруг феминизма, инклюзивности (появление курсов только для девушек). Будут создаваться продукты, где левая либеральная повестка станет точкой привлечения.
Антипод — праволиберальная повестка: «правильное лидерство» с упором на прогрессивное развитие. Тезис: «Не жди, что к тебе прилетят привилегии» — конкуренция за счет компетенций.
Какие из трендов остаются актуальны в 2021?
Методика имеет большое значение. Тренд на педагогический дизайн точно есть. Методисты могут выступать сборщиками курсами, передавая свои компетенции разным авторам.
Маленькие частные онлайн-школы будут развиваться и расти в объеме. За счет предельной индивидуализации контента и трансляции ценностей, схожих с ценностями их учащихся, смогут конкурировать с сильными игроками.
Естественно, никуда не уходит потребность развивать soft skills. Минимум для сотрудника любой компании — умение презентовать идеи; понимать новые технологии; способность к эмпатии; понимание принципов предпринимательства.
Бизнес и вузы готовы работать с онлайн-школами. Отмечается рост доли совместных проектов вузов с другими участниками рынка: например, сетевые магистратуры, разработанные университетами и онлайн-школами.
Продолжает развиваться тренд на удаленное обучение для сложных специальностей. Например, во Future learn создали онлайн-курсы для тех, кто ухаживает за людьми с различными заболеваниями. В России примером служит опыт Tactise Academy.
Модель смешанного обучения внедрили и будут продолжать внедрять. В 2021 произойдет смешение синхронного (вебинары) и асинхронного (классический онлайн-курс) обучения.
Онлайн-курсы, о которых упоминается в статье, созданы на нашей образовательной платформе. 
Future core что это
It’s completed if it’s either succeeded or failed.
onComplete
onSuccess
onFailure
result
cause
succeeded
failed
flatMap
compose
When this future (the one on which compose is called) succeeds, the mapper will be called with the completed value and this mapper returns another future object. This returned future completion will complete the future returned by this method call.
If the mapper throws an exception, the returned future will be failed with this exception.
When this future fails, the failure will be propagated to the returned future and the mapper will not be called.
recover
compose
When this future (the one on which compose is called) succeeds, the successMapper will be called with the completed value and this mapper returns another future object. This returned future completion will complete the future returned by this method call.
When this future (the one on which compose is called) fails, the failureMapper will be called with the failure and this mapper returns another future object. This returned future completion will complete the future returned by this method call.
If any mapper function throws an exception, the returned future will be failed with this exception.
transform
When this future (the one on which transform is called) completes, the mapper will be called with the async result and this mapper returns another future object. This returned future completion will complete the future returned by this method call.
If any mapper function throws an exception, the returned future will be failed with this exception.
eventually
When this future (the one on which eventually is called) completes, the mapper will be called and this mapper returns another future object. This returned future completion will complete the future returned by this method call with the original result of the future.
The outcome of the future returned by the mapper will not influence the nature of the returned future.
When this future succeeds, the mapper will be called with the completed value and this mapper returns a value. This value will complete the future returned by this method call.
If the mapper throws an exception, the returned future will be failed with this exception.
When this future fails, the failure will be propagated to the returned future and the mapper will not be called.
When this future succeeds, this value will complete the future returned by this method call.
When this future fails, the failure will be propagated to the returned future.
mapEmpty
When this future succeeds, null will complete the future returned by this method call.
When this future fails, the failure will be propagated to the returned future.
otherwise
When this future fails, the mapper will be called with the completed value and this mapper returns a value. This value will complete the future returned by this method call.
If the mapper throws an exception, the returned future will be failed with this exception.
When this future succeeds, the result will be propagated to the returned future and the mapper will not be called.
otherwise
When this future fails, this value will complete the future returned by this method call.
When this future succeeds, the result will be propagated to the returned future.
otherwiseEmpty
When this future fails, the null value will complete the future returned by this method call.
When this future succeeds, the result will be propagated to the returned future.
toCompletionStage
The CompletionStage handling methods will be called from the thread that resolves this future.
fromCompletionStage
fromCompletionStage
Copyright © 2021 Eclipse. All rights reserved.
