Терминология IT

Привет, Хабр! С наступившим!

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

В статье рассмотрен паттерн проектирования «Буфер» как мощный инструмент оптимизации и повышения надежности систем. Показано, чем отличается архитектурный паттерн от простого буфера памяти, приведены разновидности и примеры использования в разных областях: от сетевых протоколов и логирования до встроенного ПО и GPU. Особое внимание уделено ошибкам при смешении понятий, тестированию эффективности и общим параметрам буферов.

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

              Небольшой дисклеймер: речь в статье, в основном, про родной для меня рынок B2B IT. Содержание статьи отражает как личный опыт, так и мнения многих коллег. Под ролями BizDev подразумеваются: BDM, BDO, менеджер по развитию бизнеса, руководитель направления по развитию бизнеса, руководитель группы/отдела/департамента развития бизнеса и т.д.. Под Sale – роли, связанные с продажами и сопровождением клиентов и подразумевающие обязательное наличие функционала управления продажами/пайплайном/воронкой, регулярных встреч с заказчиками и развития взаимоотношений – т.е. менеджер по продажам, account manager, solution sale, менеджер по развитию продаж, руководитель направления по развитию продаж, руководитель группы/отдела/департамента продаж и т.д. Роли, предполагающие взаимодействие с заказчиками строго в рамках ограниченного функционала, определенного скриптами/инструкциями – специалисты по холодным продажам, поддержке, активациям, сотрудники колл-центров и т.д. – находятся за пределами scope данной статьи.

За последние несколько месяцев, погрузившись в активности на рынке труда, я заметил следующую массовую ошибку в описаниях вакансий и дальнейших диалогах с представителями HR и бизнес‑заказчиками — пишут «нужен BizDev», и далее перечисляют стандартные требования к Sales‑роли. Часто подобное расхождение заметно уже на этапе изучения описания позиции, иногда — выявляется только в ходе разговоров, устного обсуждения требований и представлений руководства о том «что эта роль должна делать». А бывает, что подобные скрытые ожидания и представления нанимающей стороны становятся явными только уже в процессе трудовой деятельности. Это характерно для вакансий как на линейные позиции, так и на руководящие. Чаще — это ошибка непредумышленная, реже — сознательная. И очень укоренённая. А почему ошибка?

GraphQL API — это мощно, но как его документировать, чтобы разработчики остались довольны? В этой статье — готовый план действий. Мы начнём со сравнения GraphQL и REST, затем покажем, как с помощью комментариев и примеров кода превратить схему в наглядное руководство. Вы узнаете, как улучшить GraphiQL Playground подсветкой синтаксиса и создать статический справочник, если Playground недоступен. В конце вас ждёт учебный репозиторий для тренировок на реальном API.

Если вы когда-нибудь пытались построить стабильный VPN поверх реального Интернета, то знаете: ключевая проблема не в криптографии и даже не в пропускной способности канала. Проблема — в том, как протокол ведёт себя, когда сеть начинает «качать».

Мы много лет экспериментировали с OpenVPN, WireGuard и разными вариациями UDP-туннелей. В хорошей сети → работают все. В плохой сети → перестают работать почти все. Поэтому когда в экосистеме QUIC появился MASQUE, мы решили проверить: а можно ли собрать VPN, который действительно переносит нестабильные условия?

Оказалось, что можно.

Всем привет, меня зовут Рома, я работаю во ВкусВилле, руковожу портфелем ИИ-проектов. Пишу про продукты и управление проектами у себя на канале: https://t.me/gde\_value. Сегодня расскажу, как спор между командами привел нас к пересмотру методов планирования рабочей недели. 

Я не сторонник лозунга про «баланс работы и жизни» в его карикатурном виде: по расписанию в шесть выключить ноутбук, не читать чаты по выходным и обязательно уходить в цифровые детоксы каждую неделю. Мне нравится работать в субботу, когда меньше сообщений и срочности, меня не раздражают сообщения вечером или ночью, если они важные и двигают проекты вперед. Мне интересны люди, которые горят задачами сильнее, чем должностной инструкцией, а с ребятами, которые ставят себе расписание рабочих часов в телеграме, как-то не получается найти общий язык.

Недавно обсуждал это с тимлидом из Ozon. Мы крутились вокруг темы эффективного количества рабочих часов, и ближе к концу он вкинул фразу: «Ну, сорокачасовая неделя ведь не зря придумана; наверное, кто-то исследовал и доказал, что так эффективнее всего». Эта фраза зацепила. Она звучит как успокаивающий миф, как будто есть универсальная «магическая» цифра, и если не выходить за её пределы, то и продуктивность, и здоровье в порядке. Но внутренне я вижу другое: одни люди успевают сокрушительный объём за те же часы, в которых другие тонут в бесконечных переключениях и «шуме».

ИТ-отдел работает как часы: заявки обрабатываются за 2 часа, доступность услуг выше 99%, пользователи довольны. Но каждый месяц финансовый директор спрашивает, почему ИТ-бюджет растёт быстрее бизнеса.

ITSM-система помогла навести порядок в процессах, но не дала ответа на главный вопрос: сколько на самом деле стоит порядок и можно ли тратить меньше без потери качества?

Меня зовут Евгения Асоскова, я владелец продукта SimpleOne ITAM. Давайте поговорим о том, почему компаниям с внедрённой ITSM-системой целесообразно автоматизировать управление ИТ-активами и как это усилит возможности бизнеса.

Это началось со статьи «Алгебраические типы данных на самом деле не такие страшные». Мы знаем о типах‑суммах и типах‑произведениях. Но задумывались ли вы когда‑нибудь о том, откуда они получили такие имена, и как вообще были открыты они и их свойства? Я провел последнюю неделю в кроличьей норе истории, и я просто обязан поделиться тем, что я нашёл.

