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

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

Потом я поступил в лицей, где познакомился с моим хорошим другом. Он тоже любил электронную музыку и также интересовался как ее делают. Часто смотрели всякие видосы о музыке, особенно доставляли те на которых ребята играют на «железках». Особенно удивил Launchpad от Novation.

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

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

Помещение школы

Учебный класс, на столе у каждого есть Ableton Push 2

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

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

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

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

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

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

Постер выступления

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

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

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

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

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

Железо

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

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

Хорошо что я покупал их б/у и продал по той же цене, что и покупал. Решил приобрести одно устройство, над которым можно сконцентрироваться и хорошо изучить. Остановился на коробочках от Elektron. Меня подцепил красивый дизайн, удобство и мощный сэквенсор.

Купил FM синтезатор Elektron Model:Cycles и потом докупил еще Model:Samples. Получился достаточно сбалансированный сэтап, с ним я понял, что хочу делать. Но оказалось, что Model:Cycles не сильно подходит под мои задачи, а вот samples напротив очень понравился.

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

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

Семплы

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

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

Так что ограничения рулят. Об этом Сергей Король написал отличный пост: Самоограничения

Интересные доклады

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

• «Как придумывать музыку» от Глеба Raumskaya
• «Как записать альбом» от Сергея Бурухина

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

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

Типы сервисов

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

• IaaS (Infrastructure as a Service) — облачный провайдер предоставляет минимально необходимую инфраструктуру в виде виртуальных машин, сети и хранилища, а также отвечает за работоспособность. Дальнейшая настройка, в том числе и ОС, лежит на стороне пользователя. По сути это основные строительные блоки в облаке с помощью которых можно сделать все что захотим.
• PaaS (Platform as a Service) представляет из себя готовую инфраструктуру для разработки и запуска приложений. При такой модели мы не думаем про настройку и управление серверами, операционными системами и т. д. Примером такого сервиса являются управляемые БД (managed databases). Облачный провайдер сам отвечает за правильную настройку сервера, ОС, сохранность данных, бекапах и бесперебойную работу. В основном пользователь только платит деньги и пользуется сервисом.
• Serverless, самая свежая модель, которая очень похожа на PaaS. Только при такой модели облако само выделяет ресурсы на основании текущей нагрузки. Все настройки и планирование ресурсов скрыто от пользователя. Ему остается только загрузить свой код, а все остальное сделает облако. Также в serverless мире обычно оперируют понятием облачная функция это код, который умеет обрабатывать только одни конкретный запрос.

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

Где захостить .NET бекенд?

AWS/Azure/GCP

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

Больше всего нас интересую сервисы:

• AWS EC2 (IaaS) обычные виртуальные машины. Есть маркетплейс на котором можно найти огромное множество готовых AMI образов с предустановленным софтом и нужными настройками. Например можно в один клик развернуть виртуалку с Wordpress и всем необходимым.
• Azure App Service (PaaS) самый простой и нативный способ захостить .NET приложения. App Service сам разворачивает приложение из репозитория, настраивает все необходимое для работы и предоставляет полезные метрики.
• AWS Lightsail (IaaS/PaaS) упрощенная версия AWS для тех кто с ним не знаком. Можно очень дешево арендовать виртуальную машину, поднять докер контейнер, развернуть БД и хранилище для файлов. Все это делается буквально в пару кликов мышкой. Первые три месяца бесплатные.
• AWS Elastic Beanstalk (PaaS) умеет поднимать необходимые для работы приложения компоненты в AWS. По сути мы можем все это сделать руками, но Beanstalk автоматизирует всю рутину. Под капотом он представляет из себя набор разных CloudFormation скриптов, которые поднимают необходимые сервисы и настраивают их.

DigitalOcean

Самый простой в использовании сервис. Раньше в DO можно было арендовать только виртуальные машины, сейчас же можно создавать управляемы БД, балансировщики и т. д. На текущий момент почти все мои проекты крутяться в DigitalOcean.

Нам интересны следующие сервисы:

• Droplets — виртуальная машина, есть много готовых образов на маркетплейсе под любой рантайм.
• App Platform — позволяет нативно запускать приложения написанные на Python, Nodejs, Go, php или любое другое приложение в виде контейнера.

