А через 2 года, если не заплатите, откатитесь к продукту 2-летней давности?
По мне, так это банальная подписка, вусмерть замаскированная благими намерениями «не обидеть клиента». Люди привыкли к тому, что они _покупают_ ваш продукт, и вам теперь просто адские усилия надо будет приложить, чтобы это мнение изменить. Переламывать через колено придется, а это никто не любит
Я ж не спорю, что жить надо. Просто в данном случае апеллировать надо не к свободе прессы, которая к рекламе никакого отношения не имеет, а к каким-то другим факторам. А то, как только реклама блокируется, сразу вопли об ущемлении свободы прессы.
Интересно, кто-нибудь напомнил истцам, что свобода прессы заключается в том, чтобы озвучивать на страницах издания свое мнение, а не в том, чтобы публиковать рекламу?
Правительство хочет создать структуру, которая будет повторять коммерческую? Те хотят бабла заработать, эти — распилить и подсидеть начальника. Дитя умрет во чреве.
Кстати, Ваши наработки для игр — это частные решения, которые становятся частью большого решения — фреймворка. И его тоже очень условно можно назвать CMS :)
Игры — да. Движок, который используется потом в десятках других игр и бизнес-приложение, каждое из которых суть другая разработка — разные вещи.
Терминалы — да. Они остаются терминалами и решают одну задачу. По сути, это CMS, обвешанная кастомными гуями и плюшками, об чем уже написал.
Что касается следующего коммента, никто и не просит дергаться между разными областями. И слава Богу, что Вы спец в определенной области :) В Вашей области переиспользование кода только на благо.
Кстати, так далеко метаться между областями не стоит :). Даже два кастомных веб-сайта практически гарантируют, что это будут уникальные решения без переиспользования кода.
Я в разработке уже тыщу лет, работал и на заказ, и для in-house, сделал многие десятки проектов. Делал и по нескольку в одной команде, и в разных. Это предпредисловие :)
Ведь то что пишешь для одного проекта можно потом использовать и в другом
Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо: ни в одном. Серьезно, ни в одном. Дело не в том, что не хотелось, просто все проекты были разными. Даже те, которые не отличались кардинально от предыдущих. Разумеется, эта разница касается кода, который используется в бизнес-логике, разные там логгеры и мониторинги не в счет. Мы же о коде, который выполняет бизнес-задачу, правильно? Вот об этом и говорю.
Можно использовать архитектурное решение, но, если оно сделано по уму (паттерны-шматтерны), то в следующем проекте вы будете использовать именно паттерны-шматтерны, а не конкретное решение, потому что для другого клиента реализация будет другой.
Повторно использовать то, что пишешь для одного проекта, ты, скорее всего (ни разу не факт), будешь в 2 случаях:
Когда ты продаешь решение, которое потом будет частью большого проекта. Пример — CMS.
Когда ты продаешь проект, который является долгосрочным, и однозначно уверен, что он будет дорабатываться. Если уверен!
Это было предисловие.
В данном случае Petrovich_Z решал конкретную задачу, и ему нужна была конкретная функциональность. И он ни разу не был уверен, что что-то там будет дорабатываться потом. Посему здесь уместно и должно использовать KISS. Решать ровно ту задачу, которую нужно было решить.
Не стоит придумывать элегантных универсальных решений там, где их быть не должно. Хотя, простое решение тоже может быть элегантным :) А вот когда нужно будет вернуться к фиче повторно (мы же не уверены, что к ней вообще надо будет возвращаться) и начать ее расширять, вот тогда имеет смысл реализовать свои фантазии, потому что вероятность третьего возврата к фиче будет гораздо больше. И то не факт :)
Как-то так.
На объявление о вакансии PHP-разработчика откликнулось порядка 120 человек.
… из всех присланных резюме, осталось только 60.
Напомнило.
Сидят 2 HR-а — опытный и новичок. Опытный берет пачку резюме и говорит: «Ну что, начнем разбираться?», делит пачку пополам и половину выбрасывает в мусорное ведро. Новичок в шоке. Опытный: «А на фига нам неудачники?»
Дополню.
Показать же можно уже через спринт какое-то цельное и работающее решение. Пусть оно будет в виде тележки, подвозящей провод от генератора к площадке запуска, но оно будет работать.
А через 2 года, если не заплатите, откатитесь к продукту 2-летней давности?
По мне, так это банальная подписка, вусмерть замаскированная благими намерениями «не обидеть клиента». Люди привыкли к тому, что они _покупают_ ваш продукт, и вам теперь просто адские усилия надо будет приложить, чтобы это мнение изменить. Переламывать через колено придется, а это никто не любит
Терминалы — да. Они остаются терминалами и решают одну задачу. По сути, это CMS, обвешанная кастомными гуями и плюшками, об чем уже написал.
Что касается следующего коммента, никто и не просит дергаться между разными областями. И слава Богу, что Вы спец в определенной области :) В Вашей области переиспользование кода только на благо.
Кстати, так далеко метаться между областями не стоит :). Даже два кастомных веб-сайта практически гарантируют, что это будут уникальные решения без переиспользования кода.
Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо: ни в одном. Серьезно, ни в одном. Дело не в том, что не хотелось, просто все проекты были разными. Даже те, которые не отличались кардинально от предыдущих. Разумеется, эта разница касается кода, который используется в бизнес-логике, разные там логгеры и мониторинги не в счет. Мы же о коде, который выполняет бизнес-задачу, правильно? Вот об этом и говорю.
Можно использовать архитектурное решение, но, если оно сделано по уму (паттерны-шматтерны), то в следующем проекте вы будете использовать именно паттерны-шматтерны, а не конкретное решение, потому что для другого клиента реализация будет другой.
Повторно использовать то, что пишешь для одного проекта, ты, скорее всего (ни разу не факт), будешь в 2 случаях:
Это было предисловие.
В данном случае Petrovich_Z решал конкретную задачу, и ему нужна была конкретная функциональность. И он ни разу не был уверен, что что-то там будет дорабатываться потом. Посему здесь уместно и должно использовать KISS. Решать ровно ту задачу, которую нужно было решить.
Не стоит придумывать элегантных универсальных решений там, где их быть не должно. Хотя, простое решение тоже может быть элегантным :) А вот когда нужно будет вернуться к фиче повторно (мы же не уверены, что к ней вообще надо будет возвращаться) и начать ее расширять, вот тогда имеет смысл реализовать свои фантазии, потому что вероятность третьего возврата к фиче будет гораздо больше. И то не факт :)
Как-то так.
Золотые слова. Сторонникам подхода «а давайте напишем универсальный расширяемый код» посвящается.
То есть, это не за счет инновационных разработок, пущенных в производство?
Вопрос риторический, ответа от Чубайса не жду :)
2. Не контролируются владельцами сайта
Напомнило.
Сидят 2 HR-а — опытный и новичок. Опытный берет пачку резюме и говорит: «Ну что, начнем разбираться?», делит пачку пополам и половину выбрасывает в мусорное ведро. Новичок в шоке. Опытный: «А на фига нам неудачники?»
Показать же можно уже через спринт какое-то цельное и работающее решение. Пусть оно будет в виде тележки, подвозящей провод от генератора к площадке запуска, но оно будет работать.