Тем разрабам, кто делает на своих сайтах обязательную периодическую смену паролей, надо больно бить по рукам.
Не для всех пользователей смена паролей полезна. Если человек запомнил несколько разных паролей и использует, например, один для малодоверенных сайтов, второй для соцсетей, третий для известных почтовых сервисов, четвертый для платежных систем, пятый для интернет-банкинга, то в таком случае принудительная смена пароля вынудит человека использовать пароль другого целевого назначения, что кратно увеличит вероятность его компроментации.
Один раз выучить пять сложных паролей - это вполне себе посильная задача для обычного человека. А вот периодическая смена только вынуждает либо записывать пароли, либо использовать несколько паролей несистемно. А несистемное использование нескольких паролей может привести к тому, что чел может на каком-нибудь сайте начать вводить их все подряд, потому что забыл, какой именно пароль он использовал здесь. А если этот сайт окажется фишинговым, то он сольет в базу мошенникам все свои пароли.
Стандартная структура проекта, многие так делают. Недостаток в том, что на каком-то этапе папка shared превращается в помойку. Вы сделали разделение в папке shared на компоненты, модули, директивы, пайпы. Я думаю лучше все таки делать разделение по функциональному принципу. Мы вообще UI выносим в библиотеку, так удобнее, а в shared у нас в основном какие-то компоненты, связанные с бизнес-сущностями.
И еще: в shared частая ошибка, что делают один shared модуль и в него все запихивают компонентами, директивами, пайпами итд. Лучше каждую фичу запихивать в свой модуль.
Также в автомобилях низкий КПД обусловлен законами физики, и с этим ничего не поделаешь. А вот существенно снижать КПД неоптимизированными инженерными решениями, причем без увеличения потребительской ценности конечного продукта, по мне такое себе.
Вопрос о КПД может быть и не важен, а вот вопрос оптимизации требований к инфраструктуре беспроводной передачи очень даже важен. Там скорее всего будут очень существенные ограничения по передаваемой мощности, и запитать майнинг-ферму по воздуху точно вряд ли получиться.
Ну и оптимизация нагрузки на инфраструктуру - это одна из задач, которую должен решать прикладной уровень системы. Наряду с удовлетворением потребностей конечного потребителя.
В текущих реалиях и с текущей инфраструктурой это сервис облачного биллинга для энергетиков. В квартирах убирают счетчики, но вешают счетчик на каждый электроприбор, принадлежащий тебе. И ты платишь энергосбыту не за потребление в твоей квартире, а за потребление твоими приборами. Можешь пойти к соседу со своим чайником, тогда платить за потребленную чайником энергию будешь ты. В городах на каждом столбе есть розетка, от которой можно зарядить телефон или ноутбук. Но это точно не замена суперакумулятору.
Если провести параллель с телефонией, вы предлагаете таксофон вместо мобильного телефона.
Выражаясь инженерным языком, ваша идея - это прикладной уровень системы без соответствующей ему инфраструктуры, к тому же оптимизированный не лучшим образом. Требования к инфраструктуре будут очень жесткие (возможность передавать из любой точки планеты в любую другую точку планеты как минимум каких то вменяемых юзабельных энергетических мощностей, а в идеале - неограничено больших мощностей). Плюс к этому сжигание большого количества энергии вникуда за счет майнинга, что создает только еще большую нагрузку на инфраструктуру и снижает ее КПД. На данном этапе развития энергетики, нет подходящей инфраструктуры для такого прикладного уровня, который вы описали. И без реальной, физической технологии беспроводной передачи электроэнергии она вряд ли появится. А если и появится, то есть способы получше оптимизировать перераспределение энергии, нежели сжигание лишней энергии майнингом.
А как известно, прикладной уровень без соответствующего его требованиям инфраструктурного не работает. Это все равно, что пытаться запустить майнинг на деревянных счетах.
Да, но такая система взаимозачетов не будет работать без физической возможности потребления другим человеком моей энергии удаленно, а мною энергии другого человека так же удаленно. Такая модель взаимозачетов отлично подходит для облачных вычислений, для облачного гейминга итд, поскольку там результат вычислений легко передается через высокоскоростные сети передачи данных, но никак ни для энергетики на современном этапе развития. И то это стало возможным только благодаря повсеместному распространению широкополосного интернета. Облачный гейминг с dial-up интернетом вряд ли был бы возможен. Точно так же облачный гейминг не поможет вам в тайге, где не ловит сотовая связь даже на дереве.
А если серьезно, фишка аккумулятора не столько в накоплении с целью перераспределения, сколько в портативности. Я думаю в этом ключе с аккумулятором более сравнима технология беспроводной передачи энергии, при условии тотального покрытия планеты наземными генераторами или спутниками.
Вот с такой технологией уже можно делать прикладные штуки вроде "виртуальных аккумуляторов". Криптовалюту максимум для чего там можно применить - это для оплаты электроэнергии от ближайшего генератора. Но не обязательно proof-of-work.
Но повторяю, это уже прикладной уровень. Который без фундаментальной технологии - беспроводной передачи энергии на сколь-нибдуь вменяемые расстояния, не будет иметь смысла.
Бро, я тебя огорчу, такой "супераккумулятор" на принципе перераспределения энергии уже сделали в середине 20-го века, только без лишнего геморроя с майнингом.
Опять же - всеобщая потребность в крипте и всеобщая потребность в майнинге - немного разные вещи. Ведь большинство людей сейчас, кому нужна крипта, ее тупо покупают. Так проще и дешевле и быстрее. Поэтому даже если все расчеты перевести на крипту с proof-of-work, далеко не все будут непрерывно майнить.
Ладно, допустим я даже майню, но у меня майнинг-ферма физически находится, допустим, на балконе или в гараже, и занимает там пару стелажей с видеокартами или асиками. Допустим я намайнил уже фигову тучу каких-то-коинов. И тут я решил на месяц уехать в тайгу, постичь, так сказать, дзен, уединится от этого бренного мира. Как мне в тайге поможет с электричеством моя ферма, находящаяся у меня в квартире на балконе? Которая к тому же еще и запитана от централизованной электросети. Если я ее выключу, максимум что я получу - это у меня в квартире счетчик будет меньше мотать.
Одно из ключевых свойств аккумулятора - портативность. Где тут портативность, если мне придется с балкона до тайги тянуть линию электропередач на фигову тучу километров, да еще с повышающими и понижающими подстанциями, чтобы дошла хоть какая то вменяемая мощность?
А, я выкупил фишку: вместо того, чтобы решить проблему, можно ее тупо усугубить, причем на порядок, навязав что-то, а потом можно говорить, что проблема решается послаблением этого навязанного. А это самое навязанное - это не усугубление проблемы, а ее "виртуальное решение". Гениально. Главное правительству эту идею не говорить.
Хотя, судя по всему, к сожалению, они уже в курсе этой фишки )))
От супераккумулятора я хочу, например, где нибудь в глухой тайге зарядить севший телефон и ноут, запитать спутниковую тарелку, чтобы выйти в интернет, ну и еще было бы неплохо ночью от него же запитать лампочку в палатке, а если будет холодно, то и какой-нибудь простенький обогреватель, чтобы не жечь дрова. Как это сделать с помощью криптовалюты?
ну я думаю админы зеркала смогут себе позволить время от времени актуализировать данные, разумеется не без помощи добрых людей, живущих за рубежом. Если уж совсем все плохо и зарубежный интернет отрубят физически, будут контрабандой жесткие диски фурами возить через Казахстан например ;-)
А тем, кто на Дальнем Востоке в какую сторону трактор гнать? Китай, Япония, Южная корея? (от меня ближе всего Китай и Монголия, но Монголия точно не вариант). Или лучше на Чукотку покорять берингов пролив? ))
Соц. страх по ГПХ не оплачивается - но там копейки, что то в районе 3-4-х процентов. А в отсальном да, ОПС, ОМС, НДФЛ так же как и по трудовому договору.
А вообще для ясности можно обратиться к первоисточнику - ст. 1295 ГК РФ. Там служебное задание определено как "созданное в пределах установленных для работника (автора) трудовых обязанностей".
Далее сказано, что если работодатель в течение трех лет не начал пользоваться служебным произведением, не сообщит автору о сохранении этого произведения в тайне или не передаст авторские прова другим лицам - исключительное авторское право возвращается автору.
Если в течение трех лет работодатель воспользовался служебным произведением - тогда автор имеет право на авторское вознаграждение.
Про рабочее время и оборудование работодателя там ничего не сказано. Про документирование служебного задания и актах приема-передачи тоже, но это как я понял пункты уже про наличие доказательств того, что произведение создано в рамках трудовых обязанностей и принято работодателем к оплате и использованию.
Вообще по логиге с появлением удаленки и свободного графика - пункт про рабочее время и оборудование работодателя не актуален. На удаленке в большинстве случаев работают за своим компом и в рандомное удобное время. Поэому определяющим фактором наверное все таки должно быть служебное задание.
Это же список обязательных условий. Языком булевой алгебры - между ними не ИЛИ а И. То есь произведение должно быть создано и в рабочее время, и в рамках трудовых обязанностей.
С takeUntil еще можно провернуть вообще без хука OnDestroy в компоненте. Есть решение от Тинькофф с DestroyService, который провайдится в компоненте, инжектится как Observable и делается на этот Observable уже takeUntil. А хук OnDestroy срабатывает не в компоненте, а в сервисе. Получается меньше кода в компонентах.
Тем разрабам, кто делает на своих сайтах обязательную периодическую смену паролей, надо больно бить по рукам.
Не для всех пользователей смена паролей полезна. Если человек запомнил несколько разных паролей и использует, например, один для малодоверенных сайтов, второй для соцсетей, третий для известных почтовых сервисов, четвертый для платежных систем, пятый для интернет-банкинга, то в таком случае принудительная смена пароля вынудит человека использовать пароль другого целевого назначения, что кратно увеличит вероятность его компроментации.
Один раз выучить пять сложных паролей - это вполне себе посильная задача для обычного человека. А вот периодическая смена только вынуждает либо записывать пароли, либо использовать несколько паролей несистемно. А несистемное использование нескольких паролей может привести к тому, что чел может на каком-нибудь сайте начать вводить их все подряд, потому что забыл, какой именно пароль он использовал здесь. А если этот сайт окажется фишинговым, то он сольет в базу мошенникам все свои пароли.
Стандартная структура проекта, многие так делают. Недостаток в том, что на каком-то этапе папка shared превращается в помойку. Вы сделали разделение в папке shared на компоненты, модули, директивы, пайпы. Я думаю лучше все таки делать разделение по функциональному принципу. Мы вообще UI выносим в библиотеку, так удобнее, а в shared у нас в основном какие-то компоненты, связанные с бизнес-сущностями.
И еще: в shared частая ошибка, что делают один shared модуль и в него все запихивают компонентами, директивами, пайпами итд. Лучше каждую фичу запихивать в свой модуль.
Также в автомобилях низкий КПД обусловлен законами физики, и с этим ничего не поделаешь. А вот существенно снижать КПД неоптимизированными инженерными решениями, причем без увеличения потребительской ценности конечного продукта, по мне такое себе.
Вопрос о КПД может быть и не важен, а вот вопрос оптимизации требований к инфраструктуре беспроводной передачи очень даже важен. Там скорее всего будут очень существенные ограничения по передаваемой мощности, и запитать майнинг-ферму по воздуху точно вряд ли получиться.
Ну и оптимизация нагрузки на инфраструктуру - это одна из задач, которую должен решать прикладной уровень системы. Наряду с удовлетворением потребностей конечного потребителя.
В текущих реалиях и с текущей инфраструктурой это сервис облачного биллинга для энергетиков. В квартирах убирают счетчики, но вешают счетчик на каждый электроприбор, принадлежащий тебе. И ты платишь энергосбыту не за потребление в твоей квартире, а за потребление твоими приборами. Можешь пойти к соседу со своим чайником, тогда платить за потребленную чайником энергию будешь ты. В городах на каждом столбе есть розетка, от которой можно зарядить телефон или ноутбук. Но это точно не замена суперакумулятору.
Если провести параллель с телефонией, вы предлагаете таксофон вместо мобильного телефона.
Выражаясь инженерным языком, ваша идея - это прикладной уровень системы без соответствующей ему инфраструктуры, к тому же оптимизированный не лучшим образом. Требования к инфраструктуре будут очень жесткие (возможность передавать из любой точки планеты в любую другую точку планеты как минимум каких то вменяемых юзабельных энергетических мощностей, а в идеале - неограничено больших мощностей). Плюс к этому сжигание большого количества энергии вникуда за счет майнинга, что создает только еще большую нагрузку на инфраструктуру и снижает ее КПД. На данном этапе развития энергетики, нет подходящей инфраструктуры для такого прикладного уровня, который вы описали. И без реальной, физической технологии беспроводной передачи электроэнергии она вряд ли появится. А если и появится, то есть способы получше оптимизировать перераспределение энергии, нежели сжигание лишней энергии майнингом.
А как известно, прикладной уровень без соответствующего его требованиям инфраструктурного не работает. Это все равно, что пытаться запустить майнинг на деревянных счетах.
Да, но такая система взаимозачетов не будет работать без физической возможности потребления другим человеком моей энергии удаленно, а мною энергии другого человека так же удаленно. Такая модель взаимозачетов отлично подходит для облачных вычислений, для облачного гейминга итд, поскольку там результат вычислений легко передается через высокоскоростные сети передачи данных, но никак ни для энергетики на современном этапе развития. И то это стало возможным только благодаря повсеместному распространению широкополосного интернета. Облачный гейминг с dial-up интернетом вряд ли был бы возможен. Точно так же облачный гейминг не поможет вам в тайге, где не ловит сотовая связь даже на дереве.
А если серьезно, фишка аккумулятора не столько в накоплении с целью перераспределения, сколько в портативности. Я думаю в этом ключе с аккумулятором более сравнима технология беспроводной передачи энергии, при условии тотального покрытия планеты наземными генераторами или спутниками.
Вот с такой технологией уже можно делать прикладные штуки вроде "виртуальных аккумуляторов". Криптовалюту максимум для чего там можно применить - это для оплаты электроэнергии от ближайшего генератора. Но не обязательно 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 срабатывает не в компоненте, а в сервисе. Получается меньше кода в компонентах.