А ещё интересно, как решают вопрос с СУБД. Её ведь нельзя обернуть в контейнер (иначе при перезапуске мы потеряем все изменения в данных БД)? Или там данные просто лежат в каталоге, который вне контейнера хранится)
Докеризация позволяет «монтировать» внутренние папки контейнера к внешним папкам хоста. Называется `volume`
Какой тогда вообще в этом смысл? Чтобы что-то собрать из готовых решений, не надо вообще уметь писать код. Это как раз и школьник сможет сделать. Не вижу в этом особого творчества, если честно.
Суть программирования в автоматизации, причем автоматизации того, что еще не автоматизировано. И если уже есть адекватное готовое решение, то нужно задать себе вопрос «А могу ли я сделать лучше, за адекватное время», скорее всего ответ будет очевиден. И нет, школьник (в том контексте, в котором Вы написали) не сможет собрать нормальную инфраструктуру, конечно, если мы говорим о серьезных проектах и о бизнесе.
А творчество можно проявлять в логике, да и оркестрировать готовыми решениями и связывать их в общую структуру — это тоже творчество.
По-моему, это исключение, чем правило. Редко бывает, что человек абсолютно уверен в чем-то, что в итоге оказывается в корне неверным. Конечно, если речь идет о конкретных знаниях и не о кухонных спорах. Либо человек знает ответ, либо не уверен\не помнит\не знает => нужно освежить знания, даже если в итоге правильно ответил
Аналогично против warning, для меня это как «Ну вроде бы что-то не то, и так быть не должно, ну и ладно, продолжаем», имхо это здоровый такой толчок для появления сложно-отлавливаемых багов.
Из примера сложно-отлавливаемых багов в той же Mysql:
Если в поле занести данные, которые больше указанного типа, то эта субд выдаст warning, но проведет операцию заменив значение, на максимально допустимое (то есть, если поле имеет тип varchar(10), а попытаться впихнуть в него 11 символов, то последний символ он просто обрежет, но данные впихнет). Насколько я знаю, в других субд при подобном поведение будет ошибка.
Но в целом, по сабжу, чем проще интерфейс лога, тем больше работы потребуется для его обработки. Имхо, детальность лога в первую очередь важна даже не для программиста, а для построения графиков, метрик, для чтения логов аналитиками
Я думаю, что адекватный кандидат, после собеседования сам будет понимать, какие вопросы ему стоит изучить подробнее без наставлений интервьюера. Явное указание, что подтянуть, очень часто может раздражать (каким бы тактичном оно ни было), лично для меня подобные рекомендации являются раздражителем аналогично «Шапку надень», хоть я и не покажу свои эмоции незнакомому человеку
Мы теперь не заставляем писать код на бумажке. Каждый интервьюер должен принести с собой ноутбук, дальше – выбор за кандидатом.
Жаль, код на бумажке в различных собеседованиях мне нравился, особенно, когда тебя не привязывают к конкретному языку, а можешь писать на псевдоязыке, имхо это больше говорит об опыте кандидата, если он может без зависимостей описать ту или иную логику.
Опасная тактика, если ничто не мешает изначально сделать не говнокод, а код пусть и не особо продуманный, но без грязи. Потому что есть большой шанс, что вернуться к исправлению говнокода не будет ни желания, ни возможностей. И не забывайте, что громкими цитатами типа «Make it work, make it right, make it fast» чаще всего пользуются выдающиеся личности, для которых одно только «make it work» выглядит иначе, и если эти выдающиеся личности увидят результат «make it work» многих программистов, скорее всего они отреагируют фразой из серии «i didn't mean so bad»
Если просто SFTP на общую папку, без смены маппингов, то при переключении предыдущая ветка перестанет существовать на тестовом стенде, часто это бывает неудобно, например, я в течение дня могу одновременно работать с 1-3 ветками, пока одну отправил на ручное тестирование, работаю в другой
С тех пор как появилась возможность исправлять клиентский код в браузере и делать скриншоты, впрочем, в реальной практике были не менее веселые случайности
Я согласен, если есть возможность работать локально — это здорово, но в моем случае разобраться, как выгрузить проект локально так, чтобы он не отличался от тестовых стендов, потребует больше времени (особенно учитывая всю инфраструктуру), если бы был один docker-compose.yml, то было бы проще конечно.
Реальная история:
Моя бабушка лет 5 назад показала, где хранит свой блокнот со всеми финансовыми данными (карточки-пинкоды, номера счетов и т.д.) на случай, если вдруг что.
Глянул код:
1) Ни одного исключения \ нулевая обработка ошибок \ нулевая информативность об ошибках
2) Код на 80% построен на `case` и хадукен if'ах
3) информативнейшие комментарии
// connect database
public static function connect() {
4) Поддерживать этот код сможете только вы (на самом деле любой, но никто в здравом уме это делать не будет)
5) ООП? не, не слышали.
6) Зачем аннотации, если писать в блокноте?
Подитог: для собственного велосипеда и для хобби-программирования — ок, но зачем это тут?
Итог: Для профессиональной разработки лучше использовать нормальную ORM и отказаться от принципа:
Я даже не использовал composer, потому что у меня нет ни одного проекта, где я использую сторонние зависимости кроме самописных.
Неплохой план, в принципе, если каждый день РФ будет выставлять гуглу штраф на 500к рублей, то на разорения гугла уйдет всего лишь 273972 года, не учитывая рост компании, инфляции и прочее.
Такое простое различие по-вашему: Учился в университете — программист, не учился — кодер?
А если я, например, «гуглю» что-то «кодерское», а потом неделю-две-три-год читаю-изучаю на эту тему литературу (которую скорее всего тоже гуглю), разбираюсь в предметной области? Все еще кодер?
В чем различие принципа выше от гугления Навье-Стокса и изучение соответствующей литературы, чтобы разобраться?
Докеризация позволяет «монтировать» внутренние папки контейнера к внешним папкам хоста. Называется `volume`
Суть программирования в автоматизации, причем автоматизации того, что еще не автоматизировано. И если уже есть адекватное готовое решение, то нужно задать себе вопрос «А могу ли я сделать лучше, за адекватное время», скорее всего ответ будет очевиден. И нет, школьник (в том контексте, в котором Вы написали) не сможет собрать нормальную инфраструктуру, конечно, если мы говорим о серьезных проектах и о бизнесе.
А творчество можно проявлять в логике, да и оркестрировать готовыми решениями и связывать их в общую структуру — это тоже творчество.
Из примера сложно-отлавливаемых багов в той же Mysql:
Если в поле занести данные, которые больше указанного типа, то эта субд выдаст warning, но проведет операцию заменив значение, на максимально допустимое (то есть, если поле имеет тип varchar(10), а попытаться впихнуть в него 11 символов, то последний символ он просто обрежет, но данные впихнет). Насколько я знаю, в других субд при подобном поведение будет ошибка.
Но в целом, по сабжу, чем проще интерфейс лога, тем больше работы потребуется для его обработки. Имхо, детальность лога в первую очередь важна даже не для программиста, а для построения графиков, метрик, для чтения логов аналитиками
Жаль, код на бумажке в различных собеседованиях мне нравился, особенно, когда тебя не привязывают к конкретному языку, а можешь писать на псевдоязыке, имхо это больше говорит об опыте кандидата, если он может без зависимостей описать ту или иную логику.
С тех пор как появилась возможность исправлять клиентский код в браузере и делать скриншоты, впрочем, в реальной практике были не менее веселые случайности
Реальная история:
Моя бабушка лет 5 назад показала, где хранит свой блокнот со всеми финансовыми данными (карточки-пинкоды, номера счетов и т.д.) на случай, если вдруг что.
1) Ни одного исключения \ нулевая обработка ошибок \ нулевая информативность об ошибках
2) Код на 80% построен на `case` и хадукен if'ах
3) информативнейшие комментарии
4) Поддерживать этот код сможете только вы (на самом деле любой, но никто в здравом уме это делать не будет)
5) ООП? не, не слышали.
6) Зачем аннотации, если писать в блокноте?
Подитог: для собственного велосипеда и для хобби-программирования — ок, но зачем это тут?
Итог: Для профессиональной разработки лучше использовать нормальную ORM и отказаться от принципа:
Ну по-крайней мере, так в PHPstorm'е
А если я, например, «гуглю» что-то «кодерское», а потом неделю-две-три-год читаю-изучаю на эту тему литературу (которую скорее всего тоже гуглю), разбираюсь в предметной области? Все еще кодер?
В чем различие принципа выше от гугления Навье-Стокса и изучение соответствующей литературы, чтобы разобраться?