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

В феврале 2022г. РБК опубликовал результаты опроса сервиса SuperJob, согласно которому у 51% опрошенных компаний есть сотрудники, работающие удаленно. В Москве и Санкт-Петербурге этот показатель выше – 68% и 63% соответственно. При чём, чаще всего на дистанционную работу в переводят сотрудников из сферы информационных технологий.

Удаленный режим работы, казалось бы, минимизирует количество самых разных документов и упрощает их содержание. Между тем, во всём, что касается создания результатов интеллектуальной деятельности, и в частности разработки программного обеспечения, это не так. Может меняться их форма, но документы по-прежнему остаются актуальными (и эта актуальность даже возрастает).

Количество лиц, задействованных в разработке, может быть достаточно велико (особенно если речь идет об авторских коллективах, крупных контрактах с длинными «цепочками» заказчиков, подрядчиков, субподрядчиков и т.д.). Поэтому и состав документов может быть разнообразным.

Разберем, зачем и какие именно документы нужны, почему они не заменяются различными системами управления, что предусмотреть и что будет, если их не оформлять?

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

Рекомендации ниже универсальны, как с точки зрения вида правоотношений (гражданско-правовые или трудовые), так и с точки зрения объектов авторского права, хотя и приведены на примере программного обеспечения.

Передо мной книга «Модельное мышление» Скотта Пейджа (издательство «Манн, Иванов и Фербер», Москва, 2020). По словам автора, «В книге рассматривается подход под названием “многомодельное мышление” - использование совокупности моделей для осмысления сложных явлений».

Тема эта не нова. Достаточно привести примеры публикаций популярных англосаксонских авторов Дж. Д. Вильямса (1), Л. Мозеса (2), Д. Химмельблау (3). Есть публикации и отечественных авторов (4). Отметим, что эти вопросы на различных уровнях неоднократно освещались уже 60 и 40 лет назад.

Ниже для читателей блога ЛАНИТ кратко изложены содержащиеся в книге принципы многомодельного подхода и инструменты для создания моделей.

Написано довольно много хороших материалов о свободных лицензиях, в том числе тут, на Habr. Почему стоит прочитать еще и эту статью: 

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

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

NDA (non-disclosure agreement) - это соглашение о неразглашении конфиденциальной информации. Такое соглашение очень часто подписывают с работниками, подрядчиками, партнерами. Это практически классика деловых взаимоотношений. Я думаю, вы тоже хоть раз в жизни подписывали такой документ.

Хорошая новость заключается в том, что почти все NDA как близнецы-братья похожи между собой. Сейчас я расскажу, на что стоит обратить внимание.

В праве есть два понятия, которые звучат похоже, но сильно отличаются. Это исключительное право и исключительная лицензия. Сейчас разберемся, в чем разница на примере ПО. 

Итак, исключительное право - это возможность самому использовать ПО как угодно, а еще разрешать или запрещать его использовать всем другим. 

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

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

Сначала рассмотрим варианты отчуждения исключительного права. 

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

Чтобы передача прав сработала, работодатель должен подготовить и подписать с работником комплект документов:

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

Всем привет! Меня зовут Александр Дворянский, я директор по стратегическим коммуникациям компании Infosecurity. Сегодня я отойду от своих привычных прогнозов развития кибербезопасности на ближайшее будущее, а вместо этого предлагаю вам с юмором пообсуждать наши текущие дела. Итак, сегодня будет небольшое урок английского языка, где я рассмотрю основные умные слова и аббревиатуры, пришедшие к нам с запада, которые мы каждый день используем в нашем бизнесе и в целом в отрасли кибербезопасности.

Во второй части мы рассмотрим слова общего характера на примере так полюбившегося всем нам в последнее время корпоративного Bullshit Bingo.

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

Тем не менее, я осознал: нет такого понятия — чистый код.

Изменив одно местоимение, можно на 90% увеличить показатель кликабельности (CTR) кнопки, которая приведет новых пользователей. Дописав одно предложение, можно увеличить количество оплаченных покупок и снизить нагрузку на саппорт. Поставив одну запятую, можно было бы сохранить 5 миллионов долларов. ОК, третий пример про договоры, но все равно показателен.

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

