Я занимаюсь разработкой homebrew для плееров Walkman на линуксах, NW-A50/40/30. Мне нужны девайсы для тестирования, желательно в физической доступности (СПб). Есть ли какие-нибудь российские технические сообщества, куда можно кинуть зов помощи? У меня есть только A50, на котором всё ок, а вот на A40 возникли непреодолимые (тестером из Австралии) трудности.
Очень интересно, но на мой взгляд это не самый актуальный девайс.
Новые принтеры, как указано в статье, в целом поддерживают зоопарк девайсов, печать по сети и вот это всё - им платка не нужна.
Остаётся старый принтер. Если он работает, то принт-сервер ему не нужен. Если он не работает с текущей ОС, то встаёт вопрос - будет ли пользователь покупать платку по цене чуть ли не нового принтера, или может просто купить новый с гарантией и не заморачиваться?
Также в пайплайн печати добавляется изделие, к которому должна быть подключена услуга "знакомый компьютерщик" - а что если оно в один прекрасный день помрёт? Бабка с дедом логи смотреть (и, тем более, отсылать на какой-то там гитхаб) не будут.
Ниша уж больно узкая, она обычно закрывается покупкой нового принтера (вливанием бабла). Сердцем я с вами, но скептик-практик не хочет видеть это устройство.
Моя позиция - бизнес-логика на стороне сервера, предоставляющего REST API, включает в себя всё, что не относится к TCP/IP и HTTP, а именно: балансировка нагрузки, SSL/TLS, маршрутизация между сервисами. Это разработчику действительно необязательно, может ему неплохо знать, как доставать значения из http-заголовков. Но вот всё, что идёт дальше, возлагается на плечи именно разработчика. У каждого сервиса есть своя зона ответственности, почему её надо дробить и вытаскивать на слой выше?
Предположим, что есть сервис для доступа к личному кабинету, доступ к которому (для пользователя) осуществляется путём предоставления http-заголовка Authorization: Bearer <токен>. С envoy обработка токена и решение пустить/запретить произойдёт на балансировщике, приложение даже не узнает о том, что к нему кто-то хотел сходить, верно? А раз слоя авторизации в сервисе нет, то внутри вашего контура (за envoy) к нему может ходить кто угодно как угодно и эти запросы будут считаться легитимными, так? Такой вариант нарушает принцип zero trust, создаёт дыру в безопасности и позволяет разработчикам с честными глазами говорить - "а мы ничего не знаем, к нам ничего не ходило, идите к девопсу". Ну или "нас защищает кто-то выше, мы только отдаём данные". Разве сервис не должен защищать свои данные?
С точки зрения разбора инцидентов система стала только сложнее, всё, что становится легче - это минус пара дней работы разработчика во время написания сервиса; пострадала эксплуатация.
Вот кстати хороший пример: платёжный шлюз пытается донести в вашу систему информацию о проведённом платёже - делает POST {json} на ваш /api/payment и получает 403. Заметьте, 403 может отдавать как envoy, так и сервис payment (по причине бизнес-логики или опечатки). Пользователь получает ошибку от платёжного шлюза "что-то пошло не так, обратитесь в вашу систему". Пользователь пишет вам в техподдержку, техподдержка идёт к разработчику сервиса payment, разработчик идёт к девопсу... чтобы что? Чтобы они вместе перелопатили сначала конфиги envoy, а потом и сервиса /api/payment? Три-четыре инцидента и сэкономленные два дня обнулятся, ещё парочка и вы заплатите больше за рабочие часы разраба+девопса.
Лучше избегать превращения микросервисов в раздутые сущности или монолиты, нагруженные лишней логикой.
Вы вынесли "лишнюю логику" на уровень выше, да ещё и в одно место, которое через пару лет превратится в монолит на 1к+ строчек yaml-кода с регулярками и прочими синтаксическими ужасами, которые ещё и проверить нельзя. При этом логика не отвязалась от приложения, а просто скрылась до поры до времени.
Я не против инструмента, но если им злоупотреблять, то он превратится в серебряную пулю, которая будет еженедельно оказываться в одной из ног.
По статье: спрячьте, пожалуйста, конфиги под спойлер, например,envoy.filters.http.oauth2 занимает два экрана.
Разработчики, когда пишут REST API, очень много времени могут тратить не на бизнес-код, а на различную логику, которую можно заменить одним только прокси.
На практике логика размазывается со слоя разработки на ещё и прокси, что приводит к увеличению когнитивной нагрузки. Всё прекрасно до первых инцедентов, в которых придётся лезть в код сначала прокси, а потом приложения.
Кстати, внедрение фич теперь тоже занимает больше человеко-часов. Предположим, добавляется новый роут, в котором требуется авторизация/аутентификация пользователя и запрещены retry (предположим, нельзя повторять платёж). Эту информацию разработчик доносит до девопса, который раздувает свой конфиг на ещё полэкрана ямла, потом они вместе это тестируют... В конце концов разработчику быстрее самому написать этот конфиг, но он же мог сделать это и в коде приложения.
На мой взгляд, вынос бизнес-логики на уровень балансировщика является плохой идеей, хотя и выглядит красиво. Нагрузку распределить - пожалуйста, а вот что-то сложнее пусть будет там, где ему и место - в приложении.
Зачем делать высосанные из пальца расчёты и выкладывать их на всеобщее обозрение? Соскучились по физике старших классов школы? Или вы хотите получить более точные расчёты через механизм "в интернете кто-то неправ"? Потраченного времени жаль, тем более, что технические характеристики бустера и так гуглятся.
если Вы хотите, чтобы Ваш раздел монтировался при запуске под нужную файловую систему, (а не делать каждый раз вручную в терминале) то Вам необходимо прописать строчку в /etc/fstab
Честно говоря, ожидал в статье хотя бы сборку wine из исходников, а тут рассказывают, как выполнить apt-get install wine и ярлык сделать. И это "средний" уровень сложности статьи!
На мой взгляд рендер для документации куда важнее, чем исходник. Результат будут видеть намного чаще, чем страшную сгенерированную таблицу в markdown. Раз она сгенерированная из какого-то там исходника - в чём проблема редактировать исходник и из него готовить рендер?
Вообще беда конкретно вашего примера с конфигом nginx - это ширина второй колонки с дефолтным значением. Посмотрите, как Яндекс решает эту проблему:
Картинка
Можно просто убрать дефолтное значение в описание и контент будет выглядеть хорошо. Также обратите внимание на стиль таблицы зеброй - очень хорошо видно, где заканчивается текст, относящийся к конкретной опции. В вашем примере со списками на мой взгляд строчки смешиваются друг с другом и выглядит чуть ли не как книга какая-то.
На каждую ситуацию свой инструмент. Я бы не стал отказываться от таблиц только потому, что в IDE писателю-ревьюверу будет тяжело пару минут, а вместо этого почитал бы книжки от типографов, редакторов текста, гайдлайны интерфейсов в конце концов, где точно что-нибудь будет по этому поводу.
Я неправильно рассчитывал разницу во времени между пакетами, из-за чего результаты не были похожи на что-то вменяемое. Повело в сторону других полей, шифрования через чексуммы и тд и тп.
Не смог осилить дамп, подписался на комментарии в ожидании ответа.
Как я понимаю, в дампе достаточно данных, чтобы расшифровать его, не прибегая к дополнительным шагам, типа rot13 поверх текста? Нет никаких волшебных констант, участвующих в шифровании?
IP-чексуммы верные, к идентификаторам пакетов не прицепиться. Единственное, что смущает, - Метка пакета в будущем!, как было упомянуто в статье, но там можно шифроваться как угодно, например, делать xor между первым байтом чексуммы icmp-пакета + sequence number и данными. А можно и со вторым делать xor, почему бы и нет? Как насчёт "вычесть из первого байта ts третий байт и помножить его на второй байт чексуммы"? А что если данные зашифрованы алгоритмом, использующим identifier в качестве ключа? Количество возможных операций только с sequence number и временной меткой достаточно велико (а жизнь слишком коротка), чтобы перестать гадать и начинать разогревать паяльник.
А ещё у вас по адресу из дампа гитлаб по хттп смотрит наружу, это часть загадки?
То есть вы погуглили и нагуглили? Можно было попробовать найти проблему самостоятельно через git bisect (если предполагать, что это баг в ядре).
Раз уж такая пляска пошла...
Я занимаюсь разработкой homebrew для плееров Walkman на линуксах, NW-A50/40/30. Мне нужны девайсы для тестирования, желательно в физической доступности (СПб). Есть ли какие-нибудь российские технические сообщества, куда можно кинуть зов помощи? У меня есть только A50, на котором всё ок, а вот на A40 возникли непреодолимые (тестером из Австралии) трудности.
Очень интересно, но на мой взгляд это не самый актуальный девайс.
Новые принтеры, как указано в статье, в целом поддерживают зоопарк девайсов, печать по сети и вот это всё - им платка не нужна.
Остаётся старый принтер. Если он работает, то принт-сервер ему не нужен. Если он не работает с текущей ОС, то встаёт вопрос - будет ли пользователь покупать платку по цене чуть ли не нового принтера, или может просто купить новый с гарантией и не заморачиваться?
Также в пайплайн печати добавляется изделие, к которому должна быть подключена услуга "знакомый компьютерщик" - а что если оно в один прекрасный день помрёт? Бабка с дедом логи смотреть (и, тем более, отсылать на какой-то там гитхаб) не будут.
Ниша уж больно узкая, она обычно закрывается покупкой нового принтера (вливанием бабла). Сердцем я с вами, но скептик-практик не хочет видеть это устройство.
Зачем писать обёртку вокруг adb, если можно сделать
adb pull <directory>? Поправить кодировку названий файлов?Мне кажется, что мы друг друга не совсем поняли.
Моя позиция - бизнес-логика на стороне сервера, предоставляющего REST API, включает в себя всё, что не относится к TCP/IP и HTTP, а именно: балансировка нагрузки, SSL/TLS, маршрутизация между сервисами. Это разработчику действительно необязательно, может ему неплохо знать, как доставать значения из http-заголовков. Но вот всё, что идёт дальше, возлагается на плечи именно разработчика. У каждого сервиса есть своя зона ответственности, почему её надо дробить и вытаскивать на слой выше?
Предположим, что есть сервис для доступа к личному кабинету, доступ к которому (для пользователя) осуществляется путём предоставления http-заголовка
Authorization: Bearer <токен>. С envoy обработка токена и решение пустить/запретить произойдёт на балансировщике, приложение даже не узнает о том, что к нему кто-то хотел сходить, верно? А раз слоя авторизации в сервисе нет, то внутри вашего контура (за envoy) к нему может ходить кто угодно как угодно и эти запросы будут считаться легитимными, так? Такой вариант нарушает принцип zero trust, создаёт дыру в безопасности и позволяет разработчикам с честными глазами говорить - "а мы ничего не знаем, к нам ничего не ходило, идите к девопсу". Ну или "нас защищает кто-то выше, мы только отдаём данные". Разве сервис не должен защищать свои данные?С точки зрения разбора инцидентов система стала только сложнее, всё, что становится легче - это минус пара дней работы разработчика во время написания сервиса; пострадала эксплуатация.
Вот кстати хороший пример: платёжный шлюз пытается донести в вашу систему информацию о проведённом платёже - делает POST
{json}на ваш /api/payment и получает 403. Заметьте, 403 может отдавать как envoy, так и сервис payment (по причине бизнес-логики или опечатки). Пользователь получает ошибку от платёжного шлюза "что-то пошло не так, обратитесь в вашу систему". Пользователь пишет вам в техподдержку, техподдержка идёт к разработчику сервиса payment, разработчик идёт к девопсу... чтобы что? Чтобы они вместе перелопатили сначала конфиги envoy, а потом и сервиса /api/payment? Три-четыре инцидента и сэкономленные два дня обнулятся, ещё парочка и вы заплатите больше за рабочие часы разраба+девопса.Вы вынесли "лишнюю логику" на уровень выше, да ещё и в одно место, которое через пару лет превратится в монолит на 1к+ строчек yaml-кода с регулярками и прочими синтаксическими ужасами, которые ещё и проверить нельзя. При этом логика не отвязалась от приложения, а просто скрылась до поры до времени.
Я не против инструмента, но если им злоупотреблять, то он превратится в серебряную пулю, которая будет еженедельно оказываться в одной из ног.
По статье: спрячьте, пожалуйста, конфиги под спойлер, например,
envoy.filters.http.oauth2занимает два экрана.На практике логика размазывается со слоя разработки на ещё и прокси, что приводит к увеличению когнитивной нагрузки. Всё прекрасно до первых инцедентов, в которых придётся лезть в код сначала прокси, а потом приложения.
Кстати, внедрение фич теперь тоже занимает больше человеко-часов. Предположим, добавляется новый роут, в котором требуется авторизация/аутентификация пользователя и запрещены retry (предположим, нельзя повторять платёж). Эту информацию разработчик доносит до девопса, который раздувает свой конфиг на ещё полэкрана ямла, потом они вместе это тестируют... В конце концов разработчику быстрее самому написать этот конфиг, но он же мог сделать это и в коде приложения.
На мой взгляд, вынос бизнес-логики на уровень балансировщика является плохой идеей, хотя и выглядит красиво. Нагрузку распределить - пожалуйста, а вот что-то сложнее пусть будет там, где ему и место - в приложении.
Зачем делать высосанные из пальца расчёты и выкладывать их на всеобщее обозрение? Соскучились по физике старших классов школы? Или вы хотите получить более точные расчёты через механизм "в интернете кто-то неправ"?
Потраченного времени жаль, тем более, что технические характеристики бустера и так гуглятся.
если Вы хотите, чтобы Ваш раздел монтировался при запуске под нужную файловую систему, (а не делать каждый раз вручную в терминале) то Вам необходимопрописать строчку в /etc/fstabЧестно говоря, ожидал в статье хотя бы сборку wine из исходников, а тут рассказывают, как выполнить apt-get install wine и ярлык сделать. И это "средний" уровень сложности статьи!
Потраченного времени жаль.
установите собранное в отдельную директорию? https://docs.python.org/3/using/configure.html#install-options
Вы переизобрели конспект лекции?
Хаб Читальный зал - Полезное чтиво по IT-темам.
Из IT-темы только реклама телеграм-канала и первый абзац про любовь к IT.
На мой взгляд рендер для документации куда важнее, чем исходник. Результат будут видеть намного чаще, чем страшную сгенерированную таблицу в markdown. Раз она сгенерированная из какого-то там исходника - в чём проблема редактировать исходник и из него готовить рендер?
Вообще беда конкретно вашего примера с конфигом nginx - это ширина второй колонки с дефолтным значением. Посмотрите, как Яндекс решает эту проблему:
Картинка
Можно просто убрать дефолтное значение в описание и контент будет выглядеть хорошо. Также обратите внимание на стиль таблицы зеброй - очень хорошо видно, где заканчивается текст, относящийся к конкретной опции. В вашем примере со списками на мой взгляд строчки смешиваются друг с другом и выглядит чуть ли не как книга какая-то.
На каждую ситуацию свой инструмент. Я бы не стал отказываться от таблиц только потому, что в IDE писателю-ревьюверу будет тяжело пару минут, а вместо этого почитал бы книжки от типографов, редакторов текста, гайдлайны интерфейсов в конце концов, где точно что-нибудь будет по этому поводу.
Спасибо за решение.
Я неправильно рассчитывал разницу во времени между пакетами, из-за чего результаты не были похожи на что-то вменяемое. Повело в сторону других полей, шифрования через чексуммы и тд и тп.
Не смог осилить дамп, подписался на комментарии в ожидании ответа.
Как я понимаю, в дампе достаточно данных, чтобы расшифровать его, не прибегая к дополнительным шагам, типа rot13 поверх текста? Нет никаких волшебных констант, участвующих в шифровании?
IP-чексуммы верные, к идентификаторам пакетов не прицепиться. Единственное, что смущает, -
Метка пакета в будущем!, как было упомянуто в статье, но там можно шифроваться как угодно, например, делать xor между первым байтом чексуммы icmp-пакета + sequence number и данными. А можно и со вторым делать xor, почему бы и нет? Как насчёт "вычесть из первого байта ts третий байт и помножить его на второй байт чексуммы"? А что если данные зашифрованы алгоритмом, использующим identifier в качестве ключа? Количество возможных операций только с sequence number и временной меткой достаточно велико (а жизнь слишком коротка), чтобы перестать гадать и начинать разогревать паяльник.А ещё у вас по адресу из дампа гитлаб по хттп смотрит наружу, это часть загадки?