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

Привет!

Меня зовут Коля, и я системный аналитик.

В большинстве источников моделирование данных (в контексте создания приложений) рассматривается как последовательное создание трёх моделей данных - концептуальной, логической и физический. Такого порядка придерживаются, например, DMBOK2 и BABOK, а также многочисленные статьи в сети Интернет:

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

Перед тем, как запускать свой сайт или приложение, в котором вы собираетесь использовать cookies или иные идентификаторы (local storage, AAID, UDID и т.д.) устройств/сессии пользователя, необходимо выполнить требования законодательства о персональных данных.

Зачем? Во-первых, вы выстраиваете открытые и честные отношения со своими пользователями. Во-вторых, вы будете готовы к проверкам регуляторов. В-третьих, вы сможете избежать штрафов, которые могут достигать 4% годового оборота своей компании.

Давайте разберемся, как онлайн-идентификаторы связаны с защитой персональных данных.

Согласно ФЗ «О персональных данных» и GDPR куки-файлы и иные идентификаторы пользователя относятся к персональным данным, поскольку позволяют теоретически определить конкретного субъекта или выделить его среди других лиц.

Наиболее известным делом по рассматриваемой нами теме стал судебный спор Vidal-Hall v. Google (2015). Используя сookieы-файлы, компания Google осуществляла сбор информации об интернет-трафике пользователей. Заявители, не будучи осведомлены о незаконных действиях ответчика, настаивали на привлечении последнего к ответственности за нарушение порядка использования сookies – персональных данных, которые позволяют вычислить пользователей.

Суд занял позицию истцов и положительно ответил на вопрос об отнесении Cookie-файлов к персональным данным, так как они, «не называя прямо субъекта … позволяют выделить его из всей массы пользователей, следовательно, отвечают критерию идентификации» [1].

Следовательно, в отношении cookies и прочих идентификаторов необходимо соблюдать требования законодательства.

До того, как Сатоши Накамото применил блокчейн в системе биткоина, было предпринято огромное количество попыток создать децентрализованную платежную систему. Но все они были безуспешны, так как разработчикам не удавалось создать такие условия, которые бы позволили достичь соглашения между всеми участниками сети и обеспечить ее работоспособность. Это и называется консенсусом в сети блокчейн. Он достигается тогда, когда все участники сети согласны относительно валидности транзакций и все реестры – точная копия друг друга.

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

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

Рыская по интернетам, зашел на страницу про URI и спустя несколько часов осознал, как мало я знал об этом монстре. Признаюсь, до этого я думал, что URI это либо URL, либо URN. Но это не так! Есть и другие варианты идентификации ресурса в сети.

Что такое краудсорсинг?

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

Мой личный небольшой опрос коллег показывает, что далеко не все вообще видят разницу.

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