особенно сложно соблюдать баланс между "и бизнесу хорошо и проект не в говне"

надо учиться приоритизировать, анализировать риски, принимать риски...

А будет ли полезен такой опыт? )

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

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

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

другой вопрос что сам проект и его специфику надо учитывать

А задавать всю конфигу в константах это норм?)

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

А задавать всю конфигу в константах это норм?)

ну проанализируй норм или нет)

начни с простого - посмотри че там как, потом уже думай норм или нет. Оно же работает

дальше смотри что тебе неудобно

и не смотреть неудобно а работать с этим

например - не стоит сразу впиливать ларавели или симфони - можно заюзать отдельные компоненты

так же не стоит сразу лепить DI - можно начать с сервис локаторов

ну и тесты....

и не юниты а e2e

ну то есть когда ты работаешь с легаси надо прорабатывать цели и план как этой цели достич... а это сложна

ну то есть когда ты работаешь с легаси надо прорабатывать цели и план как этой цели достич... а это сложна

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

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

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

есть испыталка

есть испыталка

Ну да, наверное время расставит все на места

вопрос

меня есть функция get

get_groups*

в ней я делаю запрос к бд

как мне в другом файле вывести эти значения?

как мне в другом файле вывести эти значения?

пусть функция эти данные... вернет!

Не удержался))

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

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

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

Тут кто-то практикует переиспользование правил валидации для бекенда и фронта? Используете ли json-schema? Изоморф не предлагать, бекенд на PHP, фронт на любом популярном JS фреймворке, интересуют любые мнения.

я, пытаюсь

на беке ещё не сделал, фронт уже готов

Тут кто-то практикует переиспользование правил валидации для бекенда и фронта? Используете ли json-schema? Изоморф не предлагать, бекенд на PHP, фронт на любом популярном JS фреймворке, интересуют любые мнения.

бек симфони, фронт vue

а как правила валидации решил делать общими между беком и фронтом?

Тут кто-то практикует переиспользование правил валидации для бекенда и фронта? Используете ли json-schema? Изоморф не предлагать, бекенд на PHP, фронт на любом популярном JS фреймворке, интересуют любые мнения.

будет работать для простых случаев

когда у тебя форма на UI мэпится на запрос 1:1

formapro/JsFormValidatorBundle: The Javascript validation for Symfony 2 and 3 forms https://github.com/formapro/JsFormValidatorBundle

А нужны как раз сложные случаи, с использованием anyOf и oneOf из json-schema: https://spacetelescope.github.io/understanding-json-schema/reference/combining.html#anyof

formapro/JsFormValidatorBundle: The Javascript validation for Symfony 2 and 3 forms https://github.com/formapro/JsFormValidatorBundle

вот только у тебя нет форм, у тебя там SPA

А нужны как раз сложные случаи, с использованием anyOf и oneOf из json-schema: https://spacetelescope.github.io/understanding-json-schema/reference/combining.html#anyof

тут хуже, на пхп не все драфты поддерживаются вроде

А нужны как раз сложные случаи, с использованием anyOf и oneOf из json-schema: https://spacetelescope.github.io/understanding-json-schema/reference/combining.html#anyof

это не сложные случаи, ты же можешь их описать через anyOf и oneOf

я для себя решил по ним проверять только простые штуки

Ув. Народ. Недавно узнал про тригеры в СУБД. И подумал, если сделать обновление timestamps через них а не в коде. Как думаете, это целесообразно для проекта где записываются в базу много данных?

может дедлочить

Ув. Народ. Недавно узнал про тригеры в СУБД. И подумал, если сделать обновление timestamps через них а не в коде. Как думаете, это целесообразно для проекта где записываются в базу много данных?

нет

шутки ради можешь замутить тестовый стэнд и проверить "есть ли выхлоп".

спойлер - его не будет

Хаха хаха. Спасибо) я понял

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

а что особенного в задаче? чёт не понятно...

слушаешь "некоторый" поток данных, рассылаешь команды/эвенты в зависимости от требуемого действия... нипанимать в общем в чём проблема :)

явно из-за таких биржестроителей я вчера на риплах 5 сотен потерял)

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

ну то есть у тебя проблемы как условия записать?

или что?

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

Думал может есть что-то уже готовое в плане алгоритма, чем просто держать в памяти все подписки и проверять на каждый тик весь массив

cqrs + event sourcing

о побольше команд басами обмазаться :)

идеально подойдет

о побольше команд басами обмазаться :)

да причем тут комманд басы вообще?

пришел ивент - чето произошло - ты его сначала записал в лог, потом наложил на стэйт, стэйт в памяти.

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

если упало - поднимаешь со снэпшета и накладываешь ивенты из лога

большую часть времени у тебя все будет быстро

ERROR: S client not available

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

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

да хоть в файл

да причем тут комманд басы вообще?

тебе на злобу)

ну то есть... снэпшет это тупо сериализованный стэйт

хоть json encode делай и пиши в файл

у тебя всеравно есть возможность по логу ивентов полностью стэйт восстановить

еще один вариант - держать 2 инстанса приложения

одну резервную которая тупо стэйт пилит

если одно упало - второе берет на себя управление пока первое восстанавливается

тогда снэпшеты можно будет реже делать

что позитивно скажется на производительности

только тут надо по другому чуть делать - с сокета тебе будет команда приходить а система уже будет генерить ивенты новые

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

типа микротрейдинга

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

ну и никаких ORM не надо

никаких там баз данных

разве что для стрима событий

но тут касандру можно жахнуть и вперед

запись/чтение будут преимущественно последовательными а значит максимально быстро

Я не осилил понять с наскоку cqrs + event sourcing и как именно он будет применён в текущей задачи... Я нуб, у меня лапки.

Я не осилил понять с наскоку cqrs + event sourcing и как именно он будет применён в текущей задачи... Я нуб, у меня лапки.

это вопрос к тому как ты модель данных делаешь

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

ибо дальше надо слишком сильно углубляться в то что тебе надо сделать

а это по сути делать за тебя

Да, спасибо за наводку, но без понимания CQRS + Event sourcing вряд ли получится запилить конфетку. Попробую сделать попроще, хранить состояние в БД, при загрузке приложения ложить всё в память и прогонять массив проверяя выполнения условия. Сразу вижу, что вероятно упрусь в производительность, но все же попробую.

ну это вряд ли можно назвать попроще

просто cqrs+es ломает мозг разработчикам, привыкшим к стандартному флоу работы с базой и реляциям

этого не отнять, сам проходил)

Мозг ломает, согласен. Но что-то нашел похожее из Redux, я прав?

привет

может не по теме, но js-ники должны быть тут