Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Бэкенд разработчик, Архитектор программного обеспечения
Ведущий
От 1 000 000 ₽
PHP
Docker
PostgreSQL
Kubernetes
CI/CD
Базы данных
Спасибо за инструмент и материалы, комменты тоже не менее информативные
У меня такой вопрос. Собираюсь менять свой кинетик на что-то другое, формировал год назад список, останавливался на:
GL-iNet Flint 2 (GL-MT6000)
ASUS TUF Gaming AX4200
ASUS TUF Gaming AX6000
Может подскажет кто, насколько это ещё актуальные железяки и справятся ли они с текущими реалиями? Может другие модели посоветуете? Я с OpenWRT пока малознаком, но хотелось бы стратегическую железку взять на вооружение домой с хорошей сетью.
Если сделаете скрин с экрана, буду очень благодарен! Сразу в статью добавлю
Проверяли команды? Отрабатывает смена состояния?
Добрый день! Спасибо за указание!
Я совсем забыл, что у меня выключено автообновление приложений и даже мысль не пришла проверить наличие этой опции сейчас)
Надо посмотреть как оно работает и обновить статью, займусь как время будет
Круто! Было бы интересно почитать про это в отдельной статье
Готовые плагины всё таки более приятный инструмент и подходит большей аудитории, чем ручное ковыряние каких-то настроек и вычитывание документации
Может быть целесообразно назвать её не просто Polaris? Чтобы люди по названию могли понять, что им это подходит?
Не знал об этой опции, не практиковал
Но что-то у меня подозрение, что подружить это с чем-то не из экосистемы Hommyn будет сложно
Вот ссылка на их датчик: https://hommyn.app/products/datchik-temperatury-i-vlazhnosti-ths30zb/
Думаю с ним отработает
Спасибо большое!
Как и говорил, на тот момент не нашел девайса альтернативного, видимо плохо искал. Может смутило, что в официальной инструкции было указание на Hommyn
А как давно это устройство на рынке? Может в момент покупки как раз и не гуглилось
Выглядит вроде здорово, следующий девайс с управлением через внешний модуль попробую через него
Спасибо за гист, почитаю обязательно
Конкретно в моём случае - это не особо важная настройка была, поэтому решил не разбираться
Если вопрос в группировке - можно взять любой датчик, например с MQTT, да прикрутить его как кастомное устройство с той же по значениям секцией
deviceСсылка на доку: https://www.home-assistant.io/integrations/sensor.mqtt/
Надо будет указать
device_class: temperatureдля "нативности"По логике, со стороны ХА будет выглядеть как цельное устройство с отдельным сенсором температуры
В целом - путей много)
Спасибо за вопрос!
Само подключение у устройства типовое, там ничего сверхъестественного нету. Стандартная процедура для устройств умного дома. В приложении при подключении указывается SSID и пароль от сети.
И, как подметил @DaemonGloom, в комп его вставлять действительно нет смысла, устройство считывает сигналы кондиционера таким образом - это интерфейс шины, а не привычный USB
Полагаю, получение адреса для MQTT делали либо на уровне роутера, либо сам вендор его выдал в своё время.
Спасибо за ёмкий ответ!
Расскажу немного про наш велосипед
К сожалению, система полностью закрытая, разрабатывалась под заказ для нужд одного университета
У нас на данный момент реализованы только html/css/js (причём js только клиентский), что позволило полностью изолировать бэк от возможных проблем, потому что код исполняется в браузере
У нас была задача с прогоном клиентских тестов, которую мы решали путём создания iframe sandbox'a, в котором специальным образом запускался код пользователя с инъекцией туда служебных вставок для прогона тестов, которые писались вместе с заданием нашими преподавателями
В целом система получилась по части бэка крайне легковесная, сложным был именно клиент в виду специфики создания там sandbox
Сейчас же мы планируем запуск курсов с использованием серверных вычислений и с компиляцией клиентского кода, чтобы преподаватели могли составлять курс по React JS
Именно поэтому мой комментарий содержит столько вопросов, потому что нам лишь предстоит пройти этот тернистый путь
Правильно ли я понимаю вашу схему организации:
1. В хостовой системе создаётся учётный пользователь с ограниченными правами, от имени которого выполняется сборка и запуск контейнера? Т.е. по сути добавляете в группу docker некоего пользователя, который ограничен в хосте только своей домашней директорией
2. Dockerfile содержит в себе необходимый минимум, сборка (при необходимости) пользовательского кода происходит в контейнере
3. Ограничение исполнения устанавливается путём, видимо, энтрипоинта с установкой линуксового таймаута
4. При работе с файлами перед запуском пользовательского кода домашняя директория очищается и монтируется к контейнеру с правами записи
Из 4 пункта следует вопрос - а как у вас дела с параллельностью? Т.е. все прогоны пользовательского кода как-то распланированы? Чем планируете? Некие queue с последовательным исполнением? Есть ли реальный параллелизм и на какое конкурентное исполнение вы нацелены? И в случае конкурентности следует вывод, что количество конкурентных прогонов равно количеству пользователей от имени которых гоняют запуск кода
И ещё открытый вопрос - это прогон тестов
Очевидно, на вход нужно давать некий ввод, на выход ловить какой-то выхлоп
Для задач без файловой системы вроде бы звучит просто, перехватил прям в контейнере stdin/stdout и работаешь
В ряде случаев даже можно писать stdout в файл и парсить, чтобы не оборачивать программу в какой-то враппер (тут кстати тоже потенциальная дыра, особенно в части stdout, потому что в зависимости от стека можно добиться исполнения произвольного кода, ну да не суть)
Т.е. всегда ли у вас прямо внутри контейнеров запускается прогон тестов, потому что нужно давать ввод и читать вывод
Или вы снаружи контейнера это делаете, путём энтрипонтов или аргументов docker run?
А вот при работе с файловой системой становится очень очевидно. С одной стороны похоже на чтение ввода вывода, а с другой совсем нет, потому что можно работать как внутри, так и снаружи, причём абсолютно по разному (и на ЯП, и на линуксовых командах, и перехватом запросов к файловой системе)
В ооооообщем, очень интересная тема для беседы
И мне кажется, что описание серверной части достойно отдельной статьи, потому что там вы решали очень интересные задачи
С радостью бы почитал, а может и смог бы помочь в решении каких-то особенных задач
Привет!
Мы с командой тоже делали сервис для изучения ЯП
Интересно в этой цепочке узнать у вас какие-то детали по работе с Docker и изоляцией запускаемого кода
Как контролируете запускаемый код по выделяемым ресурсам (таймауты, лимиты по CPU/ОЗУ)?
Какие образы используете (наверное что-то на базе alpine)? Много ли у вас заготовленных образов под разные задачи или под каждую задачу просто делаете Dockerfile с чем-то типа
FROM base-image? Сразу ли чистите собранные контейнеры?Есть ли у вас в цикле курса работа с файловой системой? Если да, то при работе с ней в запускаемом коде как работаете с Docker? Даёте право на запись файлов? Или только чтение?
Боретесь ли как-то с возможными угрозами в коде? Можно ведь выйти за границы контейнерной изоляции и запустить что-то в ядре хоста
Эта часть намного интереснее всего остального на мой взгляд)
Будет интересно почитать, если на что-то ответите
Добрый день, Олег!
Надеюсь, вы взыскали ответы на свои вопросы спустя столько времени.
P.S. Если что, ты уж пиши мне в скайпе иногда, буду рад помочь!
Лично в моем опыте werf со своим "гитермизмом" в ряде случаев становился проблемой. Инструмент, безусловно, отличный. Пайпы выглядит проще, трассировка процесса доставки очень хорошо и красиво выводится в лог job'ы в Gitlab. Но если появляется потребность в лёгкой гибкости и вам нужно внедрить что-то дополнительное в процессе сборки/деплоя, то начнется сущий ад.
Не отрицаю, опыта с werf у меня недостаточно и в случае, если вы опытный читатель, то буду рад конструктивным рекомендациям по эксплуатации данного инструмента)
А так - helm всему голова!
@pronskiy - После установки PHP8.1-RC6 на локальном окружении столкнулся с проблемой, не сталкивались ли Вы?
Вот детали по окружению:
В результате Composer начал ломаться во всех местах. Даже вызов -v вызывает краш:
При перестановке Composer под чистую валиться что-то вроде:
Нашел вчерашний Issue - https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1830385.html
Ждём фиксов?
Великое и могучее "чем бы заняться" в сочетании с высоким интеллектом меня всегда впечатляет. Круто! Спасибо за детальное пояснение в статье и отснятый материал.
Всегда впечатляет и пугает, какие могут быть соседи!)
Но единственный минус привыкания к новым утилитам в замен старым — их нужно ставить
Когда у тебя 10+ серверов в разных инфраструктурах и ты привыкаешь к таким вариантам — эффективность использования консоли может резко упасть на нет
Пока писал комментарий, понял — нужно написать утилиту «установщик», которая умеет смотреть в репозиторий для подтягивания конфига.
Выложить эту утилиту в самые распространённые дистрибутивы, научить её подтягивать конфиг со своего репо с настройкой (так можно под рукой держать несколько репозиториев с разными пресетами) и одной командой устанавливать на сервер то, что описано в пресете.
А ещё уметь обновляться нужно. Например — обновляешь свой пресет, логинишься в консоли и утилита автоматически посмотрит в использованный ранее пресет и увидит, что что-то изменилось и предложит доустановить.
Если есть такое — дайте ссылку, буду очень благодарен.
Спасибо, бальзам на душу
Редко когда можно что-то прочитать и думать — это вот прямо про меня
На тот момент времени у Googlte Translate API не было интерфейса для перевода входящего текста в массив локалей, можно было переводить только один текст на одну локаль.
В связи с этим весь перевод стал фоновой задачей. Т.е. было некоторое число воркеров, которые работали над задачами перевода вне запросов потребителей.
Появилась необходимость сделать так, чтобы можно было добавлять новую локаль максимально быстро. Т.е. взять и перевести весь имеющийся контент одной командой на новую локаль и добавить в базу. И вот однажды мой коллега сделал это в системе перевода, я быстренько заревьювил и проблем не нашел. Выкатили в прод, подняли, всё заработало.
Через 3 дня пишет клиент и говорит, что ему прилетел счёт от Google в размере $10000.
Оказалось, система в цикле начала переводить один и тот же контент. Раз за разом.
Кредитку отвязали, аккаунт удалили и забыли)
Но в первые дни было ужасно страшно!
Используете ли Вы подобные устройства у себя на работе или дома? Если да, то какие задачи решаете?
Лично я организовываю из дома VPN туннели через Intel Nuc и по чуть-чуть изучаю вопросы автоматизации домашних задач с использованием RPI 4 model B (смотрю разные реализации умного дома).
Но чем эта статья помогает «лучше организовать свою безопасность в Интернете»?
Думаю, ни для кого не секрет, что существуют подобные «мини-компьютеры».
Однако, соглашусь с комментариями выше — их использование ориентировано на обычное использование или на цели бизнеса и доступ к устройствам доступен в обычном интернете. Большая часть выше представленных ссылок (если не все) ведь не требуется привилегированного доступа к ресурсам.
Эта история заслуживает фильма.
Прочитал на одном дыхании. В свое время увлекался темой пластичности мозга, очень зацепила одноименная книга Нормана Дойджа.
В процессе изучения данной темы натыкался на описания описанного в статье заболевания, но никогда не читал истории из жизни близких к пациенту людей, лишь медицинские заметки.
Спасибо за отличный перевод отличной статьи.