Если обо всем — однозначно дешево. Не скажу, что демпинг, но можно безболезненно для себя поднимать цены раза в 3 как минимум. При необходимости, поднаймете приличного внешнего дизайнера. Зато удовольствие от работы, за которую получал условный рубль, а продал за условные три возрастает даже не в геометрической прогрессии.
А когда работаешь с удовольствием, и результат получается лучше. И в следующий раз можно за него уже четыре условных рубля брать…
Может быть и укладывается. Просто если мы говорим о работе хорошего дизайнера (я в данном случае хорошим дизайнером называю не хорошего с точки зрения работы — т.е. четко и в срок делающего то, что ему сказано — а хорошего с точки зрения готового результата — креативщика типа), его гайдлайны будут напрягать. На такой проект, IMHO, правильно давать минимум 2 дизайн-концепции от приличных людей с зарплатой от 2500/мес, напряг от дополнительного внешнего контроля (этих самых гайдлайнов в данном случае) заставит этих приличных людей пахать над концептами дольше, чем если бы этого контроля не было — скорее всего получится в идеале недели 2 — 3 — почти цельный месяц. Получается затрат только на концепции уже больше 4000. Минимум 1000 на доработку. ну и 100% наткрутки на их зарплату.
Так что, мне видится 10000 — это минимум.
Впрочем, всегда случаются варианты лучше идеального. Да и гайдлайны тоже бывают разные — у тасиса, например, они весьма либеральные, а у колгейта позволяют (или позволяли года три назад) делать официальный сайт только в Шотландии и только в виде точной копии американского. БМВшных гайдов не видел, посему точно сказать не могу. Так что, возможно все.
Просто если идеальный вариант не случится (а дизайн — штука весьма непредсказуемая), норма прибыли упадет. Рухнет даже. А это уже плохо для бизнеса.
Задача, конечно, не самая простая, но мы все-тки про web-сайт говорим — посему она может и не простая, но все равно вполне из себя примитивная.
Посему стоимость зависит от CMS. Ну и от рук, которые програмят — в топике речь ведь идет о программинге и только о нем (или я че-то не так прочел? вроде бы еще раз перечитал — только программирование.) Тогда адекватная цена (IMHO — сугубо для нашей CMS — для Битрикса было бы дороже, равно как и для джумлы, типо и проч..) — тысяч 60 — 80. Причем это даже не стоимость программинга как такового, а скорее цена, за которую мы готовы систему поставить. Т.е. данная цифра не завязана ни на себестоимость, ни на трудоемкость — только на объем готового функционала.
А вот все прочее — оно легко потянет очень даже серьезные деньги:
Дизайн — от 10 (т.е. можно попробовать и в 5 уложиться, но будет фигово и себе в убыток, с учетом гайдлайнов).
Сборка — от 1000 баксов и выше.
Наполнение — если «индийское» — то бакса по 2 за страницу, а так с каталогом будет скорее бакса четыре. тыща страниц как раз на объявленный стольник.
Ну и менеджмент + тестирование — 20% от итоговой суммы.
Итого, весь проект получается тысяч на 600 рублей, из них непосредственно программирование — около 10%. Как-то вот так.
ну, мы тоже используем свои алгоритмы. Правда, разрабатываем их чуть подольше. В целом сейчас оно уже работает вполне удволетворительно (кусок дерева — чтобы использовались индексы — вложенностью 10, объемом где-то в 30000 узлов отрабатывается примерно за 1 — 2 секунды, а с закешированным запросом — раз в 100 быстрее). Правда, наше решение катит только под PostgreSQL (возможно будет работать и под ораклом, если оно шагнуло вперед после 2001 года).
А под мускуль существует альтернатива на dklab — изящный и очень быстрый запрос, правда, с ограничением по вложенности — не более 32 уровней (или 31).
вставляет, конечно, подольше.
где-то начиная с тысячного узла в середку дерева аккурат по минуте на узел (дерево многоуровневое и ветвистое).
это уже (sorry for my english), не вставляет ни фига.
а вообще самая большая проблема с деревьями — не выбора ветки от единого родителя (эта вещь оптимально делается не рекурсией, а скорее циклом — поличество запросов равно уровню вложенности, посему в самом худшем случае (дерево у нас — лиана или виноград какой-то, и каждая ветка имеет ровно одного потомка) эта штука будет работать с той же скоростью, что рекурсия, в лучшем же — намного быстрее) а правильной сортировки выбранного. И тут возможны варианты (помимо nested sets — потому как с обновлениями и вставками на нем все просто совсем ахово получается).
Он был то ли председателем совета национальностей ВС СССР, то ли заместителем Председателя ВС СССР. При этом, кажется, возглавлял какую-то из среднеазиатских республик. Часто вел заседания ВС, транслировавшиеся по ТВ. Более всего запомнился народу именно фразой про кончил — не кончил. Часто употреблял последнюю во время прений по законам и постановлениям.
Если сайт выполняет свою функцию — в данном случае обеспечивает продажи студии №1 в мире (не скажу наверняка насчет оборота, но это вроде бы вполне устоявшееся мнение), видимо сайт получился хорошим. При этом он еще и красивый. Все, что нужно найти (как то — портфолио и контакты там вроде бы всегда находилось.
А где у них совпадает тон текста и фона, так, чтобы это было не читаемым?
Ясно — мне показалось, что мы друг друга не поняли. где-то (вроде даже на хабре по ссылке) мелькал топ буржуйских студий. думаю, смотреть надо там. У нас нечто подобное firon делал в свое время, но сейчас он сайт в очередной раз поменял и теперь там вместо флеша статика.
Глаз уже немного замылен, но если вы представили Заказчику нечто в формате jpg или любом другом графическом формате, причем на этом макете было изображено… (далее по списку из ТЗ) — свой дизайн-макет он получил. Казуистичный договор)))))
Дьявол в мелочах — очень многое зависит от того, что и, самое главное, как прописано в договоре. Если картина на самом деле такова, как вы ее описали (повторюсь — делать вывод не видя договора я не могу), предоплату, во всяком случае, можно не возвращать. Имеет смысл написать официальное письмо, где, сославшись на соответствующие пункты договора предложить на выбор:
продолжить работы по договору или
закрыть договор с подписанием соответствующих актов и передачей соответствующих материалов
По актам часть предоплаты может быть возвращена, либо может возникнуть необходимость в доплате со стороны Заказчика, либо стороны могут принять к договору Дополнительное соглашение, в котором зафиксируют финансовую и фактическую стороны дела (например заказчик получает порезанных PSD и не получает предоплату, вы — бесценный опыт 2-месячных доделок и предоплату оставляете себе — так не то, чтобы совсем честно, но в данных обстоятельствах, вероятно, наиболее реально), и по результатам Дополнительного Соглашения уже подписывать акт.
IMHO, разбирать просто написанный код, лежащий в 10 разных поддиректориях и в 50 разных файлах (типично «водительский» код — за примером, причем не из самых страшных далеко ходить не надо — PEAR. Чтобы не посыпались обвинения, поясняю — у AltLinux с выходом новых версий может иногда сложиться отличная сиутация, когда версия PHP не совпадает с версиями PHP-шных примочек, и в этом случае — например какая-нибудь функция работает не совсем так, как того ожидалось — приходится оперативно использовать руки и мозги) не в пример сложнее, чем такой сокращенный, если конечно этот сокращенный код будет снабжен комментариями. Без комментариев, возможно, будет несколько напряжнее — с непривычки.
Вообще говоря, если не рассматривать проекты вроде яндекса или гугла (то етсь проекты действительно большие и не то, чтобы относящиеся к категории сайтов, создаваемых на CMS), все прочие проекты, фактически, маленькие. И, посему, если есть в наличии CMS (а правильнее — framework для быстрого — в течение, скажем, пары рабочих дней, как максимум — создания кастомизированной CMS), способной потянуть достаточно сложный из этих «маленьких» проектов — тогда, вероятно, нет прямого смысла заморачиваться на 2 -3 cms, которые будут уметь меньше, чем основная.
Что же до целей — первая, очень правильно обозначена как маркетинговая — на моей памяти (притом, что удобство управления подавалось нами как одно из преимуществ), реально обновляли свой сайт чуть меньше 1 % клиентов. И не потому, что такое обновление казалось им задачей трудоемкой — просто как-то с самого начала работ по поддержке, все эти работы перекладывались либо на студию, либо, что реже — на знакомых фрилансеров.
Вообще, заявленная цель установки CMS (облегчить и частично автоматизировать поддержку сайта) чаще всего маскирует цель реальную — снизить издержки студии на создание и поддержку сайта.
скорее всего, зависит от модели, используемой в системе.
В нашем случае используется именно str_replace (полагаю, вы его имели в виду?). Работает быстро (собственно, если я правильно помню мануал, str_replace считается самой быстрой из функций подстановки). В общем случае не зависит от класса. Если есть у класса свойство — выведется, нету — выведется пустота. на выходе дает вполне валидный код (если, конечно, на входе во скином не намудрили — в данном случае, кстати — как раз-таки намудрили чутка — но я брал код из примера в топике).
Может быть как-нибудь так?
$skin='~~date <a href=~~link>~title</a>';
$delimiter='<br />'
$object=new News();
$news->show($skin,$news,$delimiter);/*$news — массив объектов, которые надо вывести — в данном случае — новости, в абстрактном случае — все, что угодно */
И вроде бы никаких велоcипедов, не изобретаем, и надстройку над PHP, которая будет делать то же, что делаем PHP, только хуже и медленнее (в смысле шаблонизатор, да простят меня их любители ) творить не пытаемся… И верстальщику все более менее понятно. И скорость более чем достойная (хотя это уже, конечно, от реализации зависит, но в данном случае напортачить весьма и весьма сложно).
А в скин пихаем все, что угодно — хоть хтмл, хоть иксмл, хоть плэйн. Внутри метода show подставляем значения из коллекта. Можно там же внутри и вывод делать (имено так написано в приведенном примере), однако, IMHO, правильнее будет возвратить строку, или массив, например, с задействованными в выводе айдишниками объектов — оченно полезно, например, когда на сайте несколько лент новостей, и одна и та же новость может быть в разных лентах новостей.
никогда не возникала мысль о простой, гибкой и простой в освоении системы? Я не говорю о пропиаренных системах — тлько о существующих? Или вы всерьез полагаете, что гибкая система должна быть сложна в освоении?..
На самом деле пробелма в том, что имеющиеся на рынке CMS (я говорю сейчас в первую очередь об отчуждаемых) во-первых — модульные (либо напрямую, либо идеологически), а во вторых — отнаследовавшие все ограничения древнего мускуля (поясню термин — в данном случае он означает, что следы этих естественных ограничений вроде максимального объема текстового пола в 8192 байта, или блокирования таблиц при совместном доступе до сих пор встречаются в идеологииCMS). Почему так получилось — отдельная тема, и, скорее всего, не тема данного разговора.
А чтобы все было более менее гибко_ CMS должна быть (IMHO!!! — это на тему должна и если мы говорим о гибкости) объектно-полиморфичная, и если уж привязанная к БД, то к какой-нить более мощной. Oracle, PostcgreSQL. Помимо прочегоЮ было бы очень даже правильно, чтобы параметры внутрь передавались целочисленные (коротенький кусочек PHP (int) лечит бошльшинство SQL инъекций).
А еще — и это уже сугубо IMHO — в идеале объем кода CMS не должен превышать 100 Кб кода. чем меньше — тем лучше. Достигается адекватным проектированием.
Мы с 1999 по 2004 работали с модульной системой собственного изготовления (поскольку оно изначально работало на postgresql, одной засады мы благополучно избежали), где-то во времена PHP5 RC1 собрали первый прототип фреймворка для клепания на лету кастоимзированных CMS. Не могу сказать, что все получилось идеально (например интерфейс, в свое время придуманный программистом, борется до сих пор и пока, к сожалению, побеждает), но вот при необходимости «с нуля» сотворить за неделю сайтик с уникальной функциональностью у нас вроде бы ка получается.
А когда работаешь с удовольствием, и результат получается лучше. И в следующий раз можно за него уже четыре условных рубля брать…
Так что, мне видится 10000 — это минимум.
Впрочем, всегда случаются варианты лучше идеального. Да и гайдлайны тоже бывают разные — у тасиса, например, они весьма либеральные, а у колгейта позволяют (или позволяли года три назад) делать официальный сайт только в Шотландии и только в виде точной копии американского. БМВшных гайдов не видел, посему точно сказать не могу. Так что, возможно все.
Просто если идеальный вариант не случится (а дизайн — штука весьма непредсказуемая), норма прибыли упадет. Рухнет даже. А это уже плохо для бизнеса.
Посему стоимость зависит от CMS. Ну и от рук, которые програмят — в топике речь ведь идет о программинге и только о нем (или я че-то не так прочел? вроде бы еще раз перечитал — только программирование.) Тогда адекватная цена (IMHO — сугубо для нашей CMS — для Битрикса было бы дороже, равно как и для джумлы, типо и проч..) — тысяч 60 — 80. Причем это даже не стоимость программинга как такового, а скорее цена, за которую мы готовы систему поставить. Т.е. данная цифра не завязана ни на себестоимость, ни на трудоемкость — только на объем готового функционала.
А вот все прочее — оно легко потянет очень даже серьезные деньги:
Дизайн — от 10 (т.е. можно попробовать и в 5 уложиться, но будет фигово и себе в убыток, с учетом гайдлайнов).
Сборка — от 1000 баксов и выше.
Наполнение — если «индийское» — то бакса по 2 за страницу, а так с каталогом будет скорее бакса четыре. тыща страниц как раз на объявленный стольник.
Ну и менеджмент + тестирование — 20% от итоговой суммы.
Итого, весь проект получается тысяч на 600 рублей, из них непосредственно программирование — около 10%. Как-то вот так.
А под мускуль существует альтернатива на dklab — изящный и очень быстрый запрос, правда, с ограничением по вложенности — не более 32 уровней (или 31).
где-то начиная с тысячного узла в середку дерева аккурат по минуте на узел (дерево многоуровневое и ветвистое).
это уже (sorry for my english), не вставляет ни фига.
а вообще самая большая проблема с деревьями — не выбора ветки от единого родителя (эта вещь оптимально делается не рекурсией, а скорее циклом — поличество запросов равно уровню вложенности, посему в самом худшем случае (дерево у нас — лиана или виноград какой-то, и каждая ветка имеет ровно одного потомка) эта штука будет работать с той же скоростью, что рекурсия, в лучшем же — намного быстрее) а правильной сортировки выбранного. И тут возможны варианты (помимо nested sets — потому как с обновлениями и вставками на нем все просто совсем ахово получается).
А где у них совпадает тон текста и фона, так, чтобы это было не читаемым?
продолжить работы по договору или
закрыть договор с подписанием соответствующих актов и передачей соответствующих материалов
По актам часть предоплаты может быть возвращена, либо может возникнуть необходимость в доплате со стороны Заказчика, либо стороны могут принять к договору Дополнительное соглашение, в котором зафиксируют финансовую и фактическую стороны дела (например заказчик получает порезанных PSD и не получает предоплату, вы — бесценный опыт 2-месячных доделок и предоплату оставляете себе — так не то, чтобы совсем честно, но в данных обстоятельствах, вероятно, наиболее реально), и по результатам Дополнительного Соглашения уже подписывать акт.
Что же до целей — первая, очень правильно обозначена как маркетинговая — на моей памяти (притом, что удобство управления подавалось нами как одно из преимуществ), реально обновляли свой сайт чуть меньше 1 % клиентов. И не потому, что такое обновление казалось им задачей трудоемкой — просто как-то с самого начала работ по поддержке, все эти работы перекладывались либо на студию, либо, что реже — на знакомых фрилансеров.
Вообще, заявленная цель установки CMS (облегчить и частично автоматизировать поддержку сайта) чаще всего маскирует цель реальную — снизить издержки студии на создание и поддержку сайта.
В нашем случае используется именно str_replace (полагаю, вы его имели в виду?). Работает быстро (собственно, если я правильно помню мануал, str_replace считается самой быстрой из функций подстановки). В общем случае не зависит от класса. Если есть у класса свойство — выведется, нету — выведется пустота. на выходе дает вполне валидный код (если, конечно, на входе во скином не намудрили — в данном случае, кстати — как раз-таки намудрили чутка — но я брал код из примера в топике).
$skin='~~date <a href=~~link>~title</a>';
$delimiter='<br />'
$object=new News();
$news->show($skin,$news,$delimiter);/*$news — массив объектов, которые надо вывести — в данном случае — новости, в абстрактном случае — все, что угодно */
И вроде бы никаких велоcипедов, не изобретаем, и надстройку над PHP, которая будет делать то же, что делаем PHP, только хуже и медленнее (в смысле шаблонизатор, да простят меня их любители ) творить не пытаемся… И верстальщику все более менее понятно. И скорость более чем достойная (хотя это уже, конечно, от реализации зависит, но в данном случае напортачить весьма и весьма сложно).
А в скин пихаем все, что угодно — хоть хтмл, хоть иксмл, хоть плэйн. Внутри метода show подставляем значения из коллекта. Можно там же внутри и вывод делать (имено так написано в приведенном примере), однако, IMHO, правильнее будет возвратить строку, или массив, например, с задействованными в выводе айдишниками объектов — оченно полезно, например, когда на сайте несколько лент новостей, и одна и та же новость может быть в разных лентах новостей.
На самом деле пробелма в том, что имеющиеся на рынке CMS (я говорю сейчас в первую очередь об отчуждаемых) во-первых — модульные (либо напрямую, либо идеологически), а во вторых — отнаследовавшие все ограничения древнего мускуля (поясню термин — в данном случае он означает, что следы этих естественных ограничений вроде максимального объема текстового пола в 8192 байта, или блокирования таблиц при совместном доступе до сих пор встречаются в идеологииCMS). Почему так получилось — отдельная тема, и, скорее всего, не тема данного разговора.
А чтобы все было более менее гибко_ CMS должна быть (IMHO!!! — это на тему должна и если мы говорим о гибкости) объектно-полиморфичная, и если уж привязанная к БД, то к какой-нить более мощной. Oracle, PostcgreSQL. Помимо прочегоЮ было бы очень даже правильно, чтобы параметры внутрь передавались целочисленные (коротенький кусочек PHP (int) лечит бошльшинство SQL инъекций).
А еще — и это уже сугубо IMHO — в идеале объем кода CMS не должен превышать 100 Кб кода. чем меньше — тем лучше. Достигается адекватным проектированием.
Мы с 1999 по 2004 работали с модульной системой собственного изготовления (поскольку оно изначально работало на postgresql, одной засады мы благополучно избежали), где-то во времена PHP5 RC1 собрали первый прототип фреймворка для клепания на лету кастоимзированных CMS. Не могу сказать, что все получилось идеально (например интерфейс, в свое время придуманный программистом, борется до сих пор и пока, к сожалению, побеждает), но вот при необходимости «с нуля» сотворить за неделю сайтик с уникальной функциональностью у нас вроде бы ка получается.
Господа — проектируйте, а не воюйте!