Я думаю, что не стоит извиняться за описание ужасов ограбления и прочих преступлений. Только те, кто еще не попадал в подобные ситуации, отнесутся к этому скептически. Лучше учиться на чужих ошибках. Да, такие вещи с большинством случаются очень редко, но если вероятность, что вас убьют один на миллион, лучше от этого защититься, а не умереть с низкой вероятностью.
Контроллер не меньше завязан на симфони, чем диспетчер. Если ты отвязываешься от симфони, тебе надо реализовать DI, контроллер, респонс. В случае с диспетчером – диспетчер.
Мы говорим о бизнес-логике приложения или об уровне представления? Я вижу тут обработку исключений на уровне контроллера и общего хендлера. И чем обработка исключений через ExceptionController отвязывает нас от фреймворка? Скорее, наоборот, привязывает намертво: события – это простые value-объекты, и их можно переиспользовать, а перегруженный ExcetpionController – это прямое наследие симфони.
В итоге мы получаем смешение подходов и еще большую путаницу при поддержке: бандлы, которые мы подключаем используют одну модель, приложение (я так понимаю, состоящее из одного бандла) имеет другую. Либо так, либо мы сразу говорим о том, что приложение не подразумевает расширения.
То есть если я пишу бандл, которы хочет как-то реагировать на исключения, я должен реализовать сервис, подходящий под ваши нужды и перед использованием попросить вас заинжектить его и дёрнуть в контроллере?
Почему вы решили, что я так решил? Автор отсылает нас к якобы подходу, практикуемому в СССР. На самом деле это неправда, он не практиковался. Кому было интересно, кто горел, как горит автор, тот работал и получал результаты. А «не высовываться» и создавать видимость активности можно при любом устройстве, если только не оценивается конкретный результат. В какой-нибудь финансовой компании ты можешь сколько угодно имитировать деятельность, но когда начнется квартальная оценка по методике «360 градусов», тебя уволят. И в НИИ в совке тоже можно было уйти за непрофпригодность, да еще и так, что потом никуда не возьмут.
> Они хотели простой и предсказуемой жизни: приходить в офис к 9 утра, изображать бурную деятельность, не высовываться, и уходить домой в 5 вечера.
Да? А мой батя тоже всю жизнь работает в своём НИИ. НИИ бюрократизировано насквозь. Вот все стереотипы: бабки-шпиономанки на проходной, каждый пук только с разрешающей бумажкой. Приходит он в офис к 9 утра, уходит в 5 или 6 вечера, спать ложится в 8 вечера. Создаёт аэродинамические трубы (круче которых в мире, так-то, не существует), авиадвигатели создаёт, толкает, что есть сил, отрасль вперёд. Это тоже называется «не высовываться»?
> управляют бизнесом в Барселоне или работают на фирму из Сан-Франциско, находясь в Сингапуре.
Ага. На основах предпринимательской деятельности в разделе рисков нас учили: первый и самый действенный метод отжать бизнес – выгнать владельца/управляющего из страны, лишить физического доступа к бизнесу.
Кстати, а второму пилоту что-то будет за ошибку или как это летчиков-испытателей устроено – «косякнул, вот теперь и живи с осознанием вины за смерть товарища»?
Ну то есть у вас под каждую версию по сути свой мастер, в который мы добавляете изменения, как я понял, патчами. И сразу же ставить тег релиза, так как, как было указано выше, в «релизных» ветках у вас код всегда готов поехать на бой. То есть это все-равно, что коммитить в мастер. Чем вам не нравится идея делать ветки следующий релизов от старых релизов (для того, чтобы не забирать изменения из мастера, а в мастер отправлять все изменения в старых релизах? Кстати, да, не совсем понятно, как изменения из релизных веток попадают в мастер. Только параллельно, патчами из фича-веток?
Ветви релизов не могут быть закрыты пока осуществляется сопровождение продукта, так на момент написания этих строк багфиксы и часть нового функционала вносятся на все версии выпущенные с начала 2009 года.
Не понял момента с незакрываемостью веток релизов. Вы ведь когда-то делаете, собственно, релиз. Значит можно закончить ветку release/1.0.0, а в случае дополнение сделать из неё ветку release/1.0.1? А если вы не закрываете ветку – как вы помечаете факт релиза?
Статья по ссылке начинается просто прекрасно: Доказано, что раннее пробуждение не влияет на социально-экономическое положение человека или его продуктивность. С другой стороны, я думаю, что раннее пробуждение – это воистину ключевая привычка, в которой заложен потенциал для создания цепной реакции по изменению и приведению в порядок других обыденных действий.
Да? А мой батя тоже всю жизнь работает в своём НИИ. НИИ бюрократизировано насквозь. Вот все стереотипы: бабки-шпиономанки на проходной, каждый пук только с разрешающей бумажкой. Приходит он в офис к 9 утра, уходит в 5 или 6 вечера, спать ложится в 8 вечера. Создаёт аэродинамические трубы (круче которых в мире, так-то, не существует), авиадвигатели создаёт, толкает, что есть сил, отрасль вперёд. Это тоже называется «не высовываться»?
Ага. На основах предпринимательской деятельности в разделе рисков нас учили: первый и самый действенный метод отжать бизнес – выгнать владельца/управляющего из страны, лишить физического доступа к бизнесу.
Не понял момента с незакрываемостью веток релизов. Вы ведь когда-то делаете, собственно, релиз. Значит можно закончить ветку release/1.0.0, а в случае дополнение сделать из неё ветку release/1.0.1? А если вы не закрываете ветку – как вы помечаете факт релиза?
Доказано, что раннее пробуждение не влияет на социально-экономическое положение человека или его продуктивность. С другой стороны, я думаю, что раннее пробуждение – это воистину ключевая привычка, в которой заложен потенциал для создания цепной реакции по изменению и приведению в порядок других обыденных действий.
Прочитал, #zaplakal