111.2
Karma
0.5
Rating
Протько Сергей @Fesor

Full-stack developer

Telegram-клиент на PHP (и получение сообщений с помощью MadelineProto)

-1
ей требуется 8+ ГБ оперативки для сборки

Так это же сборка, причем тут сама библиотека. Собирайте на CI, дистрибьютте итоговый бинарник.


А с учетом, что оно зависит от версий системных библиотек

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

Telegram-клиент на PHP (и получение сообщений с помощью MadelineProto)

0
Ну вот будет в php поддержка FFI — можно будет ее заюзать.

Токсичный Маск

0
Нет, просто рандом. Вообще нет смысла анализировать успех, нужно неудачи анализировать.

Токсичный Маск

+7
Он был по очереди бесплатный, неуклюжий и напряженный.

Ты присядешь или не являешься собой?


complimentary это еще и приветственный. Ну так...

Где Agile ужасен, особенно Scrum

+1
Мне нравятся подобные комментарии. Вроде как правильная мысль но совершенно бесполезная.

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

Разработка через тестирование: улучшаем навыки

0
То есть вы сразу пишете все тесты, а потом всю реализацию?

Вы правильно заметили на тему "мужественности". Но все же от "все тесты" это все очень далеко. Я как-то общался с человеком которому не нравилось TDD потому что он месяц тесты писал и только потом писал реализацию. Сами понимаете как это не эффективно.


На тему же "мужественности" — для простых задач можно сразу накидать несколько тест кейсов (триангуляция, в терминах Кента Бэка) и потом реализовывать код. И чаще всего вы врядли захотите двигаться совсем уж маленькими шагами. А вот если вы написали несколько тестов и не можете написать код — всегда можно убрать пару тестов и двигаться более маленькими шажками. Тут все очень субъективно. По сути основной момент — насколько вы уверены. Не уверены — сокращайте длину итераций.


Вы уверены, что стоит тратить рабочее время на подбор такого намеренно дефективного алгоритма?

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


да, довольно часто это все избыточно (опять же смотрим про уверенность), но если уверенности нет — имеет смысл.


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


Ну, что-то он тестирует. А то ли он тестирует?

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

Класс PHP для вывода в консоль цветного текста

0
> производительность

на фоне того что вы в консоль синхронно пишите? э не.

Класс PHP для вывода в консоль цветного текста

0
что оно тянет за собой целый фреймворк?

Вы что-то путаете. symfony/console самодостаточный пакет который по умолчанию не тянет ничего дополнительно.


Ну и опять же — простая логика. Если вам нужно текст раскрасить в CLI приложение, кто скорее всего нужно будет и аргументы распарсить, и в целом почему бы и нет.

Разработка через тестирование: улучшаем навыки

0
Вывод — первая имплементация неверная, в первом требовании ничего про исключения нет, а мы их бросаем.

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


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

Разработка через тестирование: улучшаем навыки

0
В чём преимущество перед пост-формализацией?

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


Когда разработчики, особенно те кто только начинают писать тесты, пишут тесты после реализации, чаще всего эти тесты тупо дублируют реализацию.


Что именно является способом борьбы со страхом внесения изменений?

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


Но как это может обеспечить достаточное покрытие хотя бы классов эквивалентности?

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


Какая ж она бесплатная, если вы на их написание требуется время и силы?

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


Тут стоит сделать ремарку — если вы УЖЕ можете делать более изолированные модули, вы УЖЕ умеете писать тесты неплохо, вы понимаете как определять их качество и т.д. то ценности от TDD для вас возможно нет.


Причём есть гипотеза, что писать тесты на отсутствующий код несравнимо сложнее, чем на существующий.

Кент Бэк в своей книге (опять же нет под рукой, не могу дать точную отсылку) писал о маленьком исследовании где эта гипотиза по сути опровергается. Там типа ставился эксперемент в духе пишем одно и то же приложение 10 раз (что-то простенькое, консольная симуляция игры в боулинг например), половина тесты до, половина тесты после, засекаем время и т.д.


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

Как выруливать с legacy code, когда проект нужно было на вчера

0
В большинстве случаев проще и дешевле переписать заново

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


Постепенно переписывать — можно, так или иначе придется. А вот с нуля — никогда не окупится.

Неизменяемые объекты в PHP

+1
> У неизменяемого объекта лучше уж вообще не делать таких методов, чтобы не вводить в заблуждение.

