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

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

A>как насчет тысяч крупных сайтов, работающих на Apache + PHP?

Крупных сайтов — много это правда. Но покажите полноценную систему внутреннего документооборота предприятия. Прошу подумать: реально ли написать на PHP систему формирования учебных планов например? Задача нетривиальная — нужно оптимизировать понедельную расчасовку большого количества дисциплин (может даже методы ИИ применять).

Сразу согласен — что очень квалифицированный программер все может. Но нужны ли такие затраты нервной энергии — все ведь проще можно решить.

Вот еще о чем можно подумать — а стоит ли в подобных задачих использовать тонкий клиент и web-технологии вообще?


A>кто мешает использовать тот же PostgreSQL?

Да никто. Просто MySQL рассматривать не надо. PostgreSQL, Oracle, MS SQL, Interbase ... Ну вы поняли полноценные реляционные СУБД

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

N>НО! У нас в России так дела не делаются....
Ну не стоит так обобщать-то!

N>Хихикс, "быстро, дешево, качественно — выберите любые два". И если уж есть четкие ограничения на время, то выбор оставшегося пункта — на усмотрении руководства. Мы можем только посоветовать, да и то только если будут слушать.

Ребятки, вы ж не на базаре. Вы ж "Отдел Автоматизации", который является частью административной структуры вашего универа.

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

Выясните такие вопросы:
Кому в универе ваш отдел подчинен непосредственно? Кто стоит ниже по иерархической лестнице?
Какие задачи должен выполнять ваш отдел?

И бросьте вести разговоры. Начинайте писать документы. И требуйте, чтоб к вам также обращались в письменном виде.

А еще, не забудьте всю свою переписку регистрировать в канцелярии. Во!

ИП вот если на документе, в котором вы писали, что "для разработки такого-то ПО требуется столько-то материальных и столько-то временных ресурсов, а в противном случае за качество ПО вы ответственности не несете" стоит резолюция большого дяди: "Сделать даром и за два дня". То вы либо делаете очередную "программу", либо едете с копией этой бумажки и новым заявлением к еще "большему дяде".

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

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


B>А еще, не забудьте всю свою переписку регистрировать в канцелярии. Во!

B>ИП вот если на документе, в котором вы писали, что "для разработки такого-то ПО требуется столько-то материальных и столько-то временных ресурсов, а в противном случае за качество ПО вы ответственности не несете" стоит резолюция большого дяди: "Сделать даром и за два дня". То вы либо делаете очередную "программу", либо едете с копией этой бумажки и новым заявлением к еще "большему дяде".

Совершенно со всем согласен!!!!

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

B>Ребятки, вы ж не на базаре. Вы ж "Отдел Автоматизации", который является частью административной структуры вашего универа.

B>А вы все на уровне диалогов: "нам сказали, мы сказали, нас не послушали..."
B>Слова к делу не пришьешь. А спрос будет с вас. И какой-нибудь "гондурас в галстуке", которому вы сейчас сто раз что-то объясняете, вас потом подставит. Когда у вас чего-нибудь завалится, он будет бить себя в грудь со словами: "а почему Вы в самом начале не поставили меня в известность о возможных проблемах..."

B>Выясните такие вопросы:
B>Кому в универе ваш отдел подчинен непосредственно? Кто стоит ниже по иерархической лестнице?
B>Какие задачи должен выполнять ваш отдел?

B>И бросьте вести разговоры. Начинайте писать документы. И требуйте, чтоб к вам также обращались в письменном виде.

B>А еще, не забудьте всю свою переписку регистрировать в канцелярии. Во!

B>ИП вот если на документе, в котором вы писали, что "для разработки такого-то ПО требуется столько-то материальных и столько-то временных ресурсов, а в противном случае за качество ПО вы ответственности не несете" стоит резолюция большого дяди: "Сделать даром и за два дня". То вы либо делаете очередную "программу", либо едете с копией этой бумажки и новым заявлением к еще "большему дяде".


