Кто-то хоть где-то говорил о феминистках? Есть, однако, популярное мнение у некоторых феминисток, разделяемое некоторым количеством людей, что это действительно эксплуатация. И это действительно так, для чего достаточно послушать бывших порноактрис, например.
Чем в вашем понимании отличается эксплуатация от трудовой деятельности в суровых реалиях в РФ? Сравните труд порноактрис и труд врачей в государственных больницах, которые за 20-30к в месяц работают по 70 часов в неделю. Давайте тогда запретим медицину? Это тоже эксплуатация. Также агрумент "послушать бывших порноактрис", которым после выхода на раннюю пенсию хочется сохранить былой уровень жизни, и ради этого они готовы хайповать на чем угодно - ну мягко говоря, слабенький. В моем понимании эксплуатация - это извлечение выгоды из принудительного труда, либо из якобы-добровольного труда без достойной компенсации, используя безвыходное положение жертвы. Если исходить из такого понятия, и учитывая, что никто никого в порноиндустрию насильно не тянет, а идут туда люди сами, и получают при этом вполне себе достойную оплату своего труда - эксплуатацией тут даже не пахнет.
Да, и предоставить договор с работодателем об удаленной работе, в котором указано, что доступ к сети работодателя осуществляется через VPN. И пусть компенсируют вынужденный простой сеньор-разработчика по соответствующей тарифной ставке )
Ну называть мнение радикальных феминисток "вполне себе популярным" и использовать его где то в качестве аргумента - такое себе. Так можно дойти до апеллирования к мнению эмо, готов или скинхедов каких-нибудь.
утверждение о том, что прон не несет никому никакого вреда отчасти верное. Вред несет его чрезмерное злоупотребление. Не путайте эти две разные вещи. Если я правильно понял, в данных исследованиях установлена корреляция, что у людей, злоупотребляющих просмотром порно, дофаминовая система в более худшем состоянии, чем у контрольной группы, так? Но не учитывается тот факт, что люди, злоупотребляющие просмотром порно скорее всего относятся к разряду "кайфожоров". И проблема тут не в наличии у них доступа к порно, а в их самодисциплине, а точнее в ее отсутствии. Есть много людей, кто время от времени заходит посмотреть что-то "горяченькое", но не подсаживается на это и не испытывает каких-то проблем с мотивацией.
Есть вещи, такие как тяжелые наркотики, которые вызывают зависимость у всех или почти у всех после первого - второго применения - такие вещи безусловно нужно запрещать, поскольку они несут угрозу обществу, а также жизням и здоровью людей.
Есть вещи, такие как алкоголь и сладкая еда, которые вредны только при злоупотреблении, но наносят вред как дофаминовой системе, так и физическому здоровью людей (алкоголь вызывает цирроз печени, сахар - метаболический синдром с кучей негативных последствий), и в перспективе снижают не только качество, но и продолжительность жизни.
А есть такие вещи как порно, развлекательный контент, видеоигры, итд которые только при их злоупотреблении могут якобы наносить вред дофаминовой системе человека. Однако их разумное и умеренное потребление никакого вреда не приносит.
И было бы логично запрещать их именно в таком порядке. А у нас алкоголь в свободной продаже с некоторыми ограничениями по возрасту, сладкая пища вообще в свободной продаже без ограничений по возрасту. О каком запрете порно может идти речь?
С точки зрения практической пользы есть проблемы: чтобы пойти домой тебе в любом случае нужно где-то припарковать автомобиль. То есть либо кого-то подпереть, либо встать далеко от дома. В первом случае возникает риск того, что подпертый тобой автомобиль захочет уехать раньше, чем на парковке освободиться место. Во втором случае тебе по сигналу нейросети придется ножками топать до того места, куда ты припарковал авто (какая разница топать сейчас чтобы переставить машину или завтра утром?). И не факт, что за это время место уже кто-нибудь не займет.
Поэтому такая фича была бы полезна как опция автопилота, но в случае с опцией автопилота разумнее отслеживать не освобождение мест на парковке, а момента, когда подпертый тобой автомобиль захочет выехать, чтобы автопилот его выпустил, ну и возможно встал на его место.
Опять же, ваша модель скорее всего подойдет для каких-нибудь парковок в торговых центрах. Вешается табло на въезде, где отображается количество свободных мест. Если свободных мест нет, то водители будут это видеть и не будут заезжать на перегруженную парковку. Хотя для этой задачи есть более простое решение с подсчетом количества заехавших и выехавших машин. Но у вашего решения есть небольшое преимущество: свободное место на табло появится как только машина освободила парковочное место. А в варианте с подсчетом только когда машина выехала за территорию парковки. Но количество заехавших все равно придется считать, чтобы считать освободившееся место занятым после въезда автомобиля на территорию парковки, а то заедут две машины на одно свободное место и устроят мордобой )
А потом после сдачи проекта меняется начальство у заказчика приходят аудиторы, и трясут подрядчика: за что 5 миллионов? Возвращайте деньги государству )
Из реально полезных инструментов генерации кода - это схематики и генераторы апи-клиентов с ДТО-шками из сваггера. Было бы интересно видеть добавлении ИИ в эти инструменты.
Copilot скорее всего не напишет вам бизнес-логику, потому что она специфична. Единственное, для чего он хорош - это писать велосипеды, которые, чего греха таить, мы все любим. Но по-правильному, если этот код уже написан, то нужно его переиспользовать - либо из сторонней библиотеки, либо со своего же модуля, а не копипастить.
Я все-таки склоняюсь к мысли - если в вашем проекте есть реальная польза от Copilot, значит у вас скорее всего что-то не то с архитектурой.
Делать стилизацию, добавлять dragNdrop, и прочие подобные вещи наверное все-таки лучше не через композицию, а добавлением директивы к компоненту уже в месте использования. Ибо требования бизнеса непредсказуемы, сегодня бизнес хочет только красные карточки такого дизайна и с draggable, а завтра захотел такие же, но зеленые, и без draggable, но с каким-нибудь тултипом при наведении. И делать ради этого еще один такой же компонент с композицией других директив - мягко говоря решение не очень. Либо придется выпиливать композицию из компонента, и добавлять директиву во всех местах в коде, где используется данных компонент.
А вот пример с отпиской прям огонь. Тут композиция по мне гораздо лучше всех известных на данный момент способов отписки, ну разве что кроме DestroyService от Тинькофф. Недостаток с более ранним выполнением ngOnDestroy думаю вообще не критичный, очень маловероятно, что в OnDestroy компонента понадобиться "живой" observable.
Ну по большому счету, если речь идет о SPA (а ангуляр предназначен для SPA), для фронта нет разницы, какой фреймворк на бэке. Взаимодействие через REST-API стандартное, что с Django что с .NET что со Spring. Шлете себе запросы через HttpClient и работаете дальше с полученным Observable. Нет там никаких особенностей, тем более в таком объеме, что хватило бы на целую книгу. Если вы фулстек, изучайте по отдельности Angular и Django.
Там как правило еще использвется старая неудобная версия CSS2 и без препроцессоров, переделывать все стили на CSS3 и адаптировать уже никому не хочется, тогда уж переделывать весь сайт на что-нибудь более новое.
Ну почему же, еще Firefox и Opera - у них свои движки, но они более менее следуют общепринятым Web-стандартам. Правда они уже не столь популярны, как некогда в 10-х.
Тем разрабам, кто делает на своих сайтах обязательную периодическую смену паролей, надо больно бить по рукам.
Не для всех пользователей смена паролей полезна. Если человек запомнил несколько разных паролей и использует, например, один для малодоверенных сайтов, второй для соцсетей, третий для известных почтовых сервисов, четвертый для платежных систем, пятый для интернет-банкинга, то в таком случае принудительная смена пароля вынудит человека использовать пароль другого целевого назначения, что кратно увеличит вероятность его компроментации.
Один раз выучить пять сложных паролей - это вполне себе посильная задача для обычного человека. А вот периодическая смена только вынуждает либо записывать пароли, либо использовать несколько паролей несистемно. А несистемное использование нескольких паролей может привести к тому, что чел может на каком-нибудь сайте начать вводить их все подряд, потому что забыл, какой именно пароль он использовал здесь. А если этот сайт окажется фишинговым, то он сольет в базу мошенникам все свои пароли.
Стандартная структура проекта, многие так делают. Недостаток в том, что на каком-то этапе папка shared превращается в помойку. Вы сделали разделение в папке shared на компоненты, модули, директивы, пайпы. Я думаю лучше все таки делать разделение по функциональному принципу. Мы вообще UI выносим в библиотеку, так удобнее, а в shared у нас в основном какие-то компоненты, связанные с бизнес-сущностями.
И еще: в shared частая ошибка, что делают один shared модуль и в него все запихивают компонентами, директивами, пайпами итд. Лучше каждую фичу запихивать в свой модуль.
Также в автомобилях низкий КПД обусловлен законами физики, и с этим ничего не поделаешь. А вот существенно снижать КПД неоптимизированными инженерными решениями, причем без увеличения потребительской ценности конечного продукта, по мне такое себе.
Вопрос о КПД может быть и не важен, а вот вопрос оптимизации требований к инфраструктуре беспроводной передачи очень даже важен. Там скорее всего будут очень существенные ограничения по передаваемой мощности, и запитать майнинг-ферму по воздуху точно вряд ли получиться.
Ну и оптимизация нагрузки на инфраструктуру - это одна из задач, которую должен решать прикладной уровень системы. Наряду с удовлетворением потребностей конечного потребителя.
В текущих реалиях и с текущей инфраструктурой это сервис облачного биллинга для энергетиков. В квартирах убирают счетчики, но вешают счетчик на каждый электроприбор, принадлежащий тебе. И ты платишь энергосбыту не за потребление в твоей квартире, а за потребление твоими приборами. Можешь пойти к соседу со своим чайником, тогда платить за потребленную чайником энергию будешь ты. В городах на каждом столбе есть розетка, от которой можно зарядить телефон или ноутбук. Но это точно не замена суперакумулятору.
Если провести параллель с телефонией, вы предлагаете таксофон вместо мобильного телефона.
Выражаясь инженерным языком, ваша идея - это прикладной уровень системы без соответствующей ему инфраструктуры, к тому же оптимизированный не лучшим образом. Требования к инфраструктуре будут очень жесткие (возможность передавать из любой точки планеты в любую другую точку планеты как минимум каких то вменяемых юзабельных энергетических мощностей, а в идеале - неограничено больших мощностей). Плюс к этому сжигание большого количества энергии вникуда за счет майнинга, что создает только еще большую нагрузку на инфраструктуру и снижает ее КПД. На данном этапе развития энергетики, нет подходящей инфраструктуры для такого прикладного уровня, который вы описали. И без реальной, физической технологии беспроводной передачи электроэнергии она вряд ли появится. А если и появится, то есть способы получше оптимизировать перераспределение энергии, нежели сжигание лишней энергии майнингом.
А как известно, прикладной уровень без соответствующего его требованиям инфраструктурного не работает. Это все равно, что пытаться запустить майнинг на деревянных счетах.
Да, но такая система взаимозачетов не будет работать без физической возможности потребления другим человеком моей энергии удаленно, а мною энергии другого человека так же удаленно. Такая модель взаимозачетов отлично подходит для облачных вычислений, для облачного гейминга итд, поскольку там результат вычислений легко передается через высокоскоростные сети передачи данных, но никак ни для энергетики на современном этапе развития. И то это стало возможным только благодаря повсеместному распространению широкополосного интернета. Облачный гейминг с dial-up интернетом вряд ли был бы возможен. Точно так же облачный гейминг не поможет вам в тайге, где не ловит сотовая связь даже на дереве.
Чем в вашем понимании отличается эксплуатация от трудовой деятельности в суровых реалиях в РФ? Сравните труд порноактрис и труд врачей в государственных больницах, которые за 20-30к в месяц работают по 70 часов в неделю. Давайте тогда запретим медицину? Это тоже эксплуатация.
Также агрумент "послушать бывших порноактрис", которым после выхода на раннюю пенсию хочется сохранить былой уровень жизни, и ради этого они готовы хайповать на чем угодно - ну мягко говоря, слабенький.
В моем понимании эксплуатация - это извлечение выгоды из принудительного труда, либо из якобы-добровольного труда без достойной компенсации, используя безвыходное положение жертвы. Если исходить из такого понятия, и учитывая, что никто никого в порноиндустрию насильно не тянет, а идут туда люди сами, и получают при этом вполне себе достойную оплату своего труда - эксплуатацией тут даже не пахнет.
Да, и предоставить договор с работодателем об удаленной работе, в котором указано, что доступ к сети работодателя осуществляется через VPN. И пусть компенсируют вынужденный простой сеньор-разработчика по соответствующей тарифной ставке )
Ну называть мнение радикальных феминисток "вполне себе популярным" и использовать его где то в качестве аргумента - такое себе. Так можно дойти до апеллирования к мнению эмо, готов или скинхедов каких-нибудь.
утверждение о том, что прон не несет никому никакого вреда отчасти верное. Вред несет его чрезмерное злоупотребление. Не путайте эти две разные вещи. Если я правильно понял, в данных исследованиях установлена корреляция, что у людей, злоупотребляющих просмотром порно, дофаминовая система в более худшем состоянии, чем у контрольной группы, так? Но не учитывается тот факт, что люди, злоупотребляющие просмотром порно скорее всего относятся к разряду "кайфожоров". И проблема тут не в наличии у них доступа к порно, а в их самодисциплине, а точнее в ее отсутствии. Есть много людей, кто время от времени заходит посмотреть что-то "горяченькое", но не подсаживается на это и не испытывает каких-то проблем с мотивацией.
Есть вещи, такие как тяжелые наркотики, которые вызывают зависимость у всех или почти у всех после первого - второго применения - такие вещи безусловно нужно запрещать, поскольку они несут угрозу обществу, а также жизням и здоровью людей.
Есть вещи, такие как алкоголь и сладкая еда, которые вредны только при злоупотреблении, но наносят вред как дофаминовой системе, так и физическому здоровью людей (алкоголь вызывает цирроз печени, сахар - метаболический синдром с кучей негативных последствий), и в перспективе снижают не только качество, но и продолжительность жизни.
А есть такие вещи как порно, развлекательный контент, видеоигры, итд которые только при их злоупотреблении могут якобы наносить вред дофаминовой системе человека. Однако их разумное и умеренное потребление никакого вреда не приносит.
И было бы логично запрещать их именно в таком порядке. А у нас алкоголь в свободной продаже с некоторыми ограничениями по возрасту, сладкая пища вообще в свободной продаже без ограничений по возрасту. О каком запрете порно может идти речь?
На дофаминовую систему гораздо хуже влияют листание ленты в вк и бессмысленных коротких видео по типу тик-тока, шотсов в ютубе и клипов в вк
С точки зрения практической пользы есть проблемы: чтобы пойти домой тебе в любом случае нужно где-то припарковать автомобиль. То есть либо кого-то подпереть, либо встать далеко от дома. В первом случае возникает риск того, что подпертый тобой автомобиль захочет уехать раньше, чем на парковке освободиться место. Во втором случае тебе по сигналу нейросети придется ножками топать до того места, куда ты припарковал авто (какая разница топать сейчас чтобы переставить машину или завтра утром?). И не факт, что за это время место уже кто-нибудь не займет.
Поэтому такая фича была бы полезна как опция автопилота, но в случае с опцией автопилота разумнее отслеживать не освобождение мест на парковке, а момента, когда подпертый тобой автомобиль захочет выехать, чтобы автопилот его выпустил, ну и возможно встал на его место.
Опять же, ваша модель скорее всего подойдет для каких-нибудь парковок в торговых центрах. Вешается табло на въезде, где отображается количество свободных мест. Если свободных мест нет, то водители будут это видеть и не будут заезжать на перегруженную парковку. Хотя для этой задачи есть более простое решение с подсчетом количества заехавших и выехавших машин. Но у вашего решения есть небольшое преимущество: свободное место на табло появится как только машина освободила парковочное место. А в варианте с подсчетом только когда машина выехала за территорию парковки. Но количество заехавших все равно придется считать, чтобы считать освободившееся место занятым после въезда автомобиля на территорию парковки, а то заедут две машины на одно свободное место и устроят мордобой )
А потом после сдачи проекта меняется начальство у заказчика приходят аудиторы, и трясут подрядчика: за что 5 миллионов? Возвращайте деньги государству )
Из реально полезных инструментов генерации кода - это схематики и генераторы апи-клиентов с ДТО-шками из сваггера. Было бы интересно видеть добавлении ИИ в эти инструменты.
Copilot скорее всего не напишет вам бизнес-логику, потому что она специфична. Единственное, для чего он хорош - это писать велосипеды, которые, чего греха таить, мы все любим. Но по-правильному, если этот код уже написан, то нужно его переиспользовать - либо из сторонней библиотеки, либо со своего же модуля, а не копипастить.
Я все-таки склоняюсь к мысли - если в вашем проекте есть реальная польза от Copilot, значит у вас скорее всего что-то не то с архитектурой.
Делать стилизацию, добавлять dragNdrop, и прочие подобные вещи наверное все-таки лучше не через композицию, а добавлением директивы к компоненту уже в месте использования. Ибо требования бизнеса непредсказуемы, сегодня бизнес хочет только красные карточки такого дизайна и с draggable, а завтра захотел такие же, но зеленые, и без draggable, но с каким-нибудь тултипом при наведении. И делать ради этого еще один такой же компонент с композицией других директив - мягко говоря решение не очень. Либо придется выпиливать композицию из компонента, и добавлять директиву во всех местах в коде, где используется данных компонент.
А вот пример с отпиской прям огонь. Тут композиция по мне гораздо лучше всех известных на данный момент способов отписки, ну разве что кроме DestroyService от Тинькофф. Недостаток с более ранним выполнением ngOnDestroy думаю вообще не критичный, очень маловероятно, что в OnDestroy компонента понадобиться "живой" observable.
Ну по большому счету, если речь идет о SPA (а ангуляр предназначен для SPA), для фронта нет разницы, какой фреймворк на бэке. Взаимодействие через REST-API стандартное, что с Django что с .NET что со Spring. Шлете себе запросы через HttpClient и работаете дальше с полученным Observable. Нет там никаких особенностей, тем более в таком объеме, что хватило бы на целую книгу. Если вы фулстек, изучайте по отдельности Angular и Django.
Там как правило еще использвется старая неудобная версия CSS2 и без препроцессоров, переделывать все стили на CSS3 и адаптировать уже никому не хочется, тогда уж переделывать весь сайт на что-нибудь более новое.
Ну почему же, еще Firefox и Opera - у них свои движки, но они более менее следуют общепринятым Web-стандартам. Правда они уже не столь популярны, как некогда в 10-х.
Тем разрабам, кто делает на своих сайтах обязательную периодическую смену паролей, надо больно бить по рукам.
Не для всех пользователей смена паролей полезна. Если человек запомнил несколько разных паролей и использует, например, один для малодоверенных сайтов, второй для соцсетей, третий для известных почтовых сервисов, четвертый для платежных систем, пятый для интернет-банкинга, то в таком случае принудительная смена пароля вынудит человека использовать пароль другого целевого назначения, что кратно увеличит вероятность его компроментации.
Один раз выучить пять сложных паролей - это вполне себе посильная задача для обычного человека. А вот периодическая смена только вынуждает либо записывать пароли, либо использовать несколько паролей несистемно. А несистемное использование нескольких паролей может привести к тому, что чел может на каком-нибудь сайте начать вводить их все подряд, потому что забыл, какой именно пароль он использовал здесь. А если этот сайт окажется фишинговым, то он сольет в базу мошенникам все свои пароли.
Стандартная структура проекта, многие так делают. Недостаток в том, что на каком-то этапе папка shared превращается в помойку. Вы сделали разделение в папке shared на компоненты, модули, директивы, пайпы. Я думаю лучше все таки делать разделение по функциональному принципу. Мы вообще UI выносим в библиотеку, так удобнее, а в shared у нас в основном какие-то компоненты, связанные с бизнес-сущностями.
И еще: в shared частая ошибка, что делают один shared модуль и в него все запихивают компонентами, директивами, пайпами итд. Лучше каждую фичу запихивать в свой модуль.
Также в автомобилях низкий КПД обусловлен законами физики, и с этим ничего не поделаешь. А вот существенно снижать КПД неоптимизированными инженерными решениями, причем без увеличения потребительской ценности конечного продукта, по мне такое себе.
Вопрос о КПД может быть и не важен, а вот вопрос оптимизации требований к инфраструктуре беспроводной передачи очень даже важен. Там скорее всего будут очень существенные ограничения по передаваемой мощности, и запитать майнинг-ферму по воздуху точно вряд ли получиться.
Ну и оптимизация нагрузки на инфраструктуру - это одна из задач, которую должен решать прикладной уровень системы. Наряду с удовлетворением потребностей конечного потребителя.
В текущих реалиях и с текущей инфраструктурой это сервис облачного биллинга для энергетиков. В квартирах убирают счетчики, но вешают счетчик на каждый электроприбор, принадлежащий тебе. И ты платишь энергосбыту не за потребление в твоей квартире, а за потребление твоими приборами. Можешь пойти к соседу со своим чайником, тогда платить за потребленную чайником энергию будешь ты. В городах на каждом столбе есть розетка, от которой можно зарядить телефон или ноутбук. Но это точно не замена суперакумулятору.
Если провести параллель с телефонией, вы предлагаете таксофон вместо мобильного телефона.
Выражаясь инженерным языком, ваша идея - это прикладной уровень системы без соответствующей ему инфраструктуры, к тому же оптимизированный не лучшим образом. Требования к инфраструктуре будут очень жесткие (возможность передавать из любой точки планеты в любую другую точку планеты как минимум каких то вменяемых юзабельных энергетических мощностей, а в идеале - неограничено больших мощностей). Плюс к этому сжигание большого количества энергии вникуда за счет майнинга, что создает только еще большую нагрузку на инфраструктуру и снижает ее КПД. На данном этапе развития энергетики, нет подходящей инфраструктуры для такого прикладного уровня, который вы описали. И без реальной, физической технологии беспроводной передачи электроэнергии она вряд ли появится. А если и появится, то есть способы получше оптимизировать перераспределение энергии, нежели сжигание лишней энергии майнингом.
А как известно, прикладной уровень без соответствующего его требованиям инфраструктурного не работает. Это все равно, что пытаться запустить майнинг на деревянных счетах.
Да, но такая система взаимозачетов не будет работать без физической возможности потребления другим человеком моей энергии удаленно, а мною энергии другого человека так же удаленно. Такая модель взаимозачетов отлично подходит для облачных вычислений, для облачного гейминга итд, поскольку там результат вычислений легко передается через высокоскоростные сети передачи данных, но никак ни для энергетики на современном этапе развития. И то это стало возможным только благодаря повсеместному распространению широкополосного интернета. Облачный гейминг с dial-up интернетом вряд ли был бы возможен. Точно так же облачный гейминг не поможет вам в тайге, где не ловит сотовая связь даже на дереве.