Введение

• Проверки, что вся существующая функциональность описана в документации
• Проверки, что всё описанное работает как заявлено в документации

PRINT OBJECT_DEFINITION(OBJECT_ID('sys.objects'))

IF OBJECT_ID('dbo.Table1', 'U') IS NOT NULL
  DROP TABLE dbo.Table1
GO

CREATE TABLE dbo.Table1 (ColumnID INT PRIMARY KEY)
GO

EXEC sys.sp_helptext 'dbo.Table1'
SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.Table1', 'U'))

CREATE VIEW sys.sql_modules AS
    SELECT object_id = o.id,
        definition = object_definition(o.id),
        ...
    FROM sys.sysschobjs o

SELECT owner, object_type, object_name
FROM all_objects
WHERE status = 'INVALID'

• «Что будет, если поменять поле в таблице?»
• «На каких ETL процессах это скажется?»
• «Какие отчеты будут затронуты?»
• «Какие бизнес процессы могут пострадать?»

SELECT
    LogTruncations = (
        SELECT TOP 1 SUM(cntr_value)
        FROM ##tbl_cnt
        WHERE counter_name = 'Log Truncations'
    ),
    LogShrinks = (
        SELECT TOP 1 SUM(cntr_value)
        FROM ##tbl_cnt
        WHERE counter_name = 'Log Shrinks'
    ),
    LogGrowths = (
        SELECT TOP 1 SUM(cntr_value)
        FROM ##tbl_cnt
        WHERE counter_name = 'Log Growths'
    ),
    ...

SELECT
    LogTruncations = SUM(CASE WHEN counter_name = 'Log Truncations' THEN cntr_value END),
    LogShrinks = SUM(CASE WHEN counter_name = 'Log Shrinks' THEN cntr_value END),
    LogGrowths = SUM(CASE WHEN counter_name = 'Log Growths' THEN cntr_value END),
    ...
FROM ##tbl_cnt

Не так давно передо мной стала задача проанализировать количество Excel файлов созданных за определенный месяц года. Не буду вдаваться в подробности, скажу вкратце: для оценки работы сотрудников одной фирмы. Файлов в наличии было около тысячи и суть задачи сводилась к тому, чтобы сделать понятный график в виде гистограммы для руководителя фирмы, в какой месяц года и сколько было сделано файлов (это были товарные накладные).

Продолжаем рассказывать вам об опенсорсных продуктах реализованных на JS фреймворке — IONDV. Framework. Сегодня поговорим о системе управления проектами, которая была одним из наших первых масштабных проектов и которую изначально мы реализовали для правительства Хабаровского края России. А сейчас веб-приложение открыто на GitHub под лицензией Apache 2.0. Система которую мы создали в большей степени заточена под региональный госсектор, поэтому она обладает соответствующей структурой метаданных и набором функций. Но мы не видим существенных препятствий, которые помешали бы доработать систему под конкретные задачи, да и использовать её по назначению никто не запрещает.

Прежде чем делиться опытом, ответим на очевидные на первый взгляд вопросы. Что это такое и зачем? Искать готовую или делать свою? И приведем наш опыт реализации технического решения.

Недавно к нам в команду поступил запрос на создание прототипа системы по выдачи билетов, что и было сделано за какие-то 40 часов работы включая обсуждение "ТЗ", проектирование, реализацию и даже некие доработки. Сделали мы и подумали, что такое простое приложение может быть очень даже полезным для широкой аудитории. В итоге, мы слегка поколдовали на IONDV. Framework, придумали социальное предназначение и заодно протестировали IONDV. Studio.