Спасибо за советы, хотя все это я уже знал "от старших" (мамы и пыпы всмысле). Но мой "детский" опыт, говорит что "подобные инсинуации" (в смысле служебные записки, регистрация, большие дяди) редко приводят к хорошим последствиям для простых программеров типа меня. Да, на уровне руководства — все это эффективно. Но на человечка 21 года (программиста 1 категории), который только-только закончил вуз и начинает вести политику "служебных записок", начальство смотрит несколько "осуждающе".
Лично мне ближе метод — поговорить с начальником лично, довести до него свою точку зрения, если нужно — убеждать, приводить примеры. Если руководство заинтересовано в результате оно выслушает и примет к сведению (нет — так какой смысл тратить ум, нервы и молодые годы на реализацию никому не нужной системы? ).
Кстати метод вроде бы себя пока оправдывает — сегодня в АСУ и у директора были собрания посвященные сабжевому вопросу.
Если интересно — политику решили вести на перспективу — Intenet/Intranet, .NET, реляционные и не очень (для документооборота) базы. Общие слова — но все-таки согласие и воля сверху.

Еще раз, спасибо вам и всем принимающим участие в дискуссии — вы нам очень помогаете.

M>Крупных сайтов — много это правда. Но покажите полноценную систему внутреннего документооборота предприятия. Прошу подумать: реально ли написать на PHP систему формирования учебных планов например? Задача нетривиальная — нужно оптимизировать понедельную расчасовку большого количества дисциплин (может даже методы ИИ применять).

как раз документооборот без проблем, причем имхо будет гораздо быстрей, т.к. ущербность пхпшного ооп практически не скажется, зато сильно скажется возможности "схалявить" но по сравнению с "крутыми" workflow — кривее не удастся.
да при условии что команда слышала магические слова view/front controler, а не мешает код,скл и дизайн.

M>Вот еще о чем можно подумать — а стоит ли в подобных задачих использовать тонкий клиент и web-технологии вообще?

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

A>>кто мешает использовать тот же PostgreSQL?

M>Да никто. Просто MySQL рассматривать не надо. PostgreSQL, Oracle, MS SQL, Interbase ... Ну вы поняли полноценные реляционные СУБД

mysql вполне реляционна, просто она для других задачек ...

p.s. oracle php будет супортить вместе с 10кой.

Gt_

Здравствуйте, Аноним, Вы писали:
А>как раз документооборот без проблем, причем имхо будет гораздо быстрей, т.к. ущербность пхпшного ооп практически не скажется, зато сильно скажется возможности "схалявить" но по сравнению с "крутыми" workflow — кривее не удастся.
А>да при условии что команда слышала магические слова view/front controler, а не мешает код,скл и дизайн.


Ну не знаю = лично мне в это не очень верится. Серьезная система документооборта — крупный проект
требующий:
а) Комплексного обследования предметной области (орг. структура — взаимодействие отделов и т.д.)
б) Создания полной проектной документации по созданной системе.

У нас в АСУ есть система написаная на VFP по автоматизации документооборота Деканата. Занимает чуть более 20000 строк. Я не верю, что на PHP можно реализовать систему документооборота вуза более компактно. Что такое 20000 строк на PHP, я видел. Я даже видел к чему это привело через два месяца при отсутствии документации. Дело слава богу не со мной было. Проект кстати вести такой как раз на объектной методологии было бы рульно. А в PHP она в зачаточном варианте, по крайней мере пока. Опять же CASEов нет — плохо. Все вручную документировать — не по-приколу.
Мое личное убеждение — надо выбирать средство по задаче. На PHP отлично пишутся всякие разные webы типа развитые форумы, магазины и т.д. и т.п. Оптимизационные задачи или просто крупные претенциозные проекты писать — одно мучение.

M>>Вот еще о чем можно подумать — а стоит ли в подобных задачих использовать тонкий клиент и web-технологии вообще?

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

Контора веников не вяжет. О безопасности вопрос вообще не стоял. В web ее можно вообще организовать серьезно при желании конечно. Вопрос в средствах. Смотреть учебный план должны многие — а делает его, тока зав. кафедрой. Нафига одному зав. каведрой web — интерфейс? С ним точна мучится дольше надо, чем с обычной двухзвенкой. А на счет дорого — ничуть не дороже. БД — есть. Delphi/FoxPro/VC — есть.

A>>>кто мешает использовать тот же PostgreSQL?

M>>Да никто. Просто MySQL рассматривать не надо. PostgreSQL, Oracle, MS SQL, Interbase ... Ну вы поняли полноценные реляционные СУБД

А>mysql вполне реляционна, просто она для других задачек ...

Для других... это точно. Быстрая но без наворотов, даже необходимых.

А>p.s. oracle php будет супортить вместе с 10кой.
Да он с любой БД пахать будет через ODBC.

А>Gt_

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

M> Общие слова — но все-таки согласие и воля сверху.

Воля сверху — согласованный и подписанный план + выделенные средства. А у Вас опять "общие слова".