Ну заблуждени тут из ваших личных привычек. Лично меня подобное не смущает. Ну и опять же вопрос в том что имутабельность это хорошо (потому что можно всегда вывести типы и отследить стэйт не запуская код) но получать новые значения все еще нужно. И проще клонировать объект при изменениях (можно частично если эти части не меняются).

Ну и если вы все еще считаете что «это не очевидно» и т.д. предлагаю вам не личные субъективные ощущения (или мои) использовать, а провести полноценное исследование данного вопроса. Тогда можно будет делать выводы.

Где Agile ужасен, особенно Scrum

0
> Он тратит на это время один

он не получает фидбэк, потому в целом какая разница? В этом же собственно основная проблема ватерфола, а не в том что «нет спринов». Нет фидбэка — приоритизация происходит на основе «я так вижу». А при таком раскладе можно и более ватерфольные штуки использовать (FDD то же)

Ну и опять же — если у оунера есть готовность слить результаты работы в унитаз — не понятно зачем так детально это прорабатывать.

Где Agile ужасен, особенно Scrum

0
Не ну если вы не заинтересованы — то зачем тратить время?

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

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

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

Где Agile ужасен, особенно Scrum

0
В каждом первом проекте по скраму получается одно из двух

Заметили ли вы что обычно когда все идет хорошо процессы хвалят те кто их внедрял, а в случае неудачи ругают те кто по ним работал? Если да — тогда наша статистика в целом совпадает (такая же у меня например в случае с kanban)


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


можно будет объяснять успешные результаты

главное не попасться в классическую ошибку выжевшего.


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

Где Agile ужасен, особенно Scrum

0
> Вам лучше бы было как-то более явно выразить свою мысль

Мысли не было — был вопрос на который вы не ответили. От ответа на него будет зависеть то как я буду раскрывать мысль дальше.

От того откуда приходят требования и как происходит проверка эффективности фич (и происходит ли вообще) зависит взлетит скрам или нет. Причем тут речь не только про скрам — любой итеративный подход.

Ссылки же были к другой части вашего комментария (и там было согласие с мыслью что все эти scrum сертификации и треннинги это просто отдельная индустрия сама в себе).

Где Agile ужасен, особенно Scrum

Где Agile ужасен, особенно Scrum

0
и решение это спускается для них «сверху»

Меняется ли для команды процесс формирования бэклога?


Скрам как продукт у нас сейчас продаётся в формате таблеток от болезней

У Дэйва Томаса (один из авторов agile manifesto) есть доклад на эту тему — Agile is dead. Ну и есть очень неплохая постановка на тему типичных скрам коучей: A Retake on the Agile Manifesto • Humble, Thomas, Badiceanu, Fowler & Kirk

Где Agile ужасен, особенно Scrum

0
Я обычно наблюдаю чуть другое. Вот услышал кто-то из менеджеров про скрам (потому что в целом, если быть честными, про другие фреймворки как-то не очень слышно, если не искать), прочитал пару статей про то как скрам позволяет делать больше теми же силами и решил что «ништяк, надо вводить!»

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

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

Особенно радуют аутсорс компании которые практикуют скрам. Как правило у них SoW подписан на пол года работы, фиксированный бюджет и коммитменты по функционалу, но всем говорят что они аджайл.

Где Agile ужасен, особенно Scrum

0
> Скрам таких возможностей не предусматривает.

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

Ну и опять же — у вас поквартальное планирование, вы не собираете фидбэк после каждой итерации, вы не анализируете приносит ли функционал ценности? Может вам вовсе не нужен скрам?

Описанная же вами ситуация — это исключительно про взаимодействие людей в команде. Ибо в целом так смысла в дэйли нету, если все вопросы можно тэт-а-тэт порешать. Скрам у вас, XP, FDD или RUP — проблема остается.

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

Где Agile ужасен, особенно Scrum

0
А причем тут agile/scrum? Хотите привлечь отдельного специалиста — привлекайте.

> не должна создаваться так рано

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

Если вам удалось найти специалиста и вы условились скажем в 2 недели на R&D дабы по результатам уже смотреть окупится ли дальнейшая разработка данной фичи — ну сделайте так. Если денег много и потенциальный профит перевешивает плюсы, и вы можете взять специалиста на пол года, почему нет.

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

Где Agile ужасен, особенно Scrum

+2
> творческие они, посмотри-ка!

