IT-стандарты *

В 2006 году Яндекс и Google приехали в Петербург в Borland, который сокращал команду. Обе компании одновременно открывали в Петербурге свои офисы на его базе. Тогда к нам пришли замечательные ребята. Мы много общались, но больше всего запомнились слова Толи Орлова. Он сказал, что рост Яндекса на тот момент ограничивает только количество лидов, которые бы могли развивать продукты. Что роли техлида и тимлида очень существенны, и часто рост компании зависит только от наличия сильных лидеров. Тогда мне и захотелось узнать, как им стать.

Меня зовут Владимир Горовой. Я был тимлидом, потом перешёл в менеджмент, руководил созданием разных сервисов, в том числе, Яндекс.Путешествий. Сейчас работаю в Яндекс.Вертикалях. У меня есть разный опыт: менеджерский, разработческий и тимлидский. Всем этим и хочу с вами поделиться.

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

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

Деловой мир все больше переходит в «стадию» Digital, но происходит это крайне неравномерно: пока кто-то всё ещё пытается окончательно укротить базовые подходы в  автоматизации и построению «цифровых теней» (грубо – обвешивание датчиками всего, до чего дотянутся руки и бюджет), другие учатся адаптироваться к новой цифровой реальности и начинают штурмовать сущность с названием «цифровые двойники» (грубо – изначальное моделирование объекта «в цифре» и только потом реализация его в нашем аналоговом мире). Здесь я хочу раскрыть два простых, но крайне неочевидных тезиса: почему автоматизация в большинстве случаев не приносит денег,  и почему лишь переосмысление в сторону «цифры» и сбор правильного цифрового портфеля способны поставить бизнес на ноги в кризис.

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

_{От автора перевода: Написанный далее текст может не совпадать с мнением автора перевода. Все высказывания идут от лица оригинального автора, просьба воздержаться от неоправданных минусов. Оригинальная статья выпущена в 2014 году, поэтому некоторые фрагменты кода могут быть устаревшими или "нежелаемыми".}

Содержание статьи:

В статье приведены доводы, которые ставят под вопрос правильность присутствия ORM в рамках ООП.

Привет! Проблема управления безопасностью зависимостей — supply chain security — в настоящее время как никогда актуальна. В качестве примера можно привести историю компании SolarWinds: исходный код разрабатываемой ею утилиты был скомпрометирован и среди клиентов компании распространилось вредоносное ПО. Также возникла тенденция по внедрению деструктивного кода разработчиками open-source проектов, широко используемых коммерческими компаниями.

Материал содержит применяемые в отрыве от современной политики именования и отсылки, а так же длинные слова, которые огорчают Винни-Пуха.

Cyberpunk 2077. Был перенесён больше, чем на полгода.
Atomic Heart. Как ждали бета-версию в конце 2019 года, так и ждём.
Escape from Tarkov. Бета-тестирование длится уже почти пять лет.
Vampire: The Masquerade – Bloodlines 2. Перенесён на бооооольше, чем два года, сильно больше...
Bayonetta 3. За прошедшее с момента первого анонса время уже можно было выпустить игру, спин-офф, тизер сиквела и начать снимать сериал для Netflix - но неееет, всё ещё ждём...
И прочие, и прочие, и прочие.

Ладно, "Побег из Таркова" и Atomic Heart: амбиции, нехватка опыта, технологическая болтанка. Допустим.
Но остальные игры - их как минимум продьюсировали видные деятели в этой сфере. Это не первое их родео в мир ААА-проектов. Что ж так не повезло то им?

А если сместить фокус с геймдева и окинуть взглядом IT в целом?
Куда ни глянь - "не попали в дедлайн", "кранч", "лучше MVP в проде, чем срыв сроков в ххх", etc, etc...

Вдобавок, две недавних публикации (о проектировании в IT в целом и о YOLO-разработке в геймдеве) напомнили мне в очередной раз о потенциальной причине этого феномена.
И имя ему - "феномен самораздувающихся сроков".

Все больше разработчиков модифицируют лицензии с целью защитить свои открытые продукты от перепродажи сторонними компаниями. Такая практика разделила профессиональное сообщество на два лагеря. Мы в T1 Cloud решили обсудить ситуацию и разные точки зрения по этому вопросу.

Когда начинаешь изучать смарт карты, то все выглядит достаточно понятно и логично: команды APDU несложны и описаны в ISO 7816-4, интерфейс winscard описан в MSDN. В глубины PCSC погружаться особо и не приходится. Первые программы можно написать довольно быстро. Непонятные особенности вылезают чуть позже, и выясняется, что известные два протокола T=0 и T=1 на самом деле совсем разные протоколы, и они просто похожи друг на друга. Поначалу возникает соблазн работать с ними одинаково, а это может доставить много хлопот вплоть до сбоя коммуникации в самый неожиданный момент.

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

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

