[rips-print]

Оригинал принадлежит truecolor
Неплохая заготовка для рекламного буклета, достаточно обширно и не о чем…
Очень жаль, что Вы проигнорировали мой конкретный вопрос.

Извиняюсь, не заметил.

Оригинал принадлежит truecolor
...позвольте мне усомнится в возможности, «за 15 (минут) практически создал модуль расчёта оптимальной загрузки некой единицы оборудования».
...Позвольте мне привести список этих правил, (замечу, что это лишь общеизвестные, правила оптимизации вытекающие из специфики собственно полиграфического производства на данный момент вынесем за скобки).

Критерии загрузки оборудования:
максимальный коэффициент загрузки оборудования;
минимальное число используемого оборудования;
равномерная загрузка оборудования во времени;
минимальное число переналадок;
минимальная мощность производственного грузопотока;

Приоритет запуска заказов в производство:
директивный приоритет;
заказ с ближайшим сроком готовности;
заказ с максимальным временем производства;
заказ с минимальным временем производства;

Правила постановки операций на рабочий центр:
выбор из головы очереди (первый пришел - первый пошел);
выбор из хвоста очереди (последний пришел - первый пошел);
операция с максимальным временем производства;
операция с минимальным временем производства;
операция, входящая в заказ с максимальным числом незавершенных операций;

Теперь собственно вопрос, какие из вышеперечисленных правил реализует вышеозначенный модуль, тем более что «планирование производственных ресурсов» вынесено в описание системы?

1. Вы правильно поняли - ключевыми словами в данной фразе являются слова «практически создал», то есть показал, как и по какому принципу может быть построен данный модуль.
А реализовываться он будет на основе таких основных критериев как:
- соблюдение сроков выполнения заказов;
- минимальное время простоя оборудования;
- минимальная с\стоимость работ;
- максимальное качество изделия;
Правила же, по которым будут реализованы эти критерии, позвольте я не буду расписывать, много это. То что перечислили Вы - даже не десятая их часть. Тем более в ТЗ он еще расписан не до конца - много зависимостей от других модулей.

Оригинал принадлежит Alexey

Между прочим "СИСТЕМА" о которой вы говорите, действительно неплохая, но представляет собой конструктор, очень похожий на Delphi, больше годится для хорошего склада - и, кстати, то что вы пишите под нее вашим заказчикам будет стоить дополнительно ~$500 за одно место... 8)

А «планирование производственных ресурсов» можно конечно "за уши" притянуть к готовой СИСТЕМЕ за некотрое кол-во времени, поломав весь существующий бизнес-процесс типографии, но к таким переменам руководство типографии и работники будут врят ли готовы...
А отладка такой программы, может разорить типографию... 8))

Всего самого доброго!
Ведешкин Алексей

Это конечно же не Delphi. Хотя и в Delphi можно сделать хорошие вещи, а не только склад, как вы говорите, НО... проблема с СУБД. Какую Вы будете использовать? Вы знаете цены на лицензии этих СУБД. Почему мы должны зависить от настроений и заскоков забугрян.
Я писал о том, что пишу в Delphi контрольные модули, чтобы проверить некоторые правила, правильно ли работает та или иная логика. И не более того.
По- поводу второго вашего замечания ничего не могу сказать, так как ни чего не понял.
Почему "за уши",
Почему "поломав",
Почему "не готовы",
Почему "разорить"

Заказчик будет платить только за то, чем будет пользоваться, а отлаживать ни чего не надо. Вы нас с кем то спутали.

[rips-print]

Оригинал принадлежит Max-prepress

Безусловно, создание описанного продукта , вещь очень интересная, но вот мне почему не видится все таким безоблачным.
Когда я брался за свою систему, основное требование было - это возможность удаленной работы (офис в одном месте, пр-во в другом, + удаленная работа с заказами). Так вот, одно только это требование отмело Access и им подобные платформы. Я выбрал путь сразу все делать через web. У этого пути есть и плюсы и минусы.

Согласен, что всё не так безоблачно.
Но в нашей системе работа через Инет уже реализована в самой платформе, поэтому голова об этом не болела.

Оригинал принадлежит Max-prepress

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

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

[Mk]

По поводу удаленной работы. А почему не терминал? Нам Цитрикс очень нравится. Например, с 1С вполне можно работать по мобиле через СкайЛинк, не говоря уж о прочем.

[Max-prepress]