Heroku

Честно говоря я им ни разу не пользовался, но друзья очень часто советуют. Из коробки не поддерживает .NET приложения, но вроде как есть кастомные билд паки. В основном хероку позволяет развернуть приложения на Nodejs, Go, Python и т. д. Из приятных фишек: достаточно запушить код в репозиторий, все остальное сделает Heroku.

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

Где захостить фронтенд?

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

Мой личный фаворит — Vercel. Бесплатный план включает такие фишки как HTTPS, автоматически деплой с репозитория, собственный домен. Также он умеет разворачивать приложение под каждый PR, что позволяет протестировать изменения до того как влить код в основную ветку.

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

App Platform от Digital Ocean я уже упоминал выше. Можно поднять три статических сайта бесплатно, последующие за 3$ в месяц. Есть автоматический деплой, бесплатный HTTPS, возможность подключения своего домена. Сейчас в нем крутиться мое онлайн резюме. Сервис прикольный тем что в нем можно запустить и бек и фронт.

Последним хочу отметить AWS S3. По сути это объектное хранилище (хранилище для файлов) в котором есть встроенная поддержка сайтов. Для этого нужно загрузить HTML/CSS/JS файлы и включить соответствующую опцию в настройках бакета. Часто встречает в продакшене связку CloudFront + S3.

Где развернуть базу данных?

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

• ElephantSQL, можно развернуть PostreSQL базу данных любого размера. Бесплатный план дает базу с 20 Мб и 5 параллельными подключениями.
• Mongo Atlas подойдет если нужно развернуть кластер MongoDB. Есть достаточно жирный бесплатный план.
• В DigitalOcean и AWS Lightsail начиная с 15 долларов в месяц можно развернуть достаточно неплохой сервер БД, который не нужно настраивать и работает из коробки. В Lightsail первые 3 месяца бесплатно.

Полезные ссылки

• Виды облачных ресурсов
• Хостинг веб сайта в AWS S3
• Отличный туториал по тому как настроить SSL сертификат на Ubuntu

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

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

Это не какая-то уникальная проблема, обычно для таких задач берут Google Tag Manager. Но никто из нас не умел им пользоваться да и желания изучать особо не было.

И тут внезапно пришла идея как это сделать. Можно взять AWS Lambda, набросать на коленке пару строк кода, которые будут получать событие и куда-то их складывать для дальнейшего анализа. Для места хранения метрик выбрал CloudWatch. Он как раз умеет анализировать разные метрики/логи и строить красивые дашборды.

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

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

Актуальная аналитика

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

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

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

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

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

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

Если кратно, то:

• Что делать если репозиториям нужно использовать закрытые методы друг друга?
• Можно ли использовать один репозиторий на весь проект или делать репозиторий на каждую сущность?
• Нужно ли дублировать методы репозитория в сервис или мы можем напрямую использовать репозиторий в контроллерах?
• Нужно ли возвращать IQueryable и как это повлияет на дизайн системы в случае с .NET кодом? Если нет, то как правильно изменять сущности без использования Change Tracking?
• Как правильно объединить репозиторий и UoW?

Отдельно также хочу отметить доклад: Денис Цветцих «Repository и UnitOfWork в 2020 году, must have или антипаттерн?». В нем также поднимаются проблемы репозитория, способы их решения и варианты замены этот шаблона на другой.

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

Для себя я решил что репозиторий хорошо подходит, когда вся логика приложения вписывается в CRUD модель. Но если логика более сложная или приложение подразумевает Task Base UI, тогда лучше прибегнуть к подходу CQRS. Он позволяет разбить сложную бизнес логику включая репозитории на независимые объекты, каждый из которых выполняет только одну бизнес задачу или use case.

Я кроме все прочего не люблю репозитории за:

• Ограничение функциональности ORM, большенство специфических операций недоступны. В зависимости от реализации можем потерять Change Tracking.
• Дополнительный мапинг из доменных объектов в DTO.
• Дополнительный слой абстракции, который зачастую просто не нужен. Особенно если речь идет о небольших сервисах где логику нужно делать максимально простой и незамысловатой.
• Работает только в простых CRUD сценариях.