Я бы сказал это настолько базовые настройки, что такие случаи звучат нелепо.
Это возникает, когда люди привыкшие к классическим MQ запускают Кафку методом быстрого старта. Им даже в голову не может прийти, что система может быть так специально сделана. И пока они отвлекаются на комплексные проблемы, типа exactly once или роутинга, у них стреляет политика :)
Видел выступление на конфе от человека, который не знал об этом, но уже внедрил кафку в крупной компании.
Думаю сейчас в тусовке тестировщиков есть некий консерватизм относительно автотестов. Дескать жили без них хорошо и дальше так будем. В большинстве случаев все эти примеры разбиваются об следующее утверждение.
Необходимо в архитектуру приложения изначально закладывать автотесты и подключать автотестировщиков к проектированию, тогда большинство негатива можно снять. А негатив, разумеется, есть. Например, для серверной разработки я вижу следующие проблемы:
Проблема: долгая подготовка инфраструктуры. Решение: унификация платформы запуска приложений в рамках компании, например k8s+RabitMQ+MySQL+Golang+React
Проблема: необходимость исправлять много тестов (а почему для ручного тестирования это не считается проблемой?). Решение: правильная декомпозиция задач и последовательность разработки. Например, применение DDD.
Проблема: сложность мокирования разных частей ПО. Решение: унификация механизмов взаимодействия, разбиение ПО на маленькие части. Например внедрение микросервисов с grpc.
Что получите, если решите эти проблемы:
Быстрый регресс.
Регресс (как и все остально) можно отрабатывать за пределами бизнес часов.
Предсказуемость времени прогона.
Возможность запускать тесты заранее (на ранних этапах разработки).
Меньше сотрудников: для прогона старых тестов тестировщик не нужен.
У меня создается ощущение, что Windows больше не в приоритете у MS: главное для них облачные технологии. Поэтому они начали раскручивать проекты типа Microsoft 365 (не путать с Office 365) и портировать софт на Linux.
Кстати любопытно, а используются ли кольца полноценно в других операционках. На сколько я знаю (на начало 2000х), на практике использовалось только 0 и 3 кольцо, а 1 и 2 не нашло применение в меинстриме, хотя Интел их и тащит для обратной совместимости.
Когда я работал в компании Stacksoft, один из разработчиков написал кучу хендлеров на обработку всех разумных и не разумных ошибок в одном важном блоке биллинга Onyma. Короче к блоку "else" его фантазия окончательно истощилась и он написал "Случилась такая неприятность, что я не знаю что и делать", поскольку он реально не знал что может означать заход в это ветвление и возможен ли он вообще.
И оно таки стрельнуло, правда очень не скоро, но жутко порадовало какого-то клиента.
Если исключить политичекий аспект, то деление по стране довольно бессмысленно, поскольку в среднем по миру топология сети и границы разных структор в ней не очень связаны с географией.
Наверное разумно выделять блоки большим структурам в сети без относительно их природы: цоды больших хостеров, магистральные провайдеры, правительства лично и т.д. В принципе сейчас так и происходит.
Проблема в том, что не должно быть технической возможности сделать что-либо не так.
Да, я понимаю, что это утверждение из мира пони, но тем не менее:
нельзя релизить в пятницу? - отключайте пайплайн релиза по расписанию, или вставьте блокирующий чекер.
кто-то залез в админку и все испортил? - настройте админку и процесс так, чтоб это мог делать только тот, кто несет за это отвественность, а не непонятно кто.
кто-то с дуру сделал force push? - настройте триггеры для бэкапа ref, до того как прийдет gc и настройте таки политики на бранчи.
есть неведомая фигня, которую тяжело поймать, но явно триггирется каким-то действием сотрудников - ELK вам в помощь, настройте логирование и ждите нескольких событий, чтоб понять зависимость.
Ну и т.д.
Я хочу сказать, что чаще всего, когда в IT компании хочется написать письмо, надо пойти и улучшить процесс или инфраструктру. Это бывает проблемно, но это надо делать.
Lily выглядит как-то совсем уж сурово. Все же хочется подушечек под руки, как на Sculpt. Но с другой стороны есть Ergodox EZ, который уже лет 7 в этой нише царствует.
Ну это просто пример, а обоснование может возникнуть только если будет реальная задача.
Это хорошо, что впервые, мне везёт меньше последнее время.
Это возникает, когда люди привыкшие к классическим MQ запускают Кафку методом быстрого старта. Им даже в голову не может прийти, что система может быть так специально сделана. И пока они отвлекаются на комплексные проблемы, типа exactly once или роутинга, у них стреляет политика :)
Видел выступление на конфе от человека, который не знал об этом, но уже внедрил кафку в крупной компании.
В Rabbit нельзя. Ретеншен политика не связанная с фактом доставки это именно фишка Кафки и большинство у ней узнают именно описанным выше способом.
Думаю сейчас в тусовке тестировщиков есть некий консерватизм относительно автотестов. Дескать жили без них хорошо и дальше так будем. В большинстве случаев все эти примеры разбиваются об следующее утверждение.
Необходимо в архитектуру приложения изначально закладывать автотесты и подключать автотестировщиков к проектированию, тогда большинство негатива можно снять. А негатив, разумеется, есть. Например, для серверной разработки я вижу следующие проблемы:
Проблема: долгая подготовка инфраструктуры. Решение: унификация платформы запуска приложений в рамках компании, например k8s+RabitMQ+MySQL+Golang+React
Проблема: необходимость исправлять много тестов (а почему для ручного тестирования это не считается проблемой?). Решение: правильная декомпозиция задач и последовательность разработки. Например, применение DDD.
Проблема: сложность мокирования разных частей ПО. Решение: унификация механизмов взаимодействия, разбиение ПО на маленькие части. Например внедрение микросервисов с grpc.
Что получите, если решите эти проблемы:
Быстрый регресс.
Регресс (как и все остально) можно отрабатывать за пределами бизнес часов.
Предсказуемость времени прогона.
Возможность запускать тесты заранее (на ранних этапах разработки).
Меньше сотрудников: для прогона старых тестов тестировщик не нужен.
А можете рассказать больше про то где вы храните описания и как по ним строится код (есть ли генерация моделей, например?)
GitHub вроде как обещает поддержку ssh ключей в ближайшие месяцы. Собственно именно диапазонов дат им не хватало.
https://github.com/github/feedback/discussions/7744#discussioncomment-1794438
Это давно было. Где-то в начале века. А последние годы клауд в топе. Если я правильно понимаю этот отчет https://www.microsoft.com/investor/reports/ar21/index.html, то направление "Intelligent Cloud" дает 42% Income и 24% Revenue.
У меня создается ощущение, что Windows больше не в приоритете у MS: главное для них облачные технологии. Поэтому они начали раскручивать проекты типа Microsoft 365 (не путать с Office 365) и портировать софт на Linux.
Кстати любопытно, а используются ли кольца полноценно в других операционках. На сколько я знаю (на начало 2000х), на практике использовалось только 0 и 3 кольцо, а 1 и 2 не нашло применение в меинстриме, хотя Интел их и тащит для обратной совместимости.
Когда я работал в компании Stacksoft, один из разработчиков написал кучу хендлеров на обработку всех разумных и не разумных ошибок в одном важном блоке биллинга Onyma. Короче к блоку "else" его фантазия окончательно истощилась и он написал "Случилась такая неприятность, что я не знаю что и делать", поскольку он реально не знал что может означать заход в это ветвление и возможен ли он вообще.
И оно таки стрельнуло, правда очень не скоро, но жутко порадовало какого-то клиента.
Если исключить политичекий аспект, то деление по стране довольно бессмысленно, поскольку в среднем по миру топология сети и границы разных структор в ней не очень связаны с географией.
Наверное разумно выделять блоки большим структурам в сети без относительно их природы: цоды больших хостеров, магистральные провайдеры, правительства лично и т.д. В принципе сейчас так и происходит.
Письма для этого не нужно. Нужна документация по процессам.
Проблема в том, что не должно быть технической возможности сделать что-либо не так.
Да, я понимаю, что это утверждение из мира пони, но тем не менее:
нельзя релизить в пятницу? - отключайте пайплайн релиза по расписанию, или вставьте блокирующий чекер.
кто-то залез в админку и все испортил? - настройте админку и процесс так, чтоб это мог делать только тот, кто несет за это отвественность, а не непонятно кто.
кто-то с дуру сделал force push? - настройте триггеры для бэкапа ref, до того как прийдет gc и настройте таки политики на бранчи.
есть неведомая фигня, которую тяжело поймать, но явно триггирется каким-то действием сотрудников - ELK вам в помощь, настройте логирование и ждите нескольких событий, чтоб понять зависимость.
Ну и т.д.
Я хочу сказать, что чаще всего, когда в IT компании хочется написать письмо, надо пойти и улучшить процесс или инфраструктру. Это бывает проблемно, но это надо делать.
> Дурацкий анекдот. "огонь!" по-японски "ute", и произносится не медленее, чем "fire".
Но ведь вопрос не в отдельных словах, а в среднем по тем словам которые используют военные, да еще и с частотной характеристикой.
Я тут недавно samsung dex опробовал. В целом весьма удобно. Огорчает только ограниченное количество поддерживаемых разрешении монитора
Судя по тексту статьи на НОО он не будет заходить, поэтому надо будет что-то мощнее чем Союз или Фалькон. Но вроде как Ангары хватит.
Как бы это странно не звучало, но перемещается это самое "где"
Там вроде не блютус, а собственный протокол.
Lily выглядит как-то совсем уж сурово. Все же хочется подушечек под руки, как на Sculpt. Но с другой стороны есть Ergodox EZ, который уже лет 7 в этой нише царствует.