Если колонка привязана к аккаунту, то кажется оно всё-равно будет собирать инфу, хотя бы поисковые запросы. А непривязаная колонка наверно компании особо не интересна.
может быть удобно, когда нужно поддерживать больше одного инстанса и нет поддержки секретов из-вне. Копировать на все инстансы переменные окружения может быть утомительно
Первый работал быстро, но мало умел. Второй умел все, но я не видел компьютера на котором он быстро работал :) так что за 10 лет ничего не поменялось. Ide все так же выжирает все ресурсы компа, до каких дотянется. А если не она, то рядом ее докер добьёт в котором база крутится :)
Спасибо за статью.
Открыл для себя такую вещь как squash (сплющивание нескольких коммитов или целых ветов в один коммит)
Но сразу же возник большой вопрос, на который не смог найти в интернетах вразумительного ответа.
Ткните ссылкой, если уже где-то был ответ, но пока мне интересен ответ на следующий кейс:
Текущий workflow команды разрабов выглядит так:
git pull
git commit -am "фича1"
git commit -am "баг в фиче1"
git pull
git push
git commit -am "фича2"
git commit -am "новый баг в фиче1"
git commit -am "Всё, вот теперь точно финал"
git pull
git push
Внимание вопрос. Возможно ли сплющить эти 4 коммита к фиче1 в один коммит уже после того, как они были запушены в общую ветку и ничего не сломать при этом или уже поздно метаться и надо было раньше думать? :-)
А можно и без всяких автоматов обойтись. Можно помечать старые Функции и методы тегом @deprecated, плюс в устаревший метод вкладывать вызов логера, который логирует вызов старых методов и где-нибудь начинают всплывать в логах записи о выполении старых методов. А так же помечать целые классы @deprecated и проверять в autoload'e наличие этого тега.
После этого в правильных IDE начнут всплывать подсказки у разрабочиков, что эти методы или классы уже устарели и их надо бы заменить, но и в логи активно сыпаться начнёт всё это дело.
Ну это проблема уже команды, которая не может пояснить заказчику, что она не можеть взять в итерацию больше обещанного. У нас тоже такое правило есть, но оно не распространяется на хотфиксы, которые прилетают со статусом «аааа, всё упало» и команда не может их не взять, если это угрожает стабильности продукта. У каждой команды есть свой менеджер который отвечает за часть продукта и уже он заворачивает все «хотелки» выше стоящих людей, а если не заворачивает, то берёт ответственность на себя, за то что, его команда не выпустила обещанный функционал в срок. В остальном же, задачи по улучшению и не критическим багам легко двигаются в следующюю итерацию или вообще в беклог. Так что всё возможно.
Я думаю, что как только предложение «превратить все фаталы, ворнинги и т.д в исключения» пройдет стадию обсуждения и апрува, то и finally начнет все спазу отлавливать и обрабатывать ;-)
Смысла тогда в нём особого не будет. В finally мы будем всегда закрывать коннекты, писать логи, работать с транзакциями… вариантов много… а catch — это для более тонкой настройки останется.
Вспоминаю те времена, когда Notepad++ был просто хорошей заменой обычного нотпада с подсветкой синтаксиса и вкладками. А теперь он почти как Nero стал :)
То что графика там была плохая, я узнал только что, прочитав статью. Всё там было отлично. Особенно после графики первой диаблы. С другими играми я её тогда не сравнивал.
на сколько я понял, это плагин для PWA приложений, т.е. там не используются встроенные функции телефона.
Если колонка привязана к аккаунту, то кажется оно всё-равно будет собирать инфу, хотя бы поисковые запросы. А непривязаная колонка наверно компании особо не интересна.
10 лет назад были NetBeans и Eclipse
Первый работал быстро, но мало умел. Второй умел все, но я не видел компьютера на котором он быстро работал :) так что за 10 лет ничего не поменялось. Ide все так же выжирает все ресурсы компа, до каких дотянется. А если не она, то рядом ее докер добьёт в котором база крутится :)
Открыл для себя такую вещь как squash (сплющивание нескольких коммитов или целых ветов в один коммит)
Но сразу же возник большой вопрос, на который не смог найти в интернетах вразумительного ответа.
Ткните ссылкой, если уже где-то был ответ, но пока мне интересен ответ на следующий кейс:
Текущий workflow команды разрабов выглядит так:
Внимание вопрос. Возможно ли сплющить эти 4 коммита к фиче1 в один коммит уже после того, как они были запушены в общую ветку и ничего не сломать при этом или уже поздно метаться и надо было раньше думать? :-)
После этого в правильных IDE начнут всплывать подсказки у разрабочиков, что эти методы или классы уже устарели и их надо бы заменить, но и в логи активно сыпаться начнёт всё это дело.