Оригинал принадлежит Mk
По поводу удаленной работы. А почему не терминал? Нам Цитрикс очень нравится. Например, с 1С вполне можно работать по мобиле через СкайЛинк, не говоря уж о прочем.

Михаил, честно говоря, в то время, когдя я начинал, я вообще-то и не знал о терминалах. Да и сейчас не слишком силен в этом. Если терминал выглядит как теминал Линукса, ну это конечно интересно, но боюсь что пользователю это будет совсем не "обычно". А если это выглядит как-то по другому, то скорее всего трафик большой создает.

По поводу 1С, Скайлинк и всего остального.
Скайлик, если мне не изменяет память, выдает до 155 Кбит/с. (хотя реально наверно и меньше) - ну это далеко не у всех выделеный канал с такой скоростью работает. Тогда в принципе можно говорить о том, что все программы могут работать удаленно. Поднимаешь VPN до офисной сети и работай. Хотя даже при такой скорости все будет еле шевелиться. У меня друг работает в типографии том числе и технологом, и стоит у них ЛИМ, и кто-то их надоумил , что можно таким образом из дома работать :-). Все клиенты, типа Ассеss, MSSQL и прочие имеют особенность передавать кучу данных, обычно не подконтрольную пользователю. Я в свою бытность работал с TS Полиграфией (в то время она была под крылом Титансофта, а теперь она APP System ), так при пользователях больше 5, она парализовывала 100 Мб сеть. Вот такой создавлся траффик. В моей системе на формирование страницы уходит 0.05-0.3 секунд (при сервере на 1000 Celeronу и 512 Мб памяти) и где-то 1 секунда уходит еще на передачу данных по сети (в среднем 25 Кб) и на формирование станицы в броузере (причем быстрее всего ее формирует Opera). При этом сервер начинает тормозить при 50 обращениях обновременно ( веальности такого достичь почти не возможно, а если и будет достигнут максимум - все решается небольшой оптимизацей сервера.


Михаил - если не тяжело - дайте ссылку , где прочитать про "Цитрикс". И еще, раз уж вы занимаетесь 1С - есть ли у нее (или него) драйвера (или возможность) соединиться с сервером MySQL ?

[Mk]

1. По поводу Цитрикс: http://citrix.pp.ru Если коротко, то это программа удаленного доступа, типа MS Terminal, только лучше сделана и более продвинута. Смысл: на сервере запускается приложение, а по каналу гонятся, скажем, команды Виндов, поэтому трафик небольшой. В частности, как я упоминал, СкайЛинк со 155 хватает, чтобы работать, практически с чем угодно. Запускали и офисные прложения Виндов (Ворд, Эксель, Аксесс) и 1С версий 7 и 8. Мы тестировали производительность 1С7 и 1С8 на не слишком крутом сервере под Цитрикс. 25 сеансов подключения не вызывали тормозов.

2. Насколько знаю, 1С работает с MSSQL. Наверное с MySQL работать не будет. Правда возможна работа 1С в файловом варианте. Но 1С8 в файловом очень тормозная, 1С7 получше. А почему MySQL? Это ведь легкая СУБД для HTML приложений.

3. Странно, что работа с ЛИМ в терминале вызвала трудности. По идее их не должно было бы быть, если ЛИМ поддерживает достаточное количество одновременных пользователей. Цитриксу, грубо говоря, по барабану (в определенных пределах).

[Mk]

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

Прошу извинить за наивность, т.к. не в теме. А в чем сложность раскладки? Спрашиваю потому-что имел отношение к математике и белорусских математиков знаю. Если не сложно, укажите, как можно с Вами связаться для выяснения задачи. Интерес академический (как-то занимался оптимизацией раскроя металла на продольно-поперечных станках).
Извините, что не даю мыла - боюсь спама.

[Vsevolod]

Оригинал принадлежит Mk

Прошу извинить за наивность, т.к. не в теме. А в чем сложность раскладки? Спрашиваю потому-что имел отношение к математике и белорусских математиков знаю. ... Интерес академический (как-то занимался оптимизацией раскроя металла на продольно-поперечных станках).

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

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

[Mk]

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

[POMAH]

Оригинал принадлежит Mk

Интерес академический (как-то занимался оптимизацией раскроя металла на продольно-поперечных станках).
Извините, что не даю мыла - боюсь спама.

Если действительно интересно. В пакете Xpaid.Print (имеено так называется этот пакет) реализованы:

1. Алгоритм поиска с запретами (или Tabu Search).
Я так понимаю, это на основе схемы Гловера.
В двух словах: в надежде найти глобальный оптимум поиск раскладки не останавливается в точке локального оптимума, как в стандартном алгоритме локального спуска, а продолжается перебор от одного локального оптимума к другому.

2. Рекурсивный метод.
Этот метод изначально заточен под раскладку на листовой бумаге (или небумаге. Говоря заумно, на основе "однопроходной специализированной эвристике").
В двух словах: быстро вычисляется неплохой результат при этом довольно высокое качество (так называемый, "коэффициент заполнения" если много мелких разных изделий на листе может доходить до 98%). Правда для этикеток из-за важности долевой, результат похуже.

3. Послойный алгоритм.
Видимо, основан на эволюционном алгоритме (поисковый метод, основанный на идее "борьбы за выживания") и решается методом смешанного целочисленного программирования.

4. Первый подходящий с упорядочиванием.
Ну, тут все понятно из названия.

[Vsevolod]

Оригинал принадлежит Max-prepress


Я выбрал путь сразу все делать через web. У этого пути есть и плюсы и минусы.

Вот и ище один критерий народился:

Критерий "В": Веб-интерфейс

Возможность использовать в работе веб-интерфейс. Пользователям внутри системы -- для работы. Заказчикам и/или руководству -- скинуть заказ на просчет, посмотреть как идут дела .

Можно сказать, что это веяние времени, но ведь удобно, черт подери...
Некоторые системы целиком сидят на вебе (помимо вышеупомянутых, например Логикум). Некоторые могут портировать стандартный интерфейс в веб (например, последняя версия СайтЛайна).
У кого-то отдельные модули вынесены для просчета заказов (Веб.Коннект у Принанса, еБизнес у Хайфлекса), или просмотра состояния работ.

[Max-prepress]

Я вообщем-то тоже согласен, что скорее всего оптимальной будет система "гетерогенная", особенно , когда дело дойдет до штрих-кодов .

[Mk]

Вопрос, для чего он нужен.
Если как элемент CRM, то да. Если как общая организация работы с программой, то вряд ли. Терминальный режим, ИМХО, гораздо проще и лучше. Известные мне попытки реализовать работу полностью через веб ни к чему путному не привели.

[Max-prepress]

Оригинал принадлежит Mk
Вопрос, для чего он нужен.
Если как элемент CRM, то да. Если как общая организация работы с программой, то вряд ли. Терминальный режим, ИМХО, гораздо проще и лучше. Известные мне попытки реализовать работу полностью через веб ни к чему путному не привели.

Мне известны примеры отличной реализации web-интерфеса, как основы системы. Как один из вариантов дизайна -
http://misha.design.ru/coctail/ - к такому я и хочу, свою программу привести
А терминальные решения ? Есть ? И опять же - сколько все это стоит ?

[rips-print]

Оригинал принадлежит Vsevolod


Вот и ище один критерий народился:
Критерий "В": Веб-интерфейс

Возможность использовать в работе веб-интерфейс. Пользователям внутри системы -- для работы. Заказчикам и/или руководству -- скинуть заказ на просчет, посмотреть как идут дела .

Такое у нас и так предусмотренно (контроль руководства, он-лайн просчёты, заказы), а вот насчёт посмотреть заказчикам как идут дела - идея очень интересная, правда не без проблем.

[Mk]

Опять про терминал.
1. Примеров полно.
2. Стоит: от нисколько (драный Метафрейм), до в соответствии с ценами продавцов.
3. Ничего придумывать для удаленного доступа не надо. Интерфес таков, каков у приложения. Это, как если бы Вы запускали приложение на локальной машине.

И еще несколько бонусов (впрочем, все нижеизложенное справедливо и для веб-реализации):
1. Сервер может стоять где угодно.
2. Его можно арендовать (если жалко денег на железо - примерно 3 штуки для нормальной машины).
3. Поддержка его работы: администрирование, своевременный апгрейд, температурный режим, независимое электропитание - не Ваша забота. Денежку за это, правда, платить нужно, так же как провайдеру. Полно случаев, когда поставят пассивный УПС и радуются до первого случая сварочных работ в своем здании.
4. На локальных машинах информации нет. Пришли органы, сеанс завершил - и ищи ветра в поле. Если совсем дело пахнет керосином, послал СМС, и вообще концов не найдешь.

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