Не обижайтесь, но опыт "пап и мам" — жизненный опыт. А Ваш "детский" опыт — детский опыт.

Я начал писать бумажки в 15 лет (не подумайте, что кляузы и жалобы; писал: планы, приказы, служебные записки, отчеты). И нормально. Да, начальство (директор, парторг школы) порой пытались смотреть "осуждающе", но мне было пофигу. Пару раз вызывали на "ковер" в райком. Зато нормально относились подчиненные (20 человек комитет комсомола+300 старшеклассников). Зато, после школы предлагали крутое повышение по комсомольской линии. Предлагали те, кто смотрел "осуждающе".
Отказался. Не знаю зря, или нет. Это были времена перестройки. Комсомольские вожди тех лет или олигархи, или...

С тех пор много воды утекло. Но до сих пор в тех ситуациях, где с самого начала было все четко прописано, согласовано, подписано и утверждено — положительных результатов работы было больше. Чего не могу сказать о тех ситуациях, когда даже очень хорошие люди договаривались на словах.

M>Еще раз, спасибо вам и всем принимающим участие в дискуссии — вы нам очень помогаете.

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

LVV>В заяве на ПО фигурирует Роза и BPWin.

Нафиг вам такая связка понадобилась???
В одном проекте смешивать структурный подход и ОО-подход вряд ли имеет смысл. Вообще, использование BPWin, без явного требования заказчика о применении IDEF*, на мой взгляд не оправдано.
Мое ИМХО, конечно.

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

LVV>>В заяве на ПО фигурирует Роза и BPWin.

M>Нафиг вам такая связка понадобилась???
Исключительно для учебных целей.
M>В одном проекте смешивать структурный подход и ОО-подход вряд ли имеет смысл. Вообще, использование BPWin, без явного требования заказчика о применении IDEF*, на мой взгляд не оправдано.
M>Мое ИМХО, конечно.
Два инструмента — лучше, чем один. Для разных проектов использовать можно разные: иногда то, что попроще, иногда, то, что посложнее.
Там еще и Visio заявлено.
В общем, довольно круто обогащаемся.

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

LVV>Два инструмента — лучше, чем один. Для разных проектов использовать можно разные: иногда то, что попроще, иногда, то, что посложнее.
LVV>Там еще и Visio заявлено.

Ну только если для того, чтобы было...
А вот Visio — штука хорошая! Одобряю.

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

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

M>> Общие слова — но все-таки согласие и воля сверху.

B>Воля сверху — согласованный и подписанный план + выделенные средства. А у Вас опять "общие слова".

B>Не обижайтесь, но опыт "пап и мам" — жизненный опыт. А Ваш "детский" опыт — детский опыт.


B>Я начал писать бумажки в 15 лет (не подумайте, что кляузы и жалобы; писал: планы, приказы, служебные записки, отчеты). И нормально. Да, начальство (директор, парторг школы) порой пытались смотреть "осуждающе", но мне было пофигу. Пару раз вызывали на "ковер" в райком. Зато нормально относились подчиненные (20 человек комитет комсомола+300 старшеклассников). Зато, после школы предлагали крутое повышение по комсомольской линии. Предлагали те, кто смотрел "осуждающе".
B>Отказался. Не знаю зря, или нет. Это были времена перестройки. Комсомольские вожди тех лет или олигархи, или...
B>
B>С тех пор много воды утекло. Но до сих пор в тех ситуациях, где с самого начала было все четко прописано, согласовано, подписано и утверждено — положительных результатов работы было больше. Чего не могу сказать о тех ситуациях, когда даже очень хорошие люди договаривались на словах.

C'est la vie.

А бумажки уже готовятся. Так что спасибо за совет. Как раз сегодня додавили большое начальство до полной некондиции Оно теперь готово даже читать бумажки И даже (!) писать их!!! Во!

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

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

M>> Общие слова — но все-таки согласие и воля сверху.

B>Воля сверху — согласованный и подписанный план + выделенные средства. А у Вас опять "общие слова".

Воля сверху подтверждается. Nosferatum написал уже.


B>Не обижайтесь, но опыт "пап и мам" — жизненный опыт. А Ваш "детский" опыт — детский опыт.

Да я согласен. По этому и написал. А родители то же говорят — "все хорошо вмеру","На конфликт идти не надо". И вообще я с ними всегда советуюсь.

