• ER/Studio Data Architect,
• ER/Studio Business Architect,
• ER/Studio Software Architect,
• ER/Studio Repository, CONNECT.

Росстат ежегодно публикует порядка 4 тысяч показателей государственной статистики. Они доступны всем без каких-либо ограничений по статусу, правам доступа и т.п. Но публикуя данные, Росстат прежде всего ориентируется на то, что пользователи будут работать с ними вручную (глазами и руками), хотя последние 20 лет, мягко говоря, это не совсем тренд.

Меня зовут Веденьков Максим, я работаю в ЦПУР (Центр перспективных управленческих решений), некоммерческой организации, которая проводит исследования на государственных данных с целью повышения информированности общества о происходящих в стране процессах. Также мы собираем, обогащаем и публикуем датасеты с государственными данными, как ранее опубликованными, так и теми, которые раньше не публиковались.

В этой статье хочу рассказать об одном из таких наборов данных. Большом, сложном, важном, но при этом доступном в крайне неудобном для исследователей формате — базе данных показателей муниципальных образований (БД ПМО).

Помните, как вы были студентами, и готовились к экзаменам по ночам?

Предлагаю вашему вниманию простую шпаргалку по SQL с теорией и практикой, которой вы сможете воспользоваться в любое время.

Изучите теорию на примерах и закрепите на 13 практических задачах по SQL.

