CRaC (Coordinated Restore at Checkpoint) — это проект OpenJDK, разработанный Azul для решения проблемы «медленного» запуска виртуальной машины Java в микросервисной среде.

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

В механизме восстановления контрольной точки (checkpoint-restore) нет ничего нового, и большинство из вас уже знают и используют его ежедневно. 

Если вы работаете на ноутбуке и закрываете крышку, операционная система обнаруживает это и сохраняет текущее состояние на диск. Как только вы снова открываете крышку, операционная система восстанавливает сохраненное состояние с диска.
CRaC предоставляет тот же механизм, но для JVM и вашего запущенного приложения.

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

После этого вы сможете восстанавливать состояние JVM, включая состояние вашего приложения, из этой сохраненной контрольной точки так часто, как вам захочется.

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

Решил сэкономить вам 2 года, и разобрать фейлы, которые мы допустили на этапе запуска и продвижения продукта. Будет полезно, если думаете запустить свой IT продукт.

Одним из самых больших разочарований, постигшим меня на пороге зрелости, явилось осознание факта – что даже абсолютная правота не является залогом победы в споре. Это знание изменило мой мир так же, как теорема Гёделя о неполноте изменила формальную логику. Я осознал, что вокруг меня существуют люди, которых невозможно переубедить, вне зависимости от убедительности аргументации и шаткости их позиции.

Традиционно начну издалека. Меня всегда интересовал вопрос: Почему ученые, раз такие умные, не вступают в дискуссии с обывателями, одержимыми разными лженаучными глупостями – ведь показать им истину не сложно: наука выработала многоженство инструментов, способных убедительно доказать любой спорный вопрос: от наличия законов Менделя на примере садовых мушек, до отмены «Новой Хронологии» через дендрохронологический анализ.

Сейчас я знаю ответ – переубедить сторонников лженаучных теорий невозможно. Но вовсе не потому, что они серьёзно заблуждаются. А в точности до наоборот – их невозможно переубедить, потому что они не заблуждаются вообще.

В прошлой части мы провели анализ архитектуры, итогом которого стало внедрение дополнительного разделения на слои: Core (ядро) и Externals (источники данных).

Система типов Scala 3 позволяет конструировать вторичные структуры данных в пространстве типов. Ярким примером таких структур может выступать HList, впоследствии ставший основой реализации кортежей. Кортежи в Scala 3 стали весьма гибким инструментом, позволяющим захватить в упорядоченном виде сведения о разнородных типах.

В настоящей заметке мы рассмотрим реализацию структуры "множество типов" на основе кортежей с использованием инструментов Scala 3.

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

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

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

А что, если бы операции List[A].head и List[A].tail в Scala были бы безопасными на этапе компиляции?

В один ноябрьский вечер я задался этим вопросом, и, обладая нулевыми знаниями по метапрограммированию, принялся реализовывать список SList[A, N] с известным на этапе компиляции размером. Даже for-comprehension в итоге получилось реализовать!

Как это получилось сделать и какими средствами языка? Если рассказывать подробно - долгая история.

В функциональном программировании широко используются так называемые алгебраические типы данных. Такие данные формируются из более простых типов с использованием всего двух операций — "суммы" и "произведения". Использование таких математических операций оказывается очень удобным с точки зрения последующей обработки с помощью сопоставления с образцом ("паттерн-матчинг"/pattern matching).

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

В этой заметке посмотрим на примеры моделирования ошибок и сообщений логирования.

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

Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.

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

Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.

Прежде чем начать, зацените эту красоту! Это — игра "жизнь" на языке APL:

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

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

Давайте разберем, что такое класс типов. Обратимся к формальному определению:

Класс типов (type class) — это абстрактный параметризованный тип, который позволяет добавлять новое поведение к любому закрытому типу данных без использования подтипов.

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

Функциональное программирование одной из целей ставит отражение логики программы в типах входных/выходных значений функций. Типы аргументов и результатов накладывают существенные ограничения на то, как может быть реализована функция. Тем самым, позволяют делать разумные выводы о работе функции, ориентируясь только на её сигнатуру. Такое явление называется "параметричность". Замечательным примером параметричности служит такая сигнатура:

val f: [A] => A => A

Эту сигнатуру можно прочитать так: для любого типа, получив значение этого типа, вернуть какое-то значение того же типа. Исходя из того, что тип может быть любым, и никаких операций над этим типом мы не определили, единственной продуктивно завершающейся реализацией является identity. Здесь и далее мы исключаем непродуктивные решения вида f(a) = f(a) (зависание/отсутствие завершения) или f(a) = throw Exception() (исключение).

Для представления эффектов часто используется конструкция IO[A]. Значение из этого объекта можно получить, только выполнив код, содержащийся внутри. Довольно часто можно столкнуться с ситуацией, когда само значение нам не настолько интересно, как факт выполнения определённой операции. Обычно используется тип возвращаемого значения IO[Unit]. В этой заметке предлагается воспользоваться параметричностью, чтобы получить определённые гарантии.

Всем привет! Меня зовут Владислав Шиханов, я ведущий программист в CDEK. В нашей компании работает 500+ IT-специалистов, именно мы создаём продукты и сервисы, из которых и состоит СДЭК. Моя команда разрабатывает сервисы для автоматизации процессов продаж и запуска новых продуктов.

Однажды мы столкнулись с тем, что процесс проверки кода начал задерживать выполнение задач и требовал слишком много усилий от участников. На ретро мы договорились повысить приоритет этого процесса и сделать доклад с best practices. В этой статье я решил поделиться главными выводами и лучшими практиками, которые помогли нам существенно упростить проверку кода.

Если вам зачем-то понадобилась полная адресная база России, то самый простой и дешевый способ ее заполучить — это скачать на сайте налоговой. Да, вот так вот просто все. Ну почти.

Да, это полная официальная адресная база России, просто в открытом доступе, никто ничего не спрашивает, просто раздают. Сделали на наши налоги, и честно всем, как скамейку в парке, отдают в пользование. Прекрасно? Да!

"В чем же подвох?", — спросите вы, прищурившись.

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

Получилось так, что с недавнего времени, я обзавелся личным электротранспортом, который называется моноколесо. Долго я шел к этому, но всё же решился и ни о чем не жалею, даже наоборот, испытываю полный восторг от поездок на этом сногсшибательном транспорте. А еще очень люблю поезки на природу, а езда на моноколесе на природу умножают эту любовь на 100500. Но есть одно «НО» и об этом далее...

Я провел в изучении JMM много часов и теперь делюсь с вами знаниями в простой и понятной форме.

В этой статье мы подробно разберем Java Memory Model (JMM) и применим полученные знания на практике. Да, в интернете накопилось достаточно много информации про JMM/happens-before, и, кажется, что очередную статью про такую заезженную тему можно пропускать мимо. Однако я постараюсь дать вам намного большее и глубокое понимание JMM, чем большинство информации в интернете. После прочтения этой статьи вы будете уверенно рассуждать о таких вещах как memory ordering, data race и happens-before. JMM — сложная тема и не стоит верить мне на слово, поэтому большинство моих утверждений подтверждается цитатами из спеки, дизассемблером и jcstress тестами.

Разработчик веб-приложений и распределённых систем под псевдонимом chreke* убеждён: «малые языки», то есть специализированные языки, созданные для решения конкретных задач, являются будущим программирования. Это убеждение укрепилось в нём после прочтения статьи Габриэллы Гонсалес «Конец истории программирования» и просмотра лекции Алана Кея «Программирование и масштабирование».

Под катом автор объясняет, что подразумевает под «малыми языками», и почему они так важны.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.