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

Всем привет, меня зовут Рома, я работаю во ВкусВилле, руковожу портфелем ИИ-проектов. Пишу про продукты и управление проектами у себя на канале: 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). Несмотря на схожую цель — расширение зоны покрытия — эти технологии кардинально отличаются по принципу работы, производительности и применению.

Сколько раз уже писано-переписано о том, что современные печатные книги на компьютерную тематику — это на редкость некачественный товар. И всё равно каждый раз я не перестаю удивляться, как же их создатели не стыдятся выпускать, да ещё и продавать за деньги такой редкостный треш.

И дело даже не в кривом переводе. Мы уже давно научились догадываться, что именно «хотел сказать автор» на языке оригинала. Этот этап повсеместного падения качества книг уже пройден. Теперь издательства нацелились на новые антирекорды — соревнуются, кто кого переплюнет по количеству фактических ошибок в своих творениях. Например, по ужасающим косякам в исходных кодах примеров программ. Каждый раз хочется воскликнуть: «Ребята, вы сами-то хоть один раз перечитали своё творение?!»

Во всём виноваты маркетологи, естественно! Но на самом деле нет: я бы сказал «Раньше надо было думать!», да за такое и закэнселлить на Хабре могут.

С проблемой терминологии сталкивается каждый технический писатель. Многие ИТ-термины заимствованы из английского языка и имеют несколько вариантов перевода, или не переводятся вовсе. Для создания терминологии необходимо проанализировать существующие термины и их использование, выбрать единый стандарт написания и сделать термины понятными для всех членов команды.

Мы — команда документирования платформы Platform V в СберТехе: Лидия Ковач, middle технический писатель, Мария Бурханова, senior технический писатель, и Светлана Каюшина, руководитель команды. Хотим рассказать, как мы разработали глоссарий, который повысил качество документации нашей цифровой платформы для построения ИТ‑ландшафта.

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

Продуктовые роли не появились из воздуха. Их не придумали с нуля бородатые дядьки в Долине или выглаженные воротнички из Купертино. Профессии Product/Project Owner/Manager выстраивались на протяжении почти столетия — и всё ради того, чтобы сейчас мы с вами плевались, читая вакансии на хедхантере. Кто главнее: PM или PO? Что должен делать проджект? И что ещё за AI PM и Data PM?

Давайте разбираться. И копнём аж до начала прошлого века.

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

Содержание этого документа интересно и с исторической точки зрения (а как там “деды” воевали программировали), так и в плане уточнения некоторых современных представлений об этом паттерне и программной архитектуре в целом.

Иллюстрации по максимуму сохранены как в оригинале. По ходу есть сноски с подробностями и ассоциации редактора в конце.

СУЩНОСТЬ-МОДЕЛЬ-ВЬЮ¹-РЕДАКТОР

на примере из системы планирования²

Кому: LRG³

От: Тригве Реенскауг⁴

Файл: [IVY]<Reenskaug>SMALL>TERMINOLOGY2.DOC

Дата: 12 мая 1979⁵

Цель данной заметки - исследовать метафоры thing-model-view-editor через последовательный набор примеров. Все примеры взяты из моей системы планирования и иллюстрируют вышеуказанные четыре понятия. Все примеры были реализованы, хотя и не в рамках чистой структуры классов, описанной здесь. Метафоры соответствуют real world-Model-view-Tool, предложенным в заметке о требованиях DynaBook ([Ivy]<Reenskaug>DynaBook.doc).

THING (СУЩНОСТЬ)

ОПИСАНИЕ ТЕРМИНА

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

ПРИМЕР: КРУПНЫЙ ПРОЕКТ

Сущность здесь - это крупный проект. Это может быть проектирование и строительство большого моста, электростанции или морской нефтедобывающей платформы.