Действительно, по общему правилу, исключительные права на произведения принадлежат работодателю, если иное не установлено в договоре (к примеру в трудовом договоре), но только если оно разработано работником (автором) в пределах его трудовых обязанностей. Однако, если работник вдруг обратится в суд, посчитав что исключительное право на произведение принадлежит ему, т.к. создано оно вне рамок исполнения им своих трудовых функций, сможете ли вы доказать суду документально, что этот работник создал произведение именно в рамках своих трудовых обязанностей? Если нет, то суд с большой долей вероятности может принять решение в сторону работника, тем более не следует забывать что работник в данном случае является "слабой стороной", а значит спрос с работодателя в суде будет максимальным. Исходя из личного профессионального опыта могу с уверенностью сказать что многие работодатели не уделяют кадровым документам надлежащего внимания и зачастую даже название должности не соответствует тому, чем фактически занимается работник. Ни в трудовом договоре, ни еще где-либо отсутствуют функциональные обязанности или прописаны так абстрактно, что судью становится очень сложно убедить в том, что имелось ввиду в таких «рукописях».

Здравствуй, уважаемый читатель, и спасибо за то, что решил ознакомиться (надеюсь, полностью:)) с моим постом.

Являюсь обычным ИТ менеджером среднего звена, специализация – выстраивание работы ИТ структур: в основном, структур ИТ сопровождения (Системные администраторы (серверная часть, телеком, операционные), Администраторы баз данных (разные конфигурационные единицы), тестировщики, разработчики по инцидентам. В свое время управлял отделом разработки, архитекторами...

На неделе один из участников Hacker News запустил тематический тред с целью узнать, как «связать» компьютер, колонки и другую акустику в единую звуковую систему.

Мы решили рассмотреть несколько стандартов, которые используют музыканты в студиях, а также open source решения, доступные для развертки любому аудиоману.

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

Сегодня поговорим о том, как приручить непосредственно исходные коды программ, как они архитектурно представляются. Расскажу про идеи, которые мы используем для построения прозрачной и понятной модели, чтобы ее было легко развивать вместе с заказчиком. Эти подходы касаются и архитектуры, и хранения исходного кода, и вообще в целом вопросов разработки. Также расскажу про практические сложности. Формат статьи не позволяет включить огромное количество кейсов, поэтому приведу только два примера.

Я хотел бы кратко рассказать о таких форматах данных, распространенных в ИТ-индустрии, в том числе в области инфраструктур открытых ключей (ИОК), смарт-картах, включая документы нового поколения на базе смарт-карт, в мобильной связи. Хотя рассматриваемые форматы и связаны с ASN.1, но некоторые из них ушли далеко за пределы этой области. О некоторых из них многие знают, но не все знают настолько, чтобы, допустим, уметь отличать BER от DER, а некоторые варианты типа PER вообще являются экзотикой.

Глубоко в тему погружаться не буду. Просто познакомлю с главными особенностями, чтобы понимать, что это такое и с чем это едят. Досконально и в полном объеме всё это описано в соответствующих стандартах ITU-T X.690 и ISO 7816.

Одна из моих мотивирующих задач — это уложить тему в своей голове по полочкам.

Правила абстрактной нотации (ASN.1) используются, когда надо специфицировать формат некой структуры данных. Сами правила описаны в стандартах ITU-T X.680–X.683. Пожалуй, что наиболее распространенный вариант применения — это форматы сертификатов X.509 и всего, что имеет к ним отношение. Пример текстовой нотации может выглядеть как-то так:

Люди знакомые с ITSM/ITIL знают о том, что, описывая любую услугу, мы можем выделить характеристики «полезности» (utility) и «гарантии» (warranty). Также нередко обсуждаются характеристики, описывающие опыт (experience: user experience, UX и customer experience, CX).
Как соотносятся эти понятия? Можем ли мы говорить о том, что experience — это ещё одна, третья группа характеристик? Что вообще даёт это понятие, и почему utility и warranty может быть недостаточно?

Привет! Меня зовут Александра, я инженер по информационной безопасности в Delivery Club. Мы используем Go в качестве основного языка для разработки Web-API и представляем вашему вниманию краткое руководство по быстрой проверке сервиса на соответствие базовым требованиям безопасности. Представленную ниже информацию можно адаптировать под проекты, написанные и на других языках.

31 марта 2022 года на сайте IETF был официально размещен текст рабочего документа (копия 1, копия 2) New UUID Formats (далее – стандарт), который должен формально обновить, а фактически заменить давно устаревший и изначально ущербный RFC 4122.

В долгих и жарких спорах удалось выработать стандарт высокого качества. Можно надеяться, что этот стандарт заменит многочисленные «самоделки» энтузиастов и отдельных компаний: ULID, KSUID, CUID и т.д., а в СУБД будут встроены генераторы UUID новых форматов, предназначенных для ключей высоконагруженных систем.

Международная команда инженеров разработала новый протокол — Tachyon. В статье поговорим о его возможностях, преимуществах и альтернативных решениях.

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