• Отчёт о Web Standards Days в Минске
    0
    А он действительно не является)
  • Если клиенты задерживают оплату
    0
    Позвольте, но бывает еще и третий вариант (помимо мудаковатости и нужности). Называется он умным словом «форс-мажор». Только вот этот самый форс-мажор бывает разный. В частности, случаются такие ситуации, когда форс-мажорные обстоятельства не могут быть подтверждены никакими государственными органами…

    Пример из жизни:

    Совсем недавно один их моих заказчиков задержал оплату очередного этапа разработки интернет-магазина на целых 3 недели. Причиной тому послужило внеплановое вторжение на территорию компании большой группы лиц в масках и с автоматами. Якобы по причине торговли контрафактными игровыми приставками и дисками…

    Тем не менее, через 3 недели заказчик реабилитировался и возобновил оплату по договору. Думаю, что в подобных ситуациях совсем ни к чему названивать заказчикам с требованиями выполнения договорных сроков оплаты, считать их мудаками или сомневаться в собственной «нужности»…
  • Если клиенты задерживают оплату
    +1
    Супер) В таком случае заказчик должен идти лесом...)
  • Если клиенты задерживают оплату
    0
    Но ведь и исполнитель в этом случае ничего не получит за проделанный объем работ. А самое распространенное основание отказа от оплаты, как правило, одно – «денег, простите, нет»…
  • Если клиенты задерживают оплату
    +1
    Здесь немного непонятно, с какой целью заказчик попросил удалить первый пункт. Вроде бы это совсем не в его интересах.

    Что же касается добавления второго пункта – я не вижу в этом ничего предосудительного. Гарантийные обязательства обязательно должны предоставляться. Другое дело, что формулироваться все это должно несколько по-иному:
    «РАЗРАБОТЧИК» обязуется безвозмездно устранять любые обнаруженные «ЗАКАЗЧИКОМ» в процессе эксплуатации веб-сайта недостатки и дефекты, если характер работ по их устранению не выходит за рамки утвержденного технического задания на разработку веб-сайта (Приложение №1). Данные гарантийные обязательства аннулируются в случае вмешательства «ЗАКАЗЧИКА» в программный код веб-сайта.

    Если же проектная документация изначально не составлялась и не утверждалась – это уже проблема компании-исполнителя, но никак не заказчика…
  • Если клиенты задерживают оплату
    +1
    Как вы решаете эти проблемы?

    Боюсь, что если заказчик никак не хочет платить вовремя, вряд ли можно эффективно решить эту проблему. Тема пеней уже неоднократно обсуждалась: далеко не каждого заказчика они устраивают при подписании договора. Что же касается приведенных «методов борьбы» – они, конечно, весьма оригинальны, определенно могут «браться на вооружение», но все же это не панацея. Кроме того, для солидной компании-исполнителя не всегда приемлемо «действовать заказчику на нервы» (даже если он принципиально нарушает оговоренные сроки оплаты).

    На мой взгляд, необходимый минимум – это составление грамотного договора, согласно которому работа выполняется поэтапно (разработка концепции дизайна, верстка статических прототипов веб-страниц, разработка программных компонентов и модулей, информационное наполнение), причем каждый такой этап оплачивается предварительно и только после принятия заказчиком предыдущего этапа. Что касается проведения проектных работ – они вообще должны оплачиваться отдельно от стоимости разработки веб-сайта (и тоже только предварительно), поскольку результат проектирования (техническое задание) является приложением к основному договору.

    Кроме того, некоторое время назад я взял на вооружение следующую «изюминку»:

    В случае приостановления выполняемых по настоящему договору работ по инициативе «ЗАКАЗЧИКА» денежные средства, полученные «РАЗРАБОТЧИКОМ» за выполненные этапы работ, «ЗАКАЗЧИКУ» не возвращаются. При этом исключительные права на разработанную концепцию дизайна веб-сайта, сверстанные статические прототипы веб-страниц, а также программные компоненты и модули остаются у «РАЗРАБОТЧИКА».

    Не Бог весть какое удовольствие для компании-исполнителя, но все же...)
  • Почему я не люблю российские коммерческие CMS
    +1
    Итак стал я все ковырять изучать и смотреть насколько предлагаемые рынком системы удовлетворяют моим потребностям.

    Вашим потребностям? Не слабо.) Мне почему-то всегда казалось, что предлагаемые рынком системы должны в первую очередь удовлетворять потребностям программистов и контент-менеджеров (конечных пользователей), но никак не потребностям руководителей проектов, основной задачей которых является подбор исполнителей, контроль качества и информационная поддержка заказчика в процессе реализации проекта.

    А задача то стояла простая, найти готовую систему которая бы не отнимала времени у сотрудников на создание однотипного функционала.

    Смею Вас заверить, что ни одна (даже самая паршивая и кривая система) не может отнимать у сотрудников много времени на создание однотипного функционала. Условия здесь только два:

    1. Этот «однотипный функционал» уже должен быть создан сотрудниками (хотя бы один раз).
    2. Сотрудники являются программистами и не заканчивают при этом 5 класс общеобразовательной школы.

    Например новости: заголовок, краткое содержание, подробное содержание и еще миллиард параметров. Ну нахера?

    И ведь действительно, нахера? Какой заголовок? Какое нахер краткое содержание? Возьмите, например, NetCat и создайте свой собственный программный компонент с необходимым именно Вам индивидуальным набором полей. Там это делается буквально в несколько щелчков мыши. Разве это не гибкость и кастомизация, которой Вам так не хватает? Не нужен миллиард параметров? В чем проблема?)

    Во всех этих системах видно главенство программистов.

    И так и должно быть, поскольку подавляющее большинство современных систем построения и поддержки веб-сайтов являются ни чем иным как своеобразными платформами-фреймворками, которые создаются программистами для программистов. Что же касается конечных пользователей и руководителей проектов – их должен волновать только лишь удобный пользовательский интерфейс, позволяющий легко и непринужденно наполнять веб-сайт необходимой информацией. Но никак не кастомизация программных модулей или написание нового функционала...)

    А бредовость отдельных модулей вообще поражает, например: каталог ссылок. Что это и нахера?

    Это – каталог ссылок. Весьма полезная вещь в определенных ситуациях. Если же Вам не нравится какой-то стандартный модуль – удалите его и поставьте задачу программистам, чтобы они написали другой, свой, который не будет Вам казаться бредовым. Один раз и навсегда.

    А эти ужасные WYSIWYG

    Эта проблема, по правде говоря, к CMS имеет отношение весьма и весьма косвенное. Другими словами, наплодить говнокод/говноконтент можно и не прибегая к помощи CMS и WYSIWYG-редакторов. Тут все дело в сложившихся стереотипах и традициях, которые имеют много исторических причин возникновения. Бороться с этим злом определенно стоит, но только не посредством громких заявлений о том, что все российские коммерческие CMS – «говно редкостное»…
  • Заглянем в CMS NetCat?
    +3
    Идеальных систем не бывает. Основная на то причина – коллективный труд. Когда систему разрабатывает не один человек, а команда разработчиков (а в некоторых случаях по-другому и быть не может), каждый участник старается привнести в код что-то свое – неповторимое и мегаоригинальное с его точки зрения.

    Тем не менее, по моему скромному мнению, NetCat CMS – очень даже неплохая платформа. По крайней мере она имеет весьма развитый и удобный API, предоставляет полный контроль над HTML-шаблонами, не «поганит» HTML-разметку и позволяет разрабатывать безупречные синтаксически и семантически корректные интернет-ресурсы, соответствующие всем современным веб-стандартам.

    На мой взгляд, единственная серьезная проблема программного комплекса NetCat – отсутствие поддержки UTF-8.
  • Ответ на «15 преимуществ» XHTML и 2 вопроса к читателям
    0
    Простите, это на основании чего Вы такое предположение сделали?
    Впрочем, Ваше утверждение уже опровергли соответствующим образом...
  • Ответ на «15 преимуществ» XHTML и 2 вопроса к читателям
    +1
    На мой взгляд весь сыр-бор по большей части происходит из-за того, что все свалено в одну кучу...

    Блочная верстка – это совсем не обязательно XHTML.
    Сравнивать, наверное, нужно было по отдельности следующее:

    1. Табличная верстка vs Блочная верстка (не важно – HTML или XHTML).
    2. HTML vs XHTML (не важно – табличная верстка или блочная верстка).

    У XHTML определенно есть некоторые преимущества. Но рассматривать эти преимущества необходимо вне контекста CSS-верстки. Потому как блоками можно совершенно спокойно верстать и с "чистым" HTML...