Обратная сторона такого решения - зависимость от кейклока. Достаточно положить сервер с ним и схема превращается в тыкву без альтернативных способов входа.
Ответьте, пожалуйста, на следующие вопросы: как быстро ваша компания сможет найти программиста для изменения бизнес-логики в вашем решении? Сколько будет стоить этот программист?
Может вам и кажется, что у вас Toyota, вот только запчасти к вашему авто будет найти несколько проблематичнее. Поиск запчастей - тоже проблема бизнеса.
А бизнес точно в курсе деталей решения вашей проблемы? По стране найдётся может человек 500, которые смогут это поддержать (или хотя бы понять код за день-другой). Попробуйте предложить бизнесу (например, такси в Воронеже) купить несколько Lamborghini - официального сервиса у нас нет, запчасти из-за рубежа через месяц. Не думаю, что бизнес согласится на такую авантюру.
На самом деле проблема в шрифтах, которые у меня в xterm не настроены.
Написание TUI-приложения - довольно сложная задача, в которой надо покрыть много-много edge cases. Если предполагается, что приложение будет работать на сервере (как написано в README), то тестировать нужно не на современных терминалах с поддержкой красивых шрифтов, а на самом минимуме вроде xterm, putty, termux.
В более продвинутых терминалах (xfce4-terminal) не виден фокус на кнопках:
CLI mode is perfect for automation, scripting, and quick one-liners. It's essential for server environments, cron jobs, and integrating into larger toolchains.
На сервере практически всегда живут UNIX-утилиты - find, du, rm и прочие coreutils, которые умеют всё то же, что и ваша утилита. В конце концов есть midnight commander, который ещё и мышь поддерживает.
Если вам так нужен гуй - воспользуйтесь обычным файловым менеджером: nautilus, pcmanfm, qtfm, десятки их.
Я занимаюсь разработкой 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 и ярлык сделать. И это "средний" уровень сложности статьи!
Ссылка на проект с utm-меткой
_source=chatgpt.com". В связи с этим сразу вопрос - сколько кода было написано LLM, а сколько человеком?Хаб: Информационная безопасность
Вы серьёзно?
Обратная сторона такого решения - зависимость от кейклока. Достаточно положить сервер с ним и схема превращается в тыкву без альтернативных способов входа.
Ответьте, пожалуйста, на следующие вопросы: как быстро ваша компания сможет найти программиста для изменения бизнес-логики в вашем решении? Сколько будет стоить этот программист?
Может вам и кажется, что у вас Toyota, вот только запчасти к вашему авто будет найти несколько проблематичнее. Поиск запчастей - тоже проблема бизнеса.
А бизнес точно в курсе деталей решения вашей проблемы?
По стране найдётся может человек 500, которые смогут это поддержать (или хотя бы понять код за день-другой). Попробуйте предложить бизнесу (например, такси в Воронеже) купить несколько Lamborghini - официального сервиса у нас нет, запчасти из-за рубежа через месяц. Не думаю, что бизнес согласится на такую авантюру.
Много программистов = проще (и дешевле) найти человека на поддержку. Сейчас один автобус способен оставить ваше решение без поддержки на месяц-другой.
А теперь о вреде бизнесу: для поддержки этого решения потребуется знание Zig. Хабр.Карьера: 134 программиста на Zig, 12000+ Golang, 92000+ C.
Неправда:
На самом деле проблема в шрифтах, которые у меня в xterm не настроены.
Написание TUI-приложения - довольно сложная задача, в которой надо покрыть много-много edge cases. Если предполагается, что приложение будет работать на сервере (как написано в README), то тестировать нужно не на современных терминалах с поддержкой красивых шрифтов, а на самом минимуме вроде xterm, putty, termux.
Неплохая статья по теме: https://p.janouch.name/article-tui.html
Xterm, конечно же, не осилил иконки:
В более продвинутых терминалах (xfce4-terminal) не виден фокус на кнопках:
На сервере практически всегда живут UNIX-утилиты - find, du, rm и прочие coreutils, которые умеют всё то же, что и ваша утилита. В конце концов есть midnight commander, который ещё и мышь поддерживает.
Если вам так нужен гуй - воспользуйтесь обычным файловым менеджером: nautilus, pcmanfm, qtfm, десятки их.
OpenCV?
То есть вы погуглили и нагуглили? Можно было попробовать найти проблему самостоятельно через 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.