Решил составить для себя план развития (я в IT с 2007, как аналитик - с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что обязательно и желательно знать/уметь.

С чего все началось. Я недавно менял работу, поэтому готовился к техническим собеседованиям. Для удобства составил шпаргалку частых вопросов по основным темам. Когда проходил собеседования и видел, чего я не знаю, то дописывал это в свою шпаргалку. А немного позже решил составить для себя что-то наподобие плана развития. При создании плана использовал личный опыт, опыт коллег, ряд статей, учебные планы нескольких школ, требования из вакансий.

Разработчики находятся в постоянном поиске новых способов быстрой модернизации приложений, чтобы оперативно подстраиваться под меняющиеся потребности клиентов. Один из таких способов — новые динамические схемы в MongoDB. Это мощный и гибкий инструмент, который позволяет хранить данные в JSON-документах вместо реляционных таблиц. В частности, разработчикам нравится гибкость и безсхемная природа JSON-документов.

Но по мере усложнения корпоративных приложений приходится структурировать базы данных таким образом, чтобы они повышали эффективность решения и продуктивность разработчиков, попутно снижая общую стоимость владения приложением. Для этого требуется немало мастерства. Для крупных предприятий и государственных учреждений лучшим решением будут современные приложения на базе MongoDB Atlas, но при этом им нужно обеспечить эффективное управление данными. Здесь на помощь придет инструмент моделирования данных, разработанный специально для MongoDB.

Это Hackolade. Вот уже несколько десятилетий для визуального представления структуры данных реляционных БД используются ER-диаграммы. Изначально они предназначались только для плоских структур данных. Hackolade, сертифицированный технологический партнер MongoDB, предлагает расширенные ER-диаграммы, которые позволяют адаптировать представление иерархической структуры JSON с вложенными объектами и массивами. Hackolade — это первое решение для моделирования данных и проектирования схем для баз данных NoSQL и REST API.

Много уже говорилось о том, что SQLAlchemy - одна из самых популярных библиотек для создания схем баз данных. Сегодня рассмотрим несложный пример по созданию небольшой схемы данных для приложения по поиску цитат. В качестве СУБД будем использовать PostgreSQL.

Подход к определению моделей будем использовать декларативный, так как, на мой взгляд, он проще и понятнее классического подхода, основанного на mapper.

Анна Вичугова, CBAP, написала стартовое пособие по тому, как начать моделировать бизнес-процессы в BPMN

1. Назначение BPMN.

2. Уровни моделирования.

3. Алфавит нотации: События, Логические операторы, Артефакты.

4. Правила построения диаграмм.

5. Пример построения диаграммы по тексту.

6. Рекомендуемые инструменты.

В работе мы с коллегами часто видим как компании сталкиваются с проблемой управления данными – когда таблиц и запросов становится сильно много и управлять всем этим очень сложно. В таких ситуациях мы рекомендуем моделировать данные. Чтобы разобраться, что это такое – я перевела статью-обзор про моделирование данных от Towards Data Science, в которой кроме основных терминов и понятий можно найти наглядный пример использования моделирования данных в ритейле. Вперед под кат!

Меня зовут Александр, я руковожу backend-разработкой в КТS. Мы разрабатываем сложные высоконагруженные сервисы для крупных корпораций и рекламные спецпроекты.

У нас есть Телеграм-канал «Программисты делают бизнес». Мы ведем его недавно — первый пост вышел в декабре 2020 года.

В статье рассказал о том, зачем мы начали вести канал, как придумывали темы, начали делать посты и оптимизировали процессы. Тут обо всем, от начала до результата, что есть сейчас.

Как новичку начать вести заметки по методу «Цеттелькастен» в «Обсидиане» и какой в этом смысл.

Этот текст открывает цикл статей по рассмотрению проблемы управления знаниями в Obsidian. Эта часть почти не будет содержать практических советов о работе с заметками конкретно в Obsidian. Однако в ней будут раскрыты несколько более важные проблемы обработки различных источников информации. Несмотря на последовательное перетекание статьи из одной главы в другую, вы можете попробовать каждый пункт рассматривать как идею, как хак или как возможность внедрить в свою жизнь и рабочий процесс что-то новое.

Внимание! Внимание! Внимание! Внимание! Внимание! Внимание!

Это вторая часть биографии Криса Авеллона. Если вы еще не ознакомились с первой частью, настоятельно рекомендую это сделать.

Что такое хорошая архитектура?

Привет! За 10 лет работы в IT, я заметил, что многие не знают все направления по IT-специальностям. Я и сам когда-то не знал полной картины... Но ведь какая может быть польза от этого?

Например, для айтишника уровня middle и senior, такое знание поможет выбрать новое направление, когда понял, что выгорел или достиг потолка. Для начинающего —  направит, когда тот выбирает специальность и планирует карьерный путь. Для HR — составить вакансию и список требований. А тем кто далек от IT — даст понимание, кто за что отвечает.

Я собрал весь свой опыт и опыт коллег, проштудировал информацию в интернете и составил модель IT-направлений по уровням — «SLI» (Specializations Levels Interconnection — взаимосвязь уровней специализаций). За основу взял сетевую модель OSI, которую разработали специалисты на Западе еще в далекие 80-е и считают эталоном по сей день.

Разберем схему SLI и ответим на вопросы:

Самый дорогой ресурс — время. Его всегда не хватает. Один из популярных способов экономии времени — шаблон. Например, в повседневной времени у нас есть шаблоны поведения, когда мозг, чтобы не тратить энергию, действует по привычным схемам: ездим по одним и тем же маршрутам до работы, пьем кофе, к которому привыкли, берем выкройки для нового платья из журнала, или готовим презентацию по корпоративному шаблону.

В IT шаблоны тоже есть, например, паттерны проектирования или алгоритмы — математические шаблоны. Шаблоны — полезная «вещь»: позволяют меньше писать, подставляя что-то в уже сформированные рамки. 

Мы в Ak Bars Digital тоже используем много собственных наработок, методологий и шаблонов, чтобы делать все быстро и качественно. В этой статье поделюсь прикладным шаблоном, который создали опытным путем для удобной работы с пользовательскими историями.

При написании требований часто возникает вопрос, до какого уровня стоит детализировать требования и какие артефакты должны появится в результате системного анализа.

 Я стараюсь придерживаться позиции, что это сугубо индивидуально и зависит от команды и кому как комфортно работать. Случается, что разработчикам достаточно use-case  для того, чтобы сделать дизайн, а тестировщикам этого достаточно, чтобы написать тест-кейсы. Поэтому я буду писать о тех артефактах, которые могут возникнуть при написании требований и о которых надо точно задуматься к моменту завершения разработки, а вы сами решайте и договаривайтесь внутри команды, когда это стоит описывать. Однозначно только, что к концу разработки документация должна содержать все то, о чем далее пойдет речь.

Сейчас нужно написать краткое введение о том, что важно проводить аналитику для задачи на разработку: оценить влияние изменений, проработать все возможные сценарии и т.д.

Понимание сути и объема задачи должно появиться до первой строки кода. Писать сколь угодно емкое введение о важности этого этапа можно долго, но кажется, что все мы понимаем, что самые дорогие ошибки — на этапе проектирования.

Разработчику с проектированием и документированием решения задачи помогает аналитик.