А если серьезно, фишка аккумулятора не столько в накоплении с целью перераспределения, сколько в портативности. Я думаю в этом ключе с аккумулятором более сравнима технология беспроводной передачи энергии, при условии тотального покрытия планеты наземными генераторами или спутниками.
Вот с такой технологией уже можно делать прикладные штуки вроде "виртуальных аккумуляторов". Криптовалюту максимум для чего там можно применить - это для оплаты электроэнергии от ближайшего генератора. Но не обязательно proof-of-work.
Но повторяю, это уже прикладной уровень. Который без фундаментальной технологии - беспроводной передачи энергии на сколь-нибдуь вменяемые расстояния, не будет иметь смысла.
Бро, я тебя огорчу, такой "супераккумулятор" на принципе перераспределения энергии уже сделали в середине 20-го века, только без лишнего геморроя с майнингом.
Опять же - всеобщая потребность в крипте и всеобщая потребность в майнинге - немного разные вещи. Ведь большинство людей сейчас, кому нужна крипта, ее тупо покупают. Так проще и дешевле и быстрее. Поэтому даже если все расчеты перевести на крипту с proof-of-work, далеко не все будут непрерывно майнить.
Ладно, допустим я даже майню, но у меня майнинг-ферма физически находится, допустим, на балконе или в гараже, и занимает там пару стелажей с видеокартами или асиками. Допустим я намайнил уже фигову тучу каких-то-коинов. И тут я решил на месяц уехать в тайгу, постичь, так сказать, дзен, уединится от этого бренного мира. Как мне в тайге поможет с электричеством моя ферма, находящаяся у меня в квартире на балконе? Которая к тому же еще и запитана от централизованной электросети. Если я ее выключу, максимум что я получу - это у меня в квартире счетчик будет меньше мотать.
Одно из ключевых свойств аккумулятора - портативность. Где тут портативность, если мне придется с балкона до тайги тянуть линию электропередач на фигову тучу километров, да еще с повышающими и понижающими подстанциями, чтобы дошла хоть какая то вменяемая мощность?
А, я выкупил фишку: вместо того, чтобы решить проблему, можно ее тупо усугубить, причем на порядок, навязав что-то, а потом можно говорить, что проблема решается послаблением этого навязанного. А это самое навязанное - это не усугубление проблемы, а ее "виртуальное решение". Гениально. Главное правительству эту идею не говорить.
Хотя, судя по всему, к сожалению, они уже в курсе этой фишки )))
От супераккумулятора я хочу, например, где нибудь в глухой тайге зарядить севший телефон и ноут, запитать спутниковую тарелку, чтобы выйти в интернет, ну и еще было бы неплохо ночью от него же запитать лампочку в палатке, а если будет холодно, то и какой-нибудь простенький обогреватель, чтобы не жечь дрова. Как это сделать с помощью криптовалюты?
ну я думаю админы зеркала смогут себе позволить время от времени актуализировать данные, разумеется не без помощи добрых людей, живущих за рубежом. Если уж совсем все плохо и зарубежный интернет отрубят физически, будут контрабандой жесткие диски фурами возить через Казахстан например ;-)
А тем, кто на Дальнем Востоке в какую сторону трактор гнать? Китай, Япония, Южная корея? (от меня ближе всего Китай и Монголия, но Монголия точно не вариант). Или лучше на Чукотку покорять берингов пролив? ))
Соц. страх по ГПХ не оплачивается - но там копейки, что то в районе 3-4-х процентов. А в отсальном да, ОПС, ОМС, НДФЛ так же как и по трудовому договору.
А вообще для ясности можно обратиться к первоисточнику - ст. 1295 ГК РФ. Там служебное задание определено как "созданное в пределах установленных для работника (автора) трудовых обязанностей".
Далее сказано, что если работодатель в течение трех лет не начал пользоваться служебным произведением, не сообщит автору о сохранении этого произведения в тайне или не передаст авторские прова другим лицам - исключительное авторское право возвращается автору.
Если в течение трех лет работодатель воспользовался служебным произведением - тогда автор имеет право на авторское вознаграждение.
Про рабочее время и оборудование работодателя там ничего не сказано. Про документирование служебного задания и актах приема-передачи тоже, но это как я понял пункты уже про наличие доказательств того, что произведение создано в рамках трудовых обязанностей и принято работодателем к оплате и использованию.
Вообще по логиге с появлением удаленки и свободного графика - пункт про рабочее время и оборудование работодателя не актуален. На удаленке в большинстве случаев работают за своим компом и в рандомное удобное время. Поэому определяющим фактором наверное все таки должно быть служебное задание.
Это же список обязательных условий. Языком булевой алгебры - между ними не ИЛИ а И. То есь произведение должно быть создано и в рабочее время, и в рамках трудовых обязанностей.
С takeUntil еще можно провернуть вообще без хука OnDestroy в компоненте. Есть решение от Тинькофф с DestroyService, который провайдится в компоненте, инжектится как Observable и делается на этот Observable уже takeUntil. А хук OnDestroy срабатывает не в компоненте, а в сервисе. Получается меньше кода в компонентах.
Приходилось сталкиваться с кодом проектов на jquery + native js + native css + php без фреймворков, где сменилось несколько программистов. Это такая неподдерживаемая солянка, в которой баг можно искать несколько дней, а после добавления каждой фичи нужно детально тестировать всю систему полностью, ибо обязательно где то что то отвалится. Причем отвалится там, где вообще ни разу не ожидаешь.
В отличии от этого ада, проекты на ангуляр после смены нескольких комманд разработчиков хотя бы как-то более-менее поддерживаемы. Фреймворк, ООП и строгая типизация все таки накладывает ограничения, задает какие-никакие стандарты и не позволяет уж совсем люто говнокодить. В стилях компонентов есть инкапсуляция, которая спасает от "эффектов бабочки" (это когда при смене стилей какой нибудь кнопки едет верстка в блоках, которые казалось бы вообще никакого отношения к этой кнопке не имеют). При желании это хоть как-то еще поддается рефакторингу. То же самое могу сказать про бэк - проекты что на .net, что на php-фреймворках наподобие laravell или dle с которыми я сталкивался, были более-менее поддерживаемыми, и хотя некоторые проблемы были, но не настолько фатальные, как с "велосипедными" проектами, где проще выкинуть код на помойку и переписать все с нуля, чем добавить пару новых фич.
Да при желании можно высторить хорошую архитектуру и без фреймворков, но при коммандной разработке или при смене разработчиков все равно получится солянка. Ибо это велосипед, придуманный вами и поддерживать в нормальном виде это сможете поддерживать только вы. А завтра (если вы хороший разработчик и развиваетесь) вас переманили в другую компанию на более хорошие условия. А ваш нынешний работодатель, и последующие за вами разработчики обречены страдать.
Поэтому мое мнение: нативный js может быть еще как-то подойдет для любительских проектов, где вы пишете один в понятном вам одному стиле, и в ваш код больше никто не лезет. Ну или в крайнем случае для быстрой разработки MVP (Minimum Viable Product), либо какого то приложения, которое нужно будет один раз, а потом будет выброшено на помойку.
Но в коммерческой разработке систем средней и большой сложности, и тем более в enterprice только фреймворки, и желательно поддерживающие ООП из коробки (намек на Angular). И лучше всего использовать DDD-подход, и хотя бы на первых этапах разработки не пожалеть денег на дорогого сеньора, который грамотно выстроит архитектуру приложения.
Все хорошо расписано, есть один вопрос: не задумывался, как автоматизировать процесс добавления файлов в public-api.ts, просто компонентов, сервисов, модулей в либое может быть много. А добавлять все в ручную — сам знаешь, мы разрабы народ ленивый ;-)
Слышал про самурай — там через него генеришь компоннеты, модули, сервисы и добавляешь опцию прописать в public-api.ts, но тоже не очень удобное решение.
Может есть решение получше? Хоть самому садись и скрипт пиши :-))
Мы в подобных кейсах используем резолверы. Однако такой подход тоже интересен. Статья хорошая, еще можно было бы добавить подход с резолверами о осветить плюсы и минусы частных провайдеров и резолверов. Или это уже тема для отдельной статьи? ;-)
Вообще да, EventEmitter наследуется от Subject, я раньше запихивал BehaviorSubject в Output и не парился. Потом прочитал где-то, что команда Angular рекомендует использовать в Output только эмиттеры, вроде как для совместимости с более новыми, еще не вышедшими версиями Angular, так как не исключают добавление какой-нибудь специфичной логики в эмиттеры.
Присоединяюсь к комментарию. Данный подход к проектированию достаточно популярен, однако он больше нацелен на исключительно поведенческий вектор наращивания функционала. На практике же, в проектах если не преобладает, то по крайней мере имеет место быть структурный вектор наращивания функционала. То есть очень часто меняется набор полей у классов. Сам нахожусь в поиске элегантных архитектурных решений для реализации простоты структурных изменений.
А если серьезно, фишка аккумулятора не столько в накоплении с целью перераспределения, сколько в портативности. Я думаю в этом ключе с аккумулятором более сравнима технология беспроводной передачи энергии, при условии тотального покрытия планеты наземными генераторами или спутниками.
Вот с такой технологией уже можно делать прикладные штуки вроде "виртуальных аккумуляторов". Криптовалюту максимум для чего там можно применить - это для оплаты электроэнергии от ближайшего генератора. Но не обязательно proof-of-work.
Но повторяю, это уже прикладной уровень. Который без фундаментальной технологии - беспроводной передачи энергии на сколь-нибдуь вменяемые расстояния, не будет иметь смысла.
Бро, я тебя огорчу, такой "супераккумулятор" на принципе перераспределения энергии уже сделали в середине 20-го века, только без лишнего геморроя с майнингом.
https://ru.wikipedia.org/wiki/Единая_энергетическая_система_России
Опять же - всеобщая потребность в крипте и всеобщая потребность в майнинге - немного разные вещи. Ведь большинство людей сейчас, кому нужна крипта, ее тупо покупают. Так проще и дешевле и быстрее. Поэтому даже если все расчеты перевести на крипту с proof-of-work, далеко не все будут непрерывно майнить.
Ладно, допустим я даже майню, но у меня майнинг-ферма физически находится, допустим, на балконе или в гараже, и занимает там пару стелажей с видеокартами или асиками. Допустим я намайнил уже фигову тучу каких-то-коинов. И тут я решил на месяц уехать в тайгу, постичь, так сказать, дзен, уединится от этого бренного мира. Как мне в тайге поможет с электричеством моя ферма, находящаяся у меня в квартире на балконе? Которая к тому же еще и запитана от централизованной электросети. Если я ее выключу, максимум что я получу - это у меня в квартире счетчик будет меньше мотать.
Одно из ключевых свойств аккумулятора - портативность. Где тут портативность, если мне придется с балкона до тайги тянуть линию электропередач на фигову тучу километров, да еще с повышающими и понижающими подстанциями, чтобы дошла хоть какая то вменяемая мощность?
А, я выкупил фишку: вместо того, чтобы решить проблему, можно ее тупо усугубить, причем на порядок, навязав что-то, а потом можно говорить, что проблема решается послаблением этого навязанного. А это самое навязанное - это не усугубление проблемы, а ее "виртуальное решение". Гениально. Главное правительству эту идею не говорить.
Хотя, судя по всему, к сожалению, они уже в курсе этой фишки )))
От супераккумулятора я хочу, например, где нибудь в глухой тайге зарядить севший телефон и ноут, запитать спутниковую тарелку, чтобы выйти в интернет, ну и еще было бы неплохо ночью от него же запитать лампочку в палатке, а если будет холодно, то и какой-нибудь простенький обогреватель, чтобы не жечь дрова. Как это сделать с помощью криптовалюты?
ну я думаю админы зеркала смогут себе позволить время от времени актуализировать данные, разумеется не без помощи добрых людей, живущих за рубежом. Если уж совсем все плохо и зарубежный интернет отрубят физически, будут контрабандой жесткие диски фурами возить через Казахстан например ;-)
А тем, кто на Дальнем Востоке в какую сторону трактор гнать? Китай, Япония, Южная корея? (от меня ближе всего Китай и Монголия, но Монголия точно не вариант). Или лучше на Чукотку покорять берингов пролив? ))
Соц. страх по ГПХ не оплачивается - но там копейки, что то в районе 3-4-х процентов. А в отсальном да, ОПС, ОМС, НДФЛ так же как и по трудовому договору.
А вообще для ясности можно обратиться к первоисточнику - ст. 1295 ГК РФ. Там служебное задание определено как "созданное в пределах установленных для работника (автора) трудовых обязанностей".
Далее сказано, что если работодатель в течение трех лет не начал пользоваться служебным произведением, не сообщит автору о сохранении этого произведения в тайне или не передаст авторские прова другим лицам - исключительное авторское право возвращается автору.
Если в течение трех лет работодатель воспользовался служебным произведением - тогда автор имеет право на авторское вознаграждение.
Про рабочее время и оборудование работодателя там ничего не сказано. Про документирование служебного задания и актах приема-передачи тоже, но это как я понял пункты уже про наличие доказательств того, что произведение создано в рамках трудовых обязанностей и принято работодателем к оплате и использованию.
Вообще по логиге с появлением удаленки и свободного графика - пункт про рабочее время и оборудование работодателя не актуален. На удаленке в большинстве случаев работают за своим компом и в рандомное удобное время. Поэому определяющим фактором наверное все таки должно быть служебное задание.
Это же список обязательных условий. Языком булевой алгебры - между ними не ИЛИ а И. То есь произведение должно быть создано и в рабочее время, и в рамках трудовых обязанностей.
taiga-ui/destroy.service.ts at main · Tinkoff/taiga-ui (github.com)
С takeUntil еще можно провернуть вообще без хука OnDestroy в компоненте. Есть решение от Тинькофф с DestroyService, который провайдится в компоненте, инжектится как Observable и делается на этот Observable уже takeUntil. А хук OnDestroy срабатывает не в компоненте, а в сервисе. Получается меньше кода в компонентах.
Это из серии продать мак бук и уехать в испаноговорящую страну, где все сеньоры? :-)
Приходилось сталкиваться с кодом проектов на jquery + native js + native css + php без фреймворков, где сменилось несколько программистов. Это такая неподдерживаемая солянка, в которой баг можно искать несколько дней, а после добавления каждой фичи нужно детально тестировать всю систему полностью, ибо обязательно где то что то отвалится. Причем отвалится там, где вообще ни разу не ожидаешь.
В отличии от этого ада, проекты на ангуляр после смены нескольких комманд разработчиков хотя бы как-то более-менее поддерживаемы. Фреймворк, ООП и строгая типизация все таки накладывает ограничения, задает какие-никакие стандарты и не позволяет уж совсем люто говнокодить. В стилях компонентов есть инкапсуляция, которая спасает от "эффектов бабочки" (это когда при смене стилей какой нибудь кнопки едет верстка в блоках, которые казалось бы вообще никакого отношения к этой кнопке не имеют). При желании это хоть как-то еще поддается рефакторингу. То же самое могу сказать про бэк - проекты что на .net, что на php-фреймворках наподобие laravell или dle с которыми я сталкивался, были более-менее поддерживаемыми, и хотя некоторые проблемы были, но не настолько фатальные, как с "велосипедными" проектами, где проще выкинуть код на помойку и переписать все с нуля, чем добавить пару новых фич.
Да при желании можно высторить хорошую архитектуру и без фреймворков, но при коммандной разработке или при смене разработчиков все равно получится солянка. Ибо это велосипед, придуманный вами и поддерживать в нормальном виде это сможете поддерживать только вы. А завтра (если вы хороший разработчик и развиваетесь) вас переманили в другую компанию на более хорошие условия. А ваш нынешний работодатель, и последующие за вами разработчики обречены страдать.
Поэтому мое мнение: нативный js может быть еще как-то подойдет для любительских проектов, где вы пишете один в понятном вам одному стиле, и в ваш код больше никто не лезет. Ну или в крайнем случае для быстрой разработки MVP (Minimum Viable Product), либо какого то приложения, которое нужно будет один раз, а потом будет выброшено на помойку.
Но в коммерческой разработке систем средней и большой сложности, и тем более в enterprice только фреймворки, и желательно поддерживающие ООП из коробки (намек на Angular). И лучше всего использовать DDD-подход, и хотя бы на первых этапах разработки не пожалеть денег на дорогого сеньора, который грамотно выстроит архитектуру приложения.
Слышал про самурай — там через него генеришь компоннеты, модули, сервисы и добавляешь опцию прописать в public-api.ts, но тоже не очень удобное решение.
Может есть решение получше? Хоть самому садись и скрипт пиши :-))