Вордпресс с плагинами и темами может весить вполне больше. Особенно если каждый плагин имеет свою vendor папку, а фронт лежит с не удалёнными node_modules (вес которых может достигать до гига спокойно).
Сейчас такое время, когда плагин для вордпреса может весить больше, чем сам вордпрес. Про другие CMS или фреймворки вообще молчу.
Всё потому что для решения рутинных задач разработчики, используют репозитории, имеющие в зависимостях десяток других репозиториев. На выходе мы имеем, порой десятки тысяч файлов из которых реально используется максимум сотня другая, а рукописных и того меньше.
Проблема оптимизации частично решается тем, что всякие фронтенд фреймворки создают билды в которые подключают только используемый код, но на практике мусора в билдах обычно много. Однако, хоть исходники можно из релиза удалить, оставив минифрцированный билд. В php используют composer autoload, который по идее декларирует только используемые классы, но на практике так же периодически декларирует много "мусора". При этом папку vendor удалить нельзя по понятным причинам.
Причём разработчиков в этом винить тоже нельзя. Придумывать велосипеды каждый раз с нуля дело долгое и неблагодарное, а использование готовых решений сокращает время разработки. Здесь скорее проблема куда глобальнее и виновных в ней нет. Думаю в будущем комьюнити придёт к способам решения этих проблем.
Тоже можно сказать и про паттерны, которыми обожают "обмазываться эксперты", применяя их по поводу и без, зачастую с ужасной реализацией. Причём сами по себе паттерны не хорошие и не плохие. Просто рекомендательный свод шаблонных решений, а не свод законов. Неоднократно замечал, как на паттерны бездумно чуть-ли не молятся, вместо того чтобы разобраться, где и как их лучше применять на практике.
То же можно сказать, например про clean code, автора которого в прошлом году "пожурил" один инженер, что вызвало огромное количество холиваров. Хотя посыл был простым: не нужно бездумно следовать всему, что говорят.
Мне нравится программирование тем, что в нём всё имеет своё предназначение и логику. Даже самые плохие решения всегда можно разобрать и понять почему специалисты сделали так, а не иначе, будь то специфика технологий, skill issue или что-то другое.
Солид, так же имеют своё назначение и не следует их возводить в "священные писания". Это можно сказать про любые постулаты, архитектурные решения, паттерны, методологии и т.д.
Если всё свести до уровня пабликов пацанских цитат: опытный специалист, может не просто рассказать теорию, но и пояснить, как она применяется на практике. Ауф.
Почти. Это говорили в Минцифре вроде. Здесь нужно сделать важное уточнение. Они имели ввиду нехватку специалистов в определённых сферах по типу ИБ, ML и т.д.
А вилки правда так упали? Я думал они просто стагнируют.
Если честно дичь написана, как про Германию, так и про Россию. Если коротко в Германии IT "закостенелое", а немцы имеют много стереотипов. IT как бы это странно не звучало, развито не сильно и имеет ряд проблем, например с раздутыми штатами из-за соц. пакетов, как следствие раздутыми бюджетами с малой эффективностью. Так же в стране много законов и iso стандартов, что сильно сковывают команды в техническом плане, что доходит порой до абсурда.
Касаемо России, то в IT сейчас сильный кризис. Какое может быть развитие если нехватка кадров 700000 специалистов, блокируется огромное количество ресурсов и инструментов, а отечественное по не покрывает и близко спрос. Во многих регионах программисты уходят в таксисты, потому платят больше и нервов меньше. Ну и как вишенка на торте, рынок начинают захватывать братушки азиаты.
Реальность сильно отличается от описанного в статье.
Будут более доступней, чем Москве например. Работал одно время в немецкой конторе, сейчас снять квартиру 60-70 квадратов, почти в центре Берлина обойдётся в 1200-1300 евро в месяц вместе с ЖКХ. В центре Москвы за такие деньги разве, что конуру в подвале снять можно. Там проблема в другом. В налогах лютых и более дорогой еде. Обычный хлебушек в Германии, например стоит 1.5 евро, т.е. 150 рублей и цены примерно в 2-3 раза выше, чем в МСК на еду. Однако цены на электронику, например дешевле.
Кэши имеют разные реализации и используются далеко не только в вебе. Банальный пример геймдев, где кэш либо хранится в хэш таблицах либо интегрирован прямо в код функции например. У кэша нет такой сложной архитектуры, как у БД, даже у noSQL.
Да и подходы разные. Например, кэш подразумевает полное удаление себя, без каких либо последствий для сервиса или проекта. Полное удаление всех данных в бд думаю понятно, какие последствия будет иметь.
Спасибо. Давно искал нечто подобное, чтобы делать простенькую графику для 3д игр без миллиона сочетаний клавиш в секунду.) Здесь даже создание анимаций есть, что радует.
На телефоне использую termux, потому что другие приложения почему-то на моём смартфоне не работают (хотя он вроде он далеко не старый). На ПК использую либо консоль, либо офф. приложение гитхаба. К сожалению рабочих расширений для гитхаба в самом обсидиане не нашёл. Точнее одно работало, но немного странно.
Однако zzzzzzerg дал ссылку на интересную статью, сам попробую плагин, который там описан, потому что с ним куда удобнее.)
Меня удивляет другое. Что в соц. сетях некоторые генерации становятся сенсациями.
Ну сказал и сказал. Языковая модель не имеет сознания и интеллекта, она подстраивается под наши запросы. Если я буду хейтить, например python в диалогах, то GPT это запомнит и при следующем вопросе про python будет с большой вероятностью его критиковать, чтобы максимально угодить моим интересам и не дай бог не вызвать у меня негативной реакции. И это не то чтобы какой-то секрет, а скорее очевидная вещь, описанная в инструкциях.
По теме же скажу кратко: саморазвитие хорошо, культ саморазвития плохо.
Тоже пришёл в итоге к Obsidian, только использую в связке с GitHub (всем советую попробовать, потому что Git даёт мощный, но при этом простой в освоении функционал, и все плюсы при работе с текстом, что и с кодом).
У меня был примерно такой же путь, как и у автора, только мне не понравился Everynote и долгое время хранил информацию в приватных блогах на разных сайтах. Мне это казалось в то время удобным, потому что доступ со всех устройств, можно выбирать видимость блога (вижу только я или ещё несколько людей), возможность бесплатно прикреплять файлы. Плюс поиск на сайтах работал по блогам работал неплохо. Какое-то время хранил информацию в гугл доках, из-за того же функционала. В итоге, опробовал много всего и остановился на Обсидиан.
Начал вести Любищев свою систему с 26 лет и работал так до конца своих дней.
У каждого человека свои особенности и нужно выстраивать индивидуальный подход под себя, но при этом можно посмотреть и адаптировать под себя практики других. Просто дополняю тему.
Для браузера абсолютно параллельно какой там статус, так что странно их разделять на успешные и нет.
Для браузера да, но не для фронтенда.
Тогда бы не пришлось бойлерплейт вида $this->responseFactory->createJsonResponseпостоянно дублировать и генерация ответа спокойно в 1 строку умещалась, а не в 4.
В вашем примере так же копируется строчка с render.
И возвращать не boolean, а осмысленный список ошибок валидации, который можно сразу на фронт передать. И в идеале, чтобы была возможность её вообще в отдельную миддлевару вынести
Использование мидлвара здесь будет хорошей идеей для предварительной проверки данных. Это наверное единственный верный способ декомпозиции, который тут можно было бы сделать. Однако, это будет не декомпозицией метода, а написание вообще отдельного функционала на уровне библиотеки или фреймворка.
Очевидно же из контекста, что он опциональный.
Да очевидно и это не отменяет того, что поведение метода остаётся неочевидным. В каких именно случаях нам передавать необязательный параметр? Что будет если я его не передам когда надо и передам, когда не надо (изменю дефолтное значение)? Чтобы узнать это, нужно идти в метод и смотреть, как он устроет и работает. Про то я и говорил.
systemd на самом деле ещё тот монстр, который вмещает в себя какое-то огромное количество функционала вплоть до лёгкой контейнеризации, что противоречит юникс идеалогии: "делай одну вещь и делай её хорошо". По хорошему systemd бы разделить на несколько программ, потому что большинство пользователей используют её только для работы со службами.
Фреймворки также стирают границу между фронтендом и бэкендом.
И это ужасно, потому что проекты превращаются в одну большую кашу без разделения ответственности. Да и при разделении бэкенда и фронтенда, мы можем менять ЯП. Не нравится PHP на бэке, можно переписать всё на Go, ASP, C++, Python, Node и т.д. Не нравится React на фронте, можно заменить хоть ванильным js.
Теперь один разработчик может реализовать функциональность "от и до": от запросов к базе данных до UI-интеракций.
Если бэкенд и фронтенд пишутся на одном ЯП, это не значит, что у них одинаковая специфика. Только знание ЯП не даёт понимание всех сфер, где он применяется.
Может показаться, что React Server Components с SQL-запросами похожи на старый добрый PHP с его смешением HTML, CSS и SQL.
Я рад, что описанные в статье js фреймворки добрались до уровня php дястелетней давности, но в современном php давно принято использовать OOП, шаблонизаторы, подходы по разделению логики по типу MVC и т.д. Как понимаю в реакте, даже OOП без костылей использовать нельзя поэтому сравнение с PHP очень странное.
Но главное отличие в том, что мы больше не создаем "спагетти-код".
Ещё как создаёте и даже порой более ужасный, чем создавали php программисты 10 лет назад. Когда увидел SQL запросы, вставленные в html теги, что воспринимается, как норма, ужаснулся куда катятся фулстек решения на js.
П.С. У js тоже есть хорошие решения, например нода для бэкенда, анагуляр для сложных и средних проектов на фронте и вуе для простых и думаю можно ещё десяток назвать хороших. Но статья - явный байт на холивар.
Вот по этим аспектам и надо разделять, а не тупо каждую строку в отдельную функцию выделять.
Ну во-первых не тупо, а в контексте SRP принципа, о котором шёл разговор. Мой пример далеко не лучший, но не нарушает принцип SRP, так же является более типизированным и читаемым. Однако повышает цикломатическую, сложность усложняет тестирование и т.д. Ваш вариант декомпозиции во-первых, имеет все теже проблемы, во-вторых имеет и дополнительные.
А именно метод buildLoginRespons не совсем соответствует принципу SRP т.к. занимается отправкой и удачных и ошибочных ответов. Так же он имеет неочевидное поведение. Если мы передадим любой другой код, скажем 403, то метод ничего не сделает, либо вызовет ошибку 500 (звисит от ЯП), можно добавить default значение (или return в конце метода), но это всё-равно будет-нарушением исходной логики.
Так же вкусовщина, но использование switch, вместо массива или ифов выглядит странно. Так же странным выглядит момент с resp_params который вроде обязательный аргумент, но нужен буквально только в одном случае.
В примере уже есть фабрика, что создаёт респонсы и оборачивать её в билдер тоже странно
Как не крути, но декомпозиция в моём примере ради сокращения строк метода излишняя, о чём изначально и был разговор. Первый вариант а моём примере лучший из всех почти по многим причинам, которые описывал ранее.
При этом код пытаеться присвоить значение свойству name, но его нет.
А, точно. Не заметил этого и поэтому и написал комментарий. Да, тогда вопрос отпадает, потому что подобный функционал (динамические свойства) никогда на практике особо не использовал.
Соотв вопрос почему депрекейтед? сам по себе отпадает.
Вордпресс с плагинами и темами может весить вполне больше. Особенно если каждый плагин имеет свою vendor папку, а фронт лежит с не удалёнными node_modules (вес которых может достигать до гига спокойно).
Сейчас такое время, когда плагин для вордпреса может весить больше, чем сам вордпрес. Про другие CMS или фреймворки вообще молчу.
Всё потому что для решения рутинных задач разработчики, используют репозитории, имеющие в зависимостях десяток других репозиториев. На выходе мы имеем, порой десятки тысяч файлов из которых реально используется максимум сотня другая, а рукописных и того меньше.
Проблема оптимизации частично решается тем, что всякие фронтенд фреймворки создают билды в которые подключают только используемый код, но на практике мусора в билдах обычно много. Однако, хоть исходники можно из релиза удалить, оставив минифрцированный билд. В php используют composer autoload, который по идее декларирует только используемые классы, но на практике так же периодически декларирует много "мусора". При этом папку vendor удалить нельзя по понятным причинам.
Причём разработчиков в этом винить тоже нельзя. Придумывать велосипеды каждый раз с нуля дело долгое и неблагодарное, а использование готовых решений сокращает время разработки. Здесь скорее проблема куда глобальнее и виновных в ней нет. Думаю в будущем комьюнити придёт к способам решения этих проблем.
Тоже можно сказать и про паттерны, которыми обожают "обмазываться эксперты", применяя их по поводу и без, зачастую с ужасной реализацией. Причём сами по себе паттерны не хорошие и не плохие. Просто рекомендательный свод шаблонных решений, а не свод законов. Неоднократно замечал, как на паттерны бездумно чуть-ли не молятся, вместо того чтобы разобраться, где и как их лучше применять на практике.
То же можно сказать, например про clean code, автора которого в прошлом году "пожурил" один инженер, что вызвало огромное количество холиваров. Хотя посыл был простым: не нужно бездумно следовать всему, что говорят.
Мне нравится программирование тем, что в нём всё имеет своё предназначение и логику. Даже самые плохие решения всегда можно разобрать и понять почему специалисты сделали так, а не иначе, будь то специфика технологий, skill issue или что-то другое.
Солид, так же имеют своё назначение и не следует их возводить в "священные писания". Это можно сказать про любые постулаты, архитектурные решения, паттерны, методологии и т.д.
Если всё свести до уровня пабликов пацанских цитат: опытный специалист, может не просто рассказать теорию, но и пояснить, как она применяется на практике. Ауф.
Спасибо за информацию, это любопытно.
Почти. Это говорили в Минцифре вроде. Здесь нужно сделать важное уточнение. Они имели ввиду нехватку специалистов в определённых сферах по типу ИБ, ML и т.д.
А вилки правда так упали? Я думал они просто стагнируют.
Если честно дичь написана, как про Германию, так и про Россию. Если коротко в Германии IT "закостенелое", а немцы имеют много стереотипов. IT как бы это странно не звучало, развито не сильно и имеет ряд проблем, например с раздутыми штатами из-за соц. пакетов, как следствие раздутыми бюджетами с малой эффективностью. Так же в стране много законов и iso стандартов, что сильно сковывают команды в техническом плане, что доходит порой до абсурда.
Касаемо России, то в IT сейчас сильный кризис. Какое может быть развитие если нехватка кадров 700000 специалистов, блокируется огромное количество ресурсов и инструментов, а отечественное по не покрывает и близко спрос. Во многих регионах программисты уходят в таксисты, потому платят больше и нервов меньше. Ну и как вишенка на торте, рынок начинают захватывать братушки азиаты.
Реальность сильно отличается от описанного в статье.
Будут более доступней, чем Москве например. Работал одно время в немецкой конторе, сейчас снять квартиру 60-70 квадратов, почти в центре Берлина обойдётся в 1200-1300 евро в месяц вместе с ЖКХ. В центре Москвы за такие деньги разве, что конуру в подвале снять можно. Там проблема в другом. В налогах лютых и более дорогой еде. Обычный хлебушек в Германии, например стоит 1.5 евро, т.е. 150 рублей и цены примерно в 2-3 раза выше, чем в МСК на еду. Однако цены на электронику, например дешевле.
Кэши имеют разные реализации и используются далеко не только в вебе. Банальный пример геймдев, где кэш либо хранится в хэш таблицах либо интегрирован прямо в код функции например. У кэша нет такой сложной архитектуры, как у БД, даже у noSQL.
Да и подходы разные. Например, кэш подразумевает полное удаление себя, без каких либо последствий для сервиса или проекта. Полное удаление всех данных в бд думаю понятно, какие последствия будет иметь.
Хм, может тоже попробовать через FDroid поставить. Спасибо за совет)
Спасибо. Давно искал нечто подобное, чтобы делать простенькую графику для 3д игр без миллиона сочетаний клавиш в секунду.) Здесь даже создание анимаций есть, что радует.
Неплохое приложение, но на андроиде 14+ не работает(
На телефоне использую termux, потому что другие приложения почему-то на моём смартфоне не работают (хотя он вроде он далеко не старый). На ПК использую либо консоль, либо офф. приложение гитхаба. К сожалению рабочих расширений для гитхаба в самом обсидиане не нашёл. Точнее одно работало, но немного странно.
Однако zzzzzzerg дал ссылку на интересную статью, сам попробую плагин, который там описан, потому что с ним куда удобнее.)
Меня удивляет другое. Что в соц. сетях некоторые генерации становятся сенсациями.
Ну сказал и сказал. Языковая модель не имеет сознания и интеллекта, она подстраивается под наши запросы. Если я буду хейтить, например python в диалогах, то GPT это запомнит и при следующем вопросе про python будет с большой вероятностью его критиковать, чтобы максимально угодить моим интересам и не дай бог не вызвать у меня негативной реакции. И это не то чтобы какой-то секрет, а скорее очевидная вещь, описанная в инструкциях.
По теме же скажу кратко: саморазвитие хорошо, культ саморазвития плохо.
Тоже пришёл в итоге к Obsidian, только использую в связке с GitHub (всем советую попробовать, потому что Git даёт мощный, но при этом простой в освоении функционал, и все плюсы при работе с текстом, что и с кодом).
У меня был примерно такой же путь, как и у автора, только мне не понравился Everynote и долгое время хранил информацию в приватных блогах на разных сайтах. Мне это казалось в то время удобным, потому что доступ со всех устройств, можно выбирать видимость блога (вижу только я или ещё несколько людей), возможность бесплатно прикреплять файлы. Плюс поиск на сайтах работал по блогам работал неплохо. Какое-то время хранил информацию в гугл доках, из-за того же функционала. В итоге, опробовал много всего и остановился на Обсидиан.
У каждого человека свои особенности и нужно выстраивать индивидуальный подход под себя, но при этом можно посмотреть и адаптировать под себя практики других. Просто дополняю тему.
Это очень удобно, спасибо.)
Для браузера да, но не для фронтенда.
В вашем примере так же копируется строчка с render.
Использование мидлвара здесь будет хорошей идеей для предварительной проверки данных. Это наверное единственный верный способ декомпозиции, который тут можно было бы сделать. Однако, это будет не декомпозицией метода, а написание вообще отдельного функционала на уровне библиотеки или фреймворка.
Да очевидно и это не отменяет того, что поведение метода остаётся неочевидным. В каких именно случаях нам передавать необязательный параметр? Что будет если я его не передам когда надо и передам, когда не надо (изменю дефолтное значение)? Чтобы узнать это, нужно идти в метод и смотреть, как он устроет и работает. Про то я и говорил.
systemd на самом деле ещё тот монстр, который вмещает в себя какое-то огромное количество функционала вплоть до лёгкой контейнеризации, что противоречит юникс идеалогии: "делай одну вещь и делай её хорошо". По хорошему systemd бы разделить на несколько программ, потому что большинство пользователей используют её только для работы со службами.
Systemd правда хороший пример монстра.
И это ужасно, потому что проекты превращаются в одну большую кашу без разделения ответственности. Да и при разделении бэкенда и фронтенда, мы можем менять ЯП. Не нравится PHP на бэке, можно переписать всё на Go, ASP, C++, Python, Node и т.д. Не нравится React на фронте, можно заменить хоть ванильным js.
Если бэкенд и фронтенд пишутся на одном ЯП, это не значит, что у них одинаковая специфика. Только знание ЯП не даёт понимание всех сфер, где он применяется.
Я рад, что описанные в статье js фреймворки добрались до уровня php дястелетней давности, но в современном php давно принято использовать OOП, шаблонизаторы, подходы по разделению логики по типу MVC и т.д. Как понимаю в реакте, даже OOП без костылей использовать нельзя поэтому сравнение с PHP очень странное.
Ещё как создаёте и даже порой более ужасный, чем создавали php программисты 10 лет назад. Когда увидел SQL запросы, вставленные в html теги, что воспринимается, как норма, ужаснулся куда катятся фулстек решения на js.
П.С. У js тоже есть хорошие решения, например нода для бэкенда, анагуляр для сложных и средних проектов на фронте и вуе для простых и думаю можно ещё десяток назвать хороших. Но статья - явный байт на холивар.
Ну во-первых не тупо, а в контексте SRP принципа, о котором шёл разговор. Мой пример далеко не лучший, но не нарушает принцип SRP, так же является более типизированным и читаемым. Однако повышает цикломатическую, сложность усложняет тестирование и т.д. Ваш вариант декомпозиции во-первых, имеет все теже проблемы, во-вторых имеет и дополнительные.
А именно метод buildLoginRespons не совсем соответствует принципу SRP т.к. занимается отправкой и удачных и ошибочных ответов. Так же он имеет неочевидное поведение. Если мы передадим любой другой код, скажем 403, то метод ничего не сделает, либо вызовет ошибку 500 (звисит от ЯП), можно добавить default значение (или return в конце метода), но это всё-равно будет-нарушением исходной логики.
Так же вкусовщина, но использование switch, вместо массива или ифов выглядит странно. Так же странным выглядит момент с resp_params который вроде обязательный аргумент, но нужен буквально только в одном случае.
В примере уже есть фабрика, что создаёт респонсы и оборачивать её в билдер тоже странно
Как не крути, но декомпозиция в моём примере ради сокращения строк метода излишняя, о чём изначально и был разговор. Первый вариант а моём примере лучший из всех почти по многим причинам, которые описывал ранее.
Спасибо, правда есть много схожего. Собственно вопрос с этим тоже отпал.)
А, точно. Не заметил этого и поэтому и написал комментарий. Да, тогда вопрос отпадает, потому что подобный функционал (динамические свойства) никогда на практике особо не использовал.
Да