Интересная тематика, мы как раз для наших проектов ищем транскрибацию (лучше всего из РФ)
Но честно говоря, статья сделана плохо:
Вы говорите о "бенчмарках", но при этом не выложили код
Говорите о видео, на которых основывали, но не приложили их
Где сам результат транскрибации?
"репозиторий с более подробными таблицами из статьи" – это просто набор png с графиками, которые ничего дополнительного не несут
А еще есть предположение, что вы использовали один и тот же S3 (зарубежный или РФ) и геолокация может очень сильно влиять на результаты
Короче, без вот этих пунктов выводы невозможно проверить, а значит вы могли написать абсолютно что угодно
И вот это фраза: "Если вам нужно самое лучшее качество и вы не в России, берите ElevenLabs. Если же вам нужна высокая скорость и отличное качество, пользуйтесь Nexara. Если вы хотите порезать стоимость транскрибации в несколько раз, и вам не очень важно высокое качество, используйте Groq." – буквально переводится как: "Не в РФ – ElevenLabs. В РФ – Nexara. И ни туда, ни сюда." – а поскольку статья в РФ источнике, попахивает рекламой
Могу ошибаться, но чтобы это понять, выложите вводные и результаты ваших экспериментов из пунктов, что я написал выше
Согласен, я только учусь писать быстро, со смыслом, так и чтобы красиво. Если вдруг будут советы, где подсмотреть качественный стиль написания подобных статей или что можно было бы поправить в текущей, буду признателен.
Да, полностью согласен и продавать бизнесу рефакторинг подобного рода сложно (а фриланс я вообще никогда не учитываю, для меня это сторонний мир)
Среднестатистически я пытаюсь оцифровать затраты, которые несет бизнес (сколько стоит uptime, как много часов бэклога ушло на дебагинг системы, доработку самопала или оптимизацию взаимодействия с ним, сколько тратиться на инфру, что разработчики не могут использовать из-за самопала из-за чего новые фичи выходят медленнее) и какие фичи они долгосрочно хотят, прикидывая как новое решение поможет достичь этого, потом предоставляю эти цифры, со словами: "Вот эти деньги мы сможем сохранить и конвертировать в больше фич, если сделаем вот это" – и дальше уже то, насколько я был убедителен
Уверен ли каждый раз в своих словах? Нет, удивительно насколько часто это все субъективно, НО практика показывает, что с опытом начинаешь попадать все четче и четче и это опуртонистическое: "нас ждет светлое будущее" – может и не в такой степени, но сбывается
Важно рисковать, брать ответственность, показывать всем бенефиты, но готовиться к шторму
Да, в данной ситуации (1) код был разбросан необоснованно, (2) пост больше про еще одно преимущество складывать связанный код ближе друг к другу, ЕСЛИ такая возможность имеется, (3) я вернул все на места, потому что это прод код, который сделан так как сделан и на данный момент единообразие всей кодовой базы – более ценно для всех, чем модификация одного куска.
При этом в дальнейшем, команда мигрирует уже на подход с лоцирование кода ближе к месту использования.
Наша ветка — прекрасный пример тому, что несмотря на приличное количество контрпримеров, основной текст (и тон) вашего поста остался без изменений.
Да, потому что это мой пост и мое мнение, а есть ваше мнение.
Я хочу, чтобы вы не пропагандировали идею, что что-то, называющееся «законом Деметры» на самом деле является сколько-нибудь объективным правилом, ведущим к хорошему коду.
Для вас нет, а мне и моим коллегам знание этого принципа полезно для принятия решения использовать или не использовать его в той или иной ситуации.
У всех есть свои догмы, у меня свои. Я, например, считаю, что типизация приносит исключительно положительный эффект, а есть люди, которые против использования типизации. Я с ними дел вести не буду.
У вас есть позиция против LoD, ок, это ваша позиция.
Ну то есть ваша цель — она «получить побольше комментариев»?
Начать диалог с аудиторией, потому что в процессе диалога рождается много полезных мыслей и идей. Например, наша с вами ветка – прекрасный тому пример.
А «правила» вообще существуют в определенных рамках.
Оно называет «Правило / Закон Деметры», вы хотите чтобы я перевел это как-то по-другому? Кажется, вы не заметили, что лично я использую в статье слово «принцип»
Согласен, но вы очень категоричны, мне нравится мое название, оно завлекает и заставляет людей написать почти 40 комментариев)
… а вмержить все равно не дадут, потому что правила.
Мы говорим про терминологию, а не устав процесса разработки компании, это абсолютно разные вещи. Это как соотносить «замок» на двери, и «замок» при вязке собак.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация». А если вы решили добавить его в устав, тогда становиться «правилом», но только в определенных рамках.
Случай с текстом не критический (хоть и влияет на восприятие), а вот случай с «обращением к локальной переменной» приведет к ошибке во время компиляции / исполнения кода.
Так вот, хоть и дословный перевод «Law of Demeter» получается «Правило / Закон Деметры», но, конечно же, на деле, это «рекомендация», потому что соблюдение / не соблюдение данного «правила» не повлияет на runtime или компиляцию кода.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация».
И опятьже ".Active()" это раскрытие подробностей, о которых внешнему коду может быть (зависит от бизнес-требований, о чем я писал выше) абсолютно не нужно знать.
Интересная тематика, мы как раз для наших проектов ищем транскрибацию (лучше всего из РФ)
Но честно говоря, статья сделана плохо:
Вы говорите о "бенчмарках", но при этом не выложили код
Говорите о видео, на которых основывали, но не приложили их
Где сам результат транскрибации?
"репозиторий с более подробными таблицами из статьи" – это просто набор png с графиками, которые ничего дополнительного не несут
А еще есть предположение, что вы использовали один и тот же S3 (зарубежный или РФ) и геолокация может очень сильно влиять на результаты
Короче, без вот этих пунктов выводы невозможно проверить, а значит вы могли написать абсолютно что угодно
И вот это фраза: "Если вам нужно самое лучшее качество и вы не в России, берите ElevenLabs. Если же вам нужна высокая скорость и отличное качество, пользуйтесь Nexara. Если вы хотите порезать стоимость транскрибации в несколько раз, и вам не очень важно высокое качество, используйте Groq." – буквально переводится как: "Не в РФ – ElevenLabs. В РФ – Nexara. И ни туда, ни сюда." – а поскольку статья в РФ источнике, попахивает рекламой
Могу ошибаться, но чтобы это понять, выложите вводные и результаты ваших экспериментов из пунктов, что я написал выше
А пока это псевдоисследование
Поменял
Согласен, я только учусь писать быстро, со смыслом, так и чтобы красиво. Если вдруг будут советы, где подсмотреть качественный стиль написания подобных статей или что можно было бы поправить в текущей, буду признателен.
Да, полностью согласен и продавать бизнесу рефакторинг подобного рода сложно (а фриланс я вообще никогда не учитываю, для меня это сторонний мир)
Среднестатистически я пытаюсь оцифровать затраты, которые несет бизнес (сколько стоит uptime, как много часов бэклога ушло на дебагинг системы, доработку самопала или оптимизацию взаимодействия с ним, сколько тратиться на инфру, что разработчики не могут использовать из-за самопала из-за чего новые фичи выходят медленнее) и какие фичи они долгосрочно хотят, прикидывая как новое решение поможет достичь этого, потом предоставляю эти цифры, со словами: "Вот эти деньги мы сможем сохранить и конвертировать в больше фич, если сделаем вот это" – и дальше уже то, насколько я был убедителен
Уверен ли каждый раз в своих словах? Нет, удивительно насколько часто это все субъективно, НО практика показывает, что с опытом начинаешь попадать все четче и четче и это опуртонистическое: "нас ждет светлое будущее" – может и не в такой степени, но сбывается
Важно рисковать, брать ответственность, показывать всем бенефиты, но готовиться к шторму
Да, в данной ситуации (1) код был разбросан необоснованно, (2) пост больше про еще одно преимущество складывать связанный код ближе друг к другу, ЕСЛИ такая возможность имеется, (3) я вернул все на места, потому что это прод код, который сделан так как сделан и на данный момент единообразие всей кодовой базы – более ценно для всех, чем модификация одного куска.
При этом в дальнейшем, команда мигрирует уже на подход с лоцирование кода ближе к месту использования.
Да, потому что это мой пост и мое мнение, а есть ваше мнение.
Для вас нет, а мне и моим коллегам знание этого принципа полезно для принятия решения использовать или не использовать его в той или иной ситуации.
У всех есть свои догмы, у меня свои. Я, например, считаю, что типизация приносит исключительно положительный эффект, а есть люди, которые против использования типизации. Я с ними дел вести не буду.
У вас есть позиция против LoD, ок, это ваша позиция.
Начать диалог с аудиторией, потому что в процессе диалога рождается много полезных мыслей и идей. Например, наша с вами ветка – прекрасный тому пример.
Оно называет «Правило / Закон Деметры», вы хотите чтобы я перевел это как-то по-другому? Кажется, вы не заметили, что лично я использую в статье слово «принцип»
Согласен, но вы очень категоричны, мне нравится мое название, оно завлекает и заставляет людей написать почти 40 комментариев)
Мы говорим про терминологию, а не устав процесса разработки компании, это абсолютно разные вещи. Это как соотносить «замок» на двери, и «замок» при вязке собак.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация». А если вы решили добавить его в устав, тогда становиться «правилом», но только в определенных рамках.
Так вот, хоть и дословный перевод «Law of Demeter» получается «Правило / Закон Деметры», но, конечно же, на деле, это «рекомендация», потому что соблюдение / не соблюдение данного «правила» не повлияет на runtime или компиляцию кода.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация».
Можете привести пример полноценного правила?
А можете привести пример «правил», которые нарушать нельзя нигде и никогда?
Любой адекватный программист понимает, что правила – это ориентир, а не неприкосновенная истина.
Ими можно пользоваться, а можно этого не делать. Выбор за каждым.
Просто не везде бывают getter (например в Golang в любом случае пришлось бы писать метод getComments)
Это как-то слишком похоже на QueryBuider, поэтому я скорее за «repository.Where(ActiveSpecification())», но это лично моя вкусовщина.
Через переопределение getter?
А, вы в формате Active Record пишите, понял. Я использую Repository, чтобы больше сохранять чистоту Сущностей.
Как именно будет спрятано?
Вы выстаиваете цепочку методов от post, а спецификация должна существовать как отдельный класс с chain methods или как command.
Я не говорил что LoD это говорит, наоборот, if бизнес-логика требует управлять вложенными сущностями -> можно использовать LoD
Это супер и они как раз являются отличными примером того, как LoD помогает структурировать код.
Спецификация не должна быть частью сущности post, вот здесь есть хороший пример Specification blog.byndyu.ru/2014/07/command-and-query-responsibility.html