Тост – это маленькое информационное окно, которое присутствует в большинстве приложений, сайтов для ПК и телефонов. Но когда начинаешь вспоминать в каких приложениях видел их в последний раз, на ум приходит разве что яндекс почта и какой-нибудь маркет плейс.
Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье.
Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint. UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД.
Сгенерированные UUIDv7 имеют все преимущества UUID и при этом упорядочены по дате и времени создания. Это ускоряет поиск индексов и записей в БД по ключу в формате UUID, значительно упрощает и ускоряет базы данных и распределенные системы. Неупорядоченность значений UUID прежде сдерживала использование UUID в качестве ключей и вынуждала разработчиков выдумывать собственные форматы идентификаторов или довольствоваться последовательными целыми числами в качестве ключей.
Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем".
Разные участники разработки нового стандарта придерживались различных взглядов, и практически все обсуждавшиеся альтернативные варианты структуры UUIDv7 вошли в стандарт. Поэтому теперь перед разработчиками возникает вопрос, какую из множества возможных спецификаций UUIDv7 реализовывать и применять. Также для массового перехода на UUIDv7 нужна дополнительная функциональность, повышающая привлекательность UUIDv7 для разработчиков и бизнеса.
Предложенная мной ниже спецификация UUIDv7 с дополнительной функциональностью описывает максимально надежный и удобный вариант структуры UUIDv7 для самых сложных и высоконагруженных информационных систем. Функциональность упорядочена по приоритету реализации
В чём принципиальное отличие джуна от мидла, а мидла от сеньора? На какие навыки поднажать, чтобы не задерживаться на одной ступеньке? Эти темы актуальны в ИТ-сообществе всегда.
Мы решили проследить, меняются ли с годами представления айтишников о принципиальных различиях между грейдами разработчиков.
Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».
За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.
Поговорим как раз об этом — о том, что формирует культуру работы с Git: начнём с конвенций именования коммитов и закончим практиками работы в пуллреквесте. В конце статьи я поделюсь полезными ссылками на интерактивные обучалки, шпаргалки и гайды.
Как создать эффективное резюме и сопроводительное письмо для успешного поиска работы в IT сфере?
Обсудим важность правильного форматирования и структурирования резюме, а также на что обращают внимание работодатели. Раскроем советы по написанию сопроводительного письма, обсудим его структуру и способы выделить свои профессиональные навыки.
Привет, Я Бохан Дмитрий — руководитель отдела инновационных проектов компании ПГК Диджитал. Сегодня поговорим про ретроспективу, зачем проводить ретро, а самое главное посмотрим с помощью каких игр, можно сделать ретро ярким и незабываемым.
Зачем проводить ретроспективы с командой?
Ретроспективы служат важным механизмом для команд, чтобы задуматься о своей недавней работе и выявлять области для улучшения. Создавая безопасное пространство для открытого обсуждения, ретроспективы побуждают членов команды свободно делиться своими мыслями, проблемами и идеями. Это способствует культуре прозрачности, доверия и сотрудничества в команде. Кроме того, ретроспективы помогают в следующих направлениях:
1. Непрерывное улучшение: определение того, что прошло хорошо, и что можно было бы сделать лучше, позволяет команде постоянно совершенствовать свои процессы и практики.
2. Вовлечение команды: с участие членов команды в процессе принятия решений дает им новые возможности и увеличивает их чувство владения проектом.
3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.
Инструменты для ретро
Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:
Собственно, сабж.
На это указывает ряд моментов в существующих решениях.
Прежде всего, давайте вспомним, какими важными характеристиками обладает файл?
При разработке приложения, сервиса, системы и тп возникает один из главных вопросов: как мне хранить данные (какую БД выбрать). В связи с тем, что чаще всего в получите ответ “зависит” (it depends), предлагаю рассмотреть несколько стратегий, которые будут работать почти всегда.
В России на разные виды деятельности нужны лицензии. Например, чтобы производить и продавать алкоголь и табачные изделия, требуется разрешение. Это касается и защиты конфиденциальной информации, разрешение на работу с которой выдает Федеральная служба по техническому и экспортному контролю (ФСТЭК России).
В этой статье не будет захватывающих кейсов из практики наших SRE-инженеров. Мы погрузимся в бюрократический мир, с которым столкнулись при получении лицензий ФСТЭК России. Мы расскажем, лицензии каких видов бывают и как определить, какие из них необходимы. Также пройдёмся по основным требованиям к получению лицензий и рассмотрим, как мы приводили компанию в соответствие с ними и с какими проблемами столкнулись.
Открываю исходники очередного enterprise-проекта: о да-а-а, вот они, старые знакомые, лучшие друзья разработчика — first name и last name.
Каждый из нас проходил собеседования. В разных компаниях процессы трудоустройства могут сильно отличаться друг от друга. Например, в ряде случаев вас ожидает часовой прогон по теории Frontend'a, а где-то вы столкнетесь с кучей этапов проверок: алгоритмы, теория, софт-часть и т.д. За свою 4-летнюю карьеру Frontend-разработчика я собрал конструктор самого худшего собеседование по-моему мнению.
P.S. Далее вы столкнетесь с субъективным мнением автора, которое может не соответствовать вашим ожиданиям
[[indeterminate]] и уменьшение количества Undefined Behavior,=delete;,...[42],assert(...),
Привет, Хабр! Меня зовут Олег Бондарь, я архитектор решений в CDEK. В этой статье расскажу о стандартах — сводах правил и требований, которые позволяют всем участникам процесса быть в общем контексте, действовать единообразно и совершать меньше ошибок. Кроме того делают взаимодействие между людьми и системами немного проще.
Статья будет полезна менеджерам проектов, разработчикам, тестировщикам, аналитикам и другим IT‑специалистам. Поговорим о способах выработки и применении стандартов, их влиянии на проектирование, разработку, тестирование и стабильность системы в целом. Для примера возьмем ERP CDEK, которая ежедневно обеспечивает работу десятков тысяч пользователей, нескольких сотен тысяч клиентов и позволяет нам обрабатывать до полумиллиона заказов в день.
Часто слышим «это целый процесс!», «это настоящий проект!» или смесь типа: Наш «проект - это целый процесс, который начинается с создания уникальной идеи».
Однако, отличие процесса от проекта – простое, проект это один из видов процесса, поэтому противопоставлять их некорректно. А вот с процессным подходом все очень сложно и запутано, поэтому требует отдельного исследования. В целом для процесса, процессного подхода и самого ВРМ нужна онтологизация, концептуализация «управления бизнес-процессами».
Если мы хотим управлять бизнес-процессами (Business Process Management) или проектами, то нужно понять, а чем таким управлять то мы собрались.
«Цифровизация» и «цифровая трансформация» настолько плотно вошли в новостную повестку, что кажется вот-вот побьют рекорды нано-технологий образца 2010-х, когда о них говорили буквально все. Но если все с приставкой нано- так и осталось частью исключительно научно-технологического мира и рекламных кампаний, то вот цифровизация не просто изменила нашу повседневную жизнь, но и повлияла на то, как, где и как мы потребляем информацию.
TL;DR В статье рассказывается о том, как мне удалось перевести чтение лент в ВКонтакте**, Telegram, Facebook*, Instagram**, Reddit и почтовых рассылок в единый сервис InoReader. Причем почти без написания своих велосипедов.
Привет! Меня зовут Максим Коровенков, я DevSecOps Lead в СберМаркете.
Хочу рассказать о том, как мы строим developer-центричный DevSecOps. Мы набили по ходу этого «строительства» уже достаточное количество шишек, поэтому, дабы поберечь вас, делюсь обретенным опытом.
Статья будет полезна тем, кто только начинает строить DevSecOps-процессы в компании, а также тем, кто уже начал, но столкнулся с проблемами роста (рост числа микросервисов, команд разработки, экспоненциальный рост нагрузки, нехватка кадров и т.д.). Поехали!
Седьмая версия UUID (Universally Unique Identifier Version 7, UUID Version 7, UUIDv7) является модифицированной и стандартизованной версией ULID. Проект стандарта (далее стандарт) находится в ожидании окончательной проверки редактором. Но уже имеется большое количество реализаций UUIDv7, применяемых в действующих информационных системах. В интернете доступно большое количество информации по ключевому слову UUIDv7.
Онтологический инжиниринг в области Управления бизнес-процессами (BPM). Семантический BPM (Business Process Management), впрочем, как и семантический ЕА (Enterprise Architecture), – это заимствование концепций (подходов к описанию и онтологизации) \ инструментов Linked Data к указанным направлениям (формализация процессов и архитектур предприятий).
«Красная нить»: когда мы формализуем процессы - мы говорим об одном и том же, но на разных языках (нотациях), поэтому стандартизация Языка семантики, онтологических концептов BPM (EA) – важная, но еще недостаточно популяризированная составляющая развития BPM (следующий этап, ВРМ 3.0). Отделение («мух от котлет») семантики от синтаксиса позволит «рафинировать» понятийный (смысловой) анализ бизнес-процессов и при их аналитике оперировать базовыми (семантическими) концептами (образами).
В Semantic BPM, как и в Semantic Web (семантическая паутина), смысл представленного процесса \ архитектуры понятен не только человеку, но и машинам и они могут его читать и обрабатывать. Эти смыслы, обычно передаваемые «человек – человек» на языке синтаксиса / графической грамматики через нотации VAD, EPC, BPMN, UML (плюс еще несколько десятков подобных вариантов \ форматов «обертывания», включая Дракон), исходно формализуются на языке семантики (стек Linked Data или аналогичный) и уже потом упаковываются в схемы с конкретной нотацией («пишутся» на языке какой-либо нотации). Для единого понимания смысловой составляющей схем применяется общая ВРМ-онтология, толковый словарь ВРМ.