B>Я начал писать бумажки в 15 лет (не подумайте, что кляузы и жалобы; писал: планы, приказы, служебные записки, отчеты). И нормально. Да, начальство (директор, парторг школы) порой пытались смотреть "осуждающе", но мне было пофигу. Пару раз вызывали на "ковер" в райком. Зато нормально относились подчиненные (20 человек комитет комсомола+300 старшеклассников). Зато, после школы предлагали крутое повышение по комсомольской линии. Предлагали те, кто смотрел "осуждающе".

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

B>С тех пор много воды утекло. Но до сих пор в тех ситуациях, где с самого начала было все четко прописано, согласовано, подписано и утверждено — положительных результатов работы было больше. Чего не могу сказать о тех ситуациях, когда даже очень хорошие люди договаривались на словах.

Да — это все правильно. Но метод такой наиболее эффективен когда стороны находятся в равных условиях. А я тут в аспирантуру поступаю (экзамены вроде наотлично сдал). Защититься — моя мечта. В общем зависимый я. Вот и думаю, что "записки" (как побуждающее средство воздействия) — это на крайний случай.

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

Однако, у нас проблемы сверху уже нет. Есть проблема поддержки "старых" пп. Сейчас нальство старых программистов (их 2) + нескольких студентов сажает на их поддержку. На разработку новых версий остается 3 человека (+0,5 администратора СУБД). Проекта 3 и они большие и порой нетривиальные с точки зрения программирования ("Учебная часть" — учебные планы + нагрузка на кафедры, "Деканат" — успеваемость + контингент студентов, "Абитуриент" — проведение зачисления), а времени до просмотра результатов — год (кое-где убедили срок увеличить). Есть еще "документооборот" как организация связи между упомянутыми подсистемами.
Нас волнует естественный вопрос — как достигнуть наиболшей отдачи от проекта .

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

А>Воля сверху подтверждается. Nosferatum написал уже.

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

N>

А>Нас волнует естественный вопрос — как достигнуть наиболшей отдачи от проекта .

Работать, работать и работать...

Ну и РСДН вам поможет добрым словом, советом и критикой. Я надеюсь...

Успехов!

У нас проблемы сверху уже нет. Есть проблема поддержки "старых" пп. Сейчас нальство старых программистов (их 2) + нескольких студентов сажает на их поддержку. На разработку новых версий остается 3 человека (+0,5 администратора СУБД). Проекта 3 и они большие и порой нетривиальные с точки зрения программирования ("Учебная часть" — учебные планы + нагрузка на кафедры, "Деканат" — успеваемость + контингент студентов, "Абитуриент" — проведение зачисления), а времени до просмотра результатов — год (кое-где убедили срок увеличить). Есть еще "документооборот" как организация связи между упомянутыми подсистемами.

Как считаете что надо выбрать в качестве "программной платформы" (проектирование, программирование и т.д.) чтобы достигнуть наибольшей отдачи?

M>Ну не знаю = лично мне в это не очень верится. Серьезная система документооборта — крупный проект
M>требующий:
M>а) Комплексного обследования предметной области (орг. структура — взаимодействие отделов и т.д.)
M>б) Создания полной проектной документации по созданной системе.
а причем тут пхп ?


M>У нас в АСУ есть система написаная на VFP по автоматизации документооборота Деканата. Занимает чуть более 20000 строк. Я не верю, что на PHP можно реализовать систему документооборота вуза более компактно. Что такое 20000 строк на PHP, я видел. Я даже видел к чему это привело через два месяца при отсутствии документации. Дело слава богу не со мной было. Проект кстати вести такой как раз на объектной методологии было бы рульно. А в PHP она в зачаточном варианте, по крайней мере пока. Опять же CASEов нет — плохо. Все вручную документировать — не по-приколу.
M>Мое личное убеждение — надо выбирать средство по задаче. На PHP отлично пишутся всякие разные webы типа развитые форумы, магазины и т.д. и т.п. Оптимизационные задачи или просто крупные претенциозные проекты писать — одно мучение.

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

еще мне как-то в голову никогда не приходило считать строки ... время считаю ... но строки то зачем? и причем тут пхп и криворукость которую вы где-то видели ? да и если вы не нашли CASEов ну тогда результат не должен удивлять

А>>p.s. oracle php будет супортить вместе с 10кой.
M>Да он с любой БД пахать будет через ODBC.

оракловый суппорт чуть другое, это значит они в свой апп сервер воткнут пхп и будут осуществлят техническую помощь.

Gt_

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

