В нём вопрос кабеля из золота или из серебра действительно что-то занчит, потому что после перегонки звука больше чем на 100 метров у них на целый децибел поднимается шум.
Я не знаю кем именно вы там работали в Голливуде, но за передачу аналоговых сигналов на 100+ метров, скорее всего, не отвечали. Ибо делается это не золотом и серебром, а балансным подключением обычной меди.
Маркетологический трёп какой-то. Эти переходники Type C > 3.5 по 200 рублей во всяких там фикспрайсах продаются.
Я так понимаю, первая половина новости сводится к тому, что в очередную ревизию эппловских ушей это встроили, а вторая - к тому, что продают отдельно втридорога (причём втридорога относительно своего такого же товара).
И не понимаю что там за обновления в связи с этим, потому что сторублёвые ЦАП-донглы я ещё в 2023-м к своему айпаду подключал, а другие люди и того раньше лет на 10. Никакой задержки и потери качества там и раньше не было, но теперь блютус стал настолько стандартным, что легко ему противопоставляться и более примитивное решение подавать как преимущество.
Вот если бы без потерь и задержки по радиоканалу, тогда было бы интересно.
Я бы вполне купил машину с единственным дисплеем - в салонном зеркале, причём только для обзора по камерам. Весь остальной функционал легко разделяется между физическими кнопками и смартфоном на держателе.
Работал с Nest.js в 2021-2023. Похожее впечатление от него. Потом я присоединился к другому проекту, где заказчику навязали всё сделать на AWS Lambda + MongoDB Atlas, то есть 100% serverless, и я, протестировав в такой среде знакомый Nest.js, как-то приуныл. Жалкий hello world бандлился в сотни килобайт и запускался пол-секунды. А таких лямбда-бандлов предполагалось много (ужасная архитектура в плане времени отклика безотносительно фреймворков, но сейчас речь не об этом).
Короче, решили не брать Nest.js, а запилить всё "прям так". Мы вдобавок ещё и без ORM/ODM обошлись - между JS и MongoDB практически нет impedance mismatch, ради которого стоило бы тащить мапперы. Поначалу я ещё сомневался - куда, мол, без DI и всего такого. Но быстро выяснилось, что так тоже можно, причём с покрытием юнит-тестами около 95%.
Справедливости ради, Nest.js честно навязывает свой подход, как и должен делать opinionated фреймворк. В этом есть плюс по консистентности решений.
Водитель не должен нести ответственность за бухих пешеходов, за идиотов, перебегающих дорогу где попало
Должен и несёт. "Источник повышенной опасности" и всё такое.
Основа в том, что любой человек это пешеход, даже безграмотный умственно отсталый выходец из среды отшельников. И давить его только за неосведомлённость, невнимательность и т.д. - нельзя. Он сохраняет право на жизнь и здоровье где бы ни оказался. Уже поверх этого принципа вам позволено обучиться и разогнать тонны металла до смертельно опасной скорости с условием, что вы успеете стормозить в случае чего. И вот только отсюда начинается разговор про смягчающие обстоятельства для вас в качестве водителя.
Я не пойму каким образом инкапсуляция обязательно запрещает тестировать конкретную реализацию. Тесты по интерфейсу останутся зелёными, тесты по контракту и/или деталям - покраснеют. Вполне можно позволить программисту решить насколько глубокими могут быть тесты.
Можно вытащить не ради тестов, а по соображениям, что это какая-то предварительная обработка ввода.
Всё так или иначе сводится к двум крайностям:
дробить (=усложнять) основной код ради простого тестирующего кода;
усложнять тестирующий код чтобы сохранить структуру основного.
Мне кажется, что так быть не должно. Человек на код-ревью приватный код смотрит. Линтеры приватный код анализируют и исправляют. Так почему автоматизированное тестирование должно быть только вокруг чёрного ящика?
Ок, предлагаю реальный пример. Может, не "прям необходимо", но взвесив всё, оказалось проще добраться до "приватного" метода.
Есть некий модуль регистрации пользователей. Регистрация в несколько этапов. Каждый этап представлен публичной функцией. На одном из этапов требуется ввести серийный номер устройства. То есть интерфейс примерно такой:
Всё это какое-то время работает. Среди прочего модуль регистрации покрыт своими тестами.
Но однажды заказчик говорит: вводимые серийные номера нужно сопоставлять с референсными частично, а не полностью, иначе пользователи не справляются с их вводом. К этому требованию прикладывается спецификация как именно нужно сопоставлять. Там же идёт портянка с позитивными и негативными кейсами, которые так и напрашиваются стать кейсами юнит-тестов.
Из этого change request'а на замену обычному == между строками вырастает функция matchSerialNumber:
/** Split SN into full and clean (meaningful) parts */
const parseSn = (sn: string) =>
sn
.toUpperCase() // make case-insensitive, also preferred display case
.replaceAll(/\-|\s/g, '') // remove non-positional garbage
.match(/^s?n?0*(.+)/i)!; // isolate positional garbage
const matchSerialNumber = (inputSn: string, referenceSnList: string[]): boolean => {
const input = parseSn(inputSn);
// Do we have any intersection? ([full, clean] x [full, clean]) for each entry in the list
return referenceSnList.map(parseSn).some((ref) => input.some((i) => ref.some((r) => r === i)));
};
Собственно, куда поместить этот код? Если нас не волнует юнит-тестирование согласно спецификации, то мы можем спокойно скрыть его (код) в модуле регистрации. Но если мы хотим на основе примеров сделать тесты, то с порятнкой примеров дотянуться до приватного matchSerialNumber будет сложно - на каждый нужно будет запустить сессию регистрации, довести её до ввода номера и т.п. Да, можно написать жирный хелпер в тестах, который будет готовить сессию. Либо можно вытащить matchSerialNumber в отдельный модуль, но это вытаскивание будет только ради тестов. Можно вытащить не ради тестов, а по соображениям, что это какая-то предварительная обработка ввода. Но это уже притягивание за уши. Проще всего в любом случае оставить функцию частью модуля регистрации.
В итоге я сделал функцию публичной и протестировал её почти напрямую.
С одной стороны, я поломал интерфейс. С другой, ради тестирования я написал только export, а не десятки строк кода и/или новые файлы. Если бы для тестирующего кода был свой уровень видимости, я бы с радостью воспользовался им в этой ситуации.
Там же контекст вполне чётко обозначен: получить деньги, а потом не выплачивать их. Звучит как обычное мошенничество.
И даже не пахнет несоразмерной компенсацией как в историях про "потребительский экстремизм". Классическая игра на опережение примерно как один и тот же чек два раза обналичить. С этим даже в позапрошлом веке боролись по-моему.
никакие попытки объяснить "зачем тестировать приватные методы" не будут убедительны.
Я всё же попробую. С точки зрения интеграционного тестирования юнит-тестирование это тоже нарушение доступа и проверка конкретной подкапотки. А с точки зрения end-to-end то же касается интеграционного тестирования. И так на сколько угодно уровней вверх. Но почему вдруг на каком-то уровне ниже это должно сломаться? Может, вся проблема в том, что такой уровень тестов никто красиво не назвал?
С одной стороны, да. С другой, вы позволяете второстепенному коду диктовать структуру первостепенного. По-моему это костыль от недостатка специальной области видимости только для тестов.
Да, я считаю, что тестирующему коду должно быть позволено знать больше о тестируемом, чем предлагает публичный интерфейс. Пускай такие тесты будут более хрупкими из-за привязанности к конкретной реализации, но это меньшая жертва, чем рефакторинг под публичную тестируемость. К тому же применять это можно ограниченно.
"Baseus 17 in 1 docking station", версия с тремя HDMI-выходами. Нормального номера модели у них нет.
Я не знаю кем именно вы там работали в Голливуде, но за передачу аналоговых сигналов на 100+ метров, скорее всего, не отвечали. Ибо делается это не золотом и серебром, а балансным подключением обычной меди.
Маркетологический трёп какой-то. Эти переходники Type C > 3.5 по 200 рублей во всяких там фикспрайсах продаются.
Я так понимаю, первая половина новости сводится к тому, что в очередную ревизию эппловских ушей это встроили, а вторая - к тому, что продают отдельно втридорога (причём втридорога относительно своего такого же товара).
И не понимаю что там за обновления в связи с этим, потому что сторублёвые ЦАП-донглы я ещё в 2023-м к своему айпаду подключал, а другие люди и того раньше лет на 10. Никакой задержки и потери качества там и раньше не было, но теперь блютус стал настолько стандартным, что легко ему противопоставляться и более примитивное решение подавать как преимущество.
Вот если бы без потерь и задержки по радиоканалу, тогда было бы интересно.
Я бы вполне купил машину с единственным дисплеем - в салонном зеркале, причём только для обзора по камерам. Весь остальной функционал легко разделяется между физическими кнопками и смартфоном на держателе.
С чего вы взяли?
Четыре монитора я подключал к обычному ноуту при помощи хаба за 8к₽. Видеокарта за 500 денег чисто для этого точно не нужна.
Деструктивностью редактирования. Нарисовал две стрелочки, решил подвинуть первую - облом.
Может, лучше антиплагиат прокачивать?
Работал с Nest.js в 2021-2023. Похожее впечатление от него. Потом я присоединился к другому проекту, где заказчику навязали всё сделать на AWS Lambda + MongoDB Atlas, то есть 100% serverless, и я, протестировав в такой среде знакомый Nest.js, как-то приуныл. Жалкий hello world бандлился в сотни килобайт и запускался пол-секунды. А таких лямбда-бандлов предполагалось много (ужасная архитектура в плане времени отклика безотносительно фреймворков, но сейчас речь не об этом).
Короче, решили не брать Nest.js, а запилить всё "прям так". Мы вдобавок ещё и без ORM/ODM обошлись - между JS и MongoDB практически нет impedance mismatch, ради которого стоило бы тащить мапперы. Поначалу я ещё сомневался - куда, мол, без DI и всего такого. Но быстро выяснилось, что так тоже можно, причём с покрытием юнит-тестами около 95%.
Справедливости ради, Nest.js честно навязывает свой подход, как и должен делать opinionated фреймворк. В этом есть плюс по консистентности решений.
Должен и несёт. "Источник повышенной опасности" и всё такое.
Основа в том, что любой человек это пешеход, даже безграмотный умственно отсталый выходец из среды отшельников. И давить его только за неосведомлённость, невнимательность и т.д. - нельзя. Он сохраняет право на жизнь и здоровье где бы ни оказался. Уже поверх этого принципа вам позволено обучиться и разогнать тонны металла до смертельно опасной скорости с условием, что вы успеете стормозить в случае чего. И вот только отсюда начинается разговор про смягчающие обстоятельства для вас в качестве водителя.
Я не пойму каким образом инкапсуляция обязательно запрещает тестировать конкретную реализацию. Тесты по интерфейсу останутся зелёными, тесты по контракту и/или деталям - покраснеют. Вполне можно позволить программисту решить насколько глубокими могут быть тесты.
Тоже было:
Всё так или иначе сводится к двум крайностям:
дробить (=усложнять) основной код ради простого тестирующего кода;
усложнять тестирующий код чтобы сохранить структуру основного.
Мне кажется, что так быть не должно. Человек на код-ревью приватный код смотрит. Линтеры приватный код анализируют и исправляют. Так почему автоматизированное тестирование должно быть только вокруг чёрного ящика?
Это звучит как уже рассмотренный вариант:
Ок, предлагаю реальный пример. Может, не "прям необходимо", но взвесив всё, оказалось проще добраться до "приватного" метода.
Есть некий модуль регистрации пользователей. Регистрация в несколько этапов. Каждый этап представлен публичной функцией. На одном из этапов требуется ввести серийный номер устройства. То есть интерфейс примерно такой:
Всё это какое-то время работает. Среди прочего модуль регистрации покрыт своими тестами.
Но однажды заказчик говорит: вводимые серийные номера нужно сопоставлять с референсными частично, а не полностью, иначе пользователи не справляются с их вводом. К этому требованию прикладывается спецификация как именно нужно сопоставлять. Там же идёт портянка с позитивными и негативными кейсами, которые так и напрашиваются стать кейсами юнит-тестов.
Из этого change request'а на замену обычному
==между строками вырастает функцияmatchSerialNumber:Собственно, куда поместить этот код? Если нас не волнует юнит-тестирование согласно спецификации, то мы можем спокойно скрыть его (код) в модуле регистрации. Но если мы хотим на основе примеров сделать тесты, то с порятнкой примеров дотянуться до приватного
matchSerialNumberбудет сложно - на каждый нужно будет запустить сессию регистрации, довести её до ввода номера и т.п. Да, можно написать жирный хелпер в тестах, который будет готовить сессию. Либо можно вытащитьmatchSerialNumberв отдельный модуль, но это вытаскивание будет только ради тестов. Можно вытащить не ради тестов, а по соображениям, что это какая-то предварительная обработка ввода. Но это уже притягивание за уши. Проще всего в любом случае оставить функцию частью модуля регистрации.В итоге я сделал функцию публичной и протестировал её почти напрямую.
С одной стороны, я поломал интерфейс. С другой, ради тестирования я написал только
export, а не десятки строк кода и/или новые файлы. Если бы для тестирующего кода был свой уровень видимости, я бы с радостью воспользовался им в этой ситуации.И заодно базовый "бездоговорный" тариф у любого оператора, пожалуйста.
Как только вас таких наберётся там под сотню тысяч, тогда и возникнет обязанность приземлять данные под угрозой штрафа/блокировки.
Там же контекст вполне чётко обозначен: получить деньги, а потом не выплачивать их. Звучит как обычное мошенничество.
И даже не пахнет несоразмерной компенсацией как в историях про "потребительский экстремизм". Классическая игра на опережение примерно как один и тот же чек два раза обналичить. С этим даже в позапрошлом веке боролись по-моему.
Тест прямо на проде? Ок, допустим. А какие тесты у вас выполняются до прода?
Я всё же попробую. С точки зрения интеграционного тестирования юнит-тестирование это тоже нарушение доступа и проверка конкретной подкапотки. А с точки зрения end-to-end то же касается интеграционного тестирования. И так на сколько угодно уровней вверх. Но почему вдруг на каком-то уровне ниже это должно сломаться? Может, вся проблема в том, что такой уровень тестов никто красиво не назвал?
Членотестирование?
С одной стороны, да. С другой, вы позволяете второстепенному коду диктовать структуру первостепенного. По-моему это костыль от недостатка специальной области видимости только для тестов.
Да, я считаю, что тестирующему коду должно быть позволено знать больше о тестируемом, чем предлагает публичный интерфейс. Пускай такие тесты будут более хрупкими из-за привязанности к конкретной реализации, но это меньшая жертва, чем рефакторинг под публичную тестируемость. К тому же применять это можно ограниченно.