Привет, Хабр! Меня зовут Денис Захаров. Я занимаюсь разработкой веб приложений на протяжении уже 14 лет, но история будет не об этом. Расскажу о том, как и почему я создавал эргономичное рабочее место, которое в последствии превратилось в проект Easyworkstation. Эта штука уже несколько лет полностью заменяет мне и еще нескольким десяткам пользователей привычное компьютерное кресло и рабочий стол.

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

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

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

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

Какие у нас есть варианты?

По мотивам этого поста.

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

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

Ситуация

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

1. «Генераторы „случайных чисел“: теория и практика» (А. Шень, LIRMM, Монпелье)
2. «SANNS: Scaling Up Secure Approximate k-Nearest Neighbors Search» (И. Разенштейн, Microsoft Research),
3. «Машинное обучение и приватность данных» (И. Миронов, Facebook AI),
4. «Решётки и упаковки шаров» (В. Клепцын, CNRS, Университет Ренна).

Эта статья — краткое руководство для тех, кто хочет запустить свой собственный подкаст. Когда я вместе с моим нынешним соведущим год назад запускал подкаст “В бесконечность и далее”, я не смог найти ни одной по-настоящему всеобъемлющей статьи. Поэтому я решил попытаться заполнить этот пробел и написать руководство для себя из прошлого.

Немного о структуре — это руководство содержит 4 статьи:

1. Общая философия
   1.1. Зачем делать подкаст?
   1.2. Целевая аудитория
   1.3. Выбор жанра
   1.4. Формат
2. Технический базис
   2.1. Что такое подкаст с технической точки зрения
   2.2. Аудио-формат
   2.3. Про динамики, наушники и ламповый звук
   2.4. Про тихое помещение
3. Делаем покупки
   3.1. Покупаем микрофон
   3.2. Выбираем аудиоредактор
   3.3. Выбираем программу для записи звука
   3.4. Выбираем хостинг подкаста
   3.5. Сайт-визитка
4. Записываем и выпускаем
   4.1. Запись выпуска
   4.2. Редактирование выпуска
   4.3. Про джинглы и звуковые схемы
   4.4. Про фоновый шум
   4.5. Про фильтры
   4.6. Про Show Notes, а также про то, зачем слушать свой подкаст
   4.7. Публикация подкаста
   4.8. Монетизация
   4.9. Темы, которые есть, но о которых мы не говорили

Каждый раздел статьи содержит три блока

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

Интересно — читайте все. Нет времени — читайте первый и последний абзац.

1. Общая философия

1.1. Зачем делать подкаст?

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

1. тех кто считает, что осмотический фильтр чистит все, кроме кармы и совести
2. и тех, кто подливает осмотическую воду в чай врагу, считая ее мертвой.

«Мы считаем, что через год мы предложим универсальное лечение против рака», – сказал Дэн Аридор о новом лечении, разработанном его компанией, Accelerated Evolution Biotechnologies Ltd. (AEBi), которая была основана в 2000 году в инкубаторе ITEK. AEBi разработала платформу SoAP, которая обеспечивает функциональные возможности для решения очень сложных проблем.

Связанные проекты сообщества Open Data (проект Linked Open Data Cloud). Многие датасеты на этой диаграмме могут включать в себя данные, защищенные авторским правом, и они не упоминаются в данной статье

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

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

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

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

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

Я планирую несколько статей, в которых будет пошагово рассказано, как написать свой VST плагин/инструмент: программирование осциллятора, частотного фильтра, различных эффектов и модуляции параметров. Упор будет сделан на практику, объяснение программисту простым языком, как же все это работает. Теорию (суровые выводы и доказательства) обойдем стороной (естественно, будут ссылки на статьи и книги).

Обычно плагины пишутся на C++ (кроссплатформенность, возможность эффективно реализовать алгоритмы), но я решил выбрать более подходящий для меня язык — C#; сфокусироваться на изучении самого синтезатора, алгоритмов, а не технических деталей программирования. Для создания красивого интерфейса я использовал WPF. Возможность использования архитектуры .NET дала возможность библиотека-обертка VST. NET.

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

Предстоит нелегкий путь, если вы готовы — добро пожаловать под кат.