Здравствуйте, Dmitry The Wing, Вы писали:

DTW>Ситуация:

DTW>Необходимо определиться с выбором средств разработки:
DTW>- 1С
DTW>или
DTW>- локальный сервер Apache + php + FireBird + ajax

Собственное решение Apache + PHP может вылиться в конечном счете дороже для заказчика.
1С довольно распространенная штука, имеющая стандартную архитектуру (справочники, документы, регистры, пользовательский интерфейс и др.). Проектирование собственного движка займет больше времени и поддержка, возможно, будет требовать больше "человеко-часов".

1С конечно прожорливее в плане ресурсов.
Проще взять готовый движок на 1С и не мучаться.

Здравствуйте, Аноним, Вы писали:


DTW>>Значит будем считать, что в этом различий нет...

А>Уже писал Вам письмо на e-mail в профиле, с предложением по системе, наверное, не заинтересовало.

А>Не пишите на 1С, лучше напишите с нуля на современных технологиях (web-сервер, FB), если позволяет опыт

Вчера не заглядывал в почту, потому и не видел.
Посмотрел — понравилось. Идея почти совпадает с моей, за исключением того, что я планировал все сделать в окнах без закладок + у меня нет дизайна внешнего вида, а в остальном практически то же самое.

Именно это и планируется реализовать в виде локального web-сервера.

P.S.: Возможно, других заинтересует Ваше предложение, может стоит выложить здесь ссылку?

Здравствуйте, _Oleg_, Вы писали:

_O_>Здравствуйте, Dmitry The Wing, Вы писали:

DTW>>Ситуация:

DTW>>Необходимо определиться с выбором средств разработки:
DTW>>- 1С
DTW>>или
DTW>>- локальный сервер Apache + php + FireBird + ajax

_O_>Собственное решение Apache + PHP может вылиться в конечном счете дороже для заказчика.
_O_>1С довольно распространенная штука, имеющая стандартную архитектуру (справочники, документы, регистры, пользовательский интерфейс и др.). Проектирование собственного движка займет больше времени и поддержка, возможно, будет требовать больше "человеко-часов".

_O_>1С конечно прожорливее в плане ресурсов.
_O_>Проще взять готовый движок на 1С и не мучаться.

Не согласен с тем, что разработка и поддержка займет больше "человеко-часов".

Поясню:
На первых этапах, когда происходит разработка базовых элементов интерфейса и в целом движка, которые в 1С уже есть (или почти такие как надо) бесспорно времени будет потрачено больше.
Однако на последующих этапах, когда на 1С придется разрабатывать новое + модифицировать старое, то выигрывать будет уже вариант с php.

Время, затраченное на каждый этап при использовании 1С будет по началу постоянны, а затем начнет расти.
При использовании же php, время, затраченное на каждый этап, будет постоянно уменьшаться. (стоит пояснять?)

Это мое мнение, основанное на предыдущем опыте.

Здравствуйте, Figaro, Вы писали:

F>Здравствуйте, Dmitry The Wing, Вы писали:


F>Извините... Но заказчика интересует, что? скорость разработки, поддержка (если вы отвалитесь)? Постановка неконкретизирована...

Повторюсь: исполнители в штате заказчика, т.е. оба будут в курсе всех этапов разработки (насколько это возможно) + любой этап можно проанализировать впоследствии заглянув в лог SVN, а грамотно составлять комментарии в интересах обоих разработчиков.

К слову: 1С не позволяет провести подобный анализ без покупки специальных дополнительных средств.

DTW>>Ситуация:

DTW>>Есть заказчик, которому не важно в чем будет реализовыван проект, — важна только скорость разработки и модификаций.
DTW>>Есть два штатных исполнителя.

DTW>>Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.

DTW>>Т.е. режим работы даже более экзотичен, чем Extreme Programming.

DTW>>А теперь сам вопрос:

DTW>>Необходимо определиться с выбором средств разработки:
DTW>>- 1С
DTW>>или
DTW>>- локальный сервер Apache + php + FireBird + ajax

DTW>>Нужно мнение незаинтересованных лиц.