В первой части мы рассмотрели ключевые проблемы логического рассуждения в LLM и показали, в чём именно модели ошибаются.

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

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

В первой части мы рассмотрели ключевые проблемы логического рассуждения в LLM и показали, в чём именно модели ошибаются.

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

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

Как-то раз мы со студентами-переводчиками по ИТ задались вопросом:

А реально ли LLM «думает»? Или она просто, подобно школьнику, подгоняет объяснения под ответ в конце учебника, не имея ни малейшего понятия о том, правилен ли этот ответ или логичны ли ее рассуждения?

Поиски ответов на этот вопрос привели нас к статье-исследованию "Empowering LLMs with Logical Reasoning: A Comprehensive Survey", адаптированный перевод которой мы и предоставляем вашему вниманию.

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

Как часто, используя прокси для решения задач, вы задумывались о правильности выбора типа прокси? Как говориться, а туда ли я иду? Правильные ли со мной попутчики? Если вы не специалист, хотя бы среднего уровня, уверен - вы ответите: "Да, вообще никогда не задумывался, просто вбиваю "купить прокси" и беру самый дешевый вид". Вы не одиноки - так делают 80% пользователей. Самые дешевые - это как раз серверные прокси, использовать которые нужно с умом, чтобы не навредить проекту, над которым работаете. Давайте разбираться, что это за зверь и почему он может быть опасен?

Про OPC UA слышали мы все, кто хоть раз работал со SCADA системами, АСУ ТП или просто в студенческие годы пытался состыковать оборудование и программы верхнего уровня.

Обещают независимый, безопасный, масштабируемый, al inclusive стандарт для промышленного Интернета вещей. Но как это работает в реальных условиях? Что происходит, когда ты ставишь OPC UA-сервер не в демо-лаборатории, а в реальных условиях на производстве, где есть полный набор динозавров из 90х, 00х и современные монстры.  И мы хотим, чтобы работало, не тормозило и все вместе.

В этой статье я попробую рассказать, как мы внедряли OPC UA в нескольких проектах, на практике, в реальных условиях со всеми плюсами и минусами.

Привет, Хабр! Меня зовут Павел Иванов, я работаю в AWS и последнее время выступаю ментором для наших стажёров и новичков.

– «А что пушить?» – «Всё по задаче». – «И тесты тоже?»

Этот короткий диалог когда-то ввёл меня в ступор на несколько секунд. После него я стал замечать: чем опытнее становишься, тем сложнее вспомнить, каково это – не знать тех вещей, которые со временем стали чем-то привычным и естественным. Для ментора это базовые рабочие рефлексы, а для стажёра – тайные знания, которыми никто не поделился. В итоге оба попадают в ловушку взаимного непонимания: один считает своё объяснение исчерпывающим, упуская десяток «очевидных» для него деталей и нюансов, а другой молча закапывается в проблему и, начав двигаться в неверном направлении, теряет ценное время.

В этой статье я собрал свой список таких навыков, и поделил их на две группы: неочевидные пробелы – слепые зоны для нас, менторов; и очевидные пробелы – то, чему можно и нужно научить новичка прямо сейчас, не дожидаясь, пока «само придёт с опытом».

Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.

Давайте разберем ППРФ № 1300 на молекулы, и разберемся, наконец, что-же там написано. Ниже таблица, в которой разобраны некоторые пункты данного постановления по-отдельности.

Сначала давайте определимся с терминами.

Через весь текст ППРФ речь идет про некое действие (процесс), который называется «передача», и осуществляется над объектом называемом «Информация об инициаторе телефонного вызова» это ни что иное, как «маркировка из 32 символов».

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

5. В целях передачи информации об инициаторе телефонного вызова на пользовательское оборудование (оконечное оборудование) оператор-инициатор предоставляет оператору связи, оказывающему услуги подвижной радиотелефонной связи, на основании договора об отображении информации, заключенного между инициатором телефонного вызова и оператором-инициатором, сведения, предусмотренные пунктом 6 настоящих Правил, в случае, если инициатор телефонного вызова самостоятельно или по запросу оператора-инициатора уведомил оператора-инициатора об отсутствии договора об отображении информации, заключенного ранее между инициатором телефонного вызова и оператором связи, оказывающим услуги подвижной радиотелефонной связи.

Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.

Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.

Сразу скажу: Single SPA — не «серебряная пуля» и уж точно не современный тренд фронтенд-разработки. В 2025-м появилось еще больше других подходов, которые решают похожие задачи иначе. Но Single SPA всё ещё актуален там, где есть огромные легаси-системы, которые невозможно переписать с нуля. И вот именно для таких кейсов мой опыт может быть полезен.

Древнее и сакраментальное RTFM преследует нас повсюду. Волей-неволей мы вынуждены постоянно читать инструкции: к технике, приборам, приложениям, системам.

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

В статье расскажу о пяти важных блоках информации, которые обязательно должно содержать руководство пользователя (оно же User Guide).

Привет Хабр! Меня зовут Алексей и я занимаюсь беспроводными технологиями. Сегодня разберем чем повторитель wi-fi сигнала отличается от wi-fi mesh. Многие на практике не различают эти понятия и часто считают что речь идет об одном и том же.

Беспроводные сети стали неотъемлемой частью нашей жизни, но зачастую одного роутера недостаточно для качественного покрытия большого дома или офиса. В поисках решения мы сталкиваемся с двумя основными подходами: WiFi mesh системы и ретрансляторы (repeater). Несмотря на схожую цель — расширение зоны покрытия — эти технологии кардинально отличаются по принципу работы, производительности и применению.