Ну всю эту движуху что мол на конвейере у вас не совсем уж дураки стоят начали еще в 70-х и далеко не в IT. Мол, зачем надсмотрщики, выдайте людям секундамеры и ответственности о они сами будут пытаться оптимизировать свой участок работы.

Ну там всякие книжки на эту тему вроде знаменитого The Goal и всякие там книжки про безотходное производство (toyota way, lean)…

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
речь идет о линтерах vs нормальные тайп чекеры.

Но как контр приме можно привести скажем python, который позволяет вам определить тайпинги для всего на свете. Или flow, который справляется с этим даже лучше.

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

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
Вопрос: почему тогда разработчики субд не используют такое?

индексы как-бы примерно таким образом и работают.


Даже для сохранения в памяти они использую таблицы

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

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
Официальная наука говорит

когда говорите "наука говорит" приводите источники, иначе это вы говорите а не "наука".


модульные и функциональные

то есть модульные тесты не проверяют функциональность? Ну и интеграционные тесты не являются функциональными? Чем тогда приемочные от ваших функциональных отличаются? И можно ли делать приемочные тесты не со стороны UI?


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

Мне нравится что вы начали комментарий с фразы "наука говорит".


Они не проверяют функциональность, они проверяют, что какие-то методы были вызваны с правильными параметрами

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


слишком много знаний о внутреннем устройстве кода утекает.

Это говорит о том что дизайн нашего кода такой, что провацирует подобное. Обычно — из-за большого количества зависимостей (попробуйте перегруппировать код таким образом, что бы уменьшить количество оных).


а тестирую микросервис как black box — снаружи

Немного накину: J B Rainsberger — Integrated Tests Are A Scam

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0

Исходя из вашего определение мне кажется что под "формальными тестами" мы подразумеваем проверку сходятся ли типы. "формальные модульные" явно что-то другое.

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0

Возможно вам будет интересно: Ideology — там как раз рассматриваются эти точки зрения (что статическая типизация и тесты могут заменять друг друга)

Разработка через тестирование: улучшаем навыки

+1
Что делать, когда ты не можешь написать ни одного красного теста, так как код сейчас работает верно

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


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


но тестовые сценарии покрыты определённо не все?

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

Разработка через тестирование: улучшаем навыки

0
даёт уверенность в понимании требований?

"уверенность" понятия субъективное. Суть в том что бы разработчик начал формулировать требования ДО написания кода. Если уверенности в понимании требований нет — пишите больше тестов, есть уверенность в понимании — возможно тестов уже достаточно.


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


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


решает проблему низкого покрытия?

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


О которых вы нам не расскажете?

Не могу говорить за VolCh но… для меня тесты в TDD это та самая "бесплатная" вещь. А главная цель для меня все же в формализации требований и проектировании интерфейсов (ибо тесты это тот же клиентский код). Тесты такие на ранних этапах будут намекать нам о связанности лишней, о том что с декомпозицией что-то не так пошло и т.д.


p.s. я не очень понимаю вашу позицию. Вы хотите затеять очередной холивар нужен ли TDD? А зачем? подход не претендует на универсальность а его плюсы, минусы и прочее разжеваны в 5-ти часовом холиваре DDH, Кента Бэка и Фаулера (Is TDD Dead). Есть еще TDD vs DbC с дядей Бобом и Джимом Копленом.


Ну либо накиньте что-то конкретное.

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

+1
> по свойствам вложенных объектов.

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

> ну ORM — это все же не RDBMS

прикол то в том что если у вас есть RDBMS то ограничения этой модели будут просачиваться сквозь вашу ORM (если она общего назначения, типа гибернейта). Те же one-to-many там кастылем разруливаются, что бы эмулировать однонаправленность связи.

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
> Глупо с моей стороны было упускать из виду существование ORM as is

Подозреваю что вы пользуетесь либо Доктриной либо Чем-то вроде гибернейта, ну тогда в целом мы используем одни и те же инструменты.

разница лишь в том что вот все эти «богатства» это про persistence а не про бизнес логику. И да, я помню как я сам завязывал на всякие вычисления чейнджсетов бизнес логику — это прямая дорога в ад на любом маломальски сложном проекте.

Ну и еще раз — вы сами предлагали посмотреть на вещи «по другому». Например — event sourcing вполне себе компромисный вараинт, который позволяет вам крутить вертеть вашей моделью данных как угодно.

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
> У меня информация от контрагентов…

