Про “новые технологии”
Неприемлимым считаю использование “новых технологий” в проектах.
- во-первых, результирующий продукт должен быть всегда очень стабилен, потому что заказчик и так всегда стремиться его вывести из равновесия;
- во-вторых, результирующий продукт должен работать “везде”, а не только “у данного провайдера, когда не идёт дождь”;
- в-третьих, проект должен быть сдан в срок и затраты на R&D не должны упасть в календарный план типового проекта, если это не исследовательский проект, конечно;
December 24, 2005
12 responses to Про “новые технологии”
В таком случае есть существенный риск оказаться за бортом. Новые технологии нужно если и не внедрять сразу же, то по-крайней мере экспериментировать с ними и иметь в виду. Вот Ruby on Rails уже ЯВНО ПОРА смотреть.
> В таком случае есть существенный риск оказаться за бортом. Новые технологии нужно если и не внедрять сразу же, то по-крайней мере экспериментировать с ними и иметь в виду.
Прошу обратить внимание о том, что речь идёт про “использование “новых технологий” в проектах”. Т.е. R&D не отрицается. Наоборот, в http://blog.cetera.ru/archives/2005/10 пишу о необходимости реинвестирования в R&D.
> Вот Ruby on Rails уже ЯВНО ПОРА смотреть.
Не факт, не факт. Что-то мне подсказывает, что младенец-то мертворожденный.
> Не факт, не факт. Что-то мне подсказывает, что младенец-то мертворожденный.
Требую пояснений
Вопрос распространённости. N разработчиков и N хостеров не позволяют вести коммерческую эксплуатацию.
Влад, но такая логика неминуемо приводит к тому, что единственные жизнеспособные технологии это PHP и Perl. Нет, даже Perl не подходит – живых разработчиков уже не осталось наверное.
Нет, честнее будет сказать – “а нам и так тепло, светло, и мухи не кусают”.
Я объясню чем меня RoR восхищает. Там ведь не только в том дело, что Ruby – красивый и мощный язык, а Rails позволяет делать красивые-Ajax-спецэффекты-одной-строчкой-кода”. Там ещё и сделано все для того, чтобы разработка ПО была разработкой ПО, а не лабанием кода на коленке.
Красивая архитектура приложения – нате. Инфраструктура для тестирования – нате. Миграция БД – нате. Развертывание приложения – нате.
И всё вместе это настолько впечатляет, что потом “универсальные CMS на PHP” выглядят смешно и нелепо.
> Нет, честнее будет сказать – “а нам и так тепло, светло, и мухи не кусают”.
Отчасти, ты прав.
Но, скажи честно, где это потом клиенты будут размещать и кто это потом будет поддерживать? И мы сразу приходим к тому, что:
* размещать это можно будет только на нашем не самом дешевом colo;
* поддерживать это можно будет фактически только у нас.
И кто из клиентов согласится попадать в такую зависимость? Да я сам буду их от этого отговаривать изо всех сил!
Про размещение я согласен, и только.
Про поддержку – что же плохого в том, что клиент подпишется на поддержку. По факту клиенты на две категории делятся – либо поддерживают у нас (под поддержкой я имею в виду не столько внесение контента, сколько модификацию функциональности), либо не поддерживают вообще. Просто живет себе сайт два года, а потом меняется на новый от того же или другого разработчика.
А клиенты, которые сами серьезно функциональность дорабатывают – это маловероятный, если вообще существующий, сценарий.
> Про поддержку – что же плохого в том, что клиент подпишется на поддержку.
Плохого ничего нет. Но ни один клиент не должен покупать что-то, что он не сможет поддерживать где-то ещё. А RoR пока поддерживать особо негде.
> По факту клиенты на две категории делятся – либо поддерживают у нас (под поддержкой я имею в виду не столько внесение контента, сколько модификацию функциональности), либо не поддерживают вообще. Просто живет себе сайт два года, а потом меняется на новый от того же или другого разработчика.
С постулатом согласен.
> А клиенты, которые сами серьезно функциональность дорабатывают – это маловероятный, если вообще существующий, сценарий.
Весьма существующий. Aton-Line (в эпоху “до Cetera”), например. Просто клиентов с серьёзной функциональностью не так и много.
Спасибо за дискуссию и взгляд со стороны. Очень полезно и освежающе.
Кстати, насчет Rails. Еще существует MonoRail (http://www.castleproject.org/index.php/MonoRail). Теоретически работает под любым Юниксом с Mono.
Все остальное требует работы со стороны хостера. Хостеров, которые эту работу делают/готовы сделать, существует в количестве.
Как мне кажется, проблемы с хостингом, по большому счету, надуманны. Железобетонно хорошо везде хостится только чистый HTML.
> Все остальное требует работы со стороны хостера.
Вообще не согласен.
> Хостеров, которые эту работу делают/готовы сделать, существует в количестве.
Однако, в общем случае они этим не занимаются.