Полезность ORM уже 100 раз обсудили, и давно все сошлись на мнении что если у вас не high-perf случай, то они прекрасно выполняют свою работу. Один язык, автогенерируемые миграции, защита от инъекций, красивый микс исполнения трансформаций на базе и на сервере. Плюсов море, из минусов — пониже перфоманс (часто сильно), и не всегда удобно когда нужно вклиниться с очень кастомным SQL (решаемо).
Про jekyll (github pages) я даже не знаю что вам сказать. Вы хотите чтобы на каждый запрос на статику проворачивалась машинерия рендерящая html? Даже если он не менялся год? Может вам в архитекторы?
Аутсорс — это бизнес решение. Ваша еденичная история — это безусловно повод чтобы сделать обобщение на всех, но возможно стоит посмотреть немного шире.
Возможно записи разговоров порезали на предложения. По отдельно взятому предложению уже можно монотонность определить, и возможно какие-то другие характеристики.
Я вам немножко завидую. Мне очень нравится ручная оптимизация, но по работе занимаюсь совершенно другими вещами. Пару раз в жизни удавалось пописать под NEON (в соседней с вами геймдев компании), счастью не было предела, когда запускал бенчмарки.
А что до AVX-512 — его нигде нет, так что если вы не сами себе покупаете железо под процессинг, а для людей делаете — придется писать два раза, с ним и без него.
Долгоживущий сокет на сессию, бинарный rpc протокол (хорошо grpc подойдет). Если яйца из стали — можно libquic подключить к мобильным клиентам, или хотя бы постараться использовать tls1.3 с нулевым rtt на установлении соединения.
Автор хотел на примере блокировки потоков показать крутость реактивного программирования, но показал крутость асинхронного (non-blocking) подхода.
Реактивное программирование по определению использует асинхронный подход, но нужно понимать что это абстракция более высокого порядка.
В том же .net есть старая парадигма APM когда вместо блокирующих методов создаются пары BeginXXX / EndXXX (в BeginXXX передается колбек, в котором нужно вызвать EndXXX который вернет результат или ошибку).
А реактивный это уже IObservable, и LINQ-подобные операции (Select/Where/Join/Aggregate) над источником событий. За счет того что это модель push (в нашу цепочку операторов событие пропихивается источником), а не pull (когда мы делаем условный вызов и ждем результат), модель неизбежно асинхронная.
Но опять же, важно доказывая вред блокирующего подхода противопоставлять ему не реактивный, а асинхронный
Для графиков лучше использовать Grafana поверх какой-нибудь TSDB (впрочем она работает и поверх эластика)
ELK потиху становится инструментом для метрик, но ему еще есть куда двигаться
Про jekyll (github pages) я даже не знаю что вам сказать. Вы хотите чтобы на каждый запрос на статику проворачивалась машинерия рендерящая html? Даже если он не менялся год? Может вам в архитекторы?
Аутсорс — это бизнес решение. Ваша еденичная история — это безусловно повод чтобы сделать обобщение на всех, но возможно стоит посмотреть немного шире.
Ну а что касается железа — AWS предоставляет машины на ARM. 32 GB RAM, 16 ядер. Деплойте, дебажьте.
aws.amazon.com/blogs/aws/new-ec2-instances-a1-powered-by-arm-based-aws-graviton-processors
Хотите локально — вот 24 ядра
www.socionext.com/en/products/assp/SynQuacer/Edge
А что до AVX-512 — его нигде нет, так что если вы не сами себе покупаете железо под процессинг, а для людей делаете — придется писать два раза, с ним и без него.
Реактивное программирование по определению использует асинхронный подход, но нужно понимать что это абстракция более высокого порядка.
В том же .net есть старая парадигма APM когда вместо блокирующих методов создаются пары BeginXXX / EndXXX (в BeginXXX передается колбек, в котором нужно вызвать EndXXX который вернет результат или ошибку).
А реактивный это уже IObservable, и LINQ-подобные операции (Select/Where/Join/Aggregate) над источником событий. За счет того что это модель push (в нашу цепочку операторов событие пропихивается источником), а не pull (когда мы делаем условный вызов и ждем результат), модель неизбежно асинхронная.
Но опять же, важно доказывая вред блокирующего подхода противопоставлять ему не реактивный, а асинхронный
git worktree
Не вижу проблемы положить несколько независимых продуктов в один реп в разные каталоги.
ELK потиху становится инструментом для метрик, но ему еще есть куда двигаться
no-hire по софт-скиллам если позиция выше мидла
Мне кажется у большинства людей проблема в том что компания готова платить МЕНЬШЕ а не БОЛЬШЕ.