Сейчас бы по одному кейсу статистику по индустрии проэцировать. Импорт данных может быть, но чаще всего это импорт части данных а не всех. Да, есть исключения, как и проекты где вообще нет bulk import.

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
которые отрабатываются по уже загруженным данным

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


Опять же — главное пожалуй отличие — отсутствие ссылок и возможности однонаправленные one-to-many связи делать (у вас на стороне many fk что делает его зависимым от one)


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

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0

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


Чем меньше зафиксированных зависимостей пришлось затащить в проект — тем лучше.

Меня не покидает ощущение что мы говорим о разных вещах. Что бы небыло недопонимания, давайте так.


Вы согласны что зависимость все равно есть? А это значит что мы не можем просто поставить "другую субд" и все будет гарантировано работать, то есть может потребоваться дополнительная работа.


Ну или расскажите про свои проекты. Ибо я не могу вспомнить ни одного проекта где мы гарантировали бы стабильность работы софта при смене скажем postgres на mysql.


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


Я просто не очень верю в волшебное "зависимости есть но я могу махнуть палочкой и вжух уже имплементация другая". То есть да, изолировать зависимость — понимаю и согласен. Но ORM — это не про "устранение зависимости от конкретной базы", это не ее первоочередная задача. Абстракцию вы уже сами делаете (шаблон Repository например).


Что мешает работать и тем и другим параллельно?

ничего, просто два процесса. И да — формирование email-а это представление. Независимый процесс. Запускайте сколько хотите. А вот если ваш "коркер" бизнес процессы будет разруливать, то вам уже важно что бы бизнес процессы реализованные в версии 1 и версии 2 были совместимы.


Что мне мешает запустить комплект новых воркеров

А что мешает добавить код в имеющийся воркер что бы тот сам стал считать в нужный момент по другому? У вас же по любому будет какой-то код который будет принимать решение какому из воркеров трудиться когда. Или вы руками планируете переключать?


Ради суперзадачи "использовать триггеры во что бы то ни стало?"

Нет, просто я не очень понимаю зачем может понадобиться две версии одного тригера одновременно выкатывать. Два тригера. Или две процедуры. Если очень хочется.


Пример со схемами — просто говорю что есть механизмы. Если говорить не про тригеры и процедуры, а просто про схему базы, то оно вам и с ORM поможет (удобно при zero downtime. Как пример можете глянуть как вот тут делают).


Вот как раз тут через ORM все чудесно решается.

речь идет не о тех изменениях. Это про изменения логики/кода.


Через Entity lifecycle events.

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


т.к. отслеживание изменений в ORM обычно из коробки

Только если ваша ORM имеет внутри unit of work. Это маленький процент ORM и в целом они обычно очень сложные. Не ну как, если понимать что магии там нету и разбираться как оно работает)


Я в последнем проекте просто кидал сообщение в менеджер очередей

А у меня вообще event sourcing


в PostgreSQL в триггкре доступна информация о пользователе, выполнившем транзакцию

Тригер будет запущен из под того же пользователя, из под которого идет подключение. Ну то есть соответственно помимо тригера вам надо будет еще аутентификацию на пользователей СУБД перевести. А вот это уже оч херово скейлится.


Скажем у меня на проекте HIPAA и мне нужно не только трекать кто чего подправил, но и кто чего посмотрел. Настолько что мол мне надо трекать кто в какое время в результате поиска каких пользователей увидел.


Подобное я ни в коем случае не буду делать ни на тригерах ни на ORM. У меня сверху подсистема которая коллектит ивентики эти и потом балк инсертом записывает.


и можно ли к каким-то внешним службам обратиться, типа RabbitMQ или Redis?

Там есть notify через который можно замутить pub/sub. Например — штуки типа postgraphile используют для того что бы апдейты на клиент в сокеты пихать.


Но они что, правда не работают в кластерах и при шардинге?

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


Опять же, у меня опыта такого тоже нет, просто из всех проектов которые приходилось видеть основной юзкейс был именно в том что бы жестко ограничивать доступ к данным (когда самое критически важное лежит процедурами, все данные жестко разбиты какими-нибудь row based security и т.д.). Ну и те же микросервисы, где можно ввести те же ограничения, уже могут выйти дороже. Но опять же всякое бывает. Иногда критически важную подсистему можно выделить отдельно и будет как бы монолит + внешняя система которая не меняется без согласования с контролирующими органами (какие-нибудь PCI DSS)

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
> ORM здорово тормозит на операциях bulk import

