Liquibase — это система управления миграциями базы данных. Это вторая статья о Liquibase, на этот раз содержащая советы «боевого» использования системы. Для получения базовых сведений подойдет первая статья-перевод «Управление миграциями БД с Liquibase» (ссылка).

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

Вот 10 вещей, которые в определенный момент работы с Liquibase были для меня открытием.

1. Версионность приложения должна быть отражена в структуре папок миграций

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

/db-migrations
    /v-1.0
        /2013-03-02--01-initial-schema-import.xml
        /2013-03-02--02-core-data.xml
        /2013-03-04--01-notifications.xml
        /changelog-v.1.0-cumulative.xml
    /v-2.0
        ...
        /changelog-v.2.0-cumulative.xml
    /changelog.xml

Подробнее:

Последнее десятилетие в области компьютерных технологий ознаменовалось началом новой «весны искусственного интеллекта». Впрочем, ситуацию в индустрии в наши дни можно, наверное, охарактеризовать уже не как весну, а полноценное «лето ИИ». Судите сами, за последние неполные 10 лет только в области обработки естественного языка (Natural language processing, NLP) произошли уже две настоящие технологические революции. Появившаяся в результате второй из них модель GPT-3 произвела настоящий фурор не только в технологических медиа, но стала знаменитой далеко за пределами научного сообщества. Например, GPT-3 написала для издания «The Guardian» эссе о том, почему ИИ не угрожает людям. GPT-3 сочиняет стихи и прозу, выполняет переводы, ведёт диалоги, даёт ответы на вопросы, хотя никогда специально не училась выполнять эти задачи. До недавних пор все возможности GPT-3 могли по достоинству оценить лишь англоязычные пользователи. Мы в Сбере решили исправить эту досадную оплошность. И сейчас расскажем вам, что из этого получилось.


Источник изображения

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



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

Статистика приходит к нам на помощь при решении многих задач, например: когда нет возможности построить детерминированную модель, когда слишком много факторов или когда нам необходимо оценить правдоподобие построенной модели с учётом имеющихся данных. Отношение к статистике неоднозначное. Есть мнение, что существует три вида лжи: ложь, наглая ложь и статистика. С другой стороны, многие «пользователи» статистики слишком ей верят, не понимая до конца, как она работает: применяя, например, тест Стьюдента к любым данным без проверки их нормальности. Такая небрежность способна порождать серьёзные ошибки и превращать «поклонников» теста Стьюдента в ненавистников статистики. Попробуем поставить точки над i и разобраться, какие модели случайных величин должны использоваться для описания тех или иных явлений и какая между ними существует генетическая связь.

В последнее время часто сравнивают CSS и JavaScript, споря о применении этих технологий для решения определённых задач. Споры становятся жарче по мере появления новых замечательных возможностей CSS, которые позволяют упростить решение множества задач и отказаться при этом от JS.

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

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



Мне не хотелось бы писать материал о том, почему я перешёл с Go на JavaScript, перечисляя минусы Go. Я полагаю, что подобные материалы оторваны от жизни и приносят читателям очень мало пользы. Поэтому я написал материал о том, что мне нравится в JavaScript, о том, что подвигло меня на переход.

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.

Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.

Оффтоп

В названии статьи не поместилось — данные результаты считаются таковыми по версии рейтинга Graph500. Также хотелось бы выразить благодарность компаниям IBM и RSC за предоставленные ресурсы для проведения экспериментальных запусков во время исследования.

Введение

Поиск в ширину (BFS) является одним из основных алгоритмов обхода графа и базовым для многих алгоритмов анализа графов более высокого уровня. Поиск в ширину на графах является задачей с нерегулярным доступом к памяти и с нерегулярной зависимостью по данным, что сильно усложняет его распараллеливание на все существующие архитектуры. В статье будет рассмотрена реализация алгоритма поиска в ширину (основного теста рейтинга Graph500) для обработки больших графов на различных архитектурах: Intel х86, IBM Power8+, Intel KNL и NVidia GPU. Будут описаны особенности реализации алгоритма на общей памяти, а также преобразования графа, которые позволяют достичь рекордных показателей производительности и энергоэффективности на данном алгоритме среди всех одноузловых систем рейтинга Graph500 и GreenGraph500.

Мой брат недавно отучился на компьютерщика и сейчас завершает стажировку в области фронтенд-разработки. Он узнал и о CSS Grid, и о CSS Flexbox, но в том, как он пользуется этими механизмами создания макетов, я отметил одну особенность, с которой я уже сталкивался. А именно, ему тяжело даётся принятие решений о том, когда использовать Grid, а когда — Flexbox. Например, он использовал CSS Grid для создания макета заголовка сайта. При этом он отметил, что довести проект до ума ему было нелегко, и что ему пришлось долго экспериментировать с grid-column и настраивать всё до тех пор, пока у него не получилось то, что ему было нужно.



Честно говоря, мне это не понравилось. Поэтому я решил поискать какой-нибудь ресурс, который помог бы моему брату как следует уяснить различия между Grid и Flexbox и дал бы возможность взглянуть на примеры, созданные с использованием обеих этих технологий. Но ничего подходящего мне найти не удалось. Тогда я решил написать статью, посвящённую Grid и Flexbox. Надеюсь, она получилась понятной.

