Лазер хорошо видно только если он рядом. С нескольких шагов он уже плохо различим. Это если 50 милливат даже. Большей мощности уже дороже выйдет и возникнет смысл их воровать, а не распылители=).
Чтобы детектить нештатное замыкание линии, можно припаивать в качестве терминаторов на конце UTP набор резисторов. Правда придется подключать периметр к АЦП и мерять сопротивление, детектируя изменения.
Ну и маленькая идея вам на будущее. Для длинных линий можно точное место разрыва находить по задержке эхо-сигнала.
Достаточно выясниить непосредственную причину, оценить вероятность вероятность и целесообразность принятия каких-то мер, возможно добавить или изменить каике-то диагностические мероприятия в тех-процесс.
А перекладывать вину на «бардак» и «разруху» в умах ли, в стране ли, на конкретном ли предприятии — это неконструктивно, хотя и хайпово. Политическая и идеологическая ангажированность тут ни к чему.
Понятно что хотел сказать автор, понятно что хотел сказать Боб. Залезть же в бутылку всегда можно ещё глубже и дно тут не станет ограничением. Возможно кому-то покажется необходимым написать целое эссе в названии функции. Аббревиатуры полезны, если они устоявшиеся; 'get_' может оказаться полезным, если реально убирает какую-то неоднозначность… хотя если у вас есть какая-то неоднозначность, это незначит, что её следует решать только и именно неймингом. Может быть что-то пошло не так раньше, на более ранних этапах проектирования.
Этот вариант, конечно, лучше, но объективно же возможна ситуация, когда преобразовывать из разных входных форматов к единому для вычисления или вовсе невозможно или сложнее, чем сделать два отдельных вычисления на основе разных представлений.
К примеру мы делаем функцию, которая формирует специального вида хеш, вроде контент-id. И специфика алгоритма хеширования сильно зависит от формата входных данных, хотя сам результат — это просто GUID. Этот хеш нужно считать одним способом для звука, другим для изображений и третьим для видео. Если делать тут специальный слой абстрации нецелесообразно (не все же пишут на java, там лишний слой абстракции никогда не лишний=), то сделать три реализации вполне логично.
В питоне же, кстати, нет сигнатурной перегрузки функций, если опираться на названия входных параметров, то код функции может неоправданно усложниться.
Да простят мой тонкий троллинг те, кого он затронул. Хочу лишь добавить, что все правила важны и нужны, а с опытом мы понимаем мета-правила и приобретаем знания где какие правила актуальны.
Не очень хороший пример. Получается, что у функции две «ответственности», как выражается автор. Она отправляет метрики и как-то реагирует на невозможность их отправки (игнорирует, логирует warning, считает попытки прежде чем дропнуть исключение?)
При более правильном дизайне наша функция должна ТОЛЬКО отправлять метрики на удалённый сервер и валиться с исключением, если это не удалось. Если вдруг нужно делать несколько попыток или считать неудачи прежде чем бить тревогу, то этим займётся специальная обёртка, декоратор, или какая-то конструкция в вызывающем коде.
Да, автор не затронул тему ООП, мктодов, инкапсулированного состояния и прочее. Все эти правила нужно знать и понимать, но всё было бы слишком просто, если бы это были железные правила и у них бы не было исключений.
Я, конечно, то еще специалист — сам накосячил в тёплых полах где только можно. Но на счет физики есть маленькое замечание.
Когда мы щупаем поверхность, теплее нам будет казаться не та, температура которой выше, а та, у которой теплопроводность ниже (если речь о темпарутах ниже 30 градусов).
Тепловыми рецепотрами мы чувствуем не температуру, а количество теплоты, которое поступает в наши ткани или уходит из них.
Плитка проводит тепло гораздо лучше ламината и ощущаться она будет как более холодная поверхность даже если её температура такая же как у ламината.
Моя проблема в том, что каждый раз после таких статей мне мерещится некий Продукт, который всем нужен, а его нет и его можно сделать. Вот сейчас мне зачесалось сделать сервис ВЕЧНОГО хранения тегированных заметок в распределенной структуре вроде блокчейна. Любая книга имеет ISBN, а это может быть тегом к заметке. Любая статья или картинка в интернете может быть прохешированна по чистому контенту, а хеш добавлен к метаданнм статьи, картинки или документа. Эти хеши тоже можно превратить в теги и метить ими заметки. В конечном итоге у нас гигантская распределенная база тегированных заметок. По каким-то тегам можно искать соответствующие и связанные статьи и материалы.
Ну и прочие «нью-васюки» в том же духе про закладки, цитаты, напоминалки, дайджесты, научные работы, ссылки на публикации, Pocket и аналоги…
Так вот, моя проблема в том, что это всё на самом деле, как правило, нахрен никому не нужно.
Эх, Криптономикон что-то вспомнился.
Надо что-то эдакое потовое замутить, что будет краудфандингом спонсироваться и мигировать зеркалами в облаках само по себе…
Это должен быть какой-то типовой докер-контейнер для микроинстансов, который будучи развернутым пристёгивался сам к цепи серверов, между которыми распределен почтовый сервис.
не вижу никакого смысла разбивать операторную околесицу по строчкам. Файл станет длинным и сразу же станет очень сложно что-либо в этом файле найти.
А вот тут вы не правы. В Питоне есть правильный способ писать код. Правила довольно строги и имеет смысл привыкнуть к ним, а не нести свои привычки из других языков. Если код писать правильно, то размер файла по числу строк не будет критичен, зато все будет прозрачно и понятно с одного взгляда.
При правильном разбиении кода на модули, классы и методы проблем с навигацией возникнуть не должно. А вот кучи плохо читабельных кусков через точку с запятой — это кошмар.
Прелесть PEP-8 в том, что пользуясь им вы сделаете свой код очень похожим на большую часть чужого кода. Это дорогого стоит, поскольку не нужно отвлекаться на стилистические различия.
В современных IDE есть замечательные линтеры и автоформаттеры, а для хардкорщиков, работающих в IDLE есть чудесная библиотека pep8. Если скормить её питоновский файл, она перечислит все его проблемы, связанные с оформлением по pep-8
Не удержался, залез в код.
Скажите, почему вы используете лямбдами там, где можно использовать функции из модуля `operator`?
Ещё я бы завернул хэш-алгоритм в обертку для кодирования строк в utf-8, чтобы в тысяче мест не писать такое: «m.update(obj.__module__.encode(»utf-8"))"
Хочется отформатировать код по pep-8. Вы принципиально против него, или просто руки не доходили?
Это можно спрятать за отдельными необязательными опциями.
Это можно вынести в отдельную фичу — автогенерация автотестов.
То есть у вас есть ленивое вычисление и вы можете его запустить, а можете сгенерировать по нему параноидальный автотест. Пользователи его смогут запускать в пайплайне основного CI и своевременно увидят проблемы, причем на производительности вычислений это не скажется.
Ошибка случается, например, если ленифицируемый класс не переопределяет стандартный object.__repr__, который изменяется от запуска к запуску
Нужно детектить хотя бы регекспами стандартные неподходящие __repr__ и делать про это warning.
Нужно для типов, которые встречаются в первый раз, пробовать создать дважды один и тот же объект и сравнивать их __repr__ и хеши. Если результаты получаются разные — снова warning.
Ложноотрицательные ошибки приводят к тому, что ленификация не работает. Объект будет пересчитываться при каждом новом выполнении скрипта.
Можно запоминать место вычисления в дереве и прогонять одно и то же дважды. Если значения будут отличаться — warning. Это можно делать, например, в автоматически генерируемых автотестах для конкретного вычисления или при запуске с определенным ключом.
Репрезентация объекта (или переопределенная хэш функция) [..] совпадает с репрезентацией объекта другого типа.
Можно запекать тип значения рядом со значением в одной структуре. При встрече двух разных типов с одним хешем — warning.
Поскольку нужен провод между двумя точками с разных сторон сердца, основная проблема в нём, в не в размере передатчика. Так-то можно что-то вроде NFC интерфейса замутить и будет совсем компактно и энергонезависимо. Однако пирсинг, тем более такой, устроит не всех.
Можно в кроссовок встраивать два электрода для рук, а на телефон передавать по блютусу. Сел шнурки завязать, а на тебе — экг померялось. Можно даже сделать чтоб шнурки по расписанию развязывались.
Ну что ж, это выглядело достаточно безумно, чтобы быть неосуществимым при сегодняшних технологиях.
Зато, похоже, можно выпускать бюстгалтеры, достаточно точно снимающие ЭКГ. С мужиками сложнее. Разве что портупею какую-нибудь умную делать…
В статье недвусмысленно указано, что не достаточно. И это, в общем-то, очевидно. Однако какие-то тревожные признаки устройство всё таки может обнаружить и уведомить об этом владельца. В целом посыл такой, что игрушка-игрушкой, но даже такая малость — это уже лучше чем ничего. Опасность я вижу лишь в том, что кто-то обязательно «додумается» использовать эти часики ВМЕСТО похода к врачу. Как своего рода повод успокоиться и не идти. Как подкрепление своему когнитивному искажению.
Ну и маленькая идея вам на будущее. Для длинных линий можно точное место разрыва находить по задержке эхо-сигнала.
А перекладывать вину на «бардак» и «разруху» в умах ли, в стране ли, на конкретном ли предприятии — это неконструктивно, хотя и хайпово. Политическая и идеологическая ангажированность тут ни к чему.
К примеру мы делаем функцию, которая формирует специального вида хеш, вроде контент-id. И специфика алгоритма хеширования сильно зависит от формата входных данных, хотя сам результат — это просто GUID. Этот хеш нужно считать одним способом для звука, другим для изображений и третьим для видео. Если делать тут специальный слой абстрации нецелесообразно (не все же пишут на java, там лишний слой абстракции никогда не лишний=), то сделать три реализации вполне логично.
В питоне же, кстати, нет сигнатурной перегрузки функций, если опираться на названия входных параметров, то код функции может неоправданно усложниться.
Да простят мой тонкий троллинг те, кого он затронул. Хочу лишь добавить, что все правила важны и нужны, а с опытом мы понимаем мета-правила и приобретаем знания где какие правила актуальны.
При более правильном дизайне наша функция должна ТОЛЬКО отправлять метрики на удалённый сервер и валиться с исключением, если это не удалось. Если вдруг нужно делать несколько попыток или считать неудачи прежде чем бить тревогу, то этим займётся специальная обёртка, декоратор, или какая-то конструкция в вызывающем коде.
Да, автор не затронул тему ООП, мктодов, инкапсулированного состояния и прочее. Все эти правила нужно знать и понимать, но всё было бы слишком просто, если бы это были железные правила и у них бы не было исключений.
Когда мы щупаем поверхность, теплее нам будет казаться не та, температура которой выше, а та, у которой теплопроводность ниже (если речь о темпарутах ниже 30 градусов).
Тепловыми рецепотрами мы чувствуем не температуру, а количество теплоты, которое поступает в наши ткани или уходит из них.
Плитка проводит тепло гораздо лучше ламината и ощущаться она будет как более холодная поверхность даже если её температура такая же как у ламината.
Ну и прочие «нью-васюки» в том же духе про закладки, цитаты, напоминалки, дайджесты, научные работы, ссылки на публикации, Pocket и аналоги…
Так вот, моя проблема в том, что это всё на самом деле, как правило, нахрен никому не нужно.
Надо что-то эдакое потовое замутить, что будет краудфандингом спонсироваться и мигировать зеркалами в облаках само по себе…
Это должен быть какой-то типовой докер-контейнер для микроинстансов, который будучи развернутым пристёгивался сам к цепи серверов, между которыми распределен почтовый сервис.
А вот тут вы не правы. В Питоне есть правильный способ писать код. Правила довольно строги и имеет смысл привыкнуть к ним, а не нести свои привычки из других языков. Если код писать правильно, то размер файла по числу строк не будет критичен, зато все будет прозрачно и понятно с одного взгляда.
При правильном разбиении кода на модули, классы и методы проблем с навигацией возникнуть не должно. А вот кучи плохо читабельных кусков через точку с запятой — это кошмар.
Прелесть PEP-8 в том, что пользуясь им вы сделаете свой код очень похожим на большую часть чужого кода. Это дорогого стоит, поскольку не нужно отвлекаться на стилистические различия.
В современных IDE есть замечательные линтеры и автоформаттеры, а для хардкорщиков, работающих в IDLE есть чудесная библиотека pep8. Если скормить её питоновский файл, она перечислит все его проблемы, связанные с оформлением по pep-8
Скажите, почему вы используете лямбдами там, где можно использовать функции из модуля `operator`?
Ещё я бы завернул хэш-алгоритм в обертку для кодирования строк в utf-8, чтобы в тысяче мест не писать такое: «m.update(obj.__module__.encode(»utf-8"))"
Хочется отформатировать код по pep-8. Вы принципиально против него, или просто руки не доходили?
Это можно вынести в отдельную фичу — автогенерация автотестов.
То есть у вас есть ленивое вычисление и вы можете его запустить, а можете сгенерировать по нему параноидальный автотест. Пользователи его смогут запускать в пайплайне основного CI и своевременно увидят проблемы, причем на производительности вычислений это не скажется.
Нужно детектить хотя бы регекспами стандартные неподходящие __repr__ и делать про это warning.
Нужно для типов, которые встречаются в первый раз, пробовать создать дважды один и тот же объект и сравнивать их __repr__ и хеши. Если результаты получаются разные — снова warning.
Можно запоминать место вычисления в дереве и прогонять одно и то же дважды. Если значения будут отличаться — warning. Это можно делать, например, в автоматически генерируемых автотестах для конкретного вычисления или при запуске с определенным ключом.
Можно запекать тип значения рядом со значением в одной структуре. При встрече двух разных типов с одним хешем — warning.
В целом подход интересный. Спасибо.
Зато, похоже, можно выпускать бюстгалтеры, достаточно точно снимающие ЭКГ. С мужиками сложнее. Разве что портупею какую-нибудь умную делать…