bulk import благо не самая распространенная задача. Да и для конкретного кейса можно придумать что-то поинтереснее.

В целом ORM нужны там где у вас OLTP (OnLine Transaction Processing). То есть берем чуть-чуть данных (агрегат, границы бизнес транзакции, DDD), делаем с ними что-то и записываем.

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

Собственно вы сами в конце про разделение представлений говорите.

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
ORM — она (он?) такая же реляционная как СУБД под ней.

реляционная в смысле орудует реляционной алгеброй (ну там картежи данных, предикаты) или в каком смысле вы употребляете это слово?


Должен ли это понимать джун? Я думаю да.

Понимают ли? думаю нет. Для подавляющего большинства джунов ORM это волшебная коробка которая просто работает. Более того — это довольно распространенное мнение. Вот выше тоже вещают про то что ORM это абстракция от базы. А если оно абстракция — значит про базу знать не обязательно.

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
но это внешний компонент

Почему? Можно ли воспринимать скажем версию JVM как "внешний компонент"?


У меня вещи типа база данных это внутренний компонент. Я поставляю код как готовую инфраструктуру (предположим через докер). И я регламентирую что нужно для того что бы код работал.


У меня был один кейс когда мне была выгодна смена субд прозрачная — у заказчика был тот самый вендор лок на оракл, и ничего другого они юзать не могли. И выяснилось это через 3 недели посте старта проекта. Но там и проект примитивный.


Так что нет, сегодня завязка на конкретную СУБД это данность на хоть сколько нибудь серьезном проекте.


Вы же не переживаете что выбрав определенный язык программирования вы как бы тоже создали себе вендор лок?


Задача ORM — реализовать слой абстракции в виде хранилища объектов с реляционными отношениями между ними.

Тогда было бы не O/RM (Object-relational mapping) а Object-Relation Abstraction какой. Задача ORM — исключительно мэппинг одного в другое. И при том что две эти модели данных (основанная на реляциях и ваши in memory структуры) сильно различаются, то и мэппинг мы можем сделать в ограниченном наборе сценариев (всему виной такая вещи как референсы, которые выражены сильно по разному)


Хм… я могу одновременно задеплоить разные версии воркеров, которые будут реализовывать разние версии API

это как UI, попробуйте такое с бизнес логикой провернуть. И не важно будет в тригерах она или в коде. Ну либо ваши две версии воркеров должны реализовывать совместимость на уровне бизнес процессов. Что как бы… можно провернуть и с тригерами.


но я не вижу способа задеплоить одновременно несколько разных версий SQL-триггрер.

Я не вижу необходимости в этом. Но вообще зависит от вашей СУБД. В PostgreSQL подобное можно хитро замутить со схемами.


А в чем тут проблемы с ORM? Вовсе не обязательно, чтобы все пользователи ходили к СУБД под одним пользователем.

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


Такое можно и с кодом провернуть (здрасте микросервисы).


Тот же Highload

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

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
сложно представить разработчика который с node работает (а на нем можно и бэк писать, и просто юзать тулы написанные и дистрибьютящиеся через npm) не знать что такое node_modules.

Ну а на тему изменения серд парти — это может намекать только на то что ваши разработчики никогда не работали с менеджерами пакетов. Что странно в наши дни.

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

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
но не данных

поясните что вы имеете ввиду. Мне кажется что для вас "расширение данных" это просто расширение структуры. Что-то типа сишного варианта:


typedef struct foo {
  int a;
} foo;

typedef struct bar {
  struct foo;
  int b;
} bar;

Нужно все же понимать о чем вы говорите, пока не понятно. Ибо "наследование данных" это какой-то процедурный концепт.


А как же неуправляемая память?

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


Ну и да — деструкторы в rust все же есть

Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать

0
Наследование данных

composition over inheritance и все в таком духе.


Интересный момент — даже Страуступ признает что добавление protected в плюсы было ошибкой (очень легко неявное поведение организовать, всякие LSP нарушить, контракты сломать)


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


Опять же, идеям "ооп" в плюсах лет больше чем это самое ООП существует (Хоар классы описывал задолго до того как Алан Кей сказал кому то что он "ООП делает")


Lisp более ОО чем C++.


виртуальные деструкторы

Именно деструкторы? И именно виртуальные?


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

1 There