Каждый Ангуляр разработчик видел декораторы в тайпскрипт коде. Их используют, чтобы описать Модули, сконфигурировать Dependency Injection или настроить компонент. Другими словами, декораторы используются, чтобы описать дополнительную информацию, или метаданные, для фреймворка или компилятора (в случае Ангуляра). При чем, Ангуляр лишь один из примеров. Существуют многие другие библиотеки, использующие декораторы для простоты и наглядности кода, как декларативный подход. Как .NET разработчик в прошлом, я вижу много сходства между TS декораторами и .NET аттрибутами. Наконец, набирающий популярность NestJS фреймворк для бекенд приложений (абстракция над Node), также построен на интенсивном использовании декораторов и декларативном подходе. Как это все работает и каким образом использовать декораторы в своем коде, чтобы он был более удобным и читабельным? Мы все понимаем, что после компиляции TS кода мы получаем Javascript код. В котором нет понятия декоратор, как и многих других Typescript особенностей. Поэтому для меня наиболее интересным является вопрос, во что превращается декоратор после компиляции. Занимаясь этим вопросом, я сделал выступление на митапе в Минске и хочу поделиться статьей.

Введение

NestJS — стремительно набирающий популярность фрeймворк, построенный на идеях IoC/DI, модульного дизайна и декораторов. Благодаря последним, Nest имеет лаконичный и выразительный синтаксис, что повышает удобство разработки.

Декораторы или аннотации — наследники аспектов, которые позволяют декларативно описывать логику, модифицировать поведение классов, их свойств, аргументов и методов.

Технически декораторы — это просто функции, но их вызовом полностью управляет компилятор.
Важная особенность заключается в том, что в зависимости от контекста, сигнатуры аргументов будут различаться. Материалов на эту тему существует довольно много, однако мы сосредоточимся на специфике, связанной непосредственно с Nest.

DataHub: универсальный инструмент поиска и обнаружения метаданных.

Как оператор крупнейшей в мире профессиональной сети и экономического графика, отдел данных LinkedIn постоянно работает над масштабированием своей инфраструктуры в соответствии с требованиями нашей постоянно растущей экосистемы больших данных. По мере роста объема и разнообразия данных специалистам по данным и инженерам становится все сложнее обнаруживать доступные активы данных, понимать их происхождение и предпринимать соответствующие действия на основе полученных данных. Чтобы помочь нам продолжить масштабировать производительность и вносить инновации в базу данных, мы создали универсальный инструмент поиска и обнаружения метаданных, DataHub.

DataHub с открытым исходным кодом: платформа поиска и обнаружения метаданных от LinkedIn

Быстрый поиск нужных данных необходим для любой компании, которая полагается на большое количество данных для принятия решений на основе этих данных. Это не только влияет на продуктивность пользователей данных (включая аналитиков, разработчиков машинного обучения, специалистов по обработке данных и инженеров данных), но также оказывает прямое влияние на конечные продукты, которые зависят от качественного конвейера машинного обучения (ML). Кроме того, тенденция к внедрению или созданию платформ машинного обучения естественным образом вызывает вопрос: каков ваш метод внутреннего обнаружения функций, моделей, показателей, наборов данных и т. Д.

Ежедневно я общаюсь с большим количеством крупных компаний. Нередко они выражают желание построить data-driven компанию в течение следующих нескольких лет. Их ключевая стратегия заключается в создании DWH/Big data и подключении к ней пользователей, которые сами будут строить отчеты, визуализации и дашборды, используя self-service инструменты - Tableau, Power BI или Qlik.

Одна из основных проблем Tableau, Power BI или Qlik - у них нет единого семантического слоя, единой логической модели, единого определения всех атрибутов, фактов и показателей для всей бизнес-аналитики компании. Именно поэтому они растут в компании без контроля и governance, порождая множество версий правды в отчетности и аналитике в компании. Через какое-то время компании сталкиваются с тем, что уже не могут разобраться какому отчету доверять - данные не сходятся не только в разных системах Tableau, Power BI или Qlik, но и между отчетами в одной системе. Получается, что компании вкладывают огромные средства в построение единой версии правды на уровне хранилищ данных, а в конечном счете получают невероятное количество отдельных и ungoverned отчетов, визуализаций, дашбордов, которым они не могут доверять.

Tableau, Power BI и Qlik - отличные инструменты, если вы хотите, чтобы бизнес-пользователь мог выполнять локальную аналитику self-services для нужд своего отдела. Тем не менее, чтобы построить data-driven компанию на уровне всего предприятия, вам потребуется инструмент, который позволит упорядочить, структурировать и стандартизовать всю вашу бизнес-аналитику.