К сожалению отсутствие ТЗ — и SVN не поможет, в данном случае все-таки 1С... и лучше восьмерка

Здравствуйте, Dmitry The Wing, Вы писали:

DTW>Повторюсь: исполнители в штате заказчика, т.е. оба будут в курсе всех этапов разработки (насколько это возможно) + любой этап можно проанализировать впоследствии заглянув в лог SVN, а грамотно составлять комментарии в интересах обоих разработчиков.
DTW>К слову: 1С не позволяет провести подобный анализ без покупки специальных дополнительных средств.

Опять страшилки

Для 77 — gcomp и svn. Для 8.* — её родное хранилищие.

Здравствуйте, DenisCh, Вы писали:

DC>Здравствуйте, Dmitry The Wing, Вы писали:

DTW>>Повторюсь: исполнители в штате заказчика, т.е. оба будут в курсе всех этапов разработки (насколько это возможно) + любой этап можно проанализировать впоследствии заглянув в лог SVN, а грамотно составлять комментарии в интересах обоих разработчиков.
DTW>>К слову: 1С не позволяет провести подобный анализ без покупки специальных дополнительных средств.

DC>Опять страшилки

DC>Для 77 — gcomp и svn. Для 8.* — её родное хранилищие.

прочитал про gcomp и понял, что оно предназначено для конфигурации, а ert оно умеет?

Здравствуйте, <Аноним>, Вы писали:

DC>>Для 77 — gcomp и svn. Для 8.* — её родное хранилищие.
А>прочитал про gcomp и понял, что оно предназначено для конфигурации, а ert оно умеет?

Умеет. Для этого отдельный ключ у неё есть.

Здравствуйте, Figaro, Вы писали:

F>К сожалению отсутствие ТЗ — и SVN не поможет, в данном случае все-таки 1С... и лучше восьмерка

Типа 1С сама ТЗ додумает?
Отсутствие ТЗ только приводит к необходимости частой переработки уже реализованного, что, как мне кажется, в 1С намного сложнее, т.к. оно постоянно перепроверяет и перелопачивает все свои таблички.

В нормальной БД добавить новое поле, ключ, триггер, индекс, и удалить ненужные — намного проще и не требует остановки системы.
главное сперва добавить новое, поменять код, а затем уже удалять старые.

Здравствуйте, DenisCh, Вы писали:

DC>Здравствуйте, <Аноним>, Вы писали:

DC>>>Для 77 — gcomp и svn. Для 8.* — её родное хранилищие.
А>>прочитал про gcomp и понял, что оно предназначено для конфигурации, а ert оно умеет?

DC>Умеет. Для этого отдельный ключ у неё есть.

Это хорошо. Поможет отслеживать изменения в существующих конфигурациях.
Большое спасибо за наводку.

DTW>Вчера не заглядывал в почту, потому и не видел.
DTW>Посмотрел — понравилось. Идея почти совпадает с моей, за исключением того, что я планировал все сделать в окнах без закладок + у меня нет дизайна внешнего вида, а в остальном практически то же самое.

DTW>Именно это и планируется реализовать в виде локального web-сервера.

DTW>P.S.: Возможно, других заинтересует Ваше предложение, может стоит выложить здесь ссылку?

Нет, спасибо, пока не стоит.

Сами видите, что проект еще в начальной стадии, в нем не хватает:

1. безопасности (права доступа к объектам)
2. жизненных циклов документов (стутусы)
3. встраиваемых событий
4. дополнительных сервисных функций (автопроцедуры, механизм оповещения о событий)

кроме того, возможно будет совершенстоваться администраторская часть и все конфигурирование будет осуществляться преимущественно из системы, сейчас XML-файлы.

И главное, ведется работа по "быстрому старту" демо-стенда, чтобы для знакомства с системой было бы достаточно деплоить один war в web-сервер (в том числе со встраиваемой СУБД FireBierd, которую не требуется устанавливать) и быстро начать что-то настраивать свое.

К сожалению в обычных БД не все так просто — удалить поле в существующей таблице... это уже к конкретной реализации БД... Я не являюсь защитником 1С, но пришлось иногда лет 10 подрабатывать на этом поприще, и некоторые реализации подобные видел.. И буст там был задействован и и же с ними...
Короче, пытаюсь сказать — все до нас написано

