Посмотрите на это с точки зрения потенциального клиента. Предположим вы ищете self-hosted решение для распознавания речи и желаете сравнить существующие варианты. Какова вероятность, что STT от Silero попадёт в предварительную выборку, если просто достать какую-то модель для тестов уже бюрократия и требует затрат труда вне команды разработки? Решение от OpenAI можно протестировать сразу, и потенциально, даже не рассматривать дальше. Простые ситуации закрыть vosk'ом, и так же до вас не дойти.
Возможность проверить выводы, сделанные в статье, так же отсутствует.
В ассемблере есть старый добрый RET, который извлекает из стека верхнее значение и передаёт управление соответствующей строке кода, вот только в стек можно писать что-угодно и даже забыть это что-то оттуда достать, получив неопределённое поведение. Некоторые очень злые программисты используют этот манёвр в качестве неявного GOTO.
Только в теории. На деле, фокус по матрице наводится только до определённого момента и если резкость в этом месте недостижима или аберрации велики, то получается промах. Фазовой фокусировки, в обычном представлении, у беззеркалок нет, там разные варианты встраивания его в матрицу.
Лаг затвора, скажем у Canon 1DX, от 0.1-0.04 секунды, а у второй версии порядка 0.03 в большинстве режимов. У беззеркалок, лаг обусловлен реинициализацией матрицы в режим съёмки и потом обратно, в liveview матрица работает с пониженной разрешающей способностью, так что буфера в ближайшее время можно не ждать, да и про роллинг-шаттер не забываем.
У них есть две большие проблемы — лаг видоискателя и фокусировка по матрице. Первое становится проблемой в репортажном сегменте, задержка может достигать 0.1 секунды, а снимать в слепую никому не хочется. Второе — чем дальше от центра кадра, тем ниже разрешающая способность объектива, да и плоскости резкости по краю и центру отличаются, что приводит к промахам автофокуса.
В том, что билдер инициализируется конструктором по умолчанию, а потом заполняется данными, и каждый сеттер может производить валидацию и генерировать свои исключения.
Не стоит пихать в конструкторы всё подряд. Пришла вам отрицательная цена, надо бы бросить какой-нибудь WrongPriceException, а делать это плохая идея. Java хоть и позволяет генерировать исключения в конструкторе, но на деле, вы получаете не инициализированный до конца объект который занимает место в памяти, и исключение которое может провалится туда, где оно не ожидается.
В ООП, вызывать методы ради сайдэффектов это обычная практика, особенно в высокоуровневом коде. Однако, в целом, это классическая с ситуация, если важна последовательность или целостность инициализации объекта, то вы используете фабрику или билдер, в зависимости от того, где находятся нужные для работы данные. Билдер даже можно передавать как аргумент, и возвращать из метода.
Вариант с бросанием исключения тоже приемлем. Не все договорённости можно выразить в коде, поэтому создание исключения с информативным сообщением и которое сможет возникать только во время разработки — не такой плохой способ, ибо Fail-fast.
На самом деле, ни одной из перечисленных вами проблем нет.
Презентер опирается на интерфейс, а никак не на реализацию, так что вы можете использовать его для разных вариантов одного вью. А хранение состояний в презентере — одно из худших решений, которое может придти разработчику в голову.
Храните всё в виртуальной БД уровня модели, используйте потоки, обычные или реактивные, для ленивого доступа, и забудьте о проблемах MVP.
На самом деле, у MVP есть минусы, но связаны они с совсем другими аспектами.
Вы предлагаете взаимодействовать с файловым менеджером мышкой? Я пользовался NC, пользовался Far'ом и пользуюсь Total Commander. Предпочитаю обходится клавиатурой, это быстрее и точнее. И всё перечисленное там есть десятилетия…
Windows File Explorer — простейшее встроенное средство навигации. Смысл, анализировать его функционал? Он предназначен для перекладывания пары файлов туда-обратно.
Зачем такие сложности? Код написанный с применением ретрофита, великолепно покрывается инструментальными тестами с использованием пакета com.squareup.okhttp.mockwebserver и, составленных по документации, ответов сервера.
Лично мне для этих целей понравился Dendron особенно в связке с системой контроля версий.
Раз текущие модели настолько лучше, покажите одну из старых, чтобы комьюнити могло прогнать те же самые тесты, на тех же выборках.
Посмотрите на это с точки зрения потенциального клиента. Предположим вы ищете self-hosted решение для распознавания речи и желаете сравнить существующие варианты. Какова вероятность, что STT от Silero попадёт в предварительную выборку, если просто достать какую-то модель для тестов уже бюрократия и требует затрат труда вне команды разработки? Решение от OpenAI можно протестировать сразу, и потенциально, даже не рассматривать дальше. Простые ситуации закрыть vosk'ом, и так же до вас не дойти.
Возможность проверить выводы, сделанные в статье, так же отсутствует.
Были бы модели для русского языка в открытом доступе, хотя бы старые версии, эту статью написали бы за вас.
В ассемблере есть старый добрый
RET, который извлекает из стека верхнее значение и передаёт управление соответствующей строке кода, вот только в стек можно писать что-угодно и даже забыть это что-то оттуда достать, получив неопределённое поведение. Некоторые очень злые программисты используют этот манёвр в качестве неявногоGOTO.Только в теории. На деле, фокус по матрице наводится только до определённого момента и если резкость в этом месте недостижима или аберрации велики, то получается промах. Фазовой фокусировки, в обычном представлении, у беззеркалок нет, там разные варианты встраивания его в матрицу.
Лаг затвора, скажем у Canon 1DX, от 0.1-0.04 секунды, а у второй версии порядка 0.03 в большинстве режимов. У беззеркалок, лаг обусловлен реинициализацией матрицы в режим съёмки и потом обратно, в liveview матрица работает с пониженной разрешающей способностью, так что буфера в ближайшее время можно не ждать, да и про роллинг-шаттер не забываем.
У них есть две большие проблемы — лаг видоискателя и фокусировка по матрице. Первое становится проблемой в репортажном сегменте, задержка может достигать 0.1 секунды, а снимать в слепую никому не хочется. Второе — чем дальше от центра кадра, тем ниже разрешающая способность объектива, да и плоскости резкости по краю и центру отличаются, что приводит к промахам автофокуса.
В том, что билдер инициализируется конструктором по умолчанию, а потом заполняется данными, и каждый сеттер может производить валидацию и генерировать свои исключения.
Не стоит пихать в конструкторы всё подряд. Пришла вам отрицательная цена, надо бы бросить какой-нибудь WrongPriceException, а делать это плохая идея. Java хоть и позволяет генерировать исключения в конструкторе, но на деле, вы получаете не инициализированный до конца объект который занимает место в памяти, и исключение которое может провалится туда, где оно не ожидается.
В ООП, вызывать методы ради сайдэффектов это обычная практика, особенно в высокоуровневом коде. Однако, в целом, это классическая с ситуация, если важна последовательность или целостность инициализации объекта, то вы используете фабрику или билдер, в зависимости от того, где находятся нужные для работы данные. Билдер даже можно передавать как аргумент, и возвращать из метода.
Вариант с бросанием исключения тоже приемлем. Не все договорённости можно выразить в коде, поэтому создание исключения с информативным сообщением и которое сможет возникать только во время разработки — не такой плохой способ, ибо Fail-fast.
У этих ключей есть более глобальный недостаток — многие сервисы их не поддерживают.
На самом деле, ни одной из перечисленных вами проблем нет.
Презентер опирается на интерфейс, а никак не на реализацию, так что вы можете использовать его для разных вариантов одного вью. А хранение состояний в презентере — одно из худших решений, которое может придти разработчику в голову.
Храните всё в виртуальной БД уровня модели, используйте потоки, обычные или реактивные, для ленивого доступа, и забудьте о проблемах MVP.
На самом деле, у MVP есть минусы, но связаны они с совсем другими аспектами.
Что-то это всё мне напомнило битловскую Revolution 9…
https://www.youtube.com/embed/6vwHXV_ShaI
В космосе, бессвинцовка и не используется, поскольку олово склонно к образованию "усов" и переходу в серое олово.
К счастью, наушники такой стоимости, вряд ли окажутся в руках человека грубо нарушающего технику безопасности.
Вы предлагаете взаимодействовать с файловым менеджером мышкой? Я пользовался NC, пользовался Far'ом и пользуюсь Total Commander. Предпочитаю обходится клавиатурой, это быстрее и точнее. И всё перечисленное там есть десятилетия…
Windows File Explorer — простейшее встроенное средство навигации. Смысл, анализировать его функционал? Он предназначен для перекладывания пары файлов туда-обратно.
Отличный пример, как делать НЕ надо. Если вам нужна клавиатура в приложении, соизвольте генерировать её, а не описывать каждую кнопку руками.
'данные в формате cd' читаются обычным CD проигрывателем. Например, саундтрек.
Про UMD забыли.
Зачем такие сложности? Код написанный с применением ретрофита, великолепно покрывается инструментальными тестами с использованием пакета com.squareup.okhttp.mockwebserver и, составленных по документации, ответов сервера.