Unity: причина ввода комиссии Unity Runtime Fee — это возможность продолжить устойчивый бизнес для Unity

«Самое фундаментальное, что мы пытаемся сделать, — это построить устойчивый бизнес для Unity», — пояснил Уиттен.

Unity существует 19 лет (до 2007 года под названием Over the Edge Entertainment), вышла на IPO три года назад, выручка $1.4 млрд (при этом убытки $900+ млн) и теперь они решили строить устойчивый бизнес? [мем кота с часами]

Без ответа осталось, как такой факап мог произойти. Почему проигнорировали ранний фибдек от своих разработчиков и представителей геймдева, собственные расчеты (по своей собственной статистике им было очевидно, что часть студий будет платить значительно больше 5% выручки, а часть уйдет в минус). И здравый смысл.

И что было сделано, чтобы такой факап не произошел снова.

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

Костный звук нового уровня — обзор Aftershokz Aeropex

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

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

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

Для меня в Trekz Air есть несколько жирных минусов:

1. Наушники стоят почти $150, но не умеют обновлять прошивку, – софт в них не улучшится никогда.
2. Они плохо переключаются между девайсами. Технически они multipoint pairing, но если один из источников продукт apple, то он всегда будет иметь приоритет, и переключиться обратно на андроид не получится.
3. На андроиде у них своя громкость, параллельная громкости телефона.
4. У них есть два режима эквалайзера, но невозможно узнать, в каком именно ты сейчас. При переключении наушники только подтверждают “Equalization Changed”. Саппорт рекомендует полностью сбросить на дефолтные настройки и от них считать переключения, чтобы знать, в каком ты находишься сейчас. Не шутка.
5. Они умеют отвечать на звонок телефона, но не умеют отвечать на звонок WhatsApp или Skype. Универсальная кнопка, отвечающая на звонок телефона, в случае со скайпом или WhatApp отключает гарнитуру и переводит вывод звука на динамик телефона. Крайне неочевидное решение. Приходится быстро доставать телефон.
6. Они не умеют переключать треки. Когда слушаешь аудио-книгу или подкаст часто нужно перематывать рекламные паузы или возвращаться назад, чтобы еще раз прослушать часть текста. Это только через телефон. Обычно в BT наушниках можно перенастроить кнопки громкости на переключение треков, здесь это не поддерживается.
7. У них нет аппа для настроек.
8. Они не умеют вставать на паузу, когда их снимаешь.
9. Они не умеют сами выключаться при длительной неактивности.
10. Personal assistant может отвечать очень громко, значительно громче того, что вы слушали.

Альтернативой им я бы смотрел затычки с pass-through (он же ambient sound). Не пробовал, поэтому не могу рекомендовать, что лучше.

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

Ортодоксальный Backend

если этот момент настолько принципиален

Дело не в принципиальности и не придирках

это ничего не даёт с практической точки зрения кроме демагогии

… не знаю, что на это сказать.

Action должен быть классом ввиду необходимости корректного использования DI

Может. (Кстати, в Hanami экшены контроллера реализованы отдельными классами в отличие от Rails.) Так же экшен может быть модулем. Для DI не обязателен OOP и классы.

но вот, надеюсь, что для вас не является секретом, что функции в JavaScript это тоже объекты

Не очень понимаю отсылку к JS, учитывая примеры на Руби.
Кстати, в Руби функции тоже объекты и методы объектов тоже объекты, и классы тоже объекты. Надеюсь, для вас это тоже не секрет. Но это не меняет сути. Это разные вещи с разными свойствами вне зависимости от того, что и то, и то реализовано через объекты.
Вообще, не очень понимаю этот аргумент. Если функции реализованы в языке объектами, то что?

PS. Ладно, дискуссии не получилось

Ортодоксальный Backend

С чем дискутирую я: автор в статье заявил, что «Но контроллер вообще не должен быть классом» — с чем я согласен. Но затем последовал пример с контроллером-классом. Что меня удивило.

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

Ортодоксальный Backend

Тогда вам по идее всё это надо регулировать в роутере

Да. Ну, если мы говорим, что DI это хорошо, то да, цена этого — вызов с зависимостью в параметре. Не хочется протаскивать — можно захардкодить зависимости или использовать контейнер. Это всегда вопрос trade off'a

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

Ортодоксальный Backend

Ответил ниже

Ортодоксальный Backend

По

HTTP GET

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

Почему цепочка вызовов, разве экшен контроллера будет вызываться не из роутера?

Потом, это вы же сами написали

Но контроллер вообще не должен быть классом, это должен быть скорее модуль

теперь вы этот тезис оспариваете?

Еще вариант работы с зависимостями — использовать контейнер.

Ортодоксальный Backend

Но контроллер вообще не должен быть классом, это должен быть скорее модуль

Почему тогда в примере не сделать контроллер модулем? Зачем ему стейт?

Вместо

class ListInvoices

  def initialize(invoice_repository)
    @repository = invoice_repository
  end

  def call
    @repository.get_all
  end
end

Куда проще

module ListInvoices

  def self.call(repository)
    repository.get_all
  end
end

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