Было ли у вас озарение? Возникало ли ощущение вспышки, когда вы понимали, что нашли решение проблемы?
Знаменитая фраза «Эврика!» очень хорошо отражает суть этого ощущения.
Далее — мой отзыв о хайповой теме применения LLM в разработке ПО и всего, что с этим связано.
Мне довелось выступить техническим экспертом на бизнес-акселераторе Genesis: IT & Telecom в СибГУТИ.
Я был одним из немногих экспертов, чей фокус был не на технической реализации: архитектуре, коде, инфраструктуре. И почти каждая наша беседа начиналась с одного и того же диалога:...
Мультиплексирование — это технология, позволяющая передавать несколько независимых потоков данных через одно физическое соединение. Представьте официанта в ресторане, который несёт один поднос с заказами для десяти разных столиков, вместо того чтобы делать десять отдельных ходок.
В новой статье хочу попробовать новый формат. Надеюсь, что в новом виде материал возымеет больше интереса и лучше получится донести ключевые мысли и тезисы.
Итак, представляю на ваш суд пьесу "Неэффективная эффективность" в 13 частях от продуктового лидера с 20-летним опытом, который так и не смог решить маленькую проблемку.
Всем привет! Меня зовут Анатолий, я представляю команду Front-End разработки компании DD Planet.
В этой статье расскажу о том, как наш проект завершил этап разработки и трансформировался в стабильный рабочий продукт.
Это интервью — разбор реального опыта миграции фронтенда Compo B2B Platform с Angular 13 на актуальные версии фреймворка (в итоге — Angular 19). Команда Compo Soft прошла путь через несколько мажорных апдейтов, замену и переписывание зависимостей, рефакторинг архитектуры и внедрение новых возможностей Angular — от Standalone Components до Vite и non‑destructive hydration.
Представьте, что вы нажимаете кнопку «Отправить заказ» в интернет-магазине. Если страница зависла, вы нажмёте её ещё раз. Идемпотентная система обработает повторный запрос так, что вы не получите два одинаковых заказа и с вашей карты не спишутся деньги дважды. Неидемпотентная — создаст два заказа и спишет средства дважды.
Всем привет! Это продолжение статей про мою ECS with Sectors в моём движке Stellar Forge!
В предыдущей статье я описал структуру памяти, что являлось подготовкой фундамента для быстрой итерации, а сейчас хочу рассказать как по этой памяти передвигаться.
Получилась общая обзорная статья о том, как заставить C++ код быть быстрее, так что устраивайтесь поудобнее :-)
Статья будет полезна всем, кто пишет performance-critical код на C++: геймдев, HFT, обработка данных, embedded.
Тема управления в организации достаточна многогранна и касается различных сторон деятельности сотрудников и организации их работы. В настоящей статье рассмотрим, какие возможности появляются в компании для повышения эффективности ее деятельности при совершенствовании механизма управления с применением информационных технологий.
В каждой компании складывается такая система управления, которая должна обеспечить ее деятельность наилучшим, т.е. наиболее эффективным способом, позволяющим успешно реализовать намеченную цель и выполнять возникающие при этом задачи. А всегда ли так получается? К сожалению, не всегда имеющаяся в компании система управления является наиболее оптимальной для выполнения стоящих перед руководством задач. Причиной этого является отсутствие ясного понимания о том, что входит в систему управления, какое предназначение у элементов системы управления, как они формируются, как они воздействуют на сотрудников и между собой.
Механизм управления позволяет реализовать заложенный в элементах управления потенциал путем формирования и направления информационных потоков, на основании которых руководителями принимаются решения и которые, будучи доведены до сотрудников, воздействуют на них. Для точного понимания определим, что такое управление (процесс управления) в организации.
Процесс управления – это целенаправленное воздействие субъекта управления на объект управления при помощи специальных инструментов и ресурсов управления, необходимое для достижения определенной цели путем решения ими поставленной задачи (определение автора). При этом субъектом и объектом управления в организации являются сотрудники.
Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.
Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».
Публикуем новый полный перевод хрестоматийной статьи Эдсгера Дейкстры. Этот текст, опубликованный в 1968 году в журнале Communications of the ACM в формате письма в редакцию, заложил основы структурного программирования, впервые строго аргументировав отказ от оператора go to в пользу использования циклов и условных конструкций.
Наверное, каждый программист, работавший с объектно-ориентированными языками, хотя бы раз слышал о законе Деметры. Многие знают его смысл, но мало кто читал оригинальный текст 1989 года, где закон был не только сформулирован, но и подробно обоснован. В этой статье авторы, Карл Либерхер и Иэн Холланд, рассказывают о проекте «Деметра», дают строгие формулировки для разных языков и обсуждают, когда законом можно пренебречь.
Мы в Ситидрайве строим микросервисную архитектуру. Сегодня у нас 200+ сервисов, за которыми стоят свыше 20 автономных команд — всего больше 150 инженеров. Казалось бы, идеальная модель: каждая команда быстро выкатывает свои фичи без лишней бюрократии. Но была и обратная сторона — нет единого понимания, какие сервисы действительно критичны, как они связаны друг с другом и куда развивать систему дальше.
Но нам удалось с этим справиться — мы привели сотни микросервисов в порядок и сделали систему предсказуемой. В этой статье я расскажу про путь команды к внедрению тир-листа, модели зрелости, управлению зависимостями и приоритетами инцидентов.
Здравствуйте, меня зовут Дмитрий Карловский и я.. да не важно кто я. Важно о чём я говорю, и как аргументирую.
Кто меня знает, тому и не надо рассказывать. А кто не знает — у того есть прекрасная возможность подойти к вопросу с чистым разумом. А это крайне важно, если мы хотим спроектировать что-то по настоящему хорошо, а не как обычно.
В статье рассмотрен паттерн проектирования «Буфер» как мощный инструмент оптимизации и повышения надежности систем. Показано, чем отличается архитектурный паттерн от простого буфера памяти, приведены разновидности и примеры использования в разных областях: от сетевых протоколов и логирования до встроенного ПО и GPU. Особое внимание уделено ошибкам при смешении понятий, тестированию эффективности и общим параметрам буферов.
Статья поможет разработчикам и архитекторам осознанно применять паттерн Буфер для создания производительных и устойчивых решений.
Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.
Возможно, причиной восторга стала мысль о том, что я смогу снова разнести его примеры кода, как сделал в своей первой статье.
Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.
А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад.
Несмотря на весь свой цинизм и любовь постебаться, я искренне уважаю тех, кто может признать свои ошибки и взглянуть на вещи по-новому. Я испытываю глубокую радость, когда мой посыл доходит до умов людей и меняет их взгляд на вопросы, в которых они грубо заблуждаются (хотя порой мне кажется, что мой напористый подход может, наоборот, этому мешать).
Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!
Невероятно!
Но я забегаю вперёд…
Меня зовут Миша, я бэкенд‑разработчик в платформе Яндекс Еды, и в этой статье я расскажу о принципах работы Temporal: почему мы его выбрали как основу нового процессинга, в чём его сильные стороны и как изменилась наша жизнь после перехода.
Раньше для такого требовались: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions. Теперь всё это описано в одной функции, которая вообще выглядит как псевдокод.
Магия? Нет, Temporal.
С тех пор как мы перенесли процессинг на Temporal, разработка существенно упростилась. Пользователь оплачивает заказ, ресторан его подтверждает и готовит, курьер забирает и привозит — ровно это и отражено в коде. Ну разве не прелесть?
Контроль импеданса - это основа проектирования современных высокоскоростных цифровых и высокочастотных аналоговых схем.
1. Что такое контроль импеданса?
Контроль импеданса (ImpedanceControl) – это совокупность мер при проектировании и производстве печатных плат (ПП), направленных на то, чтобы волновое сопротивление (импеданс) проводников на печатной плате имело строго заданное значение.
Проще говоря, это технология, которая заставляет дорожку на печатной плате вести себя не как простой провод, а как предсказуемый коаксиальный кабель или волновод.
Зачем это нужно?
Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день.
Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям.
Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии.
Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу?
Работа с процессами, которые имеются в любой компании, ведется уже не один год и кажется, что все уже давно изучено, описано и зачем еще раз подымать этот вроде бы теоретический вопрос. Дело в том, что при работе с процессами специалисты действуют в рамках установленной и принятой на сегодняшний день сообществом специалистов парадигмы, основываясь на которой осуществляется работа с ними (моделирование, контроль, анализ, совершенствование).
Имеется только один момент, который до конца не разобран и не систематизирован, хотя и оказывает значительное влияние на деятельность компании и на повышение ее эффективности – это процесс управления. При этом многие не осознают, что он является другой составной частью бизнес-процесса и неразрывно связан с операционным процессом. Так как в современных исследованиях, касающихся процессов, происходящих в организации, отсутствует ясное и точное определение и, соответственно, понимание, что такое процесс управления, то и пытаются его изобразить кто и как себе это представляет, применяя при этом инструменты, предназначенные для описания операционных процессов, и не понимая, что это разные сущности. А без описания происходящих в организации процессов управления деятельность организации оказывается неполной.
Но почему важно иметь точное понимание, что такое операционный процесс и что такое процесс управления?
На основании имеющихся знаний руководители и специалисты проводят моделирование, анализ и совершенствование бизнес-процессов, имеющихся в компании. А если знания не полные или недостаточные и не позволяют видеть всю картину деятельности сотрудников компании? Какая модель может быть разработана и какой результат может быть получен, основываясь на неполном знании и представлении и как это на самом деле осуществляется деятельность компании?