Исследование Nielsen Norman Group показало, что лаконичный, объективный (без маркетологического хвастовства) текст, который легко читается пользователем, увеличивает юзабилити сайта на 124%. Только текст. UX и навигацию не трогали.

В вашем продукте (сайте, программе, приложении и т.д.) есть английский текст, и вы хотите, чтобы он приносил вам выгоду, а не просто занимал место? Читайте статью дальше. Я расскажу, как писать по-английски нужно, и как не нужно.

Недавно я узнал, что довольно много людей читают статьи на Хабре «как книгу». Думаю, мы все здесь стараемся быть грамотными, уважать читателей.

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

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

Всем привет! Меня зовут Сергей, я занимаюсь процессами в блоке по развитию информационных систем Ростелекома. В зависимости от потребностей ставлю как сквозные процессы, так и процессы на уровне рабочих групп. Но есть то, что объединяет процессы на всех уровнях - это термины и их трактовка. Вот про это я хочу поговорить, добро пожаловать под кат.

Соберем пазл Ops’ов.

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

Раньше, IT отделы представляли собой единые команды, но теперь популярна идея организации команд более эффективно для удовлетворения потребностей компании. Основываясь на этих идеях,  IT группы разделяются по специализациям отделов с четкими ролями и требуемыми результатами, продолжая совместную работу. Часть из популярных идей включают в себя  TechOps, DevOps, и NoOps.

TechOps, DevOps, и NoOps это не примеры технологий или языков программирования. Это модели работы, определяющие как IT команды будут внедрять и выпускать проекты в релиз. Это просто различные подходы к производству, развертке и поддержке продуктов. 

Разберемся в этих идеях.

TechOps

Широкое и зачастую плохо определяемое назначение TechOps специалистов может дать впечатление, что они занимаются вообще всем, что связано с IT. Действительно, TechOps-задачи сильно разнятся от организации к организации, но все они попадают в категорию по предоставлению и обслуживанию существующей технологической инфраструктуры. Это включает такие вещи как сетевая поддержка, управление базами данных, обеспечение и контроль безопасности, аварийное восстановление, оптимизация сети, установка и обновление программного обеспечения и другие задачи поддержки. 

А дело было так - я ловил пескарей пару недель назад я решил начать искать работу.

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

Заголовок статьи не оставляет простора для интриги, в нём, в общем-то, максимально сжато выражена суть нижеследующего повествования - но я всё-таки рискну отнять пару минут вашего времени, расписав более подробно мои соображения на эту тему.

…а также способами обнаружения вредоносных техник в сетевом трафике

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

Одним только переводом решили не ограничиваться. Мы дополнили матрицу экспертизой Positive Technologies о том, как обнаруживать ту или иную технику  с помощью систем анализа трафика (network traffic analysis, NTA), например таких, как PT Network Attack Discovery.  Готовы познакомить вас со своим проектом и рассказать, как устроена наша матрица и чем мы руководствовались при переводе названий тактик и техник. Welcome под кат!

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

Поехали.

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

Вспомним наш любимый мультфильм «Падал прошлогодний снег» с его шикарными крылатыми фразами. Одна из них: «Уж послала, так послала». Вот и система так же — вместо отправки запроса посылает его куда-то далеко. А запросу обидно.

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

Возможно, вы уже слышали слово “легаси” (legacy) от сотрудников технических отделов и, как правило, в негативном ключе. Данным термином обозначают методы, технологии и компьютерные системы или прикладные программы, которые по каким-либо причинам признаны устаревшими. Однако всегда ли такое наследство несет негативный эффект для бизнеса, обязательно ли от него избавляться и как понять, что оно действительно вам мешает?

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

Как их только не называют: техписы, техрайтеры, документаторы... Хорошо, хоть не архивариусы!

Спрос на хорошую, качественную документацию к программам и системам постоянно растёт. При этом сейчас на рынке наблюдается серьёзный дефицит профессиональных технических писателей. Опытные технические писатели сейчас буквально на вес золота. Во всём мире профессия technical writer (или technical author) считается престижной и перспективной. Техническое документирование — это одна из замечательных пограничных областей для тех, кто так и не смог смириться в школе с разделением на гуманитариев и математиков.

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