Фокс лучше всего меняется на дотнет. Все же тоже продукт МС и позволяет более-менее с БД работать. Только ISAM-ые привычки придется менять (в дотнете все через SQL).

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

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

Не спорю с этим. FOX я уважаю как хранилище (БД) а не как средство разработки приложений. У нас просто на нем написано было (и есть).

А>еще мне как-то в голову никогда не приходило считать строки ... время считаю ... но строки то зачем? и причем тут пхп и криворукость которую вы где-то видели ? да и если вы не нашли CASEов ну тогда результат не должен удивлять

Строки считают. Это даже научное название имеет — "статистические метрики качества ПО" (если память не изменяет). Метрики Холстеда есть по-моему. Вобщем это не моя придумка.
Если CASE под PHP есть скажи.

А> оракловый суппорт чуть другое, это значит они в свой апп сервер воткнут пхп и будут осуществлят техническую помощь.

Спасибо, что внес ясность.

я не знаю какие вычисления должна производить ваша система, но многое можно сдалать на Mysql+php

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

KA>я не знаю какие вычисления должна производить ваша система, но многое можно сдалать на Mysql+php

Вычисления довольно сложные — особенно там где дело касается учебной части:
1) Абитуриент — зачисление студента (нетривиальная задачка, если учитывать что критериев отбора очень много и они меняются во времени. Дело осложняется тем, что студент может подавать заявление на несколько специальностей одновременно, расставляя приоритеты. Таким образом если не проходит на одну — поступает на другую и т.д. Рейтинг специальностей (хуже/лучше) во время зачисления тоже под вопросом. Это так кратко (только чтоб очертить круг) — там куча нюансов с формой обучения, комерческим/бюджетным, иностранцы опять же и т.д. Если по научному — задача теории принятия решений)
2) Учебные планы/графики учебного процесса (Тоже проблемная область. Надо имея на руках стандарт от минобразования построить план изучения дисциплин, но так что удовлетворить всех и студентов, которым нельзя ставить больше скольки-то экзаменов/зачетов/курсовых в семестр, определенного числа часов в неделю за семестр и весь срок обучения, и преподавателей имеющих свои методики преподавания преметов и собственно учебную часть, которая постаянно стремится (и должна стремится) сэкономить деньги вуза за счет объединения студентов в потоки. Дисциплины нужно упорядочивать, потому что изучение одной не может опережать изучение другой. Здесь тоже описание не полное — нюансов очень много. Оптимизационная задача, короче)
3) Расписание занятий. (Сильно связано с предыдущей задачей. Что это такое — думаю всем понятно, и что реализовать сложно объяснять не надо. Тут сталкивается очень много интересов и все на временном пространстве)
4) Деканат — учет контингента и успеваемости студентов. (Довольно тривиально. Надо лишь переформировывать группы, создавать проекты приказов на отчисление, перевод, восстановление и иже с ним. Задача усложняется только необходимостью печати нестандартных отчетов — по медалистам и спортстменам и т.д. и т.п. — это собственный генератор отчетов)
5) Кафедра — расчет нагрузки на преподавателей и учет всякой разной научной деятельности + всякая разная отчетность. Это еще не совсем продуманная задача. Но вобщем-то не должна оказаться сложнее предыдущих.
6) Документооборот — я его понимаю не только в обычном смысле (приказы, КИД, письма и т.д.), но и как среду передачи данных (связь) между описанными выше подсистемами. Если это реализовать так как я это хочу чтобы было — не должно будет возникать проблем с интеграцией новых авт. подсистем вуза, например таких как:
7) Отдел кадров
8) Коммерческий отдел
9) Международный отдел
10) Отдел послевузовской подготовки
11) Степендиальный отдел
.........

Если, все еще не понятно — почему я не рассматриваю PHP + MySQL как вариант, покажите мне хоть одну систему такого масштаба и вычислительной сложности сделанную на PHP + MySQL.
Ну хоть расписание покажите.
А еще лучше CASE нормальный.

Спасибо за участие.
Пишите нам — мы очень рады.

M>Если, все еще не понятно — почему я не рассматриваю PHP + MySQL как вариант, покажите мне хоть одну систему такого масштаба и вычислительной сложности сделанную на PHP + MySQL.
M>Ну хоть расписание покажите.
M>А еще лучше CASE нормальный.

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


но если у вас оракл возьмите жабу

p.s. IMHO идеальный вариант — жаба бизнес объекты, пхп — веб морда.

Gt_