Люди знакомые с 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. В статье поговорим о его возможностях, преимуществах и альтернативных решениях.
Его разработала рабочая группа, в состав которой вошли крупные производители телекоммуникационного оборудования. В целом ИТ-сообщество возлагает на стандарт большие надежды, но есть нюансы. Обсудим, что к чему.
Сейчас многие кандидаты приходят с запросом на позиции с возможностью релокации или на трудоустройство в иностранные компании и зарплату в валюте.
Но, прежде чем рассылать резюме и отклики на подобные вакансии важно привести свое СV в принятый в Европе и Америке вид.
Мы серьёзно подходим к вопросам информационной безопасности наших продуктов: бережно относимся к пользовательским данным и разрабатываем сервисы с учётом требований информационной безопасности (ИБ) и публичных стандартов по разработке безопасных приложений. К сожалению, при этом всё равно могут встречаться уязвимости, создающие риски безопасности. Этого не нужно бояться, а лучше использовать эти знания для улучшения существующих контролей безопасности и построения новых. Для этого необходим видимый, эффективный и измеряемый процесс управления уязвимостями, который мы смогли построить в Ozon, и теперь хотим поделиться опытом, советами и граблями, на которые лучше не наступать.
Полным руководством о том, что такое каскадные слои, какой у них синтаксис, зачем они могут понадобиться и как поддерживаются браузерами делимся к старту курса по Fullstack-разработке на Python.
Сегодня все чаще малый и средний бизнес отдает некоторые работы на аутсорсинг, это может быть клининг, бухгалтерия, поиск и найм необходимого кандидата или реализация работ для заказчика, которые компании выгоднее отдать на аутсорсинг чем выполнять самостоятельно. Причин в общем то много, порой на аутсорсинг отдают целые бизнес-процессы - например продажи.
Чаще всего в таких случаях мы говорим о достаточно простых и понятных процессах, в которых не нужны высококвалифицированные специалисты. Это действительно снижает затраты и дает возможность компаниям нарастить свои обороты. Тем не менее, такой тип работы с аутсорсингом больше похож на “крутить педали сильнее и быстрее” или “купить 2 велосипеда вместо одного” вместо того, чтобы пересесть в автомобиль и двигаться вперед в совершенно ином темпе.
Программисты читают код намного чаще, чем пишут его, поэтому важно писать понятный, последовательный, однозначный код. Автор книги С++17 in detail написал о способах избегать путаницы. Делимся его материалом к старту курса по разработке на С++.
«Заставь дурака Богу молиться — он лоб разобьёт»
Здравствуйте! Хочу поделиться накипевшим - головной болью интеграции с API сторонних приложений. В этой статье - c авторизацией для API достаточно популярной amoCRM, без кода и лишних деталей.
Бизнес-процесс – это алгоритм действия, последовательность действий сотрудников при создании товаров, работ, услуг. Многие компании заключают договора с гражданами на оказание разного вида работ или услуг. Берут в сети готовую болванку и заключают договор, который не учитывает специфику данного вида договора. Рассмотрим простой бизнес-процесс заключения договора оказания услуг с физическим лицом, который является исполнителем, с применением нотации BPMN.
DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.
Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.
В этой статье хотим рассказать про протокол кроссчейн совместимости (CCIP) для децентрализованного обмена сообщениями/событиями и перемещения токенов между блокчейнами.
Рост многочисленных независимых блокчейн-экосистем с различной спецификой и географическими нишами привел к тому, что мир становится все более мультиблокчейновым. Возможность беспрепятственно использовать преимущества каждого из этих блокчейнов и их уникальные активы в рамках одного приложения вызвала бы мощную волну разработки новых кросс-чейн смарт-контрактов - не хуже, чем распространение DeFi, NFT и он-чейн игровых экономик, когда появились децентрализованные сервисы оракулов для получения реальных данных и безопасных вычислений вне блокчейна.
Чтобы удовлетворить растущий спрос экосистемы на кросс-чейн решения, мы рады рассказать о предстоящем запуске Cross-Chain Interoperability Protocol (CCIP) - нового стандарта с открытым исходным кодом для кросс-чейн совместимости. Цель CCIP - установить универсальную связь между сотнями сетей блокчейн, как частных, так и публичных, разблокировать изолированные токены и расширить возможности кросс-чейн приложений для всех экосистем на блокчейне.
Гибридные смарт-контракты объединяют код, запущенный на блокчейн (on-chain), с данными и вычислениями за пределами блокчейн (off-chain), предоставляемыми децентрализованными сетями оракулов. Гибридные смарт-контракты позволяют использовать передовые формы экономической и социальной кооперации, которые обладают свойствами блокчейн, обеспечивающими защиту от взлома и неизменяемость, но при этом используют безопасные off-chain сервисы оракулов для достижения новых возможностей, таких как масштабируемость, конфиденциальность, справедливость порядка транзакций и связь с любым реальным источником внешних данных или внешней системой.
В статье мы определим роль, которую играют гибридные смарт-контракты в развивающихся моделях доверия на основе блокчейна, и продемонстрируем множество децентрализованных сервисов, которые предоставляют оракулы для расширения их возможностей. Затем мы объясним, как это в конечном итоге открывает новое поколение гибридных приложений на основе блокчейна, которые обладают всеми свойствами, необходимыми в будущем для улучшения способов сотрудничества в обществе практически во всех основных отраслях.
Ранее мы поделились подборкой настольных справочников для сисадминов. На этот раз — рассказывем о тематических материалах из нашего корп. блога.
Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать
В этой статье мы разберем признаки слабых разработчиков, которые можно обнаружить на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Важное уточнение — все описанное в нашей статье не стоит рассматривать как чек-лист формальных правил. Это скорее некоторые закономерности, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но, если в одном человеке сочетаются несколько из них, то вероятность этого сильно увеличивается.
std::expected — новый механизм сообщения об ошибках без использования исключений и без недостатков кодов возврата.std::ranges::to — результаты работы алгоритмов можно легко превратить в контейнер.std::views::join_with — добавление разделителя между элементами.
facebook.com, демо