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

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

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

ИИ безусловно вокруг нас, это ключ к диджитализации мира, Microsoft собрал 10 ключевых терминов ИИ, предлагаю вашему вниманию дословный перевод и инфографику.

Какая еще «инвентаризация»? Это вот та самая инвентаризация, когда пересчитывают стулья в кабинете и наклеивают инвентаризационные номерки? Вы серьезно?! Да, коллеги, именно такая и, конечно, серьезно. Инвентаризация как один из факторов учета материальных и нематериальных активов и инвентаризация как организованный процесс.

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

Привет, меня зовут Кирилл, в СИГМЕ я работаю в департаменте решений SAP. И речь сегодня пойдет о 7 руководящих принципах ITIL, которые я хочу раскрыть на собственных примерах. Эти принципы не новы, но, как бывает с классикой, — к ней хочется возвращаться. Тем более что обозначенные правила позволяют сохранять ясность ума, трезвость отношений с заказчиком и коллегами, а еще являются полезным инструментом для решения повседневных задач как на работе, так и в жизни. Статья подойдет молодым специалистам, которые только начинают разбираться в профессии, остальные могут использовать ее в качестве чек-листа для самопроверки?.

Мы провели опрос и узнали, какие слова, словечки и высказывания раздражают IT-специалистов. Среди ответов есть неожиданные, но лидер вряд ли кого-то удивит. Как к этому всему относиться? Как к профессиональному жаргону, который есть в каждой специальности. Обычного человека скорее всего покоробят профессионализмы юристов и врачей, но для нас всех короткое и ёмкое слово — формулировка короткой и точной мысли. По крайней мере, очень хочется так думать ;-)

Многие хотят поработать с Kali linux. По-прежнему в интернете множество запросов посвящено ей . Она всегда на слуху, когда говорят о взломах и хакерах, а также о совершенных мастерах IT( тех самых, что и микропроцессор запрогают и сеть настроят, и чайник со стиралкой отремонтируют).
Но, насколько оправдано восхищение ей? Так ли она безупречна и необходима? Нужна ли она конкретно вам? В этих вопросах мы и попробуем разобраться.

Наверно, многие из моих читателей как раз закончили квартальный (и/или годовой) цикл планирования, так что сейчас будет подходящее время напомнить, что процесс, которым мы пользуемся как стандартом в технологической отрасли, на самом деле — полная чушь. Разумеется, я имею в виду методологию Objectives and Key Results. Давайте же поговорим об OKR, что это такое и откуда они взялись, а ещё о том, почему это ужасная идея.

Как организовать рабочие процессы, какие инструменты использовать и на какие нюансы обращать внимание для эффективной защиты прав в GameDev-проектах? Рассказываем о конкретных решениях, которые можно использовать на практике

Расскажем в статье о том, как правильно оформить приобретение исключительного права на игру, урегулировать взаимоотношения с разработчиками и авторами элементов игры.

Как оформить процессы?

На каждый результат интеллектуальной деятельности составляется акт, но на практике такой подход приводит к проблемам, поскольку акт вряд ли будет распространять свое действие на каждый элемент игры. При этом у компании могут быть элементы, которые пока не задействованы, но могут пригодиться в будущем. Задача – оставить за компанией не только права на объекты, которые фактически пошли в работу, но и на рабочие материалы (другие недоработанные персонажи, схемы, дизайнерские решения, код) на случай, если они потребуются в дальнейшем.

Как создателю игры приобрести право использования всех составляющих элементов игры, право на игру в целом и избежать юридических рисков? Публикуем подробную инструкцию от GameDev-юристов

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

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

В удивительном мире информационных технологий, где айтишники и клиенты встречаются регулярно, царствует терминологический Хаос! Казалось бы, все говорят на одном языке, но когда речь заходит про «данные для авторизации», клиенты впадают в ступор. Бизнес говорит «учетки», «логины», «доступы» — как правило, подразумевая под этим пары «логин и пароль» для доступов к облачным сервисам. Однако не все новые типы информации подпадают под эти термины. Мы в TeamDo сталкиваемся с таким регулярно, потому стали искать другое емкое определение.

Если вы сеньор и зачастую не можете подобрать нужные слова, когда общаетесь с бизнесом, — заходите под кат! Мы поделимся опытом поиска полезного (хоть и не идеального) термина.

Любой компании, которая стремится сохранить конкурентоспособность на рынке, необходимо создание «золотой записи» (профиля) клиента во внутренних базах. Для этого многие используют системы управления мастер-данными (MDM, master data management), но сталкиваются с рядом проблем, другие – применяют CDP-платформы (Customer Data Platform), которые также имеют свои недостатки. А теперь представьте, если от каждого из решений можно было взять лишь лучшее, оставив за бортом все слабые стороны. Как это сделать – в новой статье CleverData под катом.

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

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

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

Эта статья – ответ на статью «Обращение к издательствам: пожалуйста, не переводите термины».

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

– Какие-такие «узлы» и «фрагменты»? – спросит программист, работающий с MongoDB. – Наверное, ты имел в виду «чанки» и «шарды»?

– Что за «чанки»? – переспросит аналитик, хранящий данные в GreenPlum. – У нас данные делятся на «регионы», которые потом распределяются по «регионсерверам»!

Можно было бы продолжать этот воображаемый спор, но я лучше приведу табличку:

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

Всем привет! Меня зовут Владислав Москалёнок, и я работаю техническим переводчиком и редактором в сфере телекома и IT уже более 20 лет. Сегодня хочу поделиться опытом команды Bercut в цифровизации переводческих процессов. Из статьи вы узнаете, как мы реализовали комплексное решение, где сочетается технология накапливаемой памяти (TM) и нейронного машинного перевода (NMT). Если вы технический переводчик или вам просто интересна тема  локализации ПО —

На днях мы работали над переводом глоссария CNCF и начали спорить о том, как писать словосочетание cloud-native. Раньше мы использовали название с дефисом — такое правило применяется к составным прилагательным в английском языке (пример — well-known actor). «Википедия» в статье «Cloud-native computing» тоже следует этому правилу, с другой стороны, название CNCF расшифровывается уже без дефиса: Cloud Native Computing Foundation. Так что нам пришлось провести небольшое расследование.