Я вот живу в своем собственном маленьком мире и использую Eloquent (даже при дорогостоящих операциях, где допустим условный join будет в 10 раз быстрее чем where exists).
Пока доводилось поработать только с низко нагруженными проектами и там это не встаёт проблемой - использование фреймворка хватает чтобы закрывать потребности.
Но, пожалуй, теперь, настаивать на том чтобы в каждую бочку пихать затычки: фреймворки и ORM, я не буду.
Посмотрите пункт 1.1 в предлагаемой сводке стандартов PSR-2: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
PhpStorm автоматически форматирует код в соответствии с данными принятыми правилами (есть такая там штука: Ctrl+Shift+L, которая позволяет даже html автоматически разминифицировать и расставить отступы). Обычно я ей пользуюсь когда вижу что код отформатирован не в соответствии со стандартами принятыми внутри команды, о которых я сразу сообщаю разработчикам, делаю style guide, где описываю общие правила для популярных конструкций кода.
Само собой, по привычке, разработчик продолжает ставить фигурную скобку после if в php на следующей строке, даже пересев с netbeans на phpstorm, это не меняет ситуацию. Сила привычки велика.
Со сравнением на ноль вообще странная штука. Видимо причина все таже - дело привычки.
Есть какие-то ситуации, когда математические операции не дают целочисленный 0 - может быть компьютерные вычисления не могут оставить равноценный остаток между, казалось, бы одинаковыми числами с плавающей точкой. Возможно это знание пришло из других языков, где это и правдо было актуально и теперь используется по привычке: https://github.com/OFFLINE-GmbH/oc-mall-plugin/issues/730
У нас тут в laravel новички постоянно оборачивают конструкции Eloquent Builder в отдельные методы якобы следуя принципу не повторяйcя, но по сути они одну строку кода, оборачивают в метод, и якобы думают что они этим самым следуют принципу DRY. Но по факту они следуют принципу "выбесить тим-лида, 1001 способ)".
И с другой стороны, если не соблюдется DRY: это практически всегда говорит о неправильном использовании концептов архитектуры. То есть код сам по себе пахнет, и как правило это всегда сопровождается не правильным использованием жизненного цикла запроса в веб-приложении (мы используем фреймворки и CMS на основе фреймворков, и когда "забивают" на архитекрнуые принципы в рамках этого "каркаса", это очень заметно и практически сразу ведёт к проблемам: повторяющийся код, не связанная логика, разделение принципов ответственности тоже отсутствует).
Действительно Вы правы, как никто другой - дело не в слепом следовании паттернам, хотя их понимание, может помочь написать более крутой код в рамках того же laravel (я честно старался понять как использовать фасады в повседневной жизни, но так пока до конца и не понял, но это и не важно), важно это чувство, когда в мыслях вы видите вашу программу, связи между классами, и насколько эти связи корректны, когда задаётесь вопросом, по проектировании кода, что "вот этого участка" здесь быть не должно и только из-за одной этой мысли - перепроектируете половину приложения, переписывая взаимосвязи по-новому, пока у вас не останется никаких претензий к логике. Вот это бы знание - да новичкам.
Начали смотреть в сторону storybook, говорят у него родная интеграция с Vite. Только до конца не уверены нужно ли это нам. Я во фронтенде не очень силен (как показала череда недавних собеседований на позицию Fullstack: я, оказывается, не знаю ES6 и flex-wrap) - поэтому искренне не могу вовлечся во все новые техники, применимые к проекту по части nodejs. Может это конечно и есть "проклятие" фуллстеков, что они не могут как следует вовлечся в какую-то одну область.
Не, знаю, насчёт лендосов. Они там неплохо и на jQuery силами самих верстальщиков собираются, с scss-ом.
Но насчёт vite для среднестастияеского интернет-магазина с грудой typoscript, неплохой сборщик.
Стартует на дев-машине быстро. Все что нужно - лоадит. SSR к Vite скоро начнем постигать на проде. Это явно речь не о лендосе уже.
Webpack Encore от Symphony ещё куда ни шло. И портянки перестали быть чем-то необходимым. Скорость: на дев-машине - проект среднего размера пересобирался очень долго. С Vite эти проблемы перестали существовать. Кмк, может я не разбираюсь, и webpack тоже может за мгновение стартовать сборку всю на дев.
Всю жизнь так работаю. И каждый раз все тоже самое. Начнёшь кодить фичу, на тебя сваливается тысячу внезапных багов, срочных новых дел и обязательств всем помогать и выполнять обещания чего то там "посмотреть". Всегда бомбило это. Раздрай человеческих ресурсов и мотивации: дело никакое большое не сделать во время и человеком себя сложно чувствовать на работе. Причем не хватает всегда "чуть-чуть" пару тройку дней чтобы дописать код, в тот момент когда менеджеры начинают отвлекать. На лицо ошибка стратегического планирования.
Что-то совсем забыли про сисадмина и девопса. Хороший программист, после сведения отчетов в бухгалтерии, и обучения джунов, должен пойти настроить CI/CD, выяснить почему с сервера 00X, перестали делаться бекапы и почему InnoDB таблицы уходят в глубокую блокировку при работе очередей.
Не вижу никакой проблемы Яндекс.Тренажера в реакции на лишние пробелы. Когда начнёте использовать линтеры, автоформатипование, нормальные IDE, то вопрос строгости к пробелами не будет казаться таким негуманным. Тренажёр как бы вас уже учит ставить ровно столько пробелов сколько нужно. Когда я вижу "гуляющие" отступы в коде джунов это наводит на мысль, что они неграмотны.
От винды отказался лет 15 назад и ни о чем не жалею. Но Ubuntu, я пожалуй все равно ставить на десктоп не буду. Без проблем не интересно.
Начинал, как и все нормальные люди, с FreeBSD (а до этого успел познакомится с MS DOS, Norton Commander, Windows 3.11, Windows 98. Windows millenium, vista, xp и 7). В те времена когда начали появляться семёрки и десятки, а где-то там в лесах сидели за маками (о них я ничего не знал и знать не буду), я уже вовсю собирал порты из исходников и учил что такое интернет (драма в том, что интернетом я уже пользовался давно, а понимать как он работает начал после чтения инструкции к FreeBSD).
Делал десткоп из OpenBSD - особый вид фетиша, но кажется я понял это не мое и поставил в итоге Арч.
Никогда этого не делал, но иногда, хотел, потрогать.
Не знаю как оно, даст ли прийти к вашей цели. Но есть, как я это понимаю, штука для мониторинга приложений на php (и не только на php, а ещё и есть штука для отслеживания пользовательских ошибок в исполняемом в их же браузерах javascript).
Сделайте калькулятор ачивок для какой-нибудь онлайн игры.
Типа расчета юнитов и силы войск, или расчета населения в строительных стратегиях.
Делайте то, что ещё не изобрели. Иначе это преступление по Дарвину.
И если уж сильно хочется сделать интернет-магазин, то там должен быть такой функционал, который ещё не придумали, берите интересные идеи сразу, на этапе обучения. Программировать вы конечно так не научитесь, но время проведёте с пользой.
Фуллстек миддл, прочитавший за день документацию с vuejs станет через год не более чем миддлом в vue. А тот чувак, который не играл в фуллстек и любит во фронт, станет хорошим спецом в vue3 и typoscript за год.
Меня на фрилансе всегда просят оценить в часах. Каждый час - плюс минус косарь для заказчика. 37 часов - соответственно 37 косарей.
Никогда не оперировали такими терминами как человеко-месяц и прочее.
Всегда, частному лицу, который работает с конкретным тобой важно знать, сколько конкретных косарей он должен потратить, чтобы получит хоть какой-нибудь результат.
И тут два варианта - либо для подрядчика это фикс цена, и сколько бы часов он не потратил на реализацию продукта - получит одну и туже сумму при каких бы то ни было трудозатратах.
Либо заказчик с тобой работает уже давно и понимает, что в ИТ невозможна точная оценка всего, а если бы и была возможна это наверняка бы существовал целый отдел аналитиков, и она бы уточнялась бы каждый день на протяжении всего срока жизни разработки.
Я вот живу в своем собственном маленьком мире и использую Eloquent (даже при дорогостоящих операциях, где допустим условный join будет в 10 раз быстрее чем where exists).
Пока доводилось поработать только с низко нагруженными проектами и там это не встаёт проблемой - использование фреймворка хватает чтобы закрывать потребности.
Но, пожалуй, теперь, настаивать на том чтобы в каждую бочку пихать затычки: фреймворки и ORM, я не буду.
Посмотрите пункт 1.1 в предлагаемой сводке стандартов PSR-2: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
PhpStorm автоматически форматирует код в соответствии с данными принятыми правилами (есть такая там штука: Ctrl+Shift+L, которая позволяет даже html автоматически разминифицировать и расставить отступы). Обычно я ей пользуюсь когда вижу что код отформатирован не в соответствии со стандартами принятыми внутри команды, о которых я сразу сообщаю разработчикам, делаю style guide, где описываю общие правила для популярных конструкций кода.
Само собой, по привычке, разработчик продолжает ставить фигурную скобку после if в php на следующей строке, даже пересев с netbeans на phpstorm, это не меняет ситуацию. Сила привычки велика.
Со сравнением на ноль вообще странная штука. Видимо причина все таже - дело привычки.
Есть какие-то ситуации, когда математические операции не дают целочисленный 0 - может быть компьютерные вычисления не могут оставить равноценный остаток между, казалось, бы одинаковыми числами с плавающей точкой. Возможно это знание пришло из других языков, где это и правдо было актуально и теперь используется по привычке: https://github.com/OFFLINE-GmbH/oc-mall-plugin/issues/730
У нас тут в laravel новички постоянно оборачивают конструкции Eloquent Builder в отдельные методы якобы следуя принципу не повторяйcя, но по сути они одну строку кода, оборачивают в метод, и якобы думают что они этим самым следуют принципу DRY. Но по факту они следуют принципу "выбесить тим-лида, 1001 способ)".
И с другой стороны, если не соблюдется DRY: это практически всегда говорит о неправильном использовании концептов архитектуры. То есть код сам по себе пахнет, и как правило это всегда сопровождается не правильным использованием жизненного цикла запроса в веб-приложении (мы используем фреймворки и CMS на основе фреймворков, и когда "забивают" на архитекрнуые принципы в рамках этого "каркаса", это очень заметно и практически сразу ведёт к проблемам: повторяющийся код, не связанная логика, разделение принципов ответственности тоже отсутствует).
Действительно Вы правы, как никто другой - дело не в слепом следовании паттернам, хотя их понимание, может помочь написать более крутой код в рамках того же laravel (я честно старался понять как использовать фасады в повседневной жизни, но так пока до конца и не понял, но это и не важно), важно это чувство, когда в мыслях вы видите вашу программу, связи между классами, и насколько эти связи корректны, когда задаётесь вопросом, по проектировании кода, что "вот этого участка" здесь быть не должно и только из-за одной этой мысли - перепроектируете половину приложения, переписывая взаимосвязи по-новому, пока у вас не останется никаких претензий к логике. Вот это бы знание - да новичкам.
Конечно же больше всего меня бесит когда фигурную скобку ставят на следующей после if строке:
Нет ничего, чтобы раздражало больше чем это.
Или вот сравнение на 0 ещё:
Camm on, серьезно? Нет, послушай, ты реально считаешь, что там может быть что-то отличное от 0 быть? (Привет Tobias)
Это да. По сравнению с ними - webpack encore выглядет минималистично: https://paste.slave.dimti.ru/?9b7c06089ea6c5b6#3b4WyKt8hNn1KVAEoQPM9dfpTTfKre5fXHw9gBuY7RVS
Начали смотреть в сторону storybook, говорят у него родная интеграция с Vite. Только до конца не уверены нужно ли это нам. Я во фронтенде не очень силен (как показала череда недавних собеседований на позицию Fullstack: я, оказывается, не знаю ES6 и flex-wrap) - поэтому искренне не могу вовлечся во все новые техники, применимые к проекту по части nodejs. Может это конечно и есть "проклятие" фуллстеков, что они не могут как следует вовлечся в какую-то одну область.
В текущей реализации проекта (без SSR) конфиг выглядит так: https://paste.slave.dimti.ru/?0e723a34823f8d4e#57wQbHT6bCMaggTb31F6th1N7AfF9z9MXET4LDjgCBVy. Мой коллега Александр подключил туда Vue и небольшой минификатор изображений.
Eslint лежит рядом: https://paste.slave.dimti.ru/?8abe3f83b6f8a93e#DdswMt6FgQdYc9894JpsEieKK9nDk7vsQ6sFJGJZWDiL
Видимо Eslint сам по себе цепляется (у меня к IDE прицеплен, но насчет сборщика я не уверен). Позову помощь.
Не, знаю, насчёт лендосов. Они там неплохо и на jQuery силами самих верстальщиков собираются, с scss-ом.
Но насчёт vite для среднестастияеского интернет-магазина с грудой typoscript, неплохой сборщик.
Стартует на дев-машине быстро. Все что нужно - лоадит. SSR к Vite скоро начнем постигать на проде. Это явно речь не о лендосе уже.
Webpack Encore от Symphony ещё куда ни шло. И портянки перестали быть чем-то необходимым. Скорость: на дев-машине - проект среднего размера пересобирался очень долго. С Vite эти проблемы перестали существовать. Кмк, может я не разбираюсь, и webpack тоже может за мгновение стартовать сборку всю на дев.
Всю жизнь так работаю. И каждый раз все тоже самое. Начнёшь кодить фичу, на тебя сваливается тысячу внезапных багов, срочных новых дел и обязательств всем помогать и выполнять обещания чего то там "посмотреть". Всегда бомбило это. Раздрай человеческих ресурсов и мотивации: дело никакое большое не сделать во время и человеком себя сложно чувствовать на работе. Причем не хватает всегда "чуть-чуть" пару тройку дней чтобы дописать код, в тот момент когда менеджеры начинают отвлекать. На лицо ошибка стратегического планирования.
Что-то совсем забыли про сисадмина и девопса. Хороший программист, после сведения отчетов в бухгалтерии, и обучения джунов, должен пойти настроить CI/CD, выяснить почему с сервера 00X, перестали делаться бекапы и почему InnoDB таблицы уходят в глубокую блокировку при работе очередей.
Не вижу никакой проблемы Яндекс.Тренажера в реакции на лишние пробелы. Когда начнёте использовать линтеры, автоформатипование, нормальные IDE, то вопрос строгости к пробелами не будет казаться таким негуманным. Тренажёр как бы вас уже учит ставить ровно столько пробелов сколько нужно. Когда я вижу "гуляющие" отступы в коде джунов это наводит на мысль, что они неграмотны.
Спасибо. Как сказка на ночь.
От винды отказался лет 15 назад и ни о чем не жалею. Но Ubuntu, я пожалуй все равно ставить на десктоп не буду. Без проблем не интересно.
Начинал, как и все нормальные люди, с FreeBSD (а до этого успел познакомится с MS DOS, Norton Commander, Windows 3.11, Windows 98. Windows millenium, vista, xp и 7). В те времена когда начали появляться семёрки и десятки, а где-то там в лесах сидели за маками (о них я ничего не знал и знать не буду), я уже вовсю собирал порты из исходников и учил что такое интернет (драма в том, что интернетом я уже пользовался давно, а понимать как он работает начал после чтения инструкции к FreeBSD).
Делал десткоп из OpenBSD - особый вид фетиша, но кажется я понял это не мое и поставил в итоге Арч.
Никогда этого не делал, но иногда, хотел, потрогать.
Не знаю как оно, даст ли прийти к вашей цели. Но есть, как я это понимаю, штука для мониторинга приложений на php (и не только на php, а ещё и есть штука для отслеживания пользовательских ошибок в исполняемом в их же браузерах javascript).
Все, это, конечно стоит безумных денег для сколь либо приемлемой аналитики. И с поддержкой в России у них "так себе" (никак). Но сервис запили знатный https://docs.newrelic.com/docs/agents/php-agent/getting-started/introduction-new-relic-php/
Сделайте калькулятор ачивок для какой-нибудь онлайн игры.
Типа расчета юнитов и силы войск, или расчета населения в строительных стратегиях.
Делайте то, что ещё не изобрели. Иначе это преступление по Дарвину.
И если уж сильно хочется сделать интернет-магазин, то там должен быть такой функционал, который ещё не придумали, берите интересные идеи сразу, на этапе обучения. Программировать вы конечно так не научитесь, но время проведёте с пользой.
Рад видеть, что что тут не только про реакт.
Фуллстек миддл, прочитавший за день документацию с vuejs станет через год не более чем миддлом в vue. А тот чувак, который не играл в фуллстек и любит во фронт, станет хорошим спецом в vue3 и typoscript за год.
Меня на фрилансе всегда просят оценить в часах. Каждый час - плюс минус косарь для заказчика. 37 часов - соответственно 37 косарей.
Никогда не оперировали такими терминами как человеко-месяц и прочее.
Всегда, частному лицу, который работает с конкретным тобой важно знать, сколько конкретных косарей он должен потратить, чтобы получит хоть какой-нибудь результат.
И тут два варианта - либо для подрядчика это фикс цена, и сколько бы часов он не потратил на реализацию продукта - получит одну и туже сумму при каких бы то ни было трудозатратах.
Либо заказчик с тобой работает уже давно и понимает, что в ИТ невозможна точная оценка всего, а если бы и была возможна это наверняка бы существовал целый отдел аналитиков, и она бы уточнялась бы каждый день на протяжении всего срока жизни разработки.