В rxjs есть два способа управления потоком - императивный через подписки и субьекты, и декларативный через pipe и разные операторы. Когда эти два подхода смешиваются, то получается нечитаемая лапша, подписки в подписках, подписки, в которых делают next субъекты и прочее непотребство.
Особенно много боли возникает, когда из сервиса торчит публичный behaviorSubject. Проблема behSubject в том, что у него есть несколько способов записи значения (initial и next), а так же несколько способов чтения. И при развитии кода он становится мини god-объектом, на котором все завязывается. Половина проекта в него пишет, а другая половина читает. Дебажить и рефакторить это невозможно.
Когда только появились сигналы и было запрещено в effect и compute делать next, то я очень обрадовался. Это бывало неудобно, но принуждало писать хороший незапутанный код.
А linkedSignal - ещё хуже, чем behSubject. Потому что он кроме initial и set имеет ещё один источник изменений. С linkedSignal - мы вообще рехнёмся, потому что там никаких концов уже не сыщешь. В этом графе всё будет переплетаться.
Спасёт ситуацию только если они какой-нибудь крутой дебагер для этого дела напишут.
Я бы забанил linkedSignal линтером на первое время.
Ангуляр пытается внутри сигналов решить многие проблемы. Чтобы наружу торчало простое api. Если им удастся реализовать всю эту машинерию так, чтобы это было безопасно использовать, без мучительно отладки, то сигналы - это, конечно, очень удобно. И linkedSignal тоже. Но я пока не понимаю, как его дебажить.
Он очень удобен. Но это удобство такого же рода, как и глобальные переменные, например. Это очень удобно, пока тебе не надо понимать, что вообще тут происходит.
То есть немецких нацистов зря судили за преступления против человечности? Они ничего не нарушили, ведь как вы говорите учитывали свои собственные интересы. А то что кучу русских сожгли в концлагерях - это русское правительство виновато, не смогло соблюсти интересы своих граждан. Гитлер не виноват нет.
Для меня решающим моментом для перехода на линукс стала скорость работы с файловой системой. На винде удалить и заново поставить node_modules в крупном проекте это прям ДЕЛО - запускаешь и идешь ставить чайник. А на убунте - в пределах минуты.
Я недавно понял, что мне тоже нужна раздельная клавиатура. Но я в этих вопросах довольно инфантильный, сам руками делать не умею, а прежде чем тратить деньги, хочется попробовать что-то бюджетное.
Мне пришла в голову идея взять две дешевых пленочных клавиатуры, подключить их одновременно, отрезать лишние половины корпусов, а внутренности просто скрутить и закрепить.
Фактически, это коррупция. Новые общественные ниши развиваются так быстро, что государство не успевает их регулировать. Коммерческая компания создаёт некоторую нишу, вкладывается в её раскрутку, а потом торгует доверием пользователей, собирая урожай. Потом цикл можно повторить с другим брендом.
Но фактически, это коррупция, которая должна преследоваться законом.
А ещё, бизнес бизнесом, конечно. Дешевизна разработки и всё такое. Но потом работать после таких вот Серёжь - одна сплошная боль. И эту боль не всегда можно измерить в суммах зарплаты. Поэтому с говнокодом надо бороться. И с заказчиками, которые его заказывают - тоже. Надо голосовать ногами против этого. Да, говнокод выгоден заказчику в краткосрочной перспективе, но обычно те заказчики, которые экономят на качестве кода, потом экономят на его рефакторинге. И потом экономят на зарплатах для страдальцев, которые будут этот код поддерживать. Потому что экономия она такая штука - увлекательная.
Понятно, что есть одноразовые проекты, и их не нужно красиво писать. Но обычно то проблема возникает как раз тогда, когда МВП переходит на следующий этап жизненного цикла и никто не хочет тратить деньги на его переписывание, потому что "ну и так же всё работает".
И тут уже разработчик для себя решает, какие косвенные плюшки ему нужны кроме зарплаты: кофе с печеньками, ДМС или качественная кодовая база. И я вот считаю, что качественный код - это прям мощная плюшка. Это как любоваться закатом или жить в помойке. Есть разница.
То есть экономный подход - он вообще не в интересах нашей касты. Это на нас экономят в итоге. И ладно бы только на зарплатах. Так ведь ещё работа с говнокодом немыслимо нервная.
Человек может сам индуцировать себя на более высокий уровень абстракции. Таким образом он получит черед все возрастающих абстракций. Если рассмотреть эту череду как очередную стратегию, то и над этой стратегией можно абстрагируясь подняться, постигнув ещё более высокую стратегию.
Да, многие люди этим не пользуются. Но человек принципиально может это делать. А машина, может ли?
А кого мы считаем теоретиками? Дядюшка Боб - практик.
Программирование - это такое ремесло, где невозможно быть теоретиком.
Таким образом советы именитых программистов - это не оторванные от реальности фантазии. Напротив, это эссенция практического опыта.
В rxjs есть два способа управления потоком - императивный через подписки и субьекты, и декларативный через pipe и разные операторы. Когда эти два подхода смешиваются, то получается нечитаемая лапша, подписки в подписках, подписки, в которых делают next субъекты и прочее непотребство.
Особенно много боли возникает, когда из сервиса торчит публичный behaviorSubject. Проблема behSubject в том, что у него есть несколько способов записи значения (initial и next), а так же несколько способов чтения. И при развитии кода он становится мини god-объектом, на котором все завязывается. Половина проекта в него пишет, а другая половина читает. Дебажить и рефакторить это невозможно.
Когда только появились сигналы и было запрещено в effect и compute делать next, то я очень обрадовался. Это бывало неудобно, но принуждало писать хороший незапутанный код.
А linkedSignal - ещё хуже, чем behSubject. Потому что он кроме initial и set имеет ещё один источник изменений. С linkedSignal - мы вообще рехнёмся, потому что там никаких концов уже не сыщешь. В этом графе всё будет переплетаться.
Спасёт ситуацию только если они какой-нибудь крутой дебагер для этого дела напишут.
Я бы забанил linkedSignal линтером на первое время.
Ангуляр пытается внутри сигналов решить многие проблемы. Чтобы наружу торчало простое api. Если им удастся реализовать всю эту машинерию так, чтобы это было безопасно использовать, без мучительно отладки, то сигналы - это, конечно, очень удобно. И linkedSignal тоже. Но я пока не понимаю, как его дебажить.
Он очень удобен. Но это удобство такого же рода, как и глобальные переменные, например. Это очень удобно, пока тебе не надо понимать, что вообще тут происходит.
То есть немецких нацистов зря судили за преступления против человечности? Они ничего не нарушили, ведь как вы говорите учитывали свои собственные интересы. А то что кучу русских сожгли в концлагерях - это русское правительство виновато, не смогло соблюсти интересы своих граждан. Гитлер не виноват нет.
Так получается?
Для меня решающим моментом для перехода на линукс стала скорость работы с файловой системой. На винде удалить и заново поставить node_modules в крупном проекте это прям ДЕЛО - запускаешь и идешь ставить чайник. А на убунте - в пределах минуты.
Я недавно понял, что мне тоже нужна раздельная клавиатура. Но я в этих вопросах довольно инфантильный, сам руками делать не умею, а прежде чем тратить деньги, хочется попробовать что-то бюджетное.
Мне пришла в голову идея взять две дешевых пленочных клавиатуры, подключить их одновременно, отрезать лишние половины корпусов, а внутренности просто скрутить и закрепить.
А что за специалист, к которому обращались? Как называется специальность?
К сожалению в Nx нету возможности затаскивать стили из одной либы в другую.
Фактически, это коррупция. Новые общественные ниши развиваются так быстро, что государство не успевает их регулировать. Коммерческая компания создаёт некоторую нишу, вкладывается в её раскрутку, а потом торгует доверием пользователей, собирая урожай. Потом цикл можно повторить с другим брендом.
Но фактически, это коррупция, которая должна преследоваться законом.
А ещё, бизнес бизнесом, конечно. Дешевизна разработки и всё такое. Но потом работать после таких вот Серёжь - одна сплошная боль. И эту боль не всегда можно измерить в суммах зарплаты. Поэтому с говнокодом надо бороться. И с заказчиками, которые его заказывают - тоже. Надо голосовать ногами против этого. Да, говнокод выгоден заказчику в краткосрочной перспективе, но обычно те заказчики, которые экономят на качестве кода, потом экономят на его рефакторинге. И потом экономят на зарплатах для страдальцев, которые будут этот код поддерживать. Потому что экономия она такая штука - увлекательная.
Понятно, что есть одноразовые проекты, и их не нужно красиво писать. Но обычно то проблема возникает как раз тогда, когда МВП переходит на следующий этап жизненного цикла и никто не хочет тратить деньги на его переписывание, потому что "ну и так же всё работает".
И тут уже разработчик для себя решает, какие косвенные плюшки ему нужны кроме зарплаты: кофе с печеньками, ДМС или качественная кодовая база. И я вот считаю, что качественный код - это прям мощная плюшка. Это как любоваться закатом или жить в помойке. Есть разница.
То есть экономный подход - он вообще не в интересах нашей касты. Это на нас экономят в итоге. И ладно бы только на зарплатах. Так ведь ещё работа с говнокодом немыслимо нервная.
Полагаю, что многие санкции введены не по идейным соображениям, а ради конъюнктуры. Поэтому мало кто будет всерьёз бороться с серыми схемами.
Да, многие люди этим не пользуются. Но человек принципиально может это делать. А машина, может ли?