Поговорим о том, с каким бэкграундом и для чего приходят в инновационную деятельность с ТРИЗ (теорией решения изобретательских задач). Мой путь длиною в 17 лет - от ИТ-ишника к корпоративному инноватику.
Анализ и проектирование систем *
Анализируй и проектируй
Новости
Разница между python и php
Год назад я полностью перешел в разработку на Python. До этого около 4-х лет писал в основном на PHP. В процессе работы я постоянно сравнивал эти 2 языка и сейчас решил уложить это все в одной статье, чтобы структурировать плюсы и минусы. Для вас эта статья может быть полезна, чтобы разобраться, какой выбрать для ваших задач.
Переход от традиционного монолитного десктоп приложения к гибридной модели
У нас в Альфа-Банке в брокерском направлении уже достаточно давно существует терминал для профессиональной работы на бирже. Терминал представляет собой полноценное рабочее место профессионального трейдера. Есть и инструменты технического анализа, и алгоритмическая торговля (торговые роботы), и скальперский стакан. Приложение писалось и поддерживалось на протяжении длительного периода времени различными командами. В последние несколько лет в связи с активным притоком клиентов на российские торговые площадки возникла необходимость развития и доработки этого терминала.
Читаем схему от минуса к плюсу
Добрый день. Я разработчик ПО и начал изучать электронику. Я хочу написать свою книгу о том что я узнаю в электронике и как создать эмулятор и построить устройство. Я прочитал первые страницы "Art of electronics" и сразу же приступил к написанию эмулятора. Но я вычисления производил от плюса к минусу. Потом вспомнил что по-настоящему ток течет от минуса к плюсу. Я начал расследовать и домысливать как это работает. Понял что у заряда есть поле. В общем если вам интересно, добро пожаловать.
Сначала я расскажу как же все таки можно вычислить общее напряжение в цепи. Вот пример картинки.
Как устроена аналитика в «Сравни»
Привет, Хабр! Меня зовут Роман Романчук, я руководитель отдела аналитики в Сравни. За последние пару лет наша компания сильно выросла. Два года назад у нас было около 80 сотрудников, а сейчас уже больше 350. Отдел аналитики также разросся: сначала в нем было всего пять человек, а сейчас уже более 30.
Изначально у нас был довольно стихийный подход к аналитике, но в какой-то момент он перестал удовлетворять потребности бизнеса, так как коллегам необходимы были точные цифры в реальном времени. Чтобы решить эту проблему, мы разработали стратегию развития аналитики в компании. В своей статье я расскажу, к чему нам удалось прийти в результате.
Бизнес-правила и требования к системе
Работа над каким-либо IT-продуктом/системой всегда начинается со сбора требований.
В идеальной вселенной, с представителя бизнеса работает бизнес-аналитик, который собирает пожелания заказчиков и формирует их в бизнес-правила. Далее уже над бизнес-правилами работает системный аналитик, формируя требования к системе. Но, зачастую, позицию «бизнес-аналитик» опускают: в бизнесе данная позиция отсутствует, в IT- команде данную роль совмещает в себе системный аналитик. У многих встает вопрос, как же правильно выделить бизнес-правила, чем они отличаются от требований к системе и зачем вообще их выделять, разве нельзя сразу приступить к формированию требований к системе?
Для начала, давайте определимся с понятиями «Бизнес-правила» и «Системные требования».
Создание чат-ботов на Bot Framework Composer без программирования для Microsoft Teams
- Microsoft Dataverse для создания структуры таблиц баз данных.
- Модели искусственного интеллекта Microsoft AI Builder.
- Механизм Dataflows для создания потоков обновления данных из различных источников.
- Пользовательские соединители.
- Шлюзы для интеграции с on-premises окружением.
- Коннекторы для интеграции с сервисами Azure (Azure Data Lake, Azure Tables, Azure Logic Apps, Azure SQL,...)
- Автоматическая миграция данных в Azure Synapse.
- Множество других полезных возможностей.
Закон Кёрли: Делай что-то одно
В статье "Пережить великую нехватку переменных" (Outliving the Great Variable Shortage) Тим Оттингер формулирует закон Кёрли:
«Переменная должна означать только что-то одно. Она не должна означать "что-то при таких-то условиях" и иметь разный смысл в разных обстоятельствах. Также она не должна иметь два смысла одновременно. "За двумя зайцами погонишься – ни одного не поймаешь". Переменная должна означать что-то одно все время своего существования»
С чего начать переход в «Индустрию 4.0» — бизнес-знания, данные и документооборот
Мы в BIOCAD занимаемся разработкой и производством лекарственных препаратов. Это — достаточно сложный процесс, пересекающийся с управлением компетенциями и даже корпоративным контентом. Сегодня руководитель группы разработки Григорий Седлецкий и инженер-программист Екатерина Машина расскажут, как эта тема связана с внедрением подходов «Индустрии 4.0».
Как построить систему аналитики на open-source — туториал по cube.js
Сube (до недавнего времени cube.js) относительно молодой проект (первый релиз март 2019) - реализация концепции OLAP-куб. Несмотря на отличную документацию, в интернете пока что мало информации на русском языке. Если вы выбираете систему аналитики, приверженец open-source или просто хотите узнать об альтернативах Power BI и Tableau, то это статья для вас. Обзор платформы и применение на реальном примере.
Кто был первым бизнес-аналитиком?
Развитие информационных технологий привело к появлению бизнес-аналитиков.
Кто это такой? В чем его основные функции?
Кто был первым бизнес-аналитиком?
Блокчейн в корпоративной архитектуре: дань моде или необходимость?
Привет! Меня зовут Денис Васин, я технический директор Waves Enterprise, и мы занимаемся блокчейн-проектами для бизнеса. Благодаря метавселенным, технология недавно снова оказалась на волне популярности. Множество крупных компаний, начиная с Meta, объявили, что планируют создавать подобные проекты с поддержкой распределенных реестров и NFT-токенов. Можно утверждать, что блокчейн в целом постепенно выходит на плато продуктивности — самое время трезво оценить его и понять, когда он вообще нужен. Постараюсь сделать это далее в посте.
220 платежей в секунду: выдержать нельзя упасть
Одни из важнейших характеристик качественного 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 Математическая модель кинетики нейтронов в «точечном» реакторе «нулевой» мощности.
Сегодня у нас легкий текст понятный даже школьнику!
Кто такие аналитики в IT и чем они занимаются
Всем привет! Рада познакомиться, меня зовут Марина. И уже четвертый год, как работаю аналитиком. В этой должности я поменяла три места работы. До этого работала разработчиком и техническим писателем. Сейчас пишу книгу о профессии Аналитик. Некоторые мысли в помощь самой себе решила публиковать здесь. Надеюсь, они окажутся полезными и другим.
Экономическая модель для ММО
Некоторые соображения о том, как концептуально может быть устроена идеализированная экономика обмена в ммо-игре.
Рабочий шаблон архитектурного решения
Уже три года, как мы постепенно передаем солюшн-архитектуру в команды разработки. Приходится часто объяснять, как сделать архитектурное решение коллегам, которые раньше подобными вещами не занимались. Отсюда родилась идея этой статьи – поделиться опытом, который сложился у меня и моих коллег за 10 лет практики. Важная часть этого опыта – шаблон архитектурного решения с пояснениями как его заполнять и почему именно так. По сути, шаблон - это структура необходимых знаний. Если вы нашли ответы на все вопросы шаблона, значит вы продуманно подошли к созданию архитектуры. А еще, сделали хороший документ, с которым удобно работать.
Статья расскажет, как правильно оформить ваши мысли, и что должно содержать качественное архитектурное решение. Статья не научит делать архитектуру.
Статья будет полезна:
• Аналитикам, тимлидам, программистам, которые уже делают или собираются делать архитектурные решения;
• Архитекторам, чтобы улучшить качество выпускаемых документов;
• Главным архитекторам с целью посмотреть «а как там у них».
Сага о моделировании бизнес-процессов на базе конечного автомата (fsm)
Про конечные автоматы (finite state machine, fsm) много кто слышал, но используют их явно в реальных проектах редко. Чаще встречаются конструкции, которые поведением напоминают КА, но ими не являются.
Почему же автоматы обходят стороной и/или изобретают велосипеды, превращая код в спагетти?
По-моему, тут дело в стереотипе: мол, автоматы — это что-то сложное из теоретической математики и к реальной жизни не относится. А применять их можно только в лексических анализаторах или еще чем-нибудь специфичном.
На самом деле, область применения КА куда шире и понятнее. Давайте разберем на примере автоматизации процессов в любимом кровавом enterprise.
Сеть данных: как уравновесить централизацию и децентрализацию
Архитектура сети данных (data mesh) распределяет владение данными среди команд из разных предметных областей, с федеративным управлением и децентрализованными продуктами по обработке данных. Сеть данных отличается от других аналогичных архитектур именно своей высокой децентрализацией: она распределена, а не централизована.
Вклад авторов
-
nmivan 1628.0 -
AloneCoder 1188.8 -
tangro 949.0 -
olegbunin 944.0 -
it_man 705.0 -
zzeng 583.0 -
1cloud 511.0 -
DmitrySpb79 449.0 -
ua-hosting 414.4 -
Uris 413.0