Только вот с оптимизацией у Redux я бы сказал абсолютно никак, со структурированием данных тоже не очень. Помимо голого Redux надо тащить за собой ещё пачку библиотек, ибо отдельно юзабелен только для очень мелких проектов.
RxJS по вашему — это магия богов? И простому смертному туда лезть не стоит? Это я так, к примеру.
На собеседовании давать задачи на программирование, мой опыт показывает — бесполезно. Я к примеру всегда давал задачи (на пару часов, для студентов поболее работы, но попроще, часа на 4-6) до собеседования, уже по факту из выполнения решал, есть ли смысл звать на собеседование. На собеседовании уже косвенно проверял, сами ли выполнял тестовое задание, попадались списуны. В общем ну ни разу эта схема не подвела.
Я вообще принципиально никогда не установлю игру так нагло паразитирующую на другом IP. Я такой не один. Да и игра на деле получилась именно такой, как я и ожидал (судя по отзывам). Именно так и выглядят игры — паразиты.
Расход того же изопропилового спирта на DLP в разы выше, я на FDM протру ваткой 1 раз в неделю и хватит, чутка совсем. На DLP же каждая печать, это промывка детали, слив смолы, промывка ванны, промывка стола и т.д.
И вот не стоит думать, что прям вот принтер гермитичен, что-то вот смотрел обзоры на некоторые, так там вообще вентиляция с внешним миром всё время работает.
ABS Like, это видимо на базе стирола, ну ещё один шикарный совет. Что уж мучиться, можно сразу взять и из окна выброситься. Ну и да, для большинства целей и PETG хватит, как замена ABS, при этом нет стирола совсем. Да выше писали, что для выделения стирола надо сильно нагреть, но дело не в этом, в пластике он есть и в свободном виде, так или иначе он будет. Я думаю о вреде можете и сами почитать.
Промывка, расход спирта будет знатный. Дополнительная засветка.
Опять же что-то мне подсказывает, что спирт очень усилит испарение этой самой токсичной смолы, у которой как минимум 3й класс опасности, да плюсом у спирта такая же. Если у вас ещё не начались проблемы с лёгкими, они начнутся. Да и головные боли не верх моих мечтаний, думаю остальные тоже о этом не мечтают. Особенно радует возможность потерять глаз от одной капли этой смолы.
Для DLP/SLS надо хорошую вытяжку, отдельное помещение, дома я такое бы себе никогда не поставил.
Шикарный совет. Смолы токсичные, требуют доп. обработки, будет всё загажено этой смолой. Они хрупкие, печать ничем не быстрее, размеры области печати мизерные.
Был у нас такой менеджер. Ему оставили отдел разработки автономным, так он всех разогнал. В итоге когда мне пришлось поддерживать тот проект, я был в ужасе. Кода много, толку нет. Он при этом познал дзен git и оценивал работу как «добавление — удаления».
Статей таких тьма, ладно, не это страшно. Спасибо за совет, но этот чайник RPI 4 я не хочу использвать, без активного охлаждения под 75 градусов, спасибо, ни за что не буду использовать. Проще использовать какую-нить андроид приставку от китайцев за цену того же порядка.
Правильно ли я понимаю, что inject декоратору аргументом нужно передать готовый внедряемый объект?
Нет конечно, я использовал аналоги интерфейсов на основе абстрактных классов, для этого был ещё доп. декоратор использован abstract, все методы помечались как абстрактные, правда кидали исключение только в рантайме. Совместить с compile-time позволит TS, если это необходимо. Моя реализация похожа на оные для строго типизированных языков, где сервис регистрируется в контейнере по интерфейсу.
Подскажите, в своем JS варианте вы использовали какую-то библиотеку? Если да то какую?
Никаких не использовал, только ES6. Метаинформацию описывал используя декораторы. Внедрить можно было в любой класс, даже незарегистрированный, полям, куда внедрять надо указать внедряемый объект через декоратор inject, для конструкторов привязка шла декоратором на класс. Работает строго для классах.
Я бы посоветовал полноценно понять, что же такое IoC (Inversion of Control) и IoC контейнеры. И после этого пересмотреть свои взгляды. Да, в списке библиотек у вас смешались в кучу кони, люди. Там есть IoC контейнеры, есть просто свободное видение IoC. Ваше же решение, это просто обилие бойлерплейт кода, всё это можно автоматизировать, но у вас надо делать ручками. IoC контейнеры автоматизируют внедрение зависимостей.
Ну и собственно в вашем велосипеде я не увидел самого главного — внедрения зависимостей. Чем ваше решение отличается от простой фабрики?
IoC контейнеры решают множество проблем. Автоматическое внедрение. Во время разработки вы просто меняете сигнатуру конструктора или список публичных параметров (возможно помеченных), и вуаля, ни строчки лишнего кода и там у вас уже будут нужные объекты.
Я конечно понимаю, вы не называли свою статью «IoC контейнеры для упрощения работы DI», но абсолютно не вижу смысла как-то частично автоматизировать внедрение зависимостей.
В общем советую полноценно разобраться с IoC контейнерами и возможно более не будете изобретать подобные велосипеды. При этом на хабре уже есть тьма статей про это. Не смотрите в срезе JS, смотрите теорию, она применима куда угодно. Я реализовывал свои решения на C++ и JS и они в общем-то работают без проблем и выполняют свои задачи. Хотя вроде как языки и не очень хорошо подходят для этого.
P.S. TS преимуществ тут никак не даст, ибо в рантайме есть только JS.
Курсовая? Точно? Я помню как устроился на работу, где 3 человека аж одну дипломную работу делали, так там качество работы даже на курсовую одного с натяжкой тянуло. А здесь всё же поболее курсовой будет.
Отвечаю: — Спасибо, что потратили моё время. И сваливаю.
RxJS по вашему — это магия богов? И простому смертному туда лезть не стоит? Это я так, к примеру.
И вот не стоит думать, что прям вот принтер гермитичен, что-то вот смотрел обзоры на некоторые, так там вообще вентиляция с внешним миром всё время работает.
ABS Like, это видимо на базе стирола, ну ещё один шикарный совет. Что уж мучиться, можно сразу взять и из окна выброситься. Ну и да, для большинства целей и PETG хватит, как замена ABS, при этом нет стирола совсем. Да выше писали, что для выделения стирола надо сильно нагреть, но дело не в этом, в пластике он есть и в свободном виде, так или иначе он будет. Я думаю о вреде можете и сами почитать.
Промывка, расход спирта будет знатный. Дополнительная засветка.
Опять же что-то мне подсказывает, что спирт очень усилит испарение этой самой токсичной смолы, у которой как минимум 3й класс опасности, да плюсом у спирта такая же. Если у вас ещё не начались проблемы с лёгкими, они начнутся. Да и головные боли не верх моих мечтаний, думаю остальные тоже о этом не мечтают. Особенно радует возможность потерять глаз от одной капли этой смолы.
Для DLP/SLS надо хорошую вытяжку, отдельное помещение, дома я такое бы себе никогда не поставил.
Нет конечно, я использовал аналоги интерфейсов на основе абстрактных классов, для этого был ещё доп. декоратор использован abstract, все методы помечались как абстрактные, правда кидали исключение только в рантайме. Совместить с compile-time позволит TS, если это необходимо. Моя реализация похожа на оные для строго типизированных языков, где сервис регистрируется в контейнере по интерфейсу.
Никаких не использовал, только ES6. Метаинформацию описывал используя декораторы. Внедрить можно было в любой класс, даже незарегистрированный, полям, куда внедрять надо указать внедряемый объект через декоратор inject, для конструкторов привязка шла декоратором на класс. Работает строго для классах.
P.S. Ответил не туда.
Ну и собственно в вашем велосипеде я не увидел самого главного — внедрения зависимостей. Чем ваше решение отличается от простой фабрики?
IoC контейнеры решают множество проблем. Автоматическое внедрение. Во время разработки вы просто меняете сигнатуру конструктора или список публичных параметров (возможно помеченных), и вуаля, ни строчки лишнего кода и там у вас уже будут нужные объекты.
Я конечно понимаю, вы не называли свою статью «IoC контейнеры для упрощения работы DI», но абсолютно не вижу смысла как-то частично автоматизировать внедрение зависимостей.
В общем советую полноценно разобраться с IoC контейнерами и возможно более не будете изобретать подобные велосипеды. При этом на хабре уже есть тьма статей про это. Не смотрите в срезе JS, смотрите теорию, она применима куда угодно. Я реализовывал свои решения на C++ и JS и они в общем-то работают без проблем и выполняют свои задачи. Хотя вроде как языки и не очень хорошо подходят для этого.
P.S. TS преимуществ тут никак не даст, ибо в рантайме есть только JS.