За последний год в Docker Hub стало доступно уже более 100 000 образов, а загружались образы с Docker Hub уже более 300 миллионов раз. Из них более 20 миллионов загрузок пришлись на 70 официальных образов разработчиков Docker, таких как Oracle, CentOS и NGINX.

NGINX используется на более 40% самых больших сайтов в мире, не только как веб-сервер, но и как реверс-прокси сервер, балансировщик нагрузки и HTTP кэш. Официальный образ NGINX был загружен 3.4 миллиона раз.



В этой статье вы узнаете:

• как развернуть и использовать Docker-образ с NGINX.
• как быстро развернуть реверс-прокси на NGINX и несколько сайтов в Docker
• как развернуть геораспределенную инсталляцию, состоящую из нескольких сайтов и реверс-прокси в каждом из 3х регионов InfoboxCloud.

Если раньше вы не использовали Docker, рекомендуется к прочтению:
Используем Docker и не волнуемся о vendor-lock
Погружаемся в Docker: Dockerfile и коммуникация между контейнерами
Обзор новшеств Docker Engine с 1.0 до 1.8. Введение в Docker Compose

В конце статьи мы раздаем пробные версии InfoboxCloud бесплатно.

Далее речь пойдет о моем опыте запуска докеризованного Spring Boot приложения на бесплатных виртуальных машинах облачного сервиса Heroku. Одно из главных преимуществ этого провайдера в том, что он дает возможность создавать бесплатные виртуалки с ограничением по часам работы, причем для этого достаточно только регистрации. Даже платежные реквизиты подтверждать не требуется, хотя если их подтвердить можно получить дополнительные бонусы. Подробнее про их прайс можно прочитать здесь. С моей точки зрения их политика по части бесплатных ресурсов почти не имеет аналогов.

И так, после того, как вы создали на Heroku приложение есть несколько способов развернуть в нем ваш код

В статье опишу использование Spring Data.

Spring Data — дополнительный удобный механизм для взаимодействия с сущностями базы данных, организации их в репозитории, извлечение данных, изменение, в каких то случаях для этого будет достаточно объявить интерфейс и метод в нем, без имплементации.

Содержание:

1. Spring Repository
2. Методы запросов из имени метода
3. Конфигурация и настройка
4. Специальная обработка параметров
5. Пользовательские реализации для репозитория
6. Пользовательский Базовый Репозиторий
7. Методы запросов — Query

Сложность представления данных для глубокого обучения растет с каждым днем. Нейронные сети на основе данных в виде графа (Graph Neural Network, GNN) стали одним из прорывов последних лет. Но почему именно графы набирают все большую популярность в машинном обучении?

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

Пару дней назад вышел релиз Spring Boot 2.3.0.M1, в описании которого первой строкой упоминается поддержка проекта Cloud Native Buildpacks, являющегося попыткой упростить жизнь разработчика, позволяя максимально автоматизировать сборку образов из исходных кодов. Так как на моем текущем проекте нашим микросервисам предстоит жить в контейнерах, решил попробовать его и разобраться в чем преимущества. Короткое продолжение под катом.

Прим. перев.: Эта статья входит в состав опубликованных в свободном доступе материалов проекта learnk8s, обучающего работе с Kubernetes компании и индивидуальных администраторов. В ней Daniele Polencic, руководитель проекта, делится наглядной инструкцией о том, какие шаги стоит предпринимать в случае возникновения проблем общего характера у приложений, запущенных в кластере K8s.



TL;DR: вот схема, которая поможет вам отладить deployment в Kubernetes:

Для начала повторим основные горячие клавиши. Если вы их ещё не используете — начните обязательно. В долгосрочной перспективе время на изучение окупится многократно.

0. Основные горячие клавиши

• Esc: Переключение между режимом выполнения и редактирования
• A: Добавление пустой ячейки сверху
• B: Добавление пустой ячейки снизу
• DD: Удаления ячейки
• C: Копирование ячеек
• X: Вырезание ячеек
• V: Вставка ячеек

1. Перезапуск блокнота

Для рестарта просто нажмите ESC + 00.

Поздравляем Хабр с выходом R2DBC версии Arabba-RELEASE! Это самый первый стабильный релиз проекта.

R2DBC (Reactive Relational Database Connectivity) — открытый проект, посвященный реактивному программированию для SQL. Разработчики R2DBC готовили первую версию спецификации целых два года! В этом хабрапосте мы поговорим, зачем нужен R2DBC, и что происходит в проекте прямо сейчас.

В сообществе Java-разработчиков отношение к реактивщине традиционно крайне неоднозначное. Реактивное программирование даёт значительный прирост к масштабируемости приложения благодаря концепту конвейерной обработки данных. Но это также означает повышенный порог вхождения, а также код, который выглядит совершенно иначе, чем «традиционный» императивный код.

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

Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

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

Когда я разбирался в том, как пользоваться методами JS-массивов .map(), .filter() и .reduce(), всё, что я читал, смотрел и слушал, казалось мне очень сложным. Эти концепции рассматривались как некие самостоятельные механизмы, ни к чему другому отношения не имеющие. Мне тяжело было ухватить их суть и их понять.



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

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

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

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

Введение

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

Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи

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

Основные правила таковы: