Не очень понимаю, как мне должно стать удобнее. В своё время я купил RubyMine 5 за какие-то там 40-50 долларов (по распродаже). И знаю, что когда захочу обновиться, мне это будет стоить 59 (вроде бы) долларов. Только я уже года два не обновляюсь, мне не нужно, оно хорошо и круто работает! Зачем мне новая версия?
А с новой моделью — должен платить каждый. год. Да, чуть-чуть дешевле чем раньше. Но там была вечная лицензия, а сейчас — каждый. год. каждый.
У нас в небольшой компании прилетел крупный проект, под него мы хотели закупить всем девелоперам идею (я пощупал community и понял, что да, это то что нам нужно) — по 500 баксов на человека нам дороговато, но т.к. проект в целом на год+ — окей, оно того стоит. Но когда через год мы поймём, что этот проект таки выстрелил и будет поддерживаться ещё 1-2 года, то с новой моделью мы в итоге очень некисло так переплатим на ровном месте. В итоге, однозначно нет, ещё и с таким курсом бакса. Мы эти деньги пустим на другие штуки.
Дык комментарий выше имхо не об этом говорит. Человек любит эффективно решать поставленные задачи, а не процесс их решения ради самого процесса. И статья именно об этом!
Я пытался сказать, что в теории, статьях, картинках, разговорах — различия между паттернами высосаны из пальца и не принципиальны. Мало смысла пытаться забивать себе голову тем, как MVC отличается от, допустим, MVPVM. На практике разница будет, но не в принципиальном подходе, а небольших деталях реализации. И вытекать она будет из требований и условий проекта, а не решений сверху «давайте здесь будет использовать MVP, а вот здесь — MVVM». И всё-равно в каждом проекте будет своя «версия» MV*, отличающаяся от теории. Даже в пресловутом ASP.NET MVC не то, что описано в данной статье.
В последнее время на Хабре, да и в принципе в головах разработчиков так часто мусолится тема MVC/MVP/MVVM/MV*, начало всплывать такое множество различных вариаций этих паттернов, что в какой-то момент задумываешься: а где же, блин, отличия между ними :-) Приходится (зачем?) глубоко вчитываться во все описания и приходить к выводу, что всё это многообразие обусловлено лишь ограничениями\спецификой случаев, в которых их применяют. И «толщиной» каждого из слоёв — где-то больше кода во вью, где-то в контроллере. Как результат — когда кто-то рассказывает тебе о MV* или задаёт тебе вопрос на эту тему, уже невольно теряешься: а что конкретно этот человек понимает под этими буквами. Все эти различия и нюансы настолько незначительны и не принципиальны…
ИМХО просто SSD заняли свою нишу, откусив у HDD кусок пирога: в моих ноутбуках уже год как установлены исключительно SSD.
И никаких сожалений об объёме диска: современные ноутбуки с установленным 1Тб HDD — простой маркетинг. Мало кому столько место реально нужно на ноутбуке.
А вот на HDD пускай хранятся архивы и редко используемый медиа-контент.
Я рискну объяснить, почему люди так отреагировали на эту статью.
Архитекторы действительно бывают разные, с разными зонами ответственности.
Лично я могу утверждать про должность архитектора ПО — эти люди действительно обязаны уметь программировать, при этом делать это отлично.
Системные архитекторы — насколько я понимаю, отвечают за интеграцию компонент одной системы или разных систем. Но опять же, опыт в разработке ПО и понимание основных инструментариев\технологий здесь тоже крайне необходимы.
Вы, скорее всего, пишете про архитектору предприятия. Здесь действительно, на мой взгляд, необходимы навыки системного администрирования. Задачи и ответственность в принципе понятны из названия — грамотно построить IT-инфраструктуру предприятия, с оглядкой на бизнес.
Однако встречаются абзацы типа:
Бывают случаи когда разработчики выпускают продукт, не удовлетворяющий требованиям пользователя. И здесь выплывает одна из малоприятных, но первоочередных задач архитектора — прослеживать процесс реализации требований пользователя в программном коде. Архитектор должен понимать и документировать не только решения, но и причины принятия данных решений.
и
Одним из методов ограничения полета фантазии разработчиков являются архитектурные принципы и ограничения. Они представляют собой набор правил системного и бизнес уровня. К примеру, один из принципов может звучать следующим образом «Для проекта используем технологию ASP.Net». Не плохо сразу же писать и причины данных принципов.
Это — ответственность архитектора ПО \ техлида. Он обязан иметь глубокие познания в разработке и архитектуре ПО, иначе банально не справится с задачами (т.к. ему необходимо принимать решения за\для программистов). Карьерный путь с простого разработчика до этой должности занимает 5+ лет.
Дык о чём я и говорю! Во фронт-енде по понятным причинам нужны валидации. В публичном API по тем же самым причинам — тоже нужны те же самые валидации. А затем, возможно, и на бекенде. Но заодно в API мы предусматриваем случай «бекенд недоступен», а во фронт-енде: «API недоступен». Всё это влечёт за собой дополнительный код, который я и назвал усложнение\удорожание процесса разработки.
А с новой моделью — должен платить каждый. год. Да, чуть-чуть дешевле чем раньше. Но там была вечная лицензия, а сейчас — каждый. год. каждый.
У нас в небольшой компании прилетел крупный проект, под него мы хотели закупить всем девелоперам идею (я пощупал community и понял, что да, это то что нам нужно) — по 500 баксов на человека нам дороговато, но т.к. проект в целом на год+ — окей, оно того стоит. Но когда через год мы поймём, что этот проект таки выстрелил и будет поддерживаться ещё 1-2 года, то с новой моделью мы в итоге очень некисло так переплатим на ровном месте. В итоге, однозначно нет, ещё и с таким курсом бакса. Мы эти деньги пустим на другие штуки.
И никаких сожалений об объёме диска: современные ноутбуки с установленным 1Тб HDD — простой маркетинг. Мало кому столько место реально нужно на ноутбуке.
А вот на HDD пускай хранятся архивы и редко используемый медиа-контент.
И вот так у IT-шников всегда! :-D
Развелось их, блин! И каждым хочется поработать :-)
Архитекторы действительно бывают разные, с разными зонами ответственности.
Лично я могу утверждать про должность архитектора ПО — эти люди действительно обязаны уметь программировать, при этом делать это отлично.
Системные архитекторы — насколько я понимаю, отвечают за интеграцию компонент одной системы или разных систем. Но опять же, опыт в разработке ПО и понимание основных инструментариев\технологий здесь тоже крайне необходимы.
Вы, скорее всего, пишете про архитектору предприятия. Здесь действительно, на мой взгляд, необходимы навыки системного администрирования. Задачи и ответственность в принципе понятны из названия — грамотно построить IT-инфраструктуру предприятия, с оглядкой на бизнес.
Однако встречаются абзацы типа:
и
Это — ответственность архитектора ПО \ техлида. Он обязан иметь глубокие познания в разработке и архитектуре ПО, иначе банально не справится с задачами (т.к. ему необходимо принимать решения за\для программистов). Карьерный путь с простого разработчика до этой должности занимает 5+ лет.