Не вижу никакой политической ангажированности. Если компания собирает данные американских граждан, и к этим данным возникают вопросы, то, когда компания американская, с ней можно что-то сделать по американским законам. А когда компания китайская, то сделать что-то по американским законам уже не получится ( кроме блокировки дальнейшей деятельности компании в США). ChatGPT несёт похожие риски для всех стран, кроме Америки. Да, в общем-то, любой софт, собирающий данные пользователей.
К сожалению, тот же размер заголовка первого уровня меняется нелинейно. А как только появляются медиа-запросы, смысл в формулах пропадает, можно сразу указать конечное значение.
Здесь вопрос сразу: если это никто и не будет в будущем трогать, то почему не использовать эту известную всем идиому с имплементацией интерфейса, а не запихивать if..else в методы.
Здесь речь в том числе и о том, что есть религиозное "тут нарушен SOLID, надо потратить ресурсы и переделать", а есть "да, SOLID тут нарушен, но пофиг, так как никакого развития кода тут не будет, конечная остановка".
А если у калькулятора будет не один calculateTotal, а 4-5 методов?
Так об этом и речь дальше: если сложность перешагнула некоторую точку, то нужно рефакторить. Но не нужно заранее усложнять архитектуру проекта с мыслью "а вдруг?". Нужно понимать, когда выделение интерфейсов, разделение типов исключений, DIP идёт на пользу продукту, а когда это FizzBuzz Enterprise Edition.
конечно, не везде. Но такое существует. Объясняется просто: вот есть некий директор, и есть в его подразделении какие-то непонятные программисты. И чем пытаться найти с ними общий язык, директору проще найти на стороне человека на позицию "руководитель отдела разработки", положить ему рыночную (или "нормальную" по понятиям этого директора) зарплату, и снять с себя эту головную боль. То, что до этого эти самые программисты как-то решали поставленные задачи без этого руководителя, (и даже мысль, что поискать руководителя можно было среди этих самых программистов, и могло получиться дешевле), как-то выпадает из поля зрения. Вот и получается: сидит человек, получает неплохие деньги, вклад его в работу примерно равен нулю, и его риск увольнения примерно равен нулю - просто потому, что он не совсем дурак и не лезет ломать то, что и без него работало.
В статье были введены ровно две сущности (МВУ и МНУ), обозначена иерархия между ними ( словами "верхний" и "нижний") и задано ровно одно отношение ("зависит"). Вы зачем-то ввели новый термин ("использует") и стали топить за то, что это как-то влияет на иерархию сущностей. @lair интересовала только иерархия, но меня - только необходимость новой терминологии. И когда я попросил Вас разъяснить эту терминологию, вы внезапно вводите третью сущность, "интерфейс". Не надо плодить сущности без необходимости, как говорил Оккам. Чтобы не затягивать, я сам переформулирую вопрос из статьи и вопрос @lairиз комментариев. И, чтобы всем было проще понять, в чём суть, первая сущность так и останется "модулем", а вторая станет "интерфейсом". Итак, начальное утверждение: "Модуль в своём коде использует интерфейс" и два вопроса: 1) можно ли сказать, что "использует" и "зависит" в данном случае синонимы? 2) кто из них по иерархии расположен выше - модуль или интерфейс?
И вот теперь всё встаёт на свои места. Во-первых, очевидно, что в данном вопросе "использует" и "зависит" - синонимы. Модуль использует только то, что задекларировано в интерфейсе, и зависит только от него же. То, что интерфейс воплощён в какой-то реализации - к делу отношения не имеет абсолютно никакого. Если Вы решите в модуле использовать то, чего в интерфейсе нет, то создадите проблемы. ( Если говорить строго, то явно вы задекларируете одну зависимость, а неявно будет другая).
Во-вторых: очевидно, что интерфейс расположен по иерархии выше, чем модуль. Иначе будет нарушен первый пункт из DIP.
А если вернуться к иллюстрации из статьи (той, которая с зелёной галочкой), то видно, что она неправильная. Правильно будет так: где-то наверху интерфейс, он же "модуль высокого уровня", а ниже его - то, что обозначено как "A" ( потому что использует интерфейс) и то, что обозначено как "B" ( то, что использует интерфейс для реализации этого самого интерфейса), два "модуля нижнего уровня" по отношению к интерфейсу. Между "A" и "B" иерархии нет, они независимы.
Если окажется, что литературного контента до 1917 года достаточно - все будут счастливы. Пусть ИИ пишет "милостивый государь" и "всенепременнейше"! Вот только нет никакого "если" (насколько я понимаю ситуацию). Уже всё доступное скормили ИИ, и всё равно мало. Ужасно напоминает кадавров Выбегалло из повести Стругацких.
Вот именно. "Эпизод перекликается". Эпизод. Если снять фэнтези фильм и вставить туда фразу "Тут Леголас не пробегал?" - думаю, никто не обидится. А вот если с помощью ИИ сгенерировать "Хроники Леголаса" (его возраст, вроде бы, старше 500 лет, так что сериальчик будет длинный), в которых будет ровно тот же экранный образ актёра и тот же реквизит, то без иска не обойдётся. И это справедливо.
А где там массовое нарушение то? Купили книжку, дали почитать сетке, она выдала собственное произведение, не похожее на источник
Если бы нейросеть выдавала одно произведенение, как лабораторную работу - вряд ли бы кто-то подал в суд. Проблема в том, что она может клепать их сотнями и тысячами. И делает это! Без ссылок на оригинал, в силу своей конструкции. Вот некий автор, выработал свой стиль, придумал некий мир и его лор. Потратил на это, скажем, лет 10. Читателям зашло, труд автора начал окупаться. Все довольны - и автор, и читатели. А теперь какая перспектива? Заходит (условно; это может быть и сайт) читатель в книжный и говорит: "я вот прочитал эту книжку, мне понравилось, у вас есть такое же?". А продавец: "Да, у этого автора в этой серии вышла ещё одна книжка, и ещё одна будет через год. И кстати, вот ещё 999 сгенерированных ИИ книг про тех же персонажей, по цене 1% от оригинала. Что брать будете?". Наиболее вероятный выбор очевиден. К чему это приведёт? К тому, что писать будут только ради развлечения, как хобби. В свободное от основной работы время (скажем, сталеваром) и при наличии сил. А что произойдёт с AI-generated книгами? Ничего: нет сорцов - нет генерации. Впрочем, человечество в целом не заметит - нам и текущего объёма мировой литературы хватит на несколько жизней. Будем читать Толстого...
Какое отношение размер иконок имеет к расположению панели - не понимаю, какая разница, где иконку 16х16 рисовать?
Если панель располагать сбоку, то ширина становилась фиксированной. Иконка выводится обязательно, так что для текста места практически нет, он весь скрывается многоточием. Если запущено несколько одинаковых приложений, то найти нужную копию на такой панели - проблема. Лучше бы многоточие иконку скрывало, а не подпись
Единственный минус - это дороже чем арендовать одно помещение и всех посадить там.
Да, но даже бизнесу нужно обоснование. Если бизнес знает, что с помощью опенспейса он сэкономит 20% на аренде, но потеряет 50% продуктивности, он ни за что не выберет опенспейс, потому что это невыгодно.
История опенспейса, кажется, публиковалась прямо на Хабре. Супер-краткое изложение: примерно в середине прошлого века кому-то в крупной корпорации понадобилось "продавить" переход на опенспейс. С этой целью были наняты "эксперты", которые в своём отчёте показали, что в опенспейсе растёт плотность коммуникаций между сотрудниками и общая креативность. Отчёт был опубликован, распиарен, идея ушла в массы.
Через десяток лет другие исследователи опубликовали отчёт, в котором показали, что в опенспейсе у сотрудников растёт уровень стресса, падает концентрация и, как итог, продуктивность - но этот отчёт широкого распростанения не получил.
Ни один самый успешный бизнесмен не даст всем своим сотрудникам по кабинету.
Джоэл Спольски с Вами не согласится. У неге есть парочка статей, где он описывает, как спроектировал и построил офис для продуктивной работы программистов
А Вы видели станок, который пружинки делает? Заурядные пружинки, куда проще, чем пошив одежды. Тот станок изобретать не нужно, уже изобрели. Выглядит так же сложно, как Терминатор Т-800.
сериализованный объект, в котором будет магический метод __wakeup , в котором произвольный код?
Вы не совсем правильно поняли. В атакуемой системе должен быть класс с методом __wakeup(), внутри которого есть вызов произвольного кода. Только тогда эксплоит сработает. В самих сериализованных данных передаётся только имя этого класса. И ещё уточню: этот класс должен быть эагружен до десериализации или доступен по autoload , иначе будет ошибка.
Я вот представить себе не могу, зачем такой подход может вообще понадобиться. На уровне
Соглашусь. Стоило бы назвать calculateTotalCost , потому что даже в этом контексте может быть ещё calculateTotalQuantity ( суммарное количество товаров в корзине) , calculateTotalDiscount ( общая скидка). Может, ещё что-то.
также исследование покажет, что наилучший по качеству мех получается, если выращивать его на коже животных. Oh, wait...
А можете привести примеры, когда понадобился даунгрейд пакета? Я как-то не сталкивался - но, может, не обращал внимания, что так можно было..
Не вижу никакой политической ангажированности. Если компания собирает данные американских граждан, и к этим данным возникают вопросы, то, когда компания американская, с ней можно что-то сделать по американским законам. А когда компания китайская, то сделать что-то по американским законам уже не получится ( кроме блокировки дальнейшей деятельности компании в США).
ChatGPT несёт похожие риски для всех стран, кроме Америки. Да, в общем-то, любой софт, собирающий данные пользователей.
К сожалению, тот же размер заголовка первого уровня меняется нелинейно. А как только появляются медиа-запросы, смысл в формулах пропадает, можно сразу указать конечное значение.
Здесь речь в том числе и о том, что есть религиозное "тут нарушен SOLID, надо потратить ресурсы и переделать", а есть "да, SOLID тут нарушен, но пофиг, так как никакого развития кода тут не будет, конечная остановка".
Так об этом и речь дальше: если сложность перешагнула некоторую точку, то нужно рефакторить. Но не нужно заранее усложнять архитектуру проекта с мыслью "а вдруг?". Нужно понимать, когда выделение интерфейсов, разделение типов исключений, DIP идёт на пользу продукту, а когда это FizzBuzz Enterprise Edition.
конечно, не везде. Но такое существует. Объясняется просто: вот есть некий директор, и есть в его подразделении какие-то непонятные программисты. И чем пытаться найти с ними общий язык, директору проще найти на стороне человека на позицию "руководитель отдела разработки", положить ему рыночную (или "нормальную" по понятиям этого директора) зарплату, и снять с себя эту головную боль. То, что до этого эти самые программисты как-то решали поставленные задачи без этого руководителя, (и даже мысль, что поискать руководителя можно было среди этих самых программистов, и могло получиться дешевле), как-то выпадает из поля зрения. Вот и получается: сидит человек, получает неплохие деньги, вклад его в работу примерно равен нулю, и его риск увольнения примерно равен нулю - просто потому, что он не совсем дурак и не лезет ломать то, что и без него работало.
В статье были введены ровно две сущности (МВУ и МНУ), обозначена иерархия между ними ( словами "верхний" и "нижний") и задано ровно одно отношение ("зависит").
Вы зачем-то ввели новый термин ("использует") и стали топить за то, что это как-то влияет на иерархию сущностей. @lair интересовала только иерархия, но меня - только необходимость новой терминологии. И когда я попросил Вас разъяснить эту терминологию, вы внезапно вводите третью сущность, "интерфейс".
Не надо плодить сущности без необходимости, как говорил Оккам.
Чтобы не затягивать, я сам переформулирую вопрос из статьи и вопрос @lairиз комментариев. И, чтобы всем было проще понять, в чём суть, первая сущность так и останется "модулем", а вторая станет "интерфейсом".
Итак, начальное утверждение:
"Модуль в своём коде использует интерфейс"
и два вопроса:
1) можно ли сказать, что "использует" и "зависит" в данном случае синонимы?
2) кто из них по иерархии расположен выше - модуль или интерфейс?
И вот теперь всё встаёт на свои места. Во-первых, очевидно, что в данном вопросе "использует" и "зависит" - синонимы. Модуль использует только то, что задекларировано в интерфейсе, и зависит только от него же. То, что интерфейс воплощён в какой-то реализации - к делу отношения не имеет абсолютно никакого. Если Вы решите в модуле использовать то, чего в интерфейсе нет, то создадите проблемы. ( Если говорить строго, то явно вы задекларируете одну зависимость, а неявно будет другая).
Во-вторых: очевидно, что интерфейс расположен по иерархии выше, чем модуль. Иначе будет нарушен первый пункт из DIP.
А если вернуться к иллюстрации из статьи (той, которая с зелёной галочкой), то видно, что она неправильная. Правильно будет так: где-то наверху интерфейс, он же "модуль высокого уровня", а ниже его - то, что обозначено как "A" ( потому что использует интерфейс) и то, что обозначено как "B" ( то, что использует интерфейс для реализации этого самого интерфейса), два "модуля нижнего уровня" по отношению к интерфейсу. Между "A" и "B" иерархии нет, они независимы.
приведите, пожалуйста, наглядный пример, когда "использует, но не зависит". Я как-то не могу понять, как такое возможно.
Если окажется, что литературного контента до 1917 года достаточно - все будут счастливы. Пусть ИИ пишет "милостивый государь" и "всенепременнейше"!
Вот только нет никакого "если" (насколько я понимаю ситуацию). Уже всё доступное скормили ИИ, и всё равно мало. Ужасно напоминает кадавров Выбегалло из повести Стругацких.
Вот именно. "Эпизод перекликается". Эпизод. Если снять фэнтези фильм и вставить туда фразу "Тут Леголас не пробегал?" - думаю, никто не обидится.
А вот если с помощью ИИ сгенерировать "Хроники Леголаса" (его возраст, вроде бы, старше 500 лет, так что сериальчик будет длинный), в которых будет ровно тот же экранный образ актёра и тот же реквизит, то без иска не обойдётся. И это справедливо.
Если бы нейросеть выдавала одно произведенение, как лабораторную работу - вряд ли бы кто-то подал в суд. Проблема в том, что она может клепать их сотнями и тысячами. И делает это! Без ссылок на оригинал, в силу своей конструкции.
Вот некий автор, выработал свой стиль, придумал некий мир и его лор. Потратил на это, скажем, лет 10. Читателям зашло, труд автора начал окупаться. Все довольны - и автор, и читатели.
А теперь какая перспектива? Заходит (условно; это может быть и сайт) читатель в книжный и говорит: "я вот прочитал эту книжку, мне понравилось, у вас есть такое же?". А продавец: "Да, у этого автора в этой серии вышла ещё одна книжка, и ещё одна будет через год. И кстати, вот ещё 999 сгенерированных ИИ книг про тех же персонажей, по цене 1% от оригинала. Что брать будете?". Наиболее вероятный выбор очевиден.
К чему это приведёт? К тому, что писать будут только ради развлечения, как хобби. В свободное от основной работы время (скажем, сталеваром) и при наличии сил. А что произойдёт с AI-generated книгами? Ничего: нет сорцов - нет генерации.
Впрочем, человечество в целом не заметит - нам и текущего объёма мировой литературы хватит на несколько жизней. Будем читать Толстого...
Если панель располагать сбоку, то ширина становилась фиксированной. Иконка выводится обязательно, так что для текста места практически нет, он весь скрывается многоточием. Если запущено несколько одинаковых приложений, то найти нужную копию на такой панели - проблема. Лучше бы многоточие иконку скрывало, а не подпись
Да, но даже бизнесу нужно обоснование. Если бизнес знает, что с помощью опенспейса он сэкономит 20% на аренде, но потеряет 50% продуктивности, он ни за что не выберет опенспейс, потому что это невыгодно.
История опенспейса, кажется, публиковалась прямо на Хабре. Супер-краткое изложение: примерно в середине прошлого века кому-то в крупной корпорации понадобилось "продавить" переход на опенспейс. С этой целью были наняты "эксперты", которые в своём отчёте показали, что в опенспейсе растёт плотность коммуникаций между сотрудниками и общая креативность. Отчёт был опубликован, распиарен, идея ушла в массы.
Через десяток лет другие исследователи опубликовали отчёт, в котором показали, что в опенспейсе у сотрудников растёт уровень стресса, падает концентрация и, как итог, продуктивность - но этот отчёт широкого распростанения не получил.
Джоэл Спольски с Вами не согласится. У неге есть парочка статей, где он описывает, как спроектировал и построил офис для продуктивной работы программистов
16 тысяч же. Что меньше 20 тысяч, как Вы и хотите
А Вы видели станок, который пружинки делает? Заурядные пружинки, куда проще, чем пошив одежды. Тот станок изобретать не нужно, уже изобрели. Выглядит так же сложно, как Терминатор Т-800.
Вы не совсем правильно поняли. В атакуемой системе должен быть класс с методом __wakeup(), внутри которого есть вызов произвольного кода. Только тогда эксплоит сработает. В самих сериализованных данных передаётся только имя этого класса.
И ещё уточню: этот класс должен быть эагружен до десериализации или доступен по autoload , иначе будет ошибка.
Я вот представить себе не могу, зачем такой подход может вообще понадобиться. На уровне
Вы не знакомы с выражением "отбитый [на всю голову]"?
Соглашусь. Стоило бы назвать calculateTotalCost , потому что даже в этом контексте может быть ещё calculateTotalQuantity ( суммарное количество товаров в корзине) , calculateTotalDiscount ( общая скидка). Может, ещё что-то.
Для защиты от перебора OTP сессия не поможет. Как только попыткии исчерпаются, атакующий меняет IP в X-Forwarded-For и стартует новую сессию.
А за дырку с незащищённым доступом с внутренних IP автору спасибо. Никогда не думал в таком ключе.