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

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

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

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

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

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

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

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

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

Изучив наиболее популярные вопросы философии (по версии разных источников), я пришел к выводу, что философскими принято называть такие вопросы, в которых просто недостаточно определены используемые термины.

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

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

Всем привет! Меня зовут Александр Дворянский, я директор по стратегическим коммуникациям компании 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 под кат!

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

Поехали.

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

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

Я работаю в IT консультантом, программистом, продавцом в общей сложности более 18 лет. За эти годы я перепробовал разные методы взаимодействия с клиентами и подходы к составлению технических заданий. И самый лучший вариант по моему мнению, я опишу в этой статье. Сам я давно пользуюсь этим методом составления ТЗ и взаимодействия на первых этапах сотрудничества. И сейчас решил поделиться с вами.

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

Почему так важно правильно начинать? Только одно начало ведет только к одному концу.

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

Согласно диалектике результат, например, внедренная IT-система (важно, не просто реализованная, но внедренная!), это – развернутое начало. 

Как видите, и философия, и жизнь подсказывают одно: начало и результат всегда связаны. И если мы говорим о результате, мы также говорим о начале. При этом начало нам очень и очень важно.

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

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

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

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

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

— Кто за сутки до отправки заказчику во всей инструкции заменил manual на manul?!

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

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

Сегодня мы разберём, какие принципы вложил в парадигму REST её автор и как они могут помочь нам при проектировании систем.

Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.

Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.

Рун не должен резать
Тот, кто в них не смыслит.
В непонятных знаках
Всякий может сбиться.
Десять знаков тайных
Я прочел и знаю...(Сага об Эгиле)

Многие начинающие программисты, уже освоив синтаксис C++, обнаруживают, что нет простого способа, как подключить библиотеку, так и собрать программу для другой ОС, или чего хуже, под другим компьютером с той же ОС. Эта проблема отчасти порождается спорной практикой обучения, когда код учат писать и запускать лишь средствами IDE, таких как Visual Studio, Code::Blocks, и других.
Поначалу такой подход работает, но лишь до первой реальной задачи сделать что-то, что запустится не только на вашей машине. Тут-то новички и сталкиваются с отсутствием стандартной системы сборки и менеджера зависимостей. После осознания этой сложности, большинство студентов, как правило, переходят на другие языки, попутно тиражируя в индустрии миф о том, что C++ де не кроссплатформенный язык, а вот мой Python/Java/C# - да.
Между тем нас окружает множество замечательных кроссплатформенных программ написанных на C++. Если вы обучаетесь C++ и хотите понять как создавать такое ПО, то эта статья для вас.