На пути от наблюдаемой системы до пользователя DataDog (здесь и далее - DD) метрические данные неизбежно проходят несколько этапов агрегации. Это означает, что в момент чтения метрик пользователь DD оперирует не конкретными значениями, а их агрегатами. Теоретически возможно записать в DD метрики таким образом, чтобы они в итоге не были подвержены агрегации, но это не имеет смысла и противоречит самой концепции DD.
В первой части статьи мы рассмотрели основные и порождающие шаблоны и особенности их реализации на Dart. Теперь пришло время поговорить о структурных шаблонах и о их реализации с использованием синтаксических конструкций языка Dart и возможностей стандартной библиотеки. Мы будем стараться исключать возможности, предоставляемые такими сущностями языка как символы и рефлексия (пакет dart:mirrors), поскольку они не поддерживаются во Flutter (но обозначим возможные их применения при использовании Dart для бэкэнда), предпочитая использовать кодогенерацию во всех ситуациях, где это возможно.
Спорить плохо, но раз уж всё равно все спорят, то почему бы не делать это конструктивно и продуктивно :)
Лайфхак как успешно убеждать датасайентистов по результатам A/B тестирования. Работают такие аргументы:
Ситуация
Есть производство, оборудованное термопластавтоматами, которое изготавливает пластиковую фурнитуру. Производство работает, есть рентабельность и прибыль. Экономические расчеты показывают, что потеря 5% эффективности работы приводит к потере 50% прибыли. Фактически оборудование всей технологической цепочки является одним целым, но работает разрозненно и не является одним целым.
Управление предприятием, как правило, осуществляется вручную, через устные распоряжения. Основным “автоматизированным” средством управления и контроля является чат в WhatsApp (или другом мессенджере). В описанной ситуации вопрос управления эффективностью остается открытым. Объективность принимаемых управленческих решений сильно зависит от достоверности информации, которую докладывают подчиненные и их человеческих качеств.
Разберем ситуацию.
Почему хакеры раз за разом достигают своих целей, побеждая тех, кто стоит на страже своих активов? По мнению одного из известных исследователей в области информационной безопасности Джона Ламберта (John Lambert), дело – в разнице в мышлении. Такую идею заслуженный инженер и генеральный управляющий Microsoft Threat Intelligence Center сформулировал в своем аккаунте на «Гитхаб».
Любой процесс, в том числе бизнес-процесс, всегда представляет собой непрерывную последовательность смены состояний определенной системы.
Бизнес процесс описывает смену состояний бизнес-системы.
Бизнес-система – это логическая система, элементы которой связаны между собой отношением причинно-следственной связи, реализуемой через функции.
Функции причинной связи являются свойствами бизнес-системы.
Люди – члены организации, реализующей бизнес-процесс, составляют управляющую систему по отношению к бизнес-системе.
Управляющая система, состоящая из людей, является физической системой, и ее нельзя смешивать с бизнес-системой, которая является логической.
В BPMN отношение причинности подменяется отношением временной последовательности, а функции подменяются физической характеристикой работы, выполняемой участниками управляющей системы, что является логической ошибкой, поэтому с помощью BPMN нельзя смоделировать свойства бизнес-системы и переходы между состояниями.
Программный комплекс – это логическая система.
С помощью свойств регистров и функций программного комплекса можно смоделировать отношения причинной связи, существующие между элементами бизнес-системы.
Для проектирования программного комплекса необходимо построить информационную модель бизнес-системы.
BPMN не позволяет построить информационную модель системы, а лишь создает правдоподобную на первый взгляд имитацию модели.
Использование BPMN в проектировании программных комплексов ведет к многочисленным логическим ошибкам, увеличению затраченного времени и ресурсов на создание программного комплекса.
Вместо BPMN и других графических нотаций бизнес-процессов для моделирования бизнес-систем лучше пользоваться такими понятиями как: информационный элемент, информационная совокупность, класс, атрибут, состояние, условие, функция.
Гибридный смарт-контракт — это приложение, состоящее из двух частей:
1) Смарт-контракт — код, который работает исключительно на блокчейне
2) Децентрализованная сеть(и) оракулов — безопасные сервисы вне блокчейн, поддерживающие смарт-контракт.
Эти два компонента беспрепятственно и безопасно взаимодействуют друг с другом, образуя единое гибридное приложение смарт-контракта. В результате код на блокчейне дополняется множеством уникальных и важных способов, открывая множество новых вариантов использования, которые были бы невозможны только с помощью кода на блокчейн из-за технических, юридических или финансовых ограничений.
Важно отметить, что DON по-прежнему обеспечивают очень высокий уровень устойчивости к взлому и надежности, соответствующий гарантиям, предоставляемым смарт-контрактом, но они делают это в изолированной среде вне блокчейн с использованием множества различных подходов к безопасности.
Для тех кто хочет погрузиться в проектирование .Net микросервисов, Kubernetes, Azure и Azure DevOps процессы.
Я изучаю Битрикс где-то пару недель. Зачем?.. Хотелось чего-то новенького, тут подвернулась учёба. Даром, с наставниками, с возможным трудоустройством дальше хотя бы на пару месяцев - на испытательный срок. Я ничего заранее про Битрикс не знала, ну кроме термина "Битрикс" и факта, что в каждой второй вакансии по Laravel (мой обычный фреймворк) я на хедхантере вижу строчку Б_ЭТОНАМ_ТОЖЕНАДО.
Ниже попробую описать, чем Битрикс труден при выраженном любопытстве. Ну и, опять же, пару опций намечу, как это вот всё лечить. Вдруг разработчики Битрикса статью увидят? Они симфонисты. Правда, они старый код не трогают (это не точно), пишут второе ядро D7. Собственно про D7 наружный лифт на картинке.
Привет! Меня зовут Ольга Татаринова, я руковожу отделом аналитики в Agima.ai. Один из самых частых запросов, с которым к нам приходят клиенты, такой: «Сделайте нам дашборд c бизнес-KPI. Мы хотим найти какие-то инсайты в наших данных, чтобы понять точки роста». Проблема с такой постановкой задачи в том, что дашборды хорошо помогают следить за бизнес-kpi. Но напрямую мешают находить инсайты в данных.
Всем привет! И сегодня мы поговорим про то, о чем принято спорить до пены у рта или задумчиво молчать с непониманием происходящего. А именно, о разнице между такими существами айтишного бестиария, как системный аналитик (англ. SA или рус. СА) и бизнес-аналитик (англ. BA или рус. БА).
Вступление: кто и про что
Для начала небольшой дисклеймер. В IT я тружусь с 2015 года в найме и на 2-3 года дольше, если считать попытки в стартапы и бизнес, и за это время увидел массу интерпретаций ролей специалистов в разработке. Последние несколько лет я трудился в роли системного аналитика в двух компаниях, а ранее вдоволь понаблюдал за работой бизнес-аналитиков в еще одной, частично подменяя их по ситуации. В текущий момент я перешел к роли Product Owner на своем проекте в Innovative People, однако совсем недавно был ведущим в системной аналитике, так что память свежа.
Эта статья не является истиной в последней инстанции, да и ничто не может быть абсолютной истиной, так как в IT достаточно гибко работает подстройка функций члена команды под конкретные задачи компании и видение команды (и это хорошо!). Так что воспринимайте сей рассказ как обзорную информацию для тех, кто “хочет войти в IT”, либо “хочет войти в аналитику”, либо прямо сейчас столкнулся с задачей сборки команды и пытается разобраться, кого нанимать и для каких целей.
А теперь поехали.
Хотя технологии на основе блокчейна обладают многими качествами, которые отличают их от других вычислительных парадигм, их основным ценностным предложением является генерация криптографической истины. В самом простом смысле, криптографическая истина — это форма вычислений и ведения учета, которая является более точной, доступной, проверяемой и защищенной от взлома, чем существующие альтернативы.
Криптографическая истина происходит от инфраструктуры с минимизацией доверия - кода, который работает именно так, как задумано, потому что его выполнение и проверка не зависят от доверия к незнакомцам или неконтролируемым переменным. Блокчейн генерирует минимизацию доверия, используя криптографию для аутентификации данных и обеспечения хронологического порядка записей, а также децентрализованный консенсус для подтверждения новых записей и сохранения их неизменности. Благодаря этому механизму многосторонние процессы могут отслеживаться и выполняться на общем, достоверно нейтральном бэкенде, который стимулируется к честному управлению.
Автор заметок UX-дизайнера — Антон Григорьев — опытный проектировщик информационных систем, преподаватель и автор статей. Он каждый месяц прочитывает десятки публикаций, отбирает из них самые достойные, выписывает основные тезисы и публикует в своём канале. В июльский дайджест полезных материалов для UX-дизайнеров попало 14 материалов…
Здравствуйте, меня зовут Дмитрий Карловский и я… как скульптор, отрезаю всё лишнее, чтобы оставить лишь самую мякотку, которая в наиболее лаконичной и практичной форме решает широкий круг задач. Вот лишь несколько спроектированных мною вещей:
На этот же раз мы спроектируем удобный клиент-серверный API, призванный убрать кровавую пелену с глаз фронтендеров и стальные мозоли с пальцев бэкендеров..
| HARP | OData | GraphQL | |
|---|---|---|---|
| Architecture | ✅REST | ✅REST | ❌RPC |
| Common uri query string compatible | ⭕Back | ✅Full | ❌ |
| Single line query | ✅ | ✅ | ❌ |
| Pseudo-static compatible | ⭕Back | ⭕Partial | ❌ |
| Same model of request and response | ✅ | ✅ | ❌ |
| File name compatible | ✅ | ❌ | ❌ |
| Web Tools Friendly | ✅ | ❌ | ❌ |
| Data filtering | ✅ | ✅ | ⭕Unspec |
| Data sorting | ✅ | ✅ | ⭕Unspec |
| Data slicing | ✅ | ✅ | ⭕Unspec |
| Data aggregation | ✅ | ✅ | ⭕Unspec |
| Deep fetch | ✅ | ✅ | ✅ |
| Limited logic | ✅ | ❌ | ✅ |
| Metadata query | ✅ | ✅ | ✅ |
| Idempotent requests | ✅Full | ⭕Partial | ❌Undef |
| Normalized response | ✅ | ❌ | ❌ |
Подобные системы применяют организации из самых разных отраслей — промышленные предприятия, нефтегазовые компании, облачные провайдеры и многие другие. Расскажем, что важно знать о ситуационных центрах.
Второй уровень (Layer 2, L2) - это любая офф-чейн сеть, система или технология, построенная поверх блокчейна (обычно известного как сеть первого уровня), которая помогает расширить возможности сети базового уровня. Сети второго уровня могут поддерживать любой блокчейн для внедрения таких улучшений, как например, более высокая пропускная способность транзакций.
Одним из основных требований к сети, системе или технологии второго уровня является то, что она наследует безопасность блокчейна, на базе которого она построена. Данные транзакций должны в той или иной форме проверяться и подтверждаться базовой сетью блокчейна, а не отдельным набором узлов. Например, сайдчейны часто не считаются вторым уровнем, поскольку они обычно используют собственные механизмы консенсуса и валидаторы, что приводит к иному набору гарантий безопасности, чем в сети базового уровня.
Для блокчейнов, которые жертвуют масштабируемостью для достижения более высокой децентрализации и безопасности, второй уровень обеспечивает большую пропускную способность транзакций, что может привести к снижению комиссий. Второй уровень можно рассматривать как одно из решений проблемы масштабируемости, обеспечивающее быстрое и масштабируемое исполнение без ущерба для децентрализации и безопасности.
Всем привет! Меня зовут Аня, я строю и развиваю инфраструктуру мониторинга в платформе телеметрии Ozon. Моя команда не только помогает настроить мониторинг, но и разрабатывает различные сервисы и инструменты, чтобы упростить жизнь разработчикам компании.
В прошлом году я рассказывала, как мы организовали мониторинг Kubernetes CronJob на основе kube-state-metrics, Thanos Receive и Thanos Ruler. За год мы нашли ответ на вопрос, почему же крон может не запускаться. И в этой статье я хочу рассказать об основных причинах и проблемах, о которых мы узнали.
Спойлер: многие не задумываются о том, как устроен и управляется CronJob.
Хабр, привет!
Нас зовут Дмитрий Фролов и Владимир Мясников.Мы стандартизировали подход по документированию внутренних систем в команде интеграционного тестирования Мир Plat.Form с помощью «Модели С4».
Платежная платформа «Мир» представляет из себя десятки систем и сотни интеграций, за работоспособность которых отвечает наша команда. Разобраться новичку, и даже опытному сотруднику, в происходящем бывает непросто, и сегодня мы расскажем, как помогаем коллегам быстро и удобно получать информацию о наших системах.
Давайте разберемся, что такое «Модель С4» и какие задачи она помогает решать. С чего начать, если вам поступила задача задокументировать «большую» систему – читайте под катом.
Привет, Хабр!
Меня зовут Александр Казанцев, я захабренный старожил с 2007 года. Недавно вместе с ребятами из «Инфосистемы Джет» довелось побывать в жюри конкурса «Технотекст-2021» в номинации «Лучший кейс». Нам предстояло оценивать посты и выбирать лучшие истории, и тогда мы задались вопросом: а есть ли универсальный рецепт, по которому можно написать интересную и полезную статью о проекте? Вопрос показался мне особенно интересным, поэтому я решил изучить публикации с высоким рейтингом и посты участников конкурса, разобрать их на ингредиенты и собрать своего рода поваренную книгу.
