Тема проксей всегда рассматривалась (по крайней мере мне попадались именно такие публикации) с точки зрения сложных терминов, которые зачастую не сильно понятны для обывателя, который в этих ваших интернетах не особо силен. И я решил разобраться в вопросе и вот что у меня из этого вышло:
Привет, меня зовут Кирилл, в СИГМЕ я работаю в департаменте решений 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. Так что нам пришлось провести небольшое расследование.
Все начинается с имени, даже в мире IT-технологий и стартапов. Это статья для всех, кто хочет выбрать идеальную доменную зону для IT-проекта и не ограничиваться доменными зонами .RU или .COM. Однако, среди большого количества доменных зон выбрать идеальную может быть настоящим вызовом. Я исследовал больше 800 доменных зон и выбрал 20 подходящих для IT сферы.
Сегодня хотелось бы рассмотреть основной список методологий применимых в тестировании и самый простым языком описать для чего каждая годна.
В том, что управленческая концепция BPM (Business Process Management, управление бизнес-процессами) до сих пор не имеет строгих непротиворечивых основ и долгое время не может «вырасти» в научную \ инженерную дисциплину во многом лежит вина низкого качества терминологии BPM (имеем семантический «зоопарк»). Точной дисциплине нужны единые универсалии, концепты, понятия, категории, таксономии, которые сверены и сведены в единый талмуд под названием Толковый словарь BPM. Эти универсалии (образы, шаблоны) должны быть четко обоснованы (логически выведены, взаимоувязаны) и систематизированы в онтологию в рамках единой непротиворечивой концепции, включающей идей (идеологию), методы (методологию), систему логических рассуждений и математическую основу. К сожалению, в BPM усиливается путаница в понятиях и прогрессирует различное толкование одних и тех же терминов, т.е. сегодня классический BPM не развивается, а скорее деградирует.
Появляются новые BPM инструменты, например, только в 2023 появились отечественные «очередные убийцы BPM-мастодонта Business Studio»: PIX Process Studio и Арахис (не путать с BPMN\ low code \ no code инструментами), но они не только не привносят чего-либо теоретического «свежего», концептуально нового, а зачастую и не содержат теоретических основ (базовых концепций) классического BPM, хотя бы в объеме ARIS четверть вековой давности (конца 90-х).
Появляются новые BPM инструменты, например, только в 2023 появились отечественные «очередные убийцы BPM-мастодонта Business Studio»: PIX Process Studio и Арахис (не путать с BPMN\ low code \ no code инструментами), но они не только не привносят чего-либо теоретического «свежего», концептуально нового, а зачастую и не содержат теоретических основ (базовых концепций) классического BPM, хотя бы в объеме ARIS четверть вековой давности (конца 90-х).
