Какая-то инфантильная позиция: все не так как вижу я в своих влажных фантазиях, потому всё и все нетакие. Это реальный мир, тут надо уметь адаптироваться и пытаться влиять на него в силу своих возможностей. Бизнес всегда будет подкидывать всякое, потому что в нем происходит всякое. Тестами покрывать код нужно, хотя бы для себя и коллег. Ревью не будет занимать дни и быть похожим на терапию, если будут правила и регламенты обязательные для всех.
Язык остался таким же как раньше, и писать на нем можно также как и раньше, только удобнее и чуток почище. Вы в шоке от фреймворков, а не от языка. Кто мешает написать все на чистом php как в 2005.
Я так и сделал, все заблокированое живёт в папке knox. Но это не решает проблему, socks5 сервер торчит из knox папки в незащищённое пространство, то есть проблема из статьи актуальная.
К техдолгу нужно относиться с "терпением", как это делает бизнес. Если бизнесу не надо, значит и тебе не надо, будь проще, это не твой код, а бизнеса. А если все таки хочется сделать свою жизнь на проекте более комфортной, то нужно научиться вшивать в оценку на выполнение продуктовых задач время на погашения технического долга. Ну и естественно с бизнесом надо уметь говорить о техдолге, продавать необходимость его погашения.
Вот наглядный пример, как привычка все обобщать убивает логику. Почему особенность одного человека проецируется на всех людей занимающихся тем же чем и этот человек?
Из статьи понятно лишь, то что автор не может выделить для себя критерии хорошего кода, что странно, так как он апеллирует к тому, какая важная и опытная он колбаса. Также одни и теже тезисы повторяются из обзаца в обзац, как будто сказанное одно и тоже, но разными словами, станет вдруг убедительнее. Текст очень манипулятивный и при этом вбрасывает странные и не убедительные тейки как аксиому, при том эти тейки нужны не для выстраивания причинно-следственных связей в логике статьи, а для для того чтобы подвести к нужному выводу через эмоции. Может не зря автор так рефлексирует по поводу БЯМ, возможно чувствует конкурента в деле формирования убедительных, но не логичных текстов 🤭
Ну если в бизнесе технологический застой, то можно поменять бизнес и развивать тот у которого больше новых технологий. Еще вариант с пет-проектами, но сколько себя помню в моих пет-проектах толчком для их развития являлись решения из работы на бизнесс.
В айти уже 15 лет, не соглашусь. Никогда не понимал зачем люди постоянно обучаются всему новому. Почему просто не нарабатывать опыт с технологиями вместе с требованиями бизнеса. Не спорю что надо иметь представление о новых технологиях, но и не обязательно уметь их применять, до момента как это потребуется. Когда потребуется тогда и наработается опыт.
Я в своих проектах выбрал комбинированный подход. Использую новый DAO объект на каждый запрос в базу данных, и уже в DAO инкапсулирую чистые SQL запросы (когда сложные или отчеты) или запросы через Doctrine DBAL (легки выборки, вставки, удаления, обновления). Из минусов: маппинг данных в объекты приходится делать руками, много классов, много кода для банальных вещей (для ORM). Из плюсов: полная независимость бизнес-логики от реализации хранения данных. В целом можно вообще "угореть" и в DAO инкапсулировать логику работы с ORM, и тогда в бизнес логике будет только работа с DAO.
Нет рецепта, просто дело случая. Но конечно главное искать удаленный вариант в жирных регионах типа мск или питер, тогда случай увеличится. Ну и конечно надо быть, а не казаться или считать себя специалистом.
У меня поднят socks5 прокси на основе 3proxy на vps с точкой выхода в Нидерландах. Не наблюдю особых проблем, а вот с vpn есть проблемы, но я научилая пускать vpn трафик через все тот же socks5.
Ни кто не заставляет использовать инъекции, для всех зависимостей, через конструктор, можно инъектировать только psr контейнер через конструктор, а его уже передавать в фабричные методы. Тем самым мы и динамический контекст сохраним, и при этом сможем подгружать классы по мере их необходимости. Этакий сервис локатор на максималках.
Вы как будто сами с собой беседуете))) вы поняли что я имею ввиду, несмотря на терминологию. Я не вкладывал больших смыслов в то что написал, право имеет тли не имеет кто-то, это уже предмет дискуссии, которая мне не интересна.
Вы говорите про смысл жизни в рамках конкретного человека, а я говорю про смысл жизни в рамах человечества. Проще аналогию привести, есть макроуровень (человечество) на котором смысла как такового нет, а есть микроуровень(человек) в которому смысл есть. Попытки наложить смыслы из микроуровня в макроуровень, колоссальный философский труд, который можно утилизировать простым вопросом: Зачем?
Автор статьи явно говорил о решении задачи со смыслом жизни на макроуровне при достижении бесмертия. На данный момент наша жизнь довольно коротка чтобы на нашем микроуровне возникали такие проблемы.
Какая-то инфантильная позиция: все не так как вижу я в своих влажных фантазиях, потому всё и все нетакие. Это реальный мир, тут надо уметь адаптироваться и пытаться влиять на него в силу своих возможностей. Бизнес всегда будет подкидывать всякое, потому что в нем происходит всякое. Тестами покрывать код нужно, хотя бы для себя и коллег. Ревью не будет занимать дни и быть похожим на терапию, если будут правила и регламенты обязательные для всех.
Язык остался таким же как раньше, и писать на нем можно также как и раньше, только удобнее и чуток почище. Вы в шоке от фреймворков, а не от языка. Кто мешает написать все на чистом php как в 2005.
буден виден незапароленный socks5, если его запоролить, то проблемы не будет, сканер хоть и найдет сервер, но авторизоваться на нем не сможет
Я так и сделал, все заблокированое живёт в папке knox. Но это не решает проблему, socks5 сервер торчит из knox папки в незащищённое пространство, то есть проблема из статьи актуальная.
К техдолгу нужно относиться с "терпением", как это делает бизнес. Если бизнесу не надо, значит и тебе не надо, будь проще, это не твой код, а бизнеса. А если все таки хочется сделать свою жизнь на проекте более комфортной, то нужно научиться вшивать в оценку на выполнение продуктовых задач время на погашения технического долга. Ну и естественно с бизнесом надо уметь говорить о техдолге, продавать необходимость его погашения.
Вот наглядный пример, как привычка все обобщать убивает логику. Почему особенность одного человека проецируется на всех людей занимающихся тем же чем и этот человек?
Из статьи понятно лишь, то что автор не может выделить для себя критерии хорошего кода, что странно, так как он апеллирует к тому, какая важная и опытная он колбаса. Также одни и теже тезисы повторяются из обзаца в обзац, как будто сказанное одно и тоже, но разными словами, станет вдруг убедительнее. Текст очень манипулятивный и при этом вбрасывает странные и не убедительные тейки как аксиому, при том эти тейки нужны не для выстраивания причинно-следственных связей в логике статьи, а для для того чтобы подвести к нужному выводу через эмоции. Может не зря автор так рефлексирует по поводу БЯМ, возможно чувствует конкурента в деле формирования убедительных, но не логичных текстов 🤭
Ну если в бизнесе технологический застой, то можно поменять бизнес и развивать тот у которого больше новых технологий. Еще вариант с пет-проектами, но сколько себя помню в моих пет-проектах толчком для их развития являлись решения из работы на бизнесс.
В айти уже 15 лет, не соглашусь. Никогда не понимал зачем люди постоянно обучаются всему новому. Почему просто не нарабатывать опыт с технологиями вместе с требованиями бизнеса. Не спорю что надо иметь представление о новых технологиях, но и не обязательно уметь их применять, до момента как это потребуется. Когда потребуется тогда и наработается опыт.
Минорное обновление, с небольшими изменениями, что тут обсуждать 🤷♂️
Я в своих проектах выбрал комбинированный подход. Использую новый DAO объект на каждый запрос в базу данных, и уже в DAO инкапсулирую чистые SQL запросы (когда сложные или отчеты) или запросы через Doctrine DBAL (легки выборки, вставки, удаления, обновления). Из минусов: маппинг данных в объекты приходится делать руками, много классов, много кода для банальных вещей (для ORM). Из плюсов: полная независимость бизнес-логики от реализации хранения данных. В целом можно вообще "угореть" и в DAO инкапсулировать логику работы с ORM, и тогда в бизнес логике будет только работа с DAO.
Нет рецепта, просто дело случая. Но конечно главное искать удаленный вариант в жирных регионах типа мск или питер, тогда случай увеличится. Ну и конечно надо быть, а не казаться или считать себя специалистом.
На телефоне запретгарм через прокси не хочет работать, а через впн, работет
У меня поднят socks5 прокси на основе 3proxy на vps с точкой выхода в Нидерландах. Не наблюдю особых проблем, а вот с vpn есть проблемы, но я научилая пускать vpn трафик через все тот же socks5.
Зашел на гитхаб, ожидаемо под капотом для версии >= 8.4 используют lazy objects, а для старых версий php костыли.
Возможно имелось ввиду lazy objects, которые добавлены в 8.4?
Ни кто не заставляет использовать инъекции, для всех зависимостей, через конструктор, можно инъектировать только psr контейнер через конструктор, а его уже передавать в фабричные методы. Тем самым мы и динамический контекст сохраним, и при этом сможем подгружать классы по мере их необходимости. Этакий сервис локатор на максималках.
Вы как будто сами с собой беседуете))) вы поняли что я имею ввиду, несмотря на терминологию. Я не вкладывал больших смыслов в то что написал, право имеет тли не имеет кто-то, это уже предмет дискуссии, которая мне не интересна.
смысл вашего существования в этом направлении может быть, но вряд ли это имеет смысл за рамками вашего существования?
Вы говорите про смысл жизни в рамках конкретного человека, а я говорю про смысл жизни в рамах человечества. Проще аналогию привести, есть макроуровень (человечество) на котором смысла как такового нет, а есть микроуровень(человек) в которому смысл есть. Попытки наложить смыслы из микроуровня в макроуровень, колоссальный философский труд, который можно утилизировать простым вопросом: Зачем?
Автор статьи явно говорил о решении задачи со смыслом жизни на макроуровне при достижении бесмертия. На данный момент наша жизнь довольно коротка чтобы на нашем микроуровне возникали такие проблемы.