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

Вначале идет немного теории про разные виды “монолитов”, а потом разбираются собственно ошибки:

1. Предполагать, что микросервисы всегда лучше монолита.
2. Общие модели и/или общая база.
3. Слишком большие микросервисы.
4. Слишком маленькие микросервисы.
5. Начинать построение нового продукта с микросервисной архитектуры.
6. Связывание через инфраструктурный код (логгирование/авторизацию и т.п.).
7. Использование синхронных вызовов между микросервисами.
8. Обратно-несовместимые изменения в событиях.
9. Отсутствие автоматизации релизов.
10. Отсутствие инкапсуляции (когда микросервис слишком много знает о деталях реализации другого микросервиса).
11. Несоответствие организационной структуры архитектуре продукта.

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

Наверняка многие случайно попадали на Rosetta Code, когда пробовали что-то делать простое на не очень знакомом языке. Недавно наткнулся на аналог для JS-фреймворков, хотя там везде выглядит все почти одинаково…

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

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

В GitHub вы можете запушить изменения в чужой репозиторий, если он является форком вашего и автор разрешил правки в PR.

Live Reload — это возможность обновления локально запущенного приложения “на лету” при изменении исходного кода вместо того, чтобы его останавливать, перекомпилировать и запускать заново. Эта функция есть много где — например, у фронтендеров в npm, у бэкендеров в Spring, в Jekyll, внезапно в gradle (там это называется continuous build) и т.д. Для реализации этого механизма нужно отслеживать изменения в коде и потом их собственно применять.

Первый этап можно реализовать одним из трех способов:

1. Запомнить состояние исходников (сделать снапшот) и периодически повторять эту процедуру, сравнивая новую версию со старой.
2. Получать и обрабатывать уведомления от файловой системы.
3. Перехватывать системные вызовы.

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

В Linux для уведомлений от ФС (второй способ) есть подсистема inotify. Использовать ее довольно просто: создается файловый дескриптор, к нему привязываются подписки на конкретные файлы и/или папки, потом в бесконечном цикле читаем структуры-сообщения об изменениях из дескриптора (ожидание будет за счет блокирующего read).

Кстати, в большинстве случаев за счет уведомлений от ФС работают команды вроде tail -f. Совсем всегда — не получится, т.к. удаленные системы обычно не посылают такой информации.

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

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

Сабж.

В игре есть сюжет, но не могу сказать, что он блещет художественностью, перестал читать его после третьего задания. По комментариям в поле ответа можно узнать все необходимое. Иногда есть небольшие неточности в задании (взбесил момент, когда в комментах были попутаны “Returned” и “Recovered”, благо в большом тексте все было нормально), но больше расстраивают манипуляции со строками в районе 15 главы. Для некоторых ошибок выдается объяснение, но у меня в основном были просто сырые исключения SQL и TypeError: can't convert undefined to object. Местами торчит диалект MySQL (или SQLite?).

Но в целом неплохой тренажер получается для начального уровня. Всего там 20 заданий на select, join, group by и т.п. и аж одно на delete.

Классная интерактивная статья про варианты балансировки нагрузки — от Round Robin до PEWMA. В конце есть интерактивные крутилки, с которыми можно поиграться, чтобы промоделировать нагрузку.

Одни из основных причин использования микросервисов (помимо культа карго, разумеется) — изоляция и инкапсуляция. Зачастую разделение на микросервисы сопровождается изоляцией на уровне команд и репозиториев: «это наш огород, даже читать нельзя!» Модно, стильно, молодежно, компетенции растут, ответственность четко ограничена (все же знают, какой команде какой микросервис принадлежит, кек).

Альтернатива микросервисам — использование модулей. Если у вас есть какая-то обособленная функциональность, то не обязательно ее изолировать жесткими мерами. Можно просто этот код иметь в отдельном модуле/пакете/папке, и настроить тупейший линтер, чтобы карал за хождение между модулями. При этом можно переиспользовать какие-то общие вещи вроде конфигов, авторизации или всяких утилит. И сделать отдельный конфиг/модуль собственно для запуска кода: если модули изолированы, то легко сделать опции чтобы запускать/собирать только нужный модуль (например, для продакшена со всяким масштабированием, запихиванием в контейнеры если надо и т.п.), набор модулей (например, какие-нибудь фоновые работы) или все вместе (например, для локального запуска).

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

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