Анализ и проектирование систем *

Поговорим о том, с каким бэкграундом и для чего приходят в инновационную деятельность с ТРИЗ (теорией решения изобретательских задач). Мой путь длиною в 17 лет - от ИТ-ишника к корпоративному инноватику.

Год назад я полностью перешел в разработку на Python. До этого около 4-х лет писал в основном на PHP. В процессе работы я постоянно сравнивал эти 2 языка и сейчас решил уложить это все в одной статье, чтобы структурировать плюсы и минусы. Для вас эта статья может быть полезна, чтобы разобраться, какой выбрать для ваших задач.

У нас в Альфа-Банке в брокерском направлении уже достаточно давно существует терминал для профессиональной работы на бирже. Терминал представляет собой полноценное рабочее место профессионального трейдера. Есть и инструменты технического анализа, и алгоритмическая торговля (торговые роботы), и скальперский стакан. Приложение писалось и поддерживалось на протяжении длительного периода времени различными командами. В последние несколько лет в связи с активным притоком клиентов на российские торговые площадки возникла необходимость развития и доработки этого терминала.

Добрый день. Я разработчик ПО и начал изучать электронику. Я хочу написать свою книгу о том что я узнаю в электронике и как создать эмулятор и построить устройство. Я прочитал первые страницы "Art of electronics" и сразу же приступил к написанию эмулятора. Но я вычисления производил от плюса к минусу. Потом вспомнил что по-настоящему ток течет от минуса к плюсу. Я начал расследовать и домысливать как это работает. Понял что у заряда есть поле. В общем если вам интересно, добро пожаловать.

Сначала я расскажу как же все таки можно вычислить общее напряжение в цепи. Вот пример картинки.

Привет, Хабр! Меня зовут Роман Романчук, я руководитель отдела аналитики в Сравни. За последние пару лет наша компания сильно выросла. Два года назад у нас было около 80 сотрудников, а сейчас уже больше 350. Отдел аналитики также разросся: сначала в нем было всего пять человек, а сейчас уже более 30. 

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

Работа над каким-либо IT-продуктом/системой всегда начинается со сбора требований.

В идеальной вселенной, с представителя бизнеса работает бизнес-аналитик, который собирает пожелания заказчиков и формирует их в бизнес-правила. Далее уже над бизнес-правилами работает системный аналитик, формируя требования к системе. Но, зачастую, позицию «бизнес-аналитик» опускают: в бизнесе данная позиция отсутствует, в IT- команде данную роль совмещает в себе системный аналитик. У многих встает вопрос, как же правильно выделить бизнес-правила, чем они отличаются от требований к системе и зачем вообще их выделять, разве нельзя сразу приступить к формированию требований к системе?

Для начала, давайте определимся с понятиями «Бизнес-правила» и «Системные требования».

1. Microsoft Dataverse для создания структуры таблиц баз данных.
2. Модели искусственного интеллекта Microsoft AI Builder.
3. Механизм Dataflows для создания потоков обновления данных из различных источников.
4. Пользовательские соединители.
5. Шлюзы для интеграции с on-premises окружением.
6. Коннекторы для интеграции с сервисами Azure (Azure Data Lake, Azure Tables, Azure Logic Apps, Azure SQL,...)
7. Автоматическая миграция данных в Azure Synapse.
8. Множество других полезных возможностей.

В статье "Пережить великую нехватку переменных" (Outliving the Great Variable Shortage) Тим Оттингер формулирует закон Кёрли:

«Переменная должна означать только что-то одно. Она не должна означать "что-то при таких-то условиях" и иметь разный смысл в разных обстоятельствах. Также она не должна иметь два смысла одновременно. "За двумя зайцами погонишься – ни одного не поймаешь". Переменная должна означать что-то одно все время своего существования»

Мы в BIOCAD занимаемся разработкой и производством лекарственных препаратов. Это — достаточно сложный процесс, пересекающийся с управлением компетенциями и даже корпоративным контентом. Сегодня руководитель группы разработки Григорий Седлецкий и инженер-программист Екатерина Машина расскажут, как эта тема связана с внедрением подходов «Индустрии 4.0».

Сube (до недавнего времени cube.js) относительно молодой проект (первый релиз март 2019) - реализация концепции OLAP-куб. Несмотря на отличную документацию, в интернете пока что мало информации на русском языке. Если вы выбираете систему аналитики, приверженец open-source или просто хотите узнать об альтернативах Power BI и Tableau, то это статья для вас. Обзор платформы и применение на реальном примере.

Развитие информационных технологий привело к появлению бизнес-аналитиков.
Кто это такой? В чем его основные функции?
Кто был первым бизнес-аналитиком?

Привет! Меня зовут Денис Васин, я технический директор Waves Enterprise, и мы занимаемся блокчейн-проектами для бизнеса. Благодаря метавселенным, технология недавно снова оказалась на волне популярности. Множество крупных компаний, начиная с Meta, объявили, что планируют создавать подобные проекты с поддержкой распределенных реестров и NFT-токенов. Можно утверждать, что блокчейн в целом постепенно выходит на плато продуктивности — самое время трезво оценить его и понять, когда он вообще нужен. Постараюсь сделать это далее в посте.

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

Я разрабатываю сервисы в команде платежей Ozon. Мы много времени уделяем тому, чтобы все транзакции были обработаны корректно, даже если речь идёт о нагрузке в 2к платежей в минуту (именно столько у нас было в пике в период ноябрьских распродаж). Кстати, сейчас, по результатам нагрузочного тестирования, мы выдерживаем 13к платежей в минуту.

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

Для организации разработки и тестирования сегодня принято выстраивать пирамиду тестов, это считается мейнстримом. Существуют десятки, если не сотни, вариаций пирамиды, опубликовано много докладов и статей о том, как она должна выглядеть. И почти все эти материалы помогут ответить на вопрос «Как мне построить пирамиду тестирования в новом проекте?».

Но что делать, если вы приходите в проект, в котором исторически применялся подход «мороженки» тестирования, когда основную часть проверок закрывали ручным тестированием? При этом компания проходит трансформацию, и от вас ждут, что вы приведёте процессы в соответствие современным практикам и ускорите их?

Меня зовут Максим Бугров, я больше 8 лет работаю в тестировании ПО. На Московскую Биржу я пришел летом 2021 года на позицию начальника отдела тестирования. Наш департамент преимущественно разрабатывает софт, который связывает клиентов и торгово-клиринговые системы Биржи. И я расскажу, как мы начали превращать мороженку в пирамиду — нас ждал огромный ледник задач.

Продолжаем публикацию лекций по курсу "Управление в Технических Системах"

Данные лекции готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется. В предыдущих сериях:

1. Введение в теорию автоматического управления.
2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13.
3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ РЕГУЛИРОВАНИЯ.
3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ. 3.2. Типовые звенья систем автоматического управления регулирования. Классификация типовых звеньев. Простейшие типовые звенья. 3.3. Апериодическое звено 1–го порядка инерционное звено. На примере входной камеры ядерного реактора. 3.4. Апериодическое звено 2-го порядка. 3.5. Колебательное звено. 3.6. Инерционно-дифференцирующее звено. 3.7. Форсирующее звено.  3.8. Инерционно-интегрирующее звено (интегрирующее звено с замедлением). 3.9. Изодромное звено (изодром). 3.10 Минимально-фазовые и не минимально-фазовые звенья. 3.11 Математическая модель кинетики нейтронов в «точечном» реакторе «нулевой» мощности.

Сегодня у нас легкий текст понятный даже школьнику!

Всем привет! Рада познакомиться, меня зовут Марина. И уже четвертый год, как работаю аналитиком. В этой должности я поменяла три места работы. До этого работала разработчиком и техническим писателем. Сейчас пишу книгу о профессии Аналитик. Некоторые мысли в помощь самой себе решила публиковать здесь. Надеюсь, они окажутся полезными и другим.

Некоторые соображения о том, как концептуально может быть устроена идеализированная экономика обмена в ммо-игре.

Уже три года, как мы постепенно передаем солюшн-архитектуру в команды разработки. Приходится часто объяснять, как сделать архитектурное решение коллегам, которые раньше подобными вещами не занимались. Отсюда родилась идея этой статьи – поделиться опытом, который сложился у меня и моих коллег за 10 лет практики. Важная часть этого опыта – шаблон архитектурного решения с пояснениями как его заполнять и почему именно так. По сути, шаблон - это структура необходимых знаний. Если вы нашли ответы на все вопросы шаблона, значит вы продуманно подошли к созданию архитектуры. А еще, сделали хороший документ, с которым удобно работать.

Статья расскажет, как правильно оформить ваши мысли, и что должно содержать качественное архитектурное решение. Статья не научит делать архитектуру.

Статья будет полезна:

• Аналитикам, тимлидам, программистам, которые уже делают или собираются делать архитектурные решения;

• Архитекторам, чтобы улучшить качество выпускаемых документов;

• Главным архитекторам с целью посмотреть «а как там у них».

Про конечные автоматы (finite state machine, fsm) много кто слышал, но используют их явно в реальных проектах редко. Чаще встречаются конструкции, которые поведением напоминают КА, но ими не являются.
Почему же автоматы обходят стороной и/или изобретают велосипеды, превращая код в спагетти?
По-моему, тут дело в стереотипе: мол, автоматы — это что-то сложное из теоретической математики и к реальной жизни не относится. А применять их можно только в лексических анализаторах или еще чем-нибудь специфичном.

На самом деле, область применения КА куда шире и понятнее. Давайте разберем на примере автоматизации процессов в любимом кровавом enterprise.

Архитектура сети данных (data mesh) распределяет владение данными среди команд из разных предметных областей, с федеративным управлением и децентрализованными продуктами по обработке данных. Сеть данных отличается от других аналогичных архитектур именно своей высокой децентрализацией: она распределена, а не централизована.