DTW>>P.S.: Возможно, других заинтересует Ваше предложение, может стоит выложить здесь ссылку?

А>Нет, спасибо, пока не стоит.

А>Сами видите, что проект еще в начальной стадии, в нем не хватает:

А>1. безопасности (права доступа к объектам)
А>2. жизненных циклов документов (стутусы)
А>3. встраиваемых событий
А>4. дополнительных сервисных функций (автопроцедуры, механизм оповещения о событий)

А>кроме того, возможно будет совершенстоваться администраторская часть и все конфигурирование будет осуществляться преимущественно из системы, сейчас XML-файлы.

А>И главное, ведется работа по "быстрому старту" демо-стенда, чтобы для знакомства с системой было бы достаточно деплоить один war в web-сервер (в том числе со встраиваемой СУБД FireBierd, которую не требуется устанавливать) и быстро начать что-то настраивать свое.

Единственное, что мне там не понравилось — скорость обработки ajax-запросов (при открытии и закрытии окон). У меня это делается намного быстрее ... Стоит обратить внимание на этот момент и поискать узкое место, ибо оно там явно есть...

Здравствуйте, Figaro, Вы писали:

F>К сожалению в обычных БД не все так просто — удалить поле в существующей таблице... это уже к конкретной реализации БД... Я не являюсь защитником 1С, но пришлось иногда лет 10 подрабатывать на этом поприще, и некоторые реализации подобные видел.. И буст там был задействован и и же с ними...
F>Короче, пытаюсь сказать — все до нас написано

Это я просто к примеру, что если очень надо — можно и физичестки структуру БД изменить, хотя это в корне неправильно.
1С делает то же самое при изменении структуры документов и справочников, но любое изменение чего-то кроме внешних отчетов — это обязательная остановка системы.

Вдогонку:
Создание одинаковых окон-закладок оправдано далеко не всегда, я бы даже сказал, что в большинстве случаев это нельзя допускать, а там можно открыть сколь угодно одинаковых ...

DTW>Единственное, что мне там не понравилось — скорость обработки ajax-запросов (при открытии и закрытии окон). У меня это делается намного быстрее ... Стоит обратить внимание на этот момент и поискать узкое место, ибо оно там явно есть...

Да, спасибо, за независимый совет, мы записали это в багтрекер, попробуем оптимизировать, кстати, в FF все открывается намного быстрее.

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

Здравствуйте, Dmitry The Wing, Вы писали:

DTW>Вдогонку:
DTW>Создание одинаковых окон-закладок оправдано далеко не всегда, я бы даже сказал, что в большинстве случаев это нельзя допускать, а там можно открыть сколь угодно одинаковых ...

Да, действительно, тогда напрашивается проверка на открытость и не создавать второй раз.
Зафиксирвоали тоже в багтрекер, думаю, что это не сложно сделать.

skipped...

А при том же сочетании php+<сочетании неважно чего> тож придется тормозить работу... ладно, эт все лирика

Здравствуйте, Figaro, Вы писали:

F>skipped...

F>А при том же сочетании php+<сочетании неважно чего> тож придется тормозить работу... ладно, эт все лирика

Зачем тормозить то?

Разработка и отладка в обоих случаях производится не на боевой системе, но!
в случае с пхп+фб обновление боевой — простое копирование файлов пхп-сценариев и запуск sql-скрипта, вносящего изменения в БД, что занимает пару минут максимум,
а на 1С это:

• сравнение,
  
• принятие,
  
• объединение
  (частенько все 3 процесса занимают немалое время)
  
• и + если изменения затронули структуру данных — ПЕРЕИНДЕКСАЦИЯ (страшное слово)

у нас одна только переиндексация занимает 30 минут (остальное не предсказуемо по времени).

Здравствуйте, Dmitry The Wing, Вы писали:

DTW>Это хорошо. Поможет отслеживать изменения в существующих конфигурациях.
DTW>Большое спасибо за наводку.

Это не мне спасибо, а Фёдору