Хреновый или нехреновый человек, это субъективный момент, который зависит от контекста в котором вы сейчас находитесь и занимаемой в данный момент позиции. При расследовании инцидентов всегда велик соблазн пойти таким путем. Насколько он простой, настолько же и не конструктивный - определив крайнего и наклеев на на него ярлык вы не снизите риск возникновения того же самого в будущем.
Одно из основных правил расследования инцидентов гласит, что причин всегда больше одной и ни одна не является ключевой: инцидент это всегда результат цепочки множества обстоятельств. В прес релизе я отметил как раз тот момент, что они не заостряют внимание на личностях, а обращают проблему внутрь себя, рассматривая её с разных точек зрения. Это выглядит профессионально.
Просто сложность проектов уже не лезет в одного кадра (да и не должна лезть по причинам рисков bus factor). Задача, которую ставят перед Scrum - в том числе как поделить кусок работы между разными людьми.
В ранних версиях, истории нарезал в беклог PO, а команда оценивала, занимаясь декомпозицией без отрыва от производства, как умеет. Но выяснять, согласовывать и прописывать требования с достаточным уровнем детализации это тоже ацкий труд. Если можете себе позволить - отдайте его BA, для которого это будет основной работой.
В плане этики к происходящему можно относиться по-разному. Возможно инженерная культура и безопасность у них так себе, но PR и юристы, на мой взгляд, отрабатывают инцидент четко.
Я попробую помедитировать над этим. Но вообще неоднократно видел как меняются технологические стеки, платформы, вендоры. А бизнес продолжает работать как и работал.
Например, сейчас много заказов на миграцию с on-prem в клауды. Это как пересесть со старого дизельного гелендвагена, на электричку типа теслы: изменение влияет на отдельные, чисто эксплуатационные моменты, но основная бизнесовая логистика и маршруты остаются такими же. Снаружи так вообще ни кто ни чего заметить не должен.
Если предположить, что изменения в бизнесе должны непосредственно влиять на технологии, то зависимости должны бы инвертированы (IoC) - стрелки идут от бизнеса в сторону нижних слоев, а не наоборот. Значит от бизнеса нужны контракты. В принципе, как вы и описываете.
Могу предложить, что это уровень ГОСТ, СНиП и прочих НПА которые задают атрибуты качества, а также же определяют методики проверки соответствия: сертификация, аудит и т.п. Может это и есть элементы архитектурного девопса?
В модели business-application-technology, DevOps это уровень technology (& implementation).
Архитектура бизнесов находится на два этажа выше. Там есть свои паттерны, только целевой платформой выступает не айти, а различные regulations, legal и т.п.
Когда мы научимся формализовать и проектировать бизнесовые архитектуры непосредственно в терминах технологий, наступит глобальная технократия. Но пока это сильно из области фантастики.
В последнее время я внимательно наблюдал, как нашей команде удаётся совершенствовать надёжность продукта и оперативность реагирования на инциденты. Это заставило меня задуматься, каков жизненный цикл современного софтверного проекта.
Занятный текст. Выглядит как будто автор обрёл просветление. Интересно, что он напишет когда узнает про ITIL.
Локальный ранер, не будучи подключенным к серверу, нормально не работает. На самом деле вот ишуя: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797 - которой уже скоро шесть лет исполнится и через год она пойдет в школу.
gitlab-ci-runner это альтернативная реализация, написанная за это время, фактически от безысходности, вообще другими людьми, под node.js. Естественно, что в ней не поддерживаются многие синтаксические конструкции, которые понимает настоящий ранер. Часть синтаксиса интерпретируется просто иначе. Поэтому результаты прогона мало что говорят о работоспособности в реальном окружении.
Честно говоря удивлен, но оказалось что-то подобное уже есть https://www.npmjs.com/package/serialize-closures. Причем сделано снаружи, а не изнутри движка (так-то DevTools показывают внутренности объектов, поэтому вопрос сериализации замыканий это лишь вопрос доступа к соответствующим API).
Интересно, в каких ещё ситуациях может потребоваться доступ к сырым строкам? В JSON разных типов данных не много. Тема с number / bigint, как видно, отпадает - надёжнее передавать сразу строкой. string и так строки. Из примитивных остаются только "true", "false" и null.
Gitlab пример продукта, где приоритеты разработки по всей видимости определяются сугубо хотелками кастомеров - кто в текущем сезоне денег занес, туда все и бегут. Как будто у себя ни головы, ни совести.
Тут на днях смотрел как наши девопсы отлаживают конфигурации пайплайнов, тыкаясь в юай этого гитлаба потому, что, говорят, ни тесты на это написать, ни запустить проверку в офлайн, нет ни какой возможности - дескать поломали несколько лет тому назад и не торопятся чинить.
Здесь для "foo" value не используется, однако парсер его все равно парсит, создаёт и передаёт в колбек, как велит интерфейс функции JSON.parse(). А если мы пишем, например, санитайзер - как делали ребята по ссылке в комменте выше, когда интересуют только ключи - то парсить value не требуется вообще - нужны лишь данные от токенайзера (в вашем примере key и context.source). Получается парсер делает кучу ненужной работы.
Чтобы передать в callback значение context, в вашей редакции каждый раз создаётся новый объект. По одному разу на каждую ноду.
Причина у проблем общая - добавление ортогональной по сути фичи в интерфейс JSON.parse().
Сканируешь себе поток и скармливаешь строки парсеру постепенно.
А можно было бы проходить json-lines поток в один проход - без загрузки и буферизации каждой отдельной строки в памяти (они могут быть довольно длинными, что сказывается как на потреблении памяти так и на latency). Вот ещё кейс, когда по сути нужен лишь токенайзер, без парсинга: https://habr.com/ru/company/quadcode/blog/660229/ .
Вариант, предложенный в статье, не выглядит эффектным: он все равно делает парсинг, даже когда это фактически не требуется. К тому же создаёт массу новых временных объектов. Поэтому я за отдельное API.
По идее аналогичная проблема со множеством вариантов интерпретации существует и для строк. Но решается она сейчас указанием encoding. Возможно аналогичный механизм для number - с возможностью указать название формата представления чисел - больше бы соответствал общей концепции.
Да, доступ к результатам работы токенайзера даёт ещё больше свободы. Например, я могу поставить себе парсер для которого правила интерпретации задаются какой-нибудь JSON Schema. Но это довольно специфическая задача, и мне кажется будет лучше иметь это в виде отдельного API, а не костылей к JSON.parse(). За одно там можно было бы предложить решение для парсинга потоковых форматов типа json-lines.
Внезапно в 70-ых перед lisp такой проблемы даже не стояло: формат JSON (JavaScript Object Notation) появился только спустя 30 с лишним лет, - когда lisp уже успел обрести просветление и превратиться в миф.
Я в свое время обжёгся с этим bigint. Клиент и сервер на python где поддержка больших чисел уже много лет из коробки. Сериализация и десериализация JSON на тестах работает четко. Но в продакшн между ними оказался API Gateway от известного вендора, со скриптигном на JS, вытворявший все те непотребства, что описаны в статье. В итоге все переделали на строки.
В спецификации JSON не уточняются ограничения на размер целых чисел - интерпретация отдана на откуп реализации. Пройдет ещё куча времени, пока все о чем-нибудь договорятся и подстроятся.
Как PoC библиотека просто класс и думаю ей можно найти массу применений. Но гонять bigint в JSON я бы не рекомендовал.
fuzzy это не то же самое, что nondeterministic - в плане логики в ней как раз все довольно четко.
Может только как функтор? В общем случае на вкус и цвет фломастеры разные.
Хреновый или нехреновый человек, это субъективный момент, который зависит от контекста в котором вы сейчас находитесь и занимаемой в данный момент позиции. При расследовании инцидентов всегда велик соблазн пойти таким путем. Насколько он простой, настолько же и не конструктивный - определив крайнего и наклеев на на него ярлык вы не снизите риск возникновения того же самого в будущем.
Одно из основных правил расследования инцидентов гласит, что причин всегда больше одной и ни одна не является ключевой: инцидент это всегда результат цепочки множества обстоятельств. В прес релизе я отметил как раз тот момент, что они не заостряют внимание на личностях, а обращают проблему внутрь себя, рассматривая её с разных точек зрения. Это выглядит профессионально.
Просто сложность проектов уже не лезет в одного кадра (да и не должна лезть по причинам рисков bus factor). Задача, которую ставят перед Scrum - в том числе как поделить кусок работы между разными людьми.
В ранних версиях, истории нарезал в беклог PO, а команда оценивала, занимаясь декомпозицией без отрыва от производства, как умеет. Но выяснять, согласовывать и прописывать требования с достаточным уровнем детализации это тоже ацкий труд. Если можете себе позволить - отдайте его BA, для которого это будет основной работой.
В плане этики к происходящему можно относиться по-разному. Возможно инженерная культура и безопасность у них так себе, но PR и юристы, на мой взгляд, отрабатывают инцидент четко.
Я попробую помедитировать над этим. Но вообще неоднократно видел как меняются технологические стеки, платформы, вендоры. А бизнес продолжает работать как и работал.
Например, сейчас много заказов на миграцию с on-prem в клауды. Это как пересесть со старого дизельного гелендвагена, на электричку типа теслы: изменение влияет на отдельные, чисто эксплуатационные моменты, но основная бизнесовая логистика и маршруты остаются такими же. Снаружи так вообще ни кто ни чего заметить не должен.
Если предположить, что изменения в бизнесе должны непосредственно влиять на технологии, то зависимости должны бы инвертированы (IoC) - стрелки идут от бизнеса в сторону нижних слоев, а не наоборот. Значит от бизнеса нужны контракты. В принципе, как вы и описываете.
Могу предложить, что это уровень ГОСТ, СНиП и прочих НПА которые задают атрибуты качества, а также же определяют методики проверки соответствия: сертификация, аудит и т.п. Может это и есть элементы архитектурного девопса?
В модели business-application-technology, DevOps это уровень technology (& implementation).
Архитектура бизнесов находится на два этажа выше. Там есть свои паттерны, только целевой платформой выступает не айти, а различные regulations, legal и т.п.
Когда мы научимся формализовать и проектировать бизнесовые архитектуры непосредственно в терминах технологий, наступит глобальная технократия. Но пока это сильно из области фантастики.
Занятный текст. Выглядит как будто автор обрёл просветление. Интересно, что он напишет когда узнает про ITIL.
Локальный ранер, не будучи подключенным к серверу, нормально не работает. На самом деле вот ишуя: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797 - которой уже скоро шесть лет исполнится и через год она пойдет в школу.
gitlab-ci-runner это альтернативная реализация, написанная за это время, фактически от безысходности, вообще другими людьми, под node.js. Естественно, что в ней не поддерживаются многие синтаксические конструкции, которые понимает настоящий ранер. Часть синтаксиса интерпретируется просто иначе. Поэтому результаты прогона мало что говорят о работоспособности в реальном окружении.
Честно говоря удивлен, но оказалось что-то подобное уже есть https://www.npmjs.com/package/serialize-closures. Причем сделано снаружи, а не изнутри движка (так-то DevTools показывают внутренности объектов, поэтому вопрос сериализации замыканий это лишь вопрос доступа к соответствующим API).
Интересно, в каких ещё ситуациях может потребоваться доступ к сырым строкам? В JSON разных типов данных не много. Тема с number / bigint, как видно, отпадает - надёжнее передавать сразу строкой. string и так строки. Из примитивных остаются только "true", "false" и null.
Gitlab пример продукта, где приоритеты разработки по всей видимости определяются сугубо хотелками кастомеров - кто в текущем сезоне денег занес, туда все и бегут. Как будто у себя ни головы, ни совести.
Тут на днях смотрел как наши девопсы отлаживают конфигурации пайплайнов, тыкаясь в юай этого гитлаба потому, что, говорят, ни тесты на это написать, ни запустить проверку в офлайн, нет ни какой возможности - дескать поломали несколько лет тому назад и не торопятся чинить.
Интересно зачем конфигурационному файлу, содержащему пароли, такие права?
Здесь для "foo" value не используется, однако парсер его все равно парсит, создаёт и передаёт в колбек, как велит интерфейс функции JSON.parse(). А если мы пишем, например, санитайзер - как делали ребята по ссылке в комменте выше, когда интересуют только ключи - то парсить value не требуется вообще - нужны лишь данные от токенайзера (в вашем примере key и context.source). Получается парсер делает кучу ненужной работы.
Чтобы передать в callback значение context, в вашей редакции каждый раз создаётся новый объект. По одному разу на каждую ноду.
Причина у проблем общая - добавление ортогональной по сути фичи в интерфейс JSON.parse().
А можно было бы проходить json-lines поток в один проход - без загрузки и буферизации каждой отдельной строки в памяти (они могут быть довольно длинными, что сказывается как на потреблении памяти так и на latency). Вот ещё кейс, когда по сути нужен лишь токенайзер, без парсинга: https://habr.com/ru/company/quadcode/blog/660229/ .
Вариант, предложенный в статье, не выглядит эффектным: он все равно делает парсинг, даже когда это фактически не требуется. К тому же создаёт массу новых временных объектов. Поэтому я за отдельное API.
По идее аналогичная проблема со множеством вариантов интерпретации существует и для строк. Но решается она сейчас указанием encoding. Возможно аналогичный механизм для number - с возможностью указать название формата представления чисел - больше бы соответствал общей концепции.
Да, доступ к результатам работы токенайзера даёт ещё больше свободы. Например, я могу поставить себе парсер для которого правила интерпретации задаются какой-нибудь JSON Schema. Но это довольно специфическая задача, и мне кажется будет лучше иметь это в виде отдельного API, а не костылей к JSON.parse(). За одно там можно было бы предложить решение для парсинга потоковых форматов типа json-lines.
Внезапно в 70-ых перед lisp такой проблемы даже не стояло: формат JSON (JavaScript Object Notation) появился только спустя 30 с лишним лет, - когда lisp уже успел обрести просветление и превратиться в миф.
Я в свое время обжёгся с этим bigint. Клиент и сервер на python где поддержка больших чисел уже много лет из коробки. Сериализация и десериализация JSON на тестах работает четко. Но в продакшн между ними оказался API Gateway от известного вендора, со скриптигном на JS, вытворявший все те непотребства, что описаны в статье. В итоге все переделали на строки.
В спецификации JSON не уточняются ограничения на размер целых чисел - интерпретация отдана на откуп реализации. Пройдет ещё куча времени, пока все о чем-нибудь договорятся и подстроятся.
Как PoC библиотека просто класс и думаю ей можно найти массу применений. Но гонять bigint в JSON я бы не рекомендовал.
Внезапно неперевод. Очень крутая работа в плане проекта, документации и продвижения.