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

А вы всегда пьёте коньяк на завтрак или только по выходным?

Привет всем, я – Соня, IT HRD. Начинала как QA инженер. Люблю tech и инженеров за то, что помимо работы тут всегда узнаёшь разные крутые понятия и термины полезные не только для работы но и для жизни. За 20 лет работы накопилось много продуктово-инженерных жаргонизмов, пратик, законов и принципов, которые я была бы рада узнать пораньше. Можно прям в старших классах школы вместо ОБЖ.Ниже — мои любимые. Добавляйте в комменты свои.

1. Ложная дихотомия
Ложная дилемма, чёрно-белое мышление — это логическая ошибка и манипулятивная тактика, при которой из множества вариантов предлагаются только два (обычно крайних), игнорируя промежуточные или иные альтернативы. Этот приём сужает выбор, вынуждая принять одну сторону, часто ложно представляя одну из альтернатив как приемлемую, а другую — как неприемлемую. Мир не чёрно-белый. Наш коньяк с этой полки.

2. Бритва Оккама
Методологический принцип: при наличии нескольких объяснений одного и того же явления нужно выбирать самое простое. Не следует множить сущности, добавлять лишние предположения без необходимости. Не надо усложнять. Оккам, кстати, — английский монах-философ. Считается одним из отцов современной эпистемологии и современной философии в целом, а также одним из величайших логиков всех времён.

3. Игра с ненулевой суммой
Ситуация в теории игр, где выигрыш одного участника не обязательно означает равный по модулю проигрыш другого. Сумма результатов (выигрышей и проигрышей) может быть больше или меньше нуля, что позволяет сторонам получить взаимную выгоду (win-win) или совместно проиграть. В играх с нулевой суммой выигрыш одного игрока всегда равен проигрышу другого. Шахматы или шашки: если один победил (+1), второй обязательно проиграл (-1). Сумма: 1 + (-1) = 0.

Позиция CTO (Chief Technology Officer, технический директор) появилась не вместе с интернетом, а задолго до этого – еще в эпоху больших корпораций и лабораторий. Ещё в 1950-х годах в США и Великобритании крупные компании создавали удалённые R&D‑центры и поняли, что там нужны не просто учёные, а техподкованные руководители, эдакие техножрецы, которые могли бы объединять науку и бизнес . К концу 1980-х технологии стали настолько важны, что «технических директоров» начали официально назначать в крупных фирмах, ориентируя их уже не только на внутреннюю лабораторию, а на развитие бизнеса в целом . Веяние новой роли быстро перекинулось и в CIS (после 2000-х главным образом), когда ИТ‑компании и стартапы стали брать на себя модели западных корпораций. Так, например, в Яндексе с основания в 2000 году одним из CTO стал сооснователь Илья Сегалович – из первых сигнальных звоночков, что даже в России формируется такой управленческий пост.

Интересно, что сами исследователи подчеркивали: изначально CTO не был просто «главным инженером». Когда корпорации 1980–90-х годов в США «переводили» директоров R&D в CTO, выяснялось, что их навыки оказываются слишком узкими. Классический научный руководитель не годился в нового тех­директора, потому что задачи CTO кардинально отличаются от задач заведующего лабораторией. Пост CTO сформулировали как задачу перевести технические возможности в стратегические бизнес-решения. Проще говоря, CTO — это уже не просто суперпрограммист с магистром, а гибрид менеджера и технаря, который одновременно понимает код и умеет объяснить его влиянию на маркетинг. Как пишет компания Splunk, CTO — это топ‑менеджер, «балансирующий техническую и бизнес‑стороны, чтобы стимулировать инновации и рост».

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

В этой статье мы рассмотрим основные категории инструментов безопасности приложений: DAST (Dynamic Application Security Testing), SAST (Static Application Security Testing), SCA (Software Composition Analysis) и IAST/RASP (Interactive/Runtime Application Security Protection). Мы разберем их назначение, преимущества и недостатки, а также предоставим список бесплатных инструментов, которые можно интегрировать в вашу инфраструктуру разработки.

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

После небольшого перерыва на связи вновь Татьяна Маркина, ведущий системный аналитик в 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 настоящих Правил, в случае, если инициатор телефонного вызова самостоятельно или по запросу оператора-инициатора уведомил оператора-инициатора об отсутствии договора об отображении информации, заключенного ранее между инициатором телефонного вызова и оператором связи, оказывающим услуги подвижной радиотелефонной связи.