Oberon space
General Category => Общий раздел => Тема начата: ilovb от Август 01, 2012, 10:46:03 am
-
Хочу поделиться одним наблюдением. При решении сложных прикладных задач над большими объемами данных узким местом практически всегда является чтение и запись этих самых данных. Т.е. скорость работы программы упирается в скорость жесткого диска, скорость сети, производительность сервера, да и вообще в нагруженность системы. Во что угодно, только не в скорость языка. По моим наблюдениям соотношение обычно 1:10, т.е. за десять минут работы программы код работает всего 1 минуту.
Вывод: решение прикладных задач на нативных языках не имеет смысла.
-
Хочу поделиться одним наблюдением. При решении сложных прикладных задач над большими объемами данных узким местом практически всегда является чтение и запись этих самых данных. Т.е. скорость работы программы упирается в скорость жесткого диска, скорость сети, производительность сервера, да и вообще в нагруженность системы. Во что угодно, только не в скорость языка. По моим наблюдениям соотношение обычно 1:10, т.е. за десять минут работы программы код работает всего 1 минуту.
Вывод: решение прикладных задач на нативных языках не имеет смысла.
Эмм. Ну вот мне нужно рисовать спектрограмму в режиме реального времени. То есть в простейшем случае это будет либо DFT либо DCT (дискретное преобразование фурье, либо дискретное косинусное преобразование). Теперь вопрос - реально ли все равно на каком языке решать такую ПРИКЛАДНУЮ задачу?
-
Если есть графическая библиотека (написанная на нативном языке естественно), то почему нет?!
ps На жабаскрипте вон целые 3д сцены ваяют под WebGL.
-
Если есть графическая библиотека (написанная на нативном языке естественно), то почему нет?!
ps На жабаскрипте вон целые 3д сцены ваяют под WebGL.
Визуализация спектрограммы тут не является узким местом.
-
Идеальный язык для прикладных программ -- это Дельфы, всё остальное нафиг не надо )))
-
2 valexey
Я не думаю что скорость вычислений будет катастрофически низкой. И если даже будет, то этот маленький кусочек можно и нативно наваять. Исключения из правил никто не отменяет. Всегда будут ситуации, когда необходимо спуститься на уровень ниже (иногда и до асма).
Опять же вычисления в реальном времени это довольно специфическая область, которая обычно обеспечивается специальными средствами. Но это опять же не повод решать прикладную задачу полностью на нативном языке. Большую часть кода лучше писать на хорошем гибком скриптовом языке имхо. В прикладных задачах удобство важнее производительности.
-
Идеальный язык для прикладных программ -- это Дельфы, всё остальное нафиг не надо )))
На мой взгляд Дельфы тоже слишком сложен и ограничен, чтобы прикладник тратил время на него.
Я бы голосовал за 1С, но он слишком примитивен для современного языка.
зы Lua кандидат
-
В идеале, для различных прикладных задач должны быть различные простые языки высокого уровня, которые должны быть надстройкой над единым низко-среднеуровневым языком, к примеру, тем же Обероном.
-
Вот кстати насчет Оберонов... КП хвалят на том форуме за рефлексию, а мне вот с некоторых пор думается, что рефлексия в нативном языке нафик не нужна. Нужна рефлексия - юзай скриптовый язык.
-
2 valexey
Я не думаю что скорость вычислений будет катастрофически низкой.
А я тоже не думаю, я знаю какой будет скорость, потому как именно этим и занимаюсь :-) И ладно преобразование фурье, оно относительно быстрое, но есть же например еще и сингулярное разложение матриц, а вот это уже тормоза вполне конкретные. Вплоть до того, что получается лишь один раз в несколько секунд анализ производить.
И если даже будет, то этот маленький кусочек можно и нативно наваять. Исключения из правил никто не отменяет. Всегда будут ситуации, когда необходимо спуститься на уровень ниже (иногда и до асма).
Нативный код - это не уровень ниже :-) Язык высокого уровня это не тот язык который оторван от реального железа и где-то там витает в виртуальных машинах, язык высокого уровня это язык который предоставляет богатые возможности для создания собственных абстракций. Например java, вообще говоря, язык более низкоуровневый нежели C++ но при этом оно сидит в виртуальной машине.
Опять же вычисления в реальном времени это довольно специфическая область, которая обычно обеспечивается специальными средствами.
Область может и специфическая, но весьма попсовая на самом деле. Любой видео или даже аудиоплеер - это реалтайм, любой софтфон (тот же скайп) - это реалтайм. Почти любая игра - это реалтайм :-)
Но это опять же не повод решать прикладную задачу полностью на нативном языке.
Вообще, что такое нативный язык? :-) Вот Ада - это нативный язык? А C++?
Большую часть кода лучше писать на хорошем гибком скриптовом языке имхо. В прикладных задачах удобство важнее производительности.
Дык в том то и дело что языки которые были разработаны исключительно для скриптовых применений, не удобны для всех остальных применений, ибо слижком уж низкоуровневы (в них нет инструментария для создания собственных абстракций). Ну что ты напишешь хорошего на таком типичном скриптовом языке, как язык bat-файлов доса? Ну, или, если брать более продвинутый язык созданный для скриптовых применений - на bash'e?
Не следует путать скриптовые языки (то есть языки которые создавались исключительно для скриптового применения, то есть написания СКРИПТОВ) с языками у которых пока есть только реализации в виде интерпретаторов (то есть компиляторы в native пока не написаны, например php, хотя у него вроде бы уже есть и компилятор в native или около того).
-
Ну под скриптовыми я подразумеваю такие как JS, ActionScript, 1С, Lua, ну и всякие питоны с рубями наверно тоже.
Вот Java скорее нативный...
Дать точное определение конечно сложно.
В скриптовых языках рефлексия обычно работает без дополнительных телодвижений.
Ну например:
Запись = Новый Структура("Имя, Фамилия")
Запись["Имя"] = "Вася"
Запись["Фамилия"] = "Пупкин"
-
Или вот еще пример:
Поля = "Один, Два, Три, Четыре";
Запись = Новый Структура(Поля)
Счетчик = 1;
Выполнить("
|Для Каждого Поле Из Запись Цикл
| Запись[Поле.Ключ] = Счетчик;
| Счетчик = Счетчик + 1;
|КонецЦикла;")
-
Ну под скриптовыми я подразумеваю такие как JS, ActionScript, 1С, Lua, ну и всякие питоны с рубями наверно тоже.
Вот Java скорее нативный...
Дать точное определение конечно сложно.
Ну почему же сложно? Очень просто: скриптовый язык - язык который был разработан исключительно для скриптовых применений. Таким образом ни современный js, ни, тем более ActionScript, ни Lua/Python/Ruby, скриптовыми языками НЕ являются. Равно как и java.
Далее: все эти языки, кроме java, роднит одно - динамическая типизация (в ActionScript'e, и, по моему, Ruby, есть и статическая, также статическая уже и в js встречается). Но динамическая у всех, это не значит что она у всех одинаковая - у некоторых языков из перечисленных выше, типизация строгая, у некоторых слабая/не строгая.
В скриптовых языках рефлексия обычно работает без дополнительных телодвижений.
Ну например:
Запись = Новый Структура("Имя, Фамилия")
Запись["Имя"] = "Вася"
Запись["Фамилия"] = "Пупкин"
Эмм.. А чем, тут суть? И чем это так сильно отличается от:
map<string, string> record;
record["Имя"] = "Вася";
record["Фамилия"] = "Пупкин";
Замечу, что никакого рефлекшина тут не надо :-)
-
Или вот еще пример:
Поля = "Один, Два, Три, Четыре";
Запись = Новый Структура(Поля)
Счетчик = 1;
Выполнить("
|Для Каждого Поле Из Запись Цикл
| Запись[Поле.Ключ] = Счетчик;
| Счетчик = Счетчик + 1;
|КонецЦикла;")
Я откровенно не понимаю что тут делается :-)
-
А так? :D
VAR
rec: RECORD
one: INTEGER;
two: INTEGER;
three: INTEGER;
four: INTEGER;
END;
i: INTEGER;
BEGIN
i := 1;
RUN("FOR EACH field IN rec DO rec[field.key] = i; INC(i); END;");
END
-
А так? :D
VAR
rec: RECORD
one: INTEGER;
two: INTEGER;
three: INTEGER;
four: INTEGER;
END;
i: INTEGER;
BEGIN
i := 1;
RUN("FOR EACH field IN rec DO rec[field.key] = i; INC(i); END;");
END
Тоже хрень какая-то. Что тут key для field? Обычно бывает таки key-value пары, где ключ это, переходя к терминологии записей, это поле, а значение это значение и есть - чиселка которая лежит в этом поле.
Ну и контрольный вопрос, что делает этот код:
Поля = "Oдин, Двa, Три; Чeтыре";
Запись = Новый Структура(Поля)
-
Ну ладно map есть в плюсах с шаблонами. А сколько нужно всего для поддержки этих контейнеров?
А если map кроме строк должно уметь еще и числа хранить?
Запись.Один = 1;
Запись.Два = "2";
а это:
Поля = "Oдин, Двa, Три; Чeтыре";
Запись = Новый Структура(Поля)
равносильно
VAR
rec: RECORD
one: INTEGER;
two: INTEGER;
three: INTEGER;
four: INTEGER;
END;Только гибкость такого подхода куда больше.
-
Тоже хрень какая-то. Что тут key для field? Обычно бывает таки key-value пары, где ключ это, переходя к терминологии записей, это поле, а значение это значение и есть - чиселка которая лежит в этом поле.
Так и есть. Записываем значение по данному ключу. Тут ключ - это имя поля структуры.
Т.е. в 1С разрешен рефлекшен относительно имен полей RECORD'а.
Унутрях это map конечно (модифицированный). Но для кодера это выглядит как обращение к полю RECORD рефлексивно, т.е. обращаясь к метаданным в реалтайме.
-
Ну ладно map есть в плюсах с шаблонами. А сколько нужно всего для поддержки этих контейнеров?
Нужен всего лишь язык высокого уровня :-)
А если map кроме строк должно уметь еще и числа хранить?
Запись.Один = 1;
Запись.Два = "2";
То никаких проблем :-)
map<string, boost::any> record;
record["Один"] = 1;
record["Два"] = "2";
Штука в том, что если у тебя есть язык высокого уровня со статической типизацией, то ты там можешь легко сделать себе подъязык с динамической типизацией, просто в виде либы. Ибо язык высокого уровня для того и нужен, чтобы можно было создавать нужные тебе абстракции (иначе это не ЯВУ), а динамическая типизация - всего лишь одна из таких абстракций.
а это:
Поля = "Oдин, Двa, Три; Чeтыре";
Запись = Новый Структура(Поля)
равносильно
VAR
rec: RECORD
one: INTEGER;
two: INTEGER;
three: INTEGER;
four: INTEGER;
END;Только гибкость такого подхода куда больше.
То есть оно спокойно прожует вместо запятой (',') мою точку с запятой (';'), и ошибки в рантайме не будет? :-) А если я эти слова в той строке буду разделять буквой "Ы"?
-
Точку с запятой я проглядел. :) В этом случае будет исключение времени выполнения (без краха даже если нет обработчика)
Сдаюсь. Шаблоны в данном случае рулят. Но процедуру по имени они все равно не смогут вызвать. ;)
У меня тогда такой вопрос: Зачем мне прикладнику изучать монстра С++? Пусть он даже большинство плюшек скриптовых языков покроет? Смысл?
-
Точку с запятой я проглядел. :) В этом случае будет исключение времени выполнения (без краха даже если нет обработчика)
Сдаюсь. Шаблоны в данном случае рулят. Но процедуру по имени они все равно не смогут вызвать. ;)
Смотря что такое вызов "процедуры по имени" :-) Тут нужна корректная полная постановка задачи. Возможно тебе и не нужна тут вызов произвольной процедуры по произвольному имени на самом деле. (тем более что "процедуры" можно сложить в тот же map, а ключ будет строка, по строке достаешь нужную "процедуру" и вызываешь её).
У меня тогда такой вопрос: Зачем мне прикладнику изучать монстра С++? Пусть он даже большинство плюшек скриптовых языков покроет? Смысл?
Ну, во-первых про терминологию я вроде бы все выше разжевал. Как прикладнику тебе больше подойдет C++ или даже asm нежели любой из скриптовых языков (иначе попробуй все выше перечисленные примеры написать на типичном скриптовом языке - например на языке bat-файлов).
Видимо ты таки подразумеваешь языки с динамической типизацией (в том числе хм… компилирующиеся в нативный код :-) ).
Так вот, я тоже прикладник (системным программированием по работе я не занимаюсь как бы, то есть не пишу ни ОС ни компиляторы). И я слабо представляю где динамическая типизация мне принесла бы больше пользы чем вреда. В общем то потенциальный вред от подхода через динамическую типизацию + eval (интерпретируем строку как кусок кода) я вроде бы успешно продемонстрировал - глаз пропустил точку с запятой, и это будет не ошибка компиляции, а ошибка в рантайме. Внезапная и беспощадная. Но даже если из моей строки это точказапятую заменить на запятую, то код:
Поля = "Oдин, Двa, Три, Чeтыре";
Запись = Новый Структура(Поля)
Запись["Один"]=42;
Запись["Четыре"]=13;
Счетчик = 1;
Выполнить("
|Для Каждого Поле Из Запись Цикл
| Запись[Поле.Ключ] = Счетчик;
| Счетчик = Счетчик + 1;
|КонецЦикла;")
наверняка отработает не так как ожидалось. ;-)
А "монстра" можно и не учить, можно взять любой другой монстр язык высокого уровня - например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#. Да даже Оберон можно (в самом-самом худшем случае там будет надежность такая же как в языке с динамической типизацией, в среднем же надежность/отлавливаемость ошибок там будет лучше). Ах, да, Аду тоже можно и нужно. Ибо оня ня (особенно если больше хочется иметь набор инструментов для работы, нежели инструмент с помощью которого можно сделать этот самый набор инструментов).
-
например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#.
Типа, C# хуже, чем все вышеперечисленное.
А в чем, собственно, претензии к C#?
-
например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#.
Типа, C# хуже, чем все вышеперечисленное.
А в чем, собственно, претензии к C#?
Да у него, собственно, только один фатальный недостаток (на фоне остальных перечисленных языков) - его "придумала" M$ ;)
-
Сдаюсь. Шаблоны в данном случае рулят. Но процедуру по имени они все равно не смогут вызвать. ;)
Рано сдаешься ;) Позиция должна быть примерно такая: на плюсах можно сделать ВСЁ, но почти всё будет через одно место ;) И ткнуть в исходники какого-нибудь boost::any.
-
например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#.
Типа, C# хуже, чем все вышеперечисленное.
А в чем, собственно, претензии к C#?
Ну, он не то чтобы хуже… он другой :-)
Во-первых в C# уж очень резво пихают все фичи подряд (ортогональные и не очень). Такое ощущение что у них там сидит специальный человек, который гуглит какие же еще есть фичи в других ЯП, которые они еще в шарп не запихнули. ООП? Легко! ФП - да не вопрос! Контракты - уже впихнули! Ждем элементов пролога и брейнфака, а также APL. С# это такой современный PL/I, с поправкой на возможности сегодняшних машин (то есть C# еще крупнее).
Во-вторых, C# это MS. Я вообще не шибко жалую языки от которых наносит vendor lock-in'ом. А тут запашок весьма и весьма сильный, да к тому же не просто lock-in какой-нибудь АдаКоры, а толстячка в виде MS. Причем не только на язык (как в случае java), но и на основной инструментарий и либы и вообще все (да, mono есть, но mono все же вторично и по большей части следует за MS). Поэтому нафиг-нафиг.
Но в плане рассматриваемого вопроса, C# весьма неплох (хотя он, повторюсь, как минимум не менее монстр нежели С++). Он быстрый, он более высокоуровневый нежели Java (сравнивать его уровневость с плюсами я не берусь, просто потому что не достаточно компетентен в современном C# для этого).
-
Хочу поделиться одним наблюдением. При решении сложных прикладных задач над большими объемами данных узким местом практически всегда является чтение и запись этих самых данных.
Такие задачи составляют 95% от задач, которые приходится решать. И большая часть времени тратится программы при приёме данных на работу со строками, если конечно запросы к базе данных составлены корректно, а в самой базе данных сделана оптимизация (хотя бы на уровне индексов, чтобы исключить fullscan).
Я не использую разные датасеты, данные из запроса "руками" размещаются в памяти (это совсем не трудно, а параллельно с получением и размещением данных выполняются и другие операции, установка признаков, калькуляция и т.п.).
(Работа ведётся в Delphi)
Т.е. скорость работы программы упирается в скорость жесткого диска, скорость сети, производительность сервера, да и вообще в нагруженность системы. Во что угодно, только не в скорость языка. По моим наблюдениям соотношение обычно 1:10, т.е. за десять минут работы программы код работает всего 1 минуту.
Вывод: решение прикладных задач на нативных языках не имеет смысла.
С моей точки зрения, это несколько преждевременный вывод.
-
Хочу поделиться одним наблюдением. При решении сложных прикладных задач над большими объемами данных узким местом практически всегда является чтение и запись этих самых данных. Т.е. скорость работы программы упирается в скорость жесткого диска, скорость сети, производительность сервера, да и вообще в нагруженность системы. Во что угодно, только не в скорость языка. По моим наблюдениям соотношение обычно 1:10, т.е. за десять минут работы программы код работает всего 1 минуту.
Вывод: решение прикладных задач на нативных языках не имеет смысла.
Эмм. Ну вот мне нужно рисовать спектрограмму в режиме реального времени. То есть в простейшем случае это будет либо DFT либо DCT (дискретное преобразование фурье, либо дискретное косинусное преобразование). Теперь вопрос - реально ли все равно на каком языке решать такую ПРИКЛАДНУЮ задачу?
Подпрограмму преобразования Фурье лучше и проще написать на ассемблере... я бы сказал, без вариантов. А обрамление - на том, что удобно для разработки интерфейса с пользователем или другими (под)программами.
-
...Видимо ты таки подразумеваешь языки с динамической типизацией...
Любой скриптовый язык имеет динамическую типизацию (хотя ничего не мешает сделать статическую)
Но! Не любой язык с динамической типизацией является скриптовым.
Чтобы не возникало ассоциаций с батами и башами предлагаю заменить скриптовый на динамический. Предполагая не только динамическую типизацию, но и рефлекшен, и интерпретируемость, и замыкания там всякие :).
А нативные языки в противовес заменить на статические.
Еще попробую по пунктам пройтись.
1. Языки обычно простые для изучения и использования.
2. Переносимость выше чем у статических языков.
3. Непосредственный и естественный рефлекшн
4. Нет необходимости в использовании стека, т.к. скорость исполнения не имеет высокого приоритета. Можно использовать альтернативные более гибкие способы (как в JS например)
5. Нет необходимости в компиляции и линковке. Более того можно работать в режиме диалога (Python, Scheme)
6. Динамический язык обычно имеет богатое окружение в виде всяких контейнеров, коллекций и т.д., которых обычно с лихвой хватает для прикладных задач. Окружение пишется на нативных языках, и как следствие производительность оказывается достаточной для большинства прикладных задач. Прикладник не занимается разработкой сложных структур данных. Он пишет окружение только для своей конкретной прикладной задачи.
Ну и по поводу всяких медиаплееров с играми. Нет никакой проблемы написать медиаплеер на том же Python, т.к. кодеки можно использовать готовые (написание коих я отношу к системному программированию). А игры (3D с крутой графикой) спокойно пишутся на том же жабаскрипте (см. Unity (http://ru.wikipedia.org/wiki/Unity_(%D0%B8%D0%B3%D1%80%D0%BE%D0%B2%D0%BE%D0%B9_%D0%B4%D0%B2%D0%B8%D0%B6%D0%BE%D0%BA)))
-
Такие задачи составляют 95% от задач, которые приходится решать. И большая часть времени тратится программы при приёме данных на работу со строками...
Не очень понятно. Что имеется ввиду? Какие именно операции со строками?
...параллельно с получением и размещением данных выполняются и другие операции, установка признаков, калькуляция и т.п.
Ну а по ощущениям сколько времени тратится на этот код по отношению к выгребанию данных из базы с последующей записью результата?
Я вот сейчас дописываю расчет коммунальных услуг для водоканала. Город (120000 абонентов) обсчитывается за 5 минут. Код работает только 10% времени (1000 строк) Остальное время это выгребание исходных данных SQL'ом (примерно 30%) и запись результата расчета (примерно 60%). И это при том, что язык 1С примерно в 500 раз медленнее нативного.
Это не первый такой случай. Да и вообще я не помню, чтобы язык был узким местом. В подавляющем большинстве случаев виновником является ввод/вывод.
-
глаз пропустил точку с запятой, и это будет не ошибка компиляции, а ошибка в рантайме. Внезапная и беспощадная.
Это она в плюсах внезапная и беспощадная. А в том же 1С это форточка с сообщением об ошибке времени выполнения. В котором отображается строчка кода в которой произошла ошибка (и даже кнопочка чтобы перейти к этой строчке кода) и причина ошибки.
Некоторые пользователи даже не подозревают что это ошибки в программе :) Закрывают форточку с ошибкой и дальше работают (Либо звонят кодеру, который удаленно подключается и за пару минут исправляет ошибку).
Проблема возникает только когда из-за ошибки пользователь не может сохранить свою работу, но это редко.
-
Такие задачи составляют 95% от задач, которые приходится решать. И большая часть времени тратится программы при приёме данных на работу со строками...
Не очень понятно. Что имеется ввиду? Какие именно операции со строками?
Из БД выбирается информация, в том числе, строкового типа. Для каждой строки происходит операция выделения памяти. При этом, как правило, сканируется таблица строк. В результате всё это очень тормозит. Но речь о Delphi. Про 1С ничего сказать не могу.
...параллельно с получением и размещением данных выполняются и другие операции, установка признаков, калькуляция и т.п.
Ну а по ощущениям сколько времени тратится на этот код по отношению к выгребанию данных из базы с последующей записью результата?
При "стандартном" написании, через датасеты, выборка из БД происходит быстро (миллисекунды), а вот размещение в памяти (десятков и тысяч записей) может занимать минуты... Когда я наткнулся на эти тормоза, то отказался от датасетов.
Сейчас пользователям быстрое отображение данных кажется нормальным, их в большей степени умиляет аналитические "фишки" в виде фильтрации данных, сортировок и т.п. Тут можно провести сравнение с 1С (есть у меня одно предприятие, где бухгалтерию ведут в 1С, а производство и сбыт работают в нашей системе. Раз в месяц некоторые данные (по объёмам выпуска продукции и платежам) из нашей системы вываливают в 1С для формирования отчётности). И на одном и том же объёме данных 1С работает очень неспешно, хотя там никакой аналитики нет, просто визуализация.
Но фильтрация - это отдельный разговор, для тех, кто любит работать уровнем пониже.
Я вот сейчас дописываю расчет коммунальных услуг для водоканала. Город (120000 абонентов) обсчитывается за 5 минут. Код работает только 10% времени (1000 строк) Остальное время это выгребание исходных данных SQL'ом (примерно 30%) и запись результата расчета (примерно 60%). И это при том, что язык 1С примерно в 500 раз медленнее нативного.
Это не первый такой случай. Да и вообще я не помню, чтобы язык был узким местом. В подавляющем большинстве случаев виновником является ввод/вывод.
Может там запросы/структуры данных в БД не оптимизированы? Более минуты на чтение... как-то многовато. А запись - это вообще нонсенс. Если речь про MS SQL, то он в лидерах по добавлениям записей, на его основе даже real-time АСУТП-системы делают (например, Industrial SQL).
-
У меня тогда такой вопрос: Зачем мне прикладнику изучать монстра С++? Пусть он даже большинство плюшек скриптовых языков покроет? Смысл?
Низачем!!! Говорю же -- Дельфы, ДЕЛЬФЫ!!!
Ну или сишарп, если сишный синтаксис нравится (буээээ)...
Как вариант, если не хочется изучать это старинное унылое г -- то можно взять хаскель, правда под винду GUI и базы данных не так удобны, как в дельфях или шарпе...
-
Любой скриптовый язык имеет динамическую типизацию (хотя ничего не мешает сделать статическую)
Но! Не любой язык с динамической типизацией является скриптовым.
Чтобы не возникало ассоциаций с батами и башами предлагаю заменить скриптовый на динамический. Предполагая не только динамическую типизацию, но и рефлекшен, и интерпретируемость, и замыкания там всякие :).
А нативные языки в противовес заменить на статические.
Еще попробую по пунктам пройтись.
1. Языки обычно простые для изучения и использования.
2. Переносимость выше чем у статических языков.
3. Непосредственный и естественный рефлекшн
4. Нет необходимости в использовании стека, т.к. скорость исполнения не имеет высокого приоритета. Можно использовать альтернативные более гибкие способы (как в JS например)
5. Нет необходимости в компиляции и линковке. Более того можно работать в режиме диалога (Python, Scheme)
6. Динамический язык обычно имеет богатое окружение в виде всяких контейнеров, коллекций и т.д., которых обычно с лихвой хватает для прикладных задач. Окружение пишется на нативных языках, и как следствие производительность оказывается достаточной для большинства прикладных задач. Прикладник не занимается разработкой сложных структур данных. Он пишет окружение только для своей конкретной прикладной задачи.
http://oberspace.dyndns.org/index.php/topic,286.0.html
-
Может там запросы/структуры данных в БД не оптимизированы? Более минуты на чтение... как-то многовато. А запись - это вообще нонсенс. Если речь про MS SQL, то он в лидерах по добавлениям записей, на его основе даже real-time АСУТП-системы делают (например, Industrial SQL).
С запросами все нормально. Все необходимые кластерные и простые индексы присутствуют.
Насчет чтения... вы наверно выделяете отдельно размещение в памяти... Я же подразумеваю, что чтение окончено когда все данные находятся в оперативе. К тому же чтение у меня это SQL запросы с кучей соединений (все соединения конечно по индексам). Запросы выполняются минимальное число раз, т.е. каждый кусок данных выдирается сразу для всего города. Можно было и в один запрос сделать, но я решил, что читабельность важнее.
Насчет записи... Да, субд там MS SQL 2008. Но не забывайте что 1С это не прямая работа с таблицами. Там куча всяких обработчиков событий срабатывает (да и триггеров в субд тоже) К тому же 120000 нужно еще на 4 помножить, т.к. на каждого абонента пишется по 3-5 строк (есть несколько видов начислений). Результат пишется в документы, а скорость их записи много ниже чем у простой таблицы. В принципе можно писать в справочник (самая простая таблица 1С). Запись в этом случае будет происходить примерно с такой же скоростью, как при непосредственной работе с MS SQL, но это значит отказаться от плюшек 1С... А это уже не отличается от работы в Делфях ;) Если в Дельфях написать подобие 1С-ных абстракций, то сомневаюсь, что оно будет быстрее работать.
-
И на одном и том же объёме данных 1С работает очень неспешно, хотя там никакой аналитики нет, просто визуализация.
Если вышлете конфигурацию (можно только часть относящуюся к отчету) и исходный код отчета, то могу подсказать почему работает медленно. :)
-
Может там запросы/структуры данных в БД не оптимизированы? Более минуты на чтение... как-то многовато. А запись - это вообще нонсенс. Если речь про MS SQL, то он в лидерах по добавлениям записей, на его основе даже real-time АСУТП-системы делают (например, Industrial SQL).
С запросами все нормально. Все необходимые кластерные и простые индексы присутствуют.
Насчет чтения... вы наверно выделяете отдельно размещение в памяти... Я же подразумеваю, что чтение окончено когда все данные находятся в оперативе.
Для меня запрос (время его срабатывания) - это одно, а размещение данных в памяти - другое. Тормозит именно размещение данных, а не СУБД, и не сеть. И при размещение тормозит из-за строк. Так у нас было.
К тому же чтение у меня это SQL запросы с кучей соединений (все соединения конечно по индексам). Запросы выполняются минимальное число раз, т.е. каждый кусок данных выдирается сразу для всего города. Можно было и в один запрос сделать, но я решил, что читабельность важнее.
Иногда быстрее бывает дёргать данные несколькими запросами, но к MS SQL это скорее всего не относится, у них мощный оптимизатор.
Насчет записи... Да, субд там MS SQL 2008. Но не забывайте что 1С это не прямая работа с таблицами. Там куча всяких обработчиков событий срабатывает (да и триггеров в субд тоже) К тому же 120000 нужно еще на 4 помножить, т.к. на каждого абонента пишется по 3-5 строк (есть несколько видов начислений). Результат пишется в документы, а скорость их записи много ниже чем у простой таблицы.
А документы - это не таблицы? (Конечно, один документ не в одной таблице хранится, но, видимо, Вы говорите о том, что есть промежуточный логический слой. Я правильно понял?)
В принципе можно писать в справочник (самая простая таблица 1С). Запись в этом случае будет происходить примерно с такой же скоростью, как при непосредственной работе с MS SQL, но это значит отказаться от плюшек 1С... А это уже не отличается от работы в Делфях ;) Если в Дельфях написать подобие 1С-ных абстракций, то сомневаюсь, что оно будет быстрее работать.
А зачем они нужны эти абстракции? Какова их роль? (Я 1С совсем не знаю)
-
И на одном и том же объёме данных 1С работает очень неспешно, хотя там никакой аналитики нет, просто визуализация.
Если вышлете конфигурацию (можно только часть относящуюся к отчету) и исходный код отчета, то могу подсказать почему работает медленно. :)
Не могу - не моя "епархия"...
-
Тормозит именно размещение данных, а не СУБД, и не сеть. И при размещение тормозит из-за строк. Так у нас было.
Может и так. Но оно бы наверно от случая к случаю по разному тормозило, а я такого не наблюдал. В любом случае нет возможности на это влиять. И если бы даже была возможность, я бы не стал заниматься оптимизацией, т.к. у нас принято не усложнять код если проблема не критична (нет угрозы бизнесу клиента)
А документы - это не таблицы? (Конечно, один документ не в одной таблице хранится, но, видимо, Вы говорите о том, что есть промежуточный логический слой. Я правильно понял?)
Документ сам по себе не сильно сложный. Обычно это две таблицы (иногда больше) В одной таблице хранятся реквизиты документов, в остальных состав. Например для документа перемещения товара между складами будет две таблицы: в одной номер, дата, склад отправитель, склад получатель; во второй товар и количество. Т.е. одним документом можем переместить список товара. Сам по себе документ - это просто фиксация факта хозяйственной операции, и количество товара на складах он не меняет. Но документ после записи может быть переведен в состояние отражения операции в данных - это называется проведение. Проведение можно отменять.
Конкретно данные предприятия хранятся в специальных таблицах называемых регистрами. При проведении документ пишет свои данные в эти регистры (обычно в несколько). А вот регистр это уже сложная абстракция.
А зачем они нужны эти абстракции? Какова их роль? (Я 1С совсем не знаю)
Ну вот например регистр накопления рассчитывает и хранит нарастающие итоги (обороты и остатки) по всем аналитикам. К нему можно обращаться на SQL как будто это одна таблица. Такие таблицы называются виртуальными, т.к. они строятся в момент выполнения запроса.
Например я могу получить остаток товара на складе выполнив такой запрос:
ВЫБРАТЬ
Номенклатура,
КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата, Склад = &Склад)
Результат будет содержать остаток по каждому товару на данном складе.
А если сделать так
ВЫБРАТЬ
Склад,
Номенклатура,
КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата)
То результат будет содержать остаток по каждому товару на каждом складе.
Т.е. регистры очень упрощают жизнь программисту. Тем более что на SQL нельзя рационально посчитать нарастащий итог. (как вы это в Делфи делаете ума не приложу :) подозреваю что сочиняете подобие 1С-ного регистра ;D)
-
Документ сам по себе не сильно сложный. Обычно это две таблицы (иногда больше) В одной таблице хранятся реквизиты документов, в остальных состав. Например для документа перемещения товара между складами будет две таблицы: в одной номер, дата, склад отправитель, склад получатель; во второй товар и количество. Т.е. одним документом можем переместить список товара. Сам по себе документ - это просто фиксация факта хозяйственной операции, и количество товара на складах он не меняет. Но документ после записи может быть переведен в состояние отражения операции в данных - это называется проведение. Проведение можно отменять.
Конкретно данные предприятия хранятся в специальных таблицах называемых регистрами. При проведении документ пишет свои данные в эти регистры (обычно в несколько). А вот регистр это уже сложная абстракция.
Это, видимо, от "бухгалтерии" идёт. В реальной жизни не слишком нужная и полезная вещь. Для примера на производстве сотни операций, между которыми передаются сотни партий полуфабрикатов каждую смену. И тоже надо знать остатки (незавершённое производство). Фиксировать всё это в регистрах с привязкой к операциям/участкам в виде остатков. Зачем?
А зачем они нужны эти абстракции? Какова их роль? (Я 1С совсем не знаю)
Ну вот например регистр накопления рассчитывает и хранит нарастающие итоги (обороты и остатки) по всем аналитикам. К нему можно обращаться на SQL как будто это одна таблица. Такие таблицы называются виртуальными, т.к. они строятся в момент выполнения запроса.
Например я могу получить остаток товара на складе выполнив такой запрос:
ВЫБРАТЬ
Номенклатура,
КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата, Склад = &Склад)
Результат будет содержать остаток по каждому товару на данном складе.
А если сделать так
ВЫБРАТЬ
Склад,
Номенклатура,
КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата)
То результат будет содержать остаток по каждому товару на каждом складе.
Т.е. регистры очень упрощают жизнь программисту. Тем более что на SQL нельзя рационально посчитать нарастащий итог. (как вы это в Делфи делаете ума не приложу :) подозреваю что сочиняете подобие 1С-ного регистра ;D)
В чём здесь упрощение?
Дело не Delphi, на Delphi пишется интерфейс между БД и пользователем.
В БД фиксируется движение материалов: приход расход, на основе документов (накладных, актов оприходывания и списания). При этом, позиции документов по приходу и расходу могут хранится в одной таблице. Есть таблица инвентаризации, в которой фиксируются фактические остатки материалов на конкретные: дату и время. Если нужен остаток материала на некоторую дату, то из таблицы инвентаризации поднимается дата+время проведения инвентаризации и количество материала по факту инвентаризации. Остаётся только посчитать сумму приходов и расходов по нужному материалу между датой+временем инвентаризации и заданной датой. (Можно и данные инвентаризации хранить в той же таблице движения материалов, но это несколько запутывает логику). Такая простая система позволяет проводить простую и скользящую инвентаризации, получать остатки, а также позволяет делать надстройки, например, размещение материалов по местам хранения, снятие материалов с мест хранения, учёт заполненности мест хранения и склада в целом, оптимизацию маршрутов складского транспорта и пр., и пр.).
Но ничто не мешает иметь дополнительно таблицу остатков, которая заполняется автоматически - триггерами, по фактам перемещения товаров (приход/уход). Мы таких таблиц не используем, поскольку при номенклатуре в десятки тысяч позиций, программа работает достаточно быстро.
-
Документ - это просто удобная абстракция. Хозяйственную операцию как правило нужно отражать в нескольких таблицах (например покупка товара - это запись в две таблицы (поступление на склад и взаиморасчеты с поставщиком)), а документ избавляет от этой работы. К тому же документ не обязательно сразу проводить, если он не полностью заполнен, а у вас кончился рабочий день. В этом случае вы его сохраняете, чтобы "добить" на следующий день.
Если нужен остаток материала на некоторую дату, то из таблицы инвентаризации поднимается дата+время проведения инвентаризации и количество материала по факту инвентаризации. Остаётся только посчитать сумму приходов и расходов по нужному материалу между датой+временем инвентаризации и заданной датой.
Так и есть. Изобретаете подобие 1С-ного регистра (он примерно так и работает)
Понятно, что можно сделать точно такой-же механизм (а можно и круче). Но прикладник не должен этим заниматься.
-
Если нужен остаток материала на некоторую дату, то из таблицы инвентаризации поднимается дата+время проведения инвентаризации и количество материала по факту инвентаризации. Остаётся только посчитать сумму приходов и расходов по нужному материалу между датой+временем инвентаризации и заданной датой.
Так и есть. Изобретаете подобие 1С-ного регистра (он примерно так и работает)
Это не 1С - это жизнь. И до появления компьютеров так работали.
Понятно, что можно сделать точно такой-же механизм (а можно и круче). Но прикладник не должен этим заниматься.
А чем должен заниматься прикладник?
-
Это не 1С - это жизнь. И до появления компьютеров так работали.
Кто ж спорит? Просто в 1С никто не занимается изобретением велосипедов, которые уже давно изобретены ;)
А чем должен заниматься прикладник?
Решением прикладных задач. Механизм расчета нарастающего итога в СУБД - это системная задача.
Провести четкую границу между системным и прикладным программированием довольно сложно. Но я придерживаюсь концепции механика и водителя.
Водитель не должен заниматься обслуживанием автомобиля (системное программирование). Он должен управлять автомобилем (прикладное программирование)
Прикладник решает человеческие проблемы, а системщик системные. Механик обеспечивает работу техники, а водитель обеспечивает доставку груза.
-
Это не 1С - это жизнь. И до появления компьютеров так работали.
Кто ж спорит? Просто в 1С никто не занимается изобретением велосипедов, которые уже давно изобретены ;)
Ну, и напрасно. Не изобретя "велосипед", вообще ничего не изобретёшь. Это раз.
Изобретая "велосипед", можно изобрести и принципиально новую конструкцию и получить массу положительных "побочных" эффектов. Это два.
И, наконец, речь фактически идёт о моделировании и проектировании БД. А процесс моделирования очень важен, поскольку в этот момент появляется и решается огромное количество проблем. Если стадии моделирования нет, то те же проблемы всплывут значительно позже и их устранение будет существенно боле затратной операцией. Это три.
А чем должен заниматься прикладник?
Решением прикладных задач.
Какие задачи Вы считаете прикладными?
-
И, наконец, речь фактически идёт о моделировании и проектировании БД.
Какое отношение это имеет к структуре БД?
Какие задачи Вы считаете прикладными?
Я уже говорил выше. Это конкретные практические человеческие проблемы.
-
Какие задачи Вы считаете прикладными?
Я уже говорил выше. Это конкретные практические человеческие проблемы.
То есть бухучёт? ))
-
Я легко могу себе представить случай, когда расчет нарастающего итога является прикладной задачей. Но это в том случае, когда у клиента есть табличка Excel, и он просит написать скрипт, считающий такой итог. В данном случае вы будете решать эту конкретную задачу, и она будет прикладной, т.к. это конкретная практическая проблема реального человека.
Но в остальных случаях, она не будет непосредственно относиться к предметной области и станет системной. Т.к. это уже будет часть системы в рамках которой прикладник решает задачу.
Все относительно и зависит от контекста.
Если я пишу складской учет, то я должен думать в терминах складов, поставщиков, взаиморасчетов, количеств, сумм, цен, себестоимости, НДС и т.д. и т.п. Но никак не о том, как мне победить SQL и посчитать нарастающий итог.
-
То есть бухучёт? ))
Смотря что имеется ввиду. Если задача озвучена теткой бухгалтером, то да ;D
-
И, наконец, речь фактически идёт о моделировании и проектировании БД.
Какое отношение это имеет к структуре БД?
Самое прямое.
Я проектирую систему хранения, используя SQL, Вы - средства 1С. Разница в формализмах (SQL и 1С), но не в сути. Разница в формализмах существенна, но не критична. Критично только, то что Вы достраиваете модель 1С, а я нет - разрабатываю с нуля. И если предположить, что модель 1С близка к действительности, то Вы выигрываете, а если предположить, что модель 1С далека от действительности, то выигрываю я.
Какие задачи Вы считаете прикладными?
Я уже говорил выше. Это конкретные практические человеческие проблемы.
Кажется я понимаю, о чём Вы говорите. Под прикладными задачами Вы имеете ввиду построение каких-нибудь форм и отчётов. Правильно?
-
Если я пишу складской учет, то я должен думать в терминах складов, поставщиков, взаиморасчетов, количеств, сумм, цен, себестоимости, НДС и т.д. и т.п. Но никак не о том, как мне победить SQL и посчитать нарастающий итог.
Какие могут быть взаиморасчёты и себестоимость на складе?
Мне кажется, что при работе в рамках не совсем адекватной модели предметной области, происходит размывание функционального содержания конкретной задачи. А это, в свою очередь, приводит к тому, что пользователи постоянно "дрейфуют" в своих пожеланиях... и "хлеб" у прикладников никогда не заканчивается :)
-
Я проектирую систему хранения...
А я модель предприятия...
Кажется я понимаю, о чём Вы говорите...
Кажется нет...
ps Меня это не удивляет. Т.к. сам пережил ломку сознания, когда устроился 1С программистом :)
-
Если я пишу складской учет, то я должен думать в терминах складов, поставщиков, взаиморасчетов, количеств, сумм, цен, себестоимости, НДС и т.д. и т.п. Но никак не о том, как мне победить SQL и посчитать нарастающий итог.
Какие могут быть взаиморасчёты и себестоимость на складе?
Под складским учетом я подразумеваю работу торгового предприятия. А вы что?
Взаиморасчеты ведутся с поставщиками и покупателями. Себестоимость товара определяется по FIFO, LIFO или средней.
Конечно я не о приходе/расходе - это смешно
-
Если я пишу складской учет, то я должен думать в терминах складов, поставщиков, взаиморасчетов, количеств, сумм, цен, себестоимости, НДС и т.д. и т.п. Но никак не о том, как мне победить SQL и посчитать нарастающий итог.
Какие могут быть взаиморасчёты и себестоимость на складе?
Под складским учетом я подразумеваю работу торгового предприятия. А вы что?
Под складским учётом я понимаю часть логики работы склада.
Торговое предприятие - это не только склад, это и снабжение, и сбыт (продажи/реализация), и финансы, и кадры, и бухгалтерия, и экономика, и организация, и планирование, и, возможно, транспорт. Как всё это можно "впихнуть" в складской учёт?.. Мне это трудно представить.
Взаиморасчеты ведутся с поставщиками и покупателями. Себестоимость товара определяется по FIFO, LIFO или средней.
Конечно я не о приходе/расходе - это смешно
Взаиморасчёты - это удел финансовой подсистемы. Там ведётся учёт полученного/отгруженного и оплаченного товара, дебиторско-кредиторские задолженности, взаимозачёты и пр.
Себестоимость - это экономический показатель. Одного LIFO/FIFO/AVG тут может быть мало. Часто надо учитывать стоимость доставки (это не всегда тривиально, так как одномоментно доставляется, как правило, много разного товара, и стоимость доставки должна по какой-то методике распределяться между этими товарами). Надо учитывать стоимость хранения, особенно, если при хранении должны создаваться специальные условия, по температуре, влажности, освещённости. Стоимость товаров вышедших из пригодности. Отдельно учёт возвратной/перерабатываемой тары и пр. и пр.
-
В 1С просто привыкли классифицировать задачи по определенным признакам.
Обычно выделяют:
1. Оперативный учет (в народе складской)
2. Бухгалтерский учет (сюда же и финансы и экономику)
3. Производственный учет
4. Сложные периодические расчеты (в народе зарплата)
Такая классификация возникла по причине разной сложности задач. Соответственно и квалификация нужна разная.
На торговом предприятии (за вычетом бухгалтерии и расчетного отдела) все крутится вокруг склада.
Потому и говорим между собой, что задача из разряда складского учета. Грубо говоря легкая задача.
Например на любом производственном предприятии есть склад. Но склад там не занимает центрального положения. Потому мы не говорим о складском учете на таком предприятии. Т.к. это не отражает сути задач. Склад там - это часть производства, следовательно учет производственный.
-
То есть бухучёт? ))
Смотря что имеется ввиду. Если задача озвучена теткой бухгалтером, то да ;D
А если задача озвучена высокоэнергичным физиком?
-
А если задача озвучена высокоэнергичным физиком?
Исключено ;D он для этого слишком "высокоэнергетичен" - не сможет просто себе представить как такие задачи могут вообще заинтересовать кого-ибо... -это удел приматов.
-
Любая реальная практическая проблема, любого реального человека является прикладной.
Но это конечно не повод изобретать автомобиль если физик попросил подкинуть его до работы ;)
Можно долго переливать из пустого в порожнее. Я пользуюсь термином "прикладной" в житейском его понимании. Потому как точно определить границы невозможно.
Любой может назвать разработку операционной системы прикладной задачей и будет относительно прав.
-
Я даже так определю.
Можно задать отношение включения.
Т.е. как только прикладная задача становится частной по отношению к другой прикладной задаче, то она становится системной (при условии что их можно разделить конечно). Если эта внутренняя задача не имеет смысла вне объемлющей, то она не является системной и считается прикладной подзадачей этой большей прикладной задачи.
Прикладной программист всегда работает в терминах предметной логики прикладной задачи и возникающих подзадач.
Системная же задача формулируется в терминах не имеющих непосредственного отношения к проблеме человека. Она формулируется в терминах системы, проблемы которой призвана решить.
-
В 1С просто привыкли классифицировать задачи по определенным признакам.
Обычно выделяют:
1. Оперативный учет (в народе складской)
2. Бухгалтерский учет (сюда же и финансы и экономику)
3. Производственный учет
4. Сложные периодические расчеты (в народе зарплата)
1. Оперативный учёт (в народе) - это не складской учёт, а детальный учёт в каждом подразделении. Например, в сбыте под оперативный учёт попадает, учёт договоров, учёт заявок на товары, учёт запасов (по номенклатуре), учёт отгрузок, учёт оплат, прейскуранты, учёт рабочего времени сотрудников и пр.
2. Финансы и экономика относятся к бухгалтерии, так же баня относится к берёзовому венику... Финансисты распоряжаются платёжными средствами, планируют и контролируют бюджет, контролируют ликвидность платёжных средств, управляют займами и кредитами. Экономисты считают экономические (плановые и фактические) показатели по всем подразделениям.
А бухгалтерия - это маленькая (по функционалу) кладовка, куда сбрасываются документы, которые прошли через функциональные подразделения. Потребность в бухгалтерском учёте у предприятий - нулевая, при нормально оперативном и управленческом учёте.
3. Производственный учёт - это часть оперативного учёта.
4. С этим подробнее разберёмся.
Есть первичная информация, например, те же накладные, сменно-суточные задания, платежи и пр. Эта первичная информация является основой оперативного учёта. В понятие оперативного управления (как и любое другое управление), помимо учёта, входит оперативное планирование (на смену, сутки, неделю, декаду, реже встречается месяц или квартал).
Над первичной информацией настраивается расчётно-экономический уровень, где происходит обработка первичной информации, расчёт экономических показателей, зарплат, себестоимости (цеховой), нормативов остатков и т.п.
Далее надстраивается управленческий учёт (учёт на уровне предприятия). Здесь агрегируется и анализируется информация с первичного и расчётно-экономического уровня. На уровне управления предприятием также есть планирование, и здесь происходит сравнение и анализ плановых и фактических показателей. (с соответствующими орг. выводами).
Ещё выше находится уровень моделирования, где при необходимости вносятся изменения в действующую модель предприятия (добавляются/удаляются подсистемы; устанавливаются/перенаправляются/удаляются связи между подсистемами и пр.).
Такая классификация возникла по причине разной сложности задач. Соответственно и квалификация нужна разная.
На торговом предприятии (за вычетом бухгалтерии и расчетного отдела) все крутится вокруг склада.
Угу, в гипермаркете... например, только складом и занимаются.
Потому и говорим между собой, что задача из разряда складского учета. Грубо говоря легкая задача.
Мне кажется, что Вы частную постановку задачи, несколько неоправданно обобщаете.
Например на любом производственном предприятии есть склад. Но склад там не занимает центрального положения. Потому мы не говорим о складском учете на таком предприятии. Т.к. это не отражает сути задач. Склад там - это часть производства, следовательно учет производственный.
По секрету, там склады - на каждом производственно участке (помимо всего прочего)... только система списания материалов с участков в производство не такая простая, как в магазине.
-
Я понял что у вас есть свой личный взгляд на вещи. Ничего против не имею.
Мной была приведена обычная классификация в среде 1С-ников. Можете не соглашаться с ней, но не нужно учить меня моей профессии.
-
Угу, в гипермаркете... например, только складом и занимаются.
За вычетом бухгалтерии и зарплаты ДА.
Закупили товар на склад. Продали со склада. Посчитали остатки на складе. Переместили между складами. Провели инвентаризацию на складе. Списали со склада. Оценили себестоимость на складе. Разместили по ячейкам на складе. Распределили по партиям на складе.
Все крутится вокруг склада.
Чего там еще то?
-
По секрету, там склады - на каждом производственно участке (помимо всего прочего)... только система списания материалов с участков в производство не такая простая, как в магазине.
Если производственных участков несколько, то конечно и складов несколько.
И чем же система списания сложнее?
-
Я понял что у вас есть свой личный взгляд на вещи. Ничего против не имею.
Мной была приведена обычная классификация в среде 1С-ников. Можете не соглашаться с ней, но не нужно учить меня моей профессии.
Дело не в моих взглядах. Я просто показал уровни, которые реально есть на любом предприятии (даже, если это ИП Пупкина, и он всё держит в голове).
А профессии я Вас не учу, у меня более интересных задач хватает.
-
Эти уровни кроме как унутрях головы вроде нигде и не существуют. ;)
ps Может поделитесь своими взглядами по теме ветки? :)
-
...даже, если это ИП Пупкина, и он всё держит в голове...
Если это собирательный образ успешного но недалекого торгаша, то это не так - как правило в голове у них, помимо базовых понятий, сидят индикаторы бизнеса и его функциональная модель - до абстракций он не опускается ( или поднимается) :D
-
Угу, в гипермаркете... например, только складом и занимаются.
За вычетом бухгалтерии и зарплаты ДА.
Закупили товар на склад. Продали со склада. Посчитали остатки на складе. Переместили между складами. Провели инвентаризацию на складе. Списали со склада. Оценили себестоимость на складе. Разместили по ячейкам на складе. Распределили по партиям на складе.
Все крутится вокруг склада.
Чего там еще то?
Поиск поставщиков, анализ рынка, система торгового обслуживания, анализ потребностей, планирование сбыта и поставок, ППР торгового оборудования и транспорта, те же кадры с системой периодических мероприятий: медосмотров, инструктажей, курсов повышения квалификации и сертификации и пр.
-
По секрету, там склады - на каждом производственно участке (помимо всего прочего)... только система списания материалов с участков в производство не такая простая, как в магазине.
Если производственных участков несколько, то конечно и складов несколько.
И чем же система списания сложнее?
Тем, что помимо списания в производство (по нормативам!), идёт ещё учёт и списание брака, учёт, списание, переработка отходов, учёт выбросов, сливов и т.п.. Там же в материальном учёте на участке - учёт инструмента и его износа (по нормативам и по факту).
-
Эти уровни кроме как унутрях головы вроде нигде и не существуют. ;)
Эти уровни - частное отображение системы с обратными связями. Если нет обратных связей, а в данном случае и управления, то, конечно, всё это не более, чем мои фантазии.
-
ps Может поделитесь своими взглядами по теме ветки? :)
Чем делиться-то? Все эти разговоры вокруг языков, как правило, происходят от того, что не хотят/не умеют моделировать и проектировать. Хороший проект и на ассемблере реализуется, а для плохого - все языки плохие. Это вариант разговора про "танцора и тапочки", IMHO.
-
По секрету, там склады - на каждом производственно участке (помимо всего прочего)... только система списания материалов с участков в производство не такая простая, как в магазине.
Если производственных участков несколько, то конечно и складов несколько.
И чем же система списания сложнее?
Тем, что помимо списания в производство (по нормативам!), идёт ещё учёт и списание брака, учёт, списание, переработка отходов, учёт выбросов, сливов и т.п.. Там же в материальном учёте на участке - учёт инструмента и его износа (по нормативам и по факту).
Я спрашивал о сложности, а не о номенклатуре.
-
По секрету, там склады - на каждом производственно участке (помимо всего прочего)... только система списания материалов с участков в производство не такая простая, как в магазине.
Если производственных участков несколько, то конечно и складов несколько.
И чем же система списания сложнее?
Тем, что помимо списания в производство (по нормативам!), идёт ещё учёт и списание брака, учёт, списание, переработка отходов, учёт выбросов, сливов и т.п.. Там же в материальном учёте на участке - учёт инструмента и его износа (по нормативам и по факту).
Я спрашивал о сложности, а не о номенклатуре.
Именно об этом я и написал. Одно дело списать банку консервов или булку хлеба, совсем другое списывать на основе объёмов производства по нормативам расхода, отходов, выбросов и с учётом брака. Списать одну позицию или десяток рассчитываемых позиций (нормативы тоже могут/должны меняться).
-
Идеальный язык для прикладных программ -- это Дельфы, всё остальное нафиг не надо )))
Точнее, если нужно сваять быстро и с минимальными низкоквалифицированными человеческими ресурсами, причем желательно, что бы на разрабатываемую прогу не накладывавись серьезные требования на поддержку и модернизацию.
-
Угу, в гипермаркете... например, только складом и занимаются.
За вычетом бухгалтерии и зарплаты ДА.
Закупили товар на склад. Продали со склада. Посчитали остатки на складе. Переместили между складами. Провели инвентаризацию на складе. Списали со склада. Оценили себестоимость на складе. Разместили по ячейкам на складе. Распределили по партиям на складе.
Все крутится вокруг склада.
Чего там еще то?
Поиск поставщиков, анализ рынка, система торгового обслуживания, анализ потребностей, планирование сбыта и поставок, ППР торгового оборудования и транспорта, те же кадры с системой периодических мероприятий: медосмотров, инструктажей, курсов повышения квалификации и сертификации и пр.
Я вам о конкретной задаче на предприятии. Вы мне обо всех потребностях предприятия.
Я говорю:
За вычетом бухгалтерии и зарплаты...
Вы мне о кадровом учете.
Я вам о торговле.
Вы мне об анализах, рынка, потребностей и т.д. (Поиск поставщиков - это что такое?)
Само собой весь ваш перечень будет присутствовать в нормальной конторе. Но я разбиваю все задачи на классы. И опираюсь на эти классы, чтобы знать сколько сил и мозгов нужно для решения каждого класса.
Если нужно кодить бух. учет, то делать будет Вася, т.к. он имеет опыт, шарит в бух учете и умеет общаться с бухгалтерами. И Васе пофиг по большому счету чем занимается предприятие, т.к. знаний нужно примерно одно количество/качество для решения любой бухгалтерской задачи.
А вот Петя стажер, он будет кодить складской учет. Ну а самый опытный Сан Саныч будет кодить планирование и зарплату.
Вы же все задачи в кучу и говорите, что вот оно торговое предприятие. Да пофиг чем оно еще занимается. К процессу торговли это не имеет непосредственного отношения. Без планирований и анализов жить можно. Без склада нет.
ИМХО бесполезный разговор.
-
Именно об этом я и написал. Одно дело списать банку консервов или булку хлеба, совсем другое списывать на основе объёмов производства по нормативам расхода, отходов, выбросов и с учётом брака. Списать одну позицию или десяток рассчитываемых позиций (нормативы тоже могут/должны меняться).
Все равно не понял. Кодеру то чем сложнее? Ума нужно больше? По клавиатуре дольше стучать?
-
Именно об этом я и написал. Одно дело списать банку консервов или булку хлеба, совсем другое списывать на основе объёмов производства по нормативам расхода, отходов, выбросов и с учётом брака. Списать одну позицию или десяток рассчитываемых позиций (нормативы тоже могут/должны меняться).
Все равно не понял. Кодеру то чем сложнее? Ума нужно больше? По клавиатуре дольше стучать?
Всё вместе: и ума нужно больше, и стучать дольше. Есть и другие проявления "сложности", ну, да, не суть.
-
Именно об этом я и написал. Одно дело списать банку консервов или булку хлеба, совсем другое списывать на основе объёмов производства по нормативам расхода, отходов, выбросов и с учётом брака.
Еще сложнее. К примеру, при производстве хлебобулочных, тупо списывать по нормативам - чревато. Хотя, я часто подобное встречаю на предприятиях, особенно у новоявленных "эффективных собственников", которые об особенностях технологии производства ничего не знают и знать не хотят. А понятие себестоимости вгоняет их в тихий ужас. Один мне так и заявил "нафига мне себестоимость, мне прибыль нужна". Новоявленные "господа", побывавшие на курсах "экономикс - что это", "эффективное управление предприятием за 3 дня!" и т.п.
-
Именно об этом я и написал. Одно дело списать банку консервов или булку хлеба, совсем другое списывать на основе объёмов производства по нормативам расхода, отходов, выбросов и с учётом брака.
Еще сложнее. К примеру, при производстве хлебобулочных, тупо списывать по нормативам - чревато.
Почему? Вроде обычное рецептурное производство... А как там списание делают.
Хотя, я часто подобное встречаю на предприятиях, особенно у новоявленных "эффективных собственников", которые об особенностях технологии производства ничего не знают и знать не хотят. А понятие себестоимости вгоняет их в тихий ужас. Один мне так и заявил "нафига мне себестоимость, мне прибыль нужна". Новоявленные "господа", побывавшие на курсах "экономикс - что это", "эффективное управление предприятием за 3 дня!" и т.п.
Согласен. Число их - много...
-
Почему? Вроде обычное рецептурное производство... А как там списание делают.
Естественно, сам механизм списания ничем не отличается.
И если есть вменяемый технолог, который не пойдёт на поводу у "эффективного собственника"/руководителя/главного бухгалтера, то никаких проблем.
Дело в том, что мука имеет ряд свойств, в частности влажность, которая существенно влияет на закладку сырья. Калькуляция ( рецептура ) рассчитана исходя из Базовой влажности муки. И хороший технолог перед закладкой измерит текущую влажность, которая может существенно отличаться в мешках одной партии и меняться в зависимости от условий хранения. И скорректирует необходимое количество муки, дрожжей, соли, воды..
Если влажность не учесть и просто измерить муку мешками, тазиками или даже килограммами, то 100% ошибемся с количеством дрожжей и либо тесто не поднимется, либо перекиснет, либо потом готовый хлеб быстро закиснет. Т.е. мало того, что, нарушив технологию производства, мы выпустили некачественный продукт, мы, к тому же, допустили перерасход сырья или недобор, что ведет к недостачам/излишкам и желанию сотрудников ка-то это скрыть.
Если теперь бухгалтерия, обработав сменные отчеты и посчитав выпуск продукции хоть в штуках, хоть в тоннах, и по калькуляции спишет, то будет несоответствии с фактическим расходом сырья.
У меня около 37 производственных предприятия на обслуживании, и только на 7-ми из них учитывают технологию производства при списании муки, и то на 4-х мне удалось доказать руководителям, что должно быть так, а не иначе и построить правильный производственный и учетный процесс. На других слышать об этом не хотят, даже если понимают. Их устраивает существующее положение вещей и возможность поставить "недостачу" на МОТ - как говорил незабвенный классик нет такого преступления, на которое бы не пошел капиталист ради 300% прибыли (((
-
Почему? Вроде обычное рецептурное производство... А как там списание делают.
Естественно, сам механизм списания ничем не отличается.
И если есть вменяемый технолог, который не пойдёт на поводу у "эффективного собственника"/руководителя/главного бухгалтера, то никаких проблем.
Дело в том, что мука имеет ряд свойств, в частности влажность, которая существенно влияет на закладку сырья. Калькуляция ( рецептура ) рассчитана исходя из Базовой влажности муки. И хороший технолог перед закладкой измерит текущую влажность, которая может существенно отличаться в мешках одной партии и меняться в зависимости от условий хранения. И скорректирует необходимое количество муки, дрожжей, соли, воды..
Всё, понял. Спасибо! (я даже вспомнил, о том что мы смотрели мукомольную фабрику, там тоже о влажности шла речь). Это кстати и с ГСМ имеет место быть. Покупают в тоннах, а продают в литрах. А в тонне может быть разное количество литров (зависит от температуры). С этим тоже играют...
На других слышать об этом не хотят, даже если понимают. Их устраивает существующее положение вещей и возможность поставить "недостачу" на МОТ - как говорил незабвенный классик нет такого преступления, на которое бы не пошел капиталист ради 300% прибыли (((
В софтверной индустрии легальная прибыль исчисляется миллионами процентов... Натуральный лохатрон, если разобраться.
-
Почему? Вроде обычное рецептурное производство... А как там списание делают.
Естественно, сам механизм списания ничем не отличается.
И если есть вменяемый технолог, который не пойдёт на поводу у "эффективного собственника"/руководителя/главного бухгалтера, то никаких проблем.
Дело в том, что мука имеет ряд свойств, в частности влажность, которая существенно влияет на закладку сырья. Калькуляция ( рецептура ) рассчитана исходя из Базовой влажности муки. И хороший технолог перед закладкой измерит текущую влажность, которая может существенно отличаться в мешках одной партии и меняться в зависимости от условий хранения. И скорректирует необходимое количество муки, дрожжей, соли, воды..
После размышлений... Списание муки и других ингредиентов в хлебобулочном производстве должно происходить по нормативам, а параметры муки перед применением должны проверяться на рабочем участке. Контроль производства, соблюдения технологии по всей цепочке операций, должен выполняться технологом, который отвечает за конечный результат, его соответствие ГОСТу, ОСТу или ТУ.
То есть, то что Вы написали, - правильно, а мой пример с ГСМ здесь неуместен, там другая ситуация. Списание ГСМ производят с учётом температуры, таким образом, нормы списания ГСМ "плавают".
-
После размышлений... Списание муки и других ингредиентов в хлебобулочном производстве должно происходить по нормативам, а параметры муки перед применением должны проверяться на рабочем участке. Контроль производства, соблюдения технологии по всей цепочке операций, должен выполняться технологом, который отвечает за конечный результат, его соответствие ГОСТу, ОСТу или ТУ.
То есть, то что Вы написали, - правильно, а мой пример с ГСМ здесь неуместен, там другая ситуация. Списание ГСМ производят с учётом температуры, таким образом, нормы списания ГСМ "плавают".
Эти примеры сходны, по своей сути, хотя да, не к ночи будет помянут, скрывается в деталях.
У нас это реализовано так - к номенклатуре можно привязать список параметров, которые могут в дальнейшем использоваться в учетной системе.
Есть документы "Планирование производства", "Выпуск продукции", в котором помимо указания выпускаемой продукции фиксируются параметры сырья текущей закладки. И есть документ "Сменный отчет", который автоматически собирает все выпуски и производит фактический расчет списания сырья с учетом нужных параметров. Естественно, в итоге списание происходит по рецептуре, ведь она составлена в соответствии с ГОСТ или ТУ и менять мы ее не имеем права, имеем право только скорректировать в соответствии с особенностями технологического процесса.
-
Как я понимаю, здесь пример того, как нормативные документы по-разному соотносятся с жизнью... ;) Списание ГСМ учитывает влияющий фактор (температура). А списание ингредиентов - получается, нет (влажность). Если действительно нормы тупо задают рецептуру без учёта потенциальной динамичности ключевых свойств ингредиентов... хотя бы в виде указания, при каких влажности (а также температуре и ещё каких существенных факторах) задана норма и формулировки типа: "при отклонении реальных значений рецептура пересчитывается и используются рассчитанные нормы" (по-хорошему также надо делать ссылку на методики пересчёта... технологи же какую-то модель для этого имеют... скажем, с влажностью она вполне очевидна - суммарное содержание связанной в ингредиентах и доливаемой при приготовлении воды в продукте д.б. в пределах, обеспечивающих качество :) )...
-
Списание ГСМ учитывает влияющий фактор (температура). А списание ингредиентов - получается, нет (влажность). Если действительно нормы тупо задают рецептуру без учёта потенциальной динамичности ключевых свойств ингредиентов... хотя бы в виде указания, при каких влажности (а также температуре и ещё каких существенных факторах) задана норма и формулировки типа: "при отклонении реальных значений рецептура пересчитывается и используются рассчитанные нормы" (по-хорошему также надо делать ссылку на методики пересчёта... технологи же какую-то модель для этого имеют... скажем, с влажностью она вполне очевидна - суммарное содержание связанной в ингредиентах и доливаемой при приготовлении воды в продукте д.б. в пределах, обеспечивающих качество :) )...
Влад, производство это производство, а учет это учет.
Калькуляции относятся не к учету, т.е. задают не правила и нормативы списания, а к технологии производства и задают необходимые условия для производства продукции с конкретными характеристиками.
Т.е. рецептура предназначена для обеспечения системы качества (соответствия продукции заданным параметрам), обеспечения возможности контроля качества. Списание материалов, использованных для производства осуществляется на основании производственных отчетов, а не нормативов. Нормативы списания используются для других целей.
Что касается хлебопекарного производства, то в рецептуре, естественно, все указано относительно базовой влажности муки (есть такое специальное понятие с фиксированным значением). И сама технология производства это учитывает. Я имею ввиду настоящая технология производства, а не её имитация. Кроме того, в хлебопекарном производстве есть такое понятие - "припёк". Припек - это хороший пример того, как делать деньги из воздуха )))
Поэтому списать сырьё, просто посчитав, сколько мы произвели хлеба, хоть в штуках, хоть в тоннах, а затем применить данные из рецептуры ( а так некоторые предприниматели и делают, когда показывают себестоимость производства, чтобы оправдать повышение цен, а контролирующие ничего о технологии производства не знают) не получится - это не будет соответствовать реальности.
Если же не разделять учёт и технологию (производства, хранения, продаж ...), то и возникают такие казусы.
Это не только к гсм и муке относится...
-
Вот я где-то о том же... предметный язык должен предоставлять средства выражения реальных моделей предметки... :) Кстати, калькуляция в моём представлении - это рецептура+удельные стоимости ингредиентов/компонентов... ну и расчёт нормативной цены порции/единицы продукта...
Припёк - да, хороший пример... как "из четырёх ручёв получается одна река" ((С) И. Росохватский)... с эффектами слияния... ;)
-
Как я понимаю, здесь пример того, как нормативные документы по-разному соотносятся с жизнью... ;) Списание ГСМ учитывает влияющий фактор (температура). А списание ингредиентов - получается, нет (влажность).
Не только - нет, а строгое нет. :) Дело в том, что из одинакового веса муки, но с разной влажностью получается разная продукция (разного качества). А если продукция различается, то это уже и разная технология. Которая различается в том числе и составом ингредиентов, нормами их расхода или параметрами.
Если действительно нормы тупо задают рецептуру без учёта потенциальной динамичности ключевых свойств ингредиентов... хотя бы в виде указания, при каких влажности (а также температуре и ещё каких существенных факторах) задана норма и формулировки типа: "при отклонении реальных значений рецептура пересчитывается и используются рассчитанные нормы" (по-хорошему также надо делать ссылку на методики пересчёта... технологи же какую-то модель для этого имеют... скажем, с влажностью она вполне очевидна - суммарное содержание связанной в ингредиентах и доливаемой при приготовлении воды в продукте д.б. в пределах, обеспечивающих качество :) )...
Зря Вы так думаете. В технологических документах строго указываются не только нормы расхода, но и параметры сырья, материалов, комплектующих. Это и называется ТПП - технологическая подготовка производства, со своими ГОСТами, ОСТами и пр. нормативными документами.
К слову, сейчас во всём мире происходит изменение в системах ТПП. Если раньше описание тех. процесса жёстко регламентировало описание каждой стадии (операции), включая не только требования и нормативы к сырью и др. материалам, а также описание передач, то сейчас технологическое описание делится на две части. Один документ описывает последовательность операций и нормативы времени (при описании подсистемы производства, если оно нужно, об этом обязательно поговорим), а второй документ, под названием "регламент" описывает требования к оборудованию (типы, классы точности, критические параметры, оснастка, инструмент), персоналу и материалам. Регламенты могут создаваться под конкретный тех.процесс (выпуск конкретной продукции), но могут быть обобщённые, которые подходят для выпуска разной продукции (по разным тех. процессам). Например, в регламенте может быть сказано обработка трубной заготовки диаметром "Х" из стали "МаркаСтали" использовать резец "ОписаниеРезца", а может быть сказано так: при обработке трубной заготовки диаметром свыше "Х" или твёрдости стали свыше "ПараметрТвёрдости" использовать резец "ОписаниеРезца1", иначе применять резец "ОписаниеРезца2". При этом в регламентах допускается оставлять выбор некоторых параметров (сырья оборудования, персонала) за исполнителем (мастером/сменным инженером и т.п.). Но при этом ответственности за соблюдение технологии с технологов никто не снимает.
Меня всегда удивляло, что вопросам планирования производства, готовности оборудования, обеспеченности материалами, учёта и пр. в автоматизированных системах (MES, APS) уделяется много внимания, а вопросам ТПП - очень мало. Эти вопросы отдаются на откуп сторонним продуктам, в большинстве случаев это CAD/CAM системы (используемые в машино- приборостроении), которые лишены привязки к конкретному производству и тем более к контролю за выпуском продукции, планированию выпуска и пр. Между тем качественное описание тех.процесса очень трудоёмкий и, при этом, хорошо формализованный процесс. А само описание тех. процесса ключевой элемент в организации производства.
-
Как я понимаю, здесь пример того, как нормативные документы по-разному соотносятся с жизнью... ;) Списание ГСМ учитывает влияющий фактор (температура). А списание ингредиентов - получается, нет (влажность).
Не только - нет, а строгое нет. :) Дело в том, что из одинакового веса муки, но с разной влажностью получается разная продукция (разного качества). А если продукция различается, то это уже и разная технология. Которая различается в том числе и составом ингредиентов, нормами их расхода или параметрами.
Вот это интересно. Т.е. если мы, владея моделью предметки, хотим заложить варианты техпроцесса для приведения к заданному качеству при допустимых (для начала - ессно, хотя бы учтённых в модели :) ) изменениях начальных/граничных условий - то их всегда надо понимать не как случаи одного техпроцесса, а как разные техпроцессы?..
...
Если действительно нормы тупо задают рецептуру без учёта потенциальной динамичности ключевых свойств ингредиентов... хотя бы в виде указания, при каких влажности (а также температуре и ещё каких существенных факторах) задана норма и формулировки типа: "при отклонении реальных значений рецептура пересчитывается и используются рассчитанные нормы" (по-хорошему также надо делать ссылку на методики пересчёта... технологи же какую-то модель для этого имеют... скажем, с влажностью она вполне очевидна - суммарное содержание связанной в ингредиентах и доливаемой при приготовлении воды в продукте д.б. в пределах, обеспечивающих качество :) )...
Зря Вы так думаете. В технологических документах строго указываются не только нормы расхода, но и параметры сырья, материалов, комплектующих. Это и называется ТПП - технологическая подготовка производства, со своими ГОСТами, ОСТами и пр. нормативными документами.
Не, я немного не о том. Что они по-нормальному указываются - это я знаю. :) Вопрос в другом - в "плохом" на мой взгляд НД нормы м.б. заданы чересчур жёстко относительно реальности. И не указано, что делать при выходе за нормированные значения. Так что фактически технолог/производственник часто находятся в реальности, не предусмотренной составителем НД... ;)
...
К слову, сейчас во всём мире происходит изменение в системах ТПП. Если раньше описание тех. процесса жёстко регламентировало описание каждой стадии (операции), включая не только требования и нормативы к сырью и др. материалам, а также описание передач, то сейчас технологическое описание делится на две части. Один документ описывает последовательность операций и нормативы времени (при описании подсистемы производства, если оно нужно, об этом обязательно поговорим), а второй документ, под названием "регламент" описывает требования к оборудованию (типы, классы точности, критические параметры, оснастка, инструмент), персоналу и материалам. Регламенты могут создаваться под конкретный тех.процесс (выпуск конкретной продукции), но могут быть обобщённые, которые подходят для выпуска разной продукции (по разным тех. процессам). Например, в регламенте может быть сказано обработка трубной заготовки диаметром "Х" из стали "МаркаСтали" использовать резец "ОписаниеРезца", а может быть сказано так: при обработке трубной заготовки диаметром свыше "Х" или твёрдости стали свыше "ПараметрТвёрдости" использовать резец "ОписаниеРезца1", иначе применять резец "ОписаниеРезца2". При этом в регламентах допускается оставлять выбор некоторых параметров (сырья оборудования, персонала) за исполнителем (мастером/сменным инженером и т.п.). Но при этом ответственности за соблюдение технологии с технологов никто не снимает.
...
Вот это дело... давно пора... :)
Кстати, это лишь отражение жизни - на опыте производства в время войны можно понять, скажем...
Насчёт откупа конструкторским приложениям - читая доку на них, можно понять, что это во многом из-за сложившегося представления о разделении функций между классами пакетов автоматизации предприятий. Когда есть система "конторская" и "цеховая"... ;) Возможно, правильным было бы другое подразделение - на среды разработки и исполнения (понятно, что та и другая включает элементы и "конторы", и "цеха"). Т.е. аналогично ИТ-системам, вообще говоря...
Между прочим, это можно проследить у того же Грабина - хотя бы в описании скоростного метода в его реализации... когда роли конструктора и технолога не соединили, а связали без лишних "административных барьеров"...
-
Как я понимаю, здесь пример того, как нормативные документы по-разному соотносятся с жизнью... ;) Списание ГСМ учитывает влияющий фактор (температура). А списание ингредиентов - получается, нет (влажность).
Не только - нет, а строгое нет. :) Дело в том, что из одинакового веса муки, но с разной влажностью получается разная продукция (разного качества). А если продукция различается, то это уже и разная технология. Которая различается в том числе и составом ингредиентов, нормами их расхода или параметрами.
Вот это интересно. Т.е. если мы, владея моделью предметки, хотим заложить варианты техпроцесса для приведения к заданному качеству при допустимых (для начала - ессно, хотя бы учтённых в модели :) ) изменениях начальных/граничных условий - то их всегда надо понимать не как случаи одного техпроцесса, а как разные техпроцессы?..
Если на выходе имеем разную продукцию то, да, это разные тех. процессы.
...
Если действительно нормы тупо задают рецептуру без учёта потенциальной динамичности ключевых свойств ингредиентов... хотя бы в виде указания, при каких влажности (а также температуре и ещё каких существенных факторах) задана норма и формулировки типа: "при отклонении реальных значений рецептура пересчитывается и используются рассчитанные нормы" (по-хорошему также надо делать ссылку на методики пересчёта... технологи же какую-то модель для этого имеют... скажем, с влажностью она вполне очевидна - суммарное содержание связанной в ингредиентах и доливаемой при приготовлении воды в продукте д.б. в пределах, обеспечивающих качество :) )...
Зря Вы так думаете. В технологических документах строго указываются не только нормы расхода, но и параметры сырья, материалов, комплектующих. Это и называется ТПП - технологическая подготовка производства, со своими ГОСТами, ОСТами и пр. нормативными документами.
Не, я немного не о том. Что они по-нормальному указываются - это я знаю. :) Вопрос в другом - в "плохом" на мой взгляд НД нормы м.б. заданы чересчур жёстко относительно реальности. И не указано, что делать при выходе за нормированные значения. Так что фактически технолог/производственник часто находятся в реальности, не предусмотренной составителем НД... ;)
Что делать - известно, контролировать полученную продукцию на соответствие требованиям стандарта на продукцию (ГОСТ, ОСТ, ТУ). О любом отклонении по любому параметру производитель должен ставить в известность потребителя.
...
К слову, сейчас во всём мире происходит изменение в системах ТПП.
...
Вот это дело... давно пора... :)
Кстати, это лишь отражение жизни - на опыте производства в время войны можно понять, скажем...
Дело не только в "войне", сейчас распространяется т.н. "тюнинг", когда продукция дорабатывается под требования заказчика. Это, в частности, означает, что последние стадии производства не могут быть строго определены в рамках тех.процесса (одному нужен кожаный салон в автомобиле, другому велюровый, третьему... с GPS).
Насчёт откупа конструкторским приложениям - читая доку на них, можно понять, что это во многом из-за сложившегося представления о разделении функций между классами пакетов автоматизации предприятий. Когда есть система "конторская" и "цеховая"... ;) Возможно, правильным было бы другое подразделение - на среды разработки и исполнения (понятно, что та и другая включает элементы и "конторы", и "цеха"). Т.е. аналогично ИТ-системам, вообще говоря...
Между прочим, это можно проследить у того же Грабина - хотя бы в описании скоростного метода в его реализации... когда роли конструктора и технолога не соединили, а связали без лишних "административных барьеров"...
Нет, объединять их не надо, это совсем разные взгляды, но сопрягать нужно обязательно, с помощью ПО, в частности. В машиностроении большая проблема из-за того, что изменения сделанные конструкторами с большими запозданиями отражаются в тех. процессе.
-
...
Если на выходе имеем разную продукцию то, да, это разные тех. процессы.
Ну, и если одну (как в обсуждавшемся случае - хлеб конкретного вида и заданного качества) - то всё-таки ТП понимается как один... но д.б. вариантным под учтённые вариации предмета/средств/условий труда?..
...
Что делать - известно, контролировать полученную продукцию на соответствие требованиям стандарта на продукцию (ГОСТ, ОСТ, ТУ). О любом отклонении по любому параметру производитель должен ставить в известность потребителя.
Это тоже важная сторона дела. А делать-то что... если отклонение парируемое в реальности с сохранением качества, но превышающее нормативное?.. только извещать или всё-таки выпускать продукцию?..
...
... , сейчас распространяется т.н. "тюнинг", когда продукция дорабатывается под требования заказчика. Это, в частности, означает, что последние стадии производства не могут быть строго определены в рамках тех.процесса (одному нужен кожаный салон в автомобиле, другому велюровый, третьему... с GPS).
А это не тот вопрос, что решается введением понятия "исполнение" и вариантов ТП по исполнениям?..
Хотя тут, наверное, возникает и "философский" вопрос - до каких пределов мы можем считать изменившийся продукт исполнением существующего, а не новым самостоятельным?..
...
Нет, объединять их не надо, это совсем разные взгляды, но сопрягать нужно обязательно, с помощью ПО, в частности. В машиностроении большая проблема из-за того, что изменения сделанные конструкторами с большими запозданиями отражаются в тех. процессе.
Вот именно, что Грабиным так и было сделано: http://forum.oberoncore.ru/viewtopic.php?p=44068#p44068 - технолог включён в конструирование и побуждает конструктора повысить технологичность.
А про современность - думаю, потому-то в "цеховые" решения наряду с САПР-К стали включать САПР-Т (часто интегрируя через приложения управления инженерными данными - как тот же АСКОН, упомянутый здесь (http://forum.oberoncore.ru/viewtopic.php?p=73666#p73666))... Вероятно, Вы видите решение несколько иначе (кстати, заметим, что они ввели элементы WF-моделирования на Паскале... интересно, как при этом описываются совместно протекающие процессы ;) )?..
-
...
Если на выходе имеем разную продукцию то, да, это разные тех. процессы.
Ну, и если одну (как в обсуждавшемся случае - хлеб конкретного вида и заданного качества) - то всё-таки ТП понимается как один... но д.б. вариантным под учтённые вариации предмета/средств/условий труда?..
Каждый тех. процесс имеет на выходе конкретную продукцию (продукт или услугу). Но одна и та же продукция может быть произведена по разным тех. процессам. В описании тех. процесса допускаются различные замены, прежде всего, материалов и оборудования (хотя даже отдельные операции могут быть необязательными). Наверное, надо обсудить подсистему "Производство", чтобы снять такие вопросы.
...
Что делать - известно, контролировать полученную продукцию на соответствие требованиям стандарта на продукцию (ГОСТ, ОСТ, ТУ). О любом отклонении по любому параметру производитель должен ставить в известность потребителя.
Это тоже важная сторона дела. А делать-то что... если отклонение парируемое в реальности с сохранением качества, но превышающее нормативное?.. только извещать или всё-таки выпускать продукцию?..
Выпускать (если покупать будут) и извещать (обязательно).
...
... , сейчас распространяется т.н. "тюнинг", когда продукция дорабатывается под требования заказчика. Это, в частности, означает, что последние стадии производства не могут быть строго определены в рамках тех.процесса (одному нужен кожаный салон в автомобиле, другому велюровый, третьему... с GPS).
А это не тот вопрос, что решается введением понятия "исполнение" и вариантов ТП по исполнениям?..
Хотя тут, наверное, возникает и "философский" вопрос - до каких пределов мы можем считать изменившийся продукт исполнением существующего, а не новым самостоятельным?..
Каждый вид продукции обладает уникальными значениями ключевых характеристик. Изменение любой ключевой характеристики создаёт подвид данной продукции или новую продукцию. Какие характеристики являются ключевыми для конкретного вида продукции решает потребитель. Аналитики обследуют желаемые потребителями значения этих характеристик и на основании этого анализа производится моделирование нового вида продукции.
...
Нет, объединять их не надо, это совсем разные взгляды, но сопрягать нужно обязательно, с помощью ПО, в частности. В машиностроении большая проблема из-за того, что изменения сделанные конструкторами с большими запозданиями отражаются в тех. процессе.
Вот именно, что Грабиным так и было сделано: http://forum.oberoncore.ru/viewtopic.php?p=44068#p44068 - технолог включён в конструирование и побуждает конструктора повысить технологичность.
А про современность - думаю, потому-то в "цеховые" решения наряду с САПР-К стали включать САПР-Т (часто интегрируя через приложения управления инженерными данными - как тот же АСКОН, упомянутый здесь (http://forum.oberoncore.ru/viewtopic.php?p=73666#p73666))... Вероятно, Вы видите решение несколько иначе (кстати, заметим, что они ввели элементы WF-моделирования на Паскале... интересно, как при этом описываются совместно протекающие процессы ;) )?..
Подход к технологии со стороны конструкторов был предсказуем в машиностроительных отраслях, но это не совсем корректно (аналогично тому, как описывать склад с помощью бухгалтера). Тем паче, что описание тех. процесса важно не само по себе, после привязки к производству, оно используется в планировании. Примером того, почему конструкторский взгляд на технологию не совсем корректен, служит тот факт, что конструктора не задумываются об отходах, браке и пр. Например, в изделии используется 4 крепёжных элемента, конструктор и задаст (совершенно справедливо!), что для сборки изделия необходимо иметь 4 таких крепёжных детали. Но технолог, в отличие от конструктора, знает, что в норматив надо заложить не 4, а 5 крепёжных элементов, поскольку в среднем один элемент из 4-х будет не годен (или сломан, во время установки). Если начать планировать по конструкторским нормативам, то производство просто встанет из-за нехватки этих крепёжных изделий.
Что касается подключения технологов к конструированию, то правильнее всё же, на мой взгляд, проведения технологической экспертизы конструкторского решения. Другое дело, что конструкторское решение - это не обязательно комплект конструкторской документации, это может быть эскизный набросок какой-то детали или узла. То есть, привлекать технологов можно не в момент окончания конструирования, а тогда, когда найдено какое-то принципиальное решение. Привлечение для экспертизы - это одно, а постоянное включение технолога в конструкторский коллектив - это совсем другое.
-
В 1С просто привыкли классифицировать задачи по определенным признакам.
Обычно выделяют:
1. Оперативный учет (в народе складской)
2. Бухгалтерский учет (сюда же и финансы и экономику)
3. Производственный учет
4. Сложные периодические расчеты (в народе зарплата)
У меня почему-то в мозгах отложилась другая классификация 1С:
1. Оперативный учет (связанный не только со складом, но и с финансами, производством и т.д.) - основной учет для деятельности любого предприятия.
2. Бухгалтерский (плюс налоговый) - основанный на плане счетов и проводках (нужен только для отчетности перед государством)
3. Расчеты (может тут есть еще что-то кроме зарплаты, но я с таким не сталкивался)
Это вроде бы более соотносится со взглядами Alexus.
Конечно (1) можно заменить и бух. проводками (2), но это будет все же менее оптимально в плане аналитик и прочего
-
Угу, в гипермаркете... например, только складом и занимаются.
За вычетом бухгалтерии и зарплаты ДА.
Закупили товар на склад. Продали со склада. Посчитали остатки на складе. Переместили между складами. Провели инвентаризацию на складе. Списали со склада. Оценили себестоимость на складе. Разместили по ячейкам на складе. Распределили по партиям на складе.
Все крутится вокруг склада.
Чего там еще то?
Как минимум взаиморасчеты с поставщиками (а седовательно и деньги - финансы). Причем нужно это в первую очередь не бухгалтерии. Как интересно без денег будет закупаться товар?
-
Взаиморасчеты кодить не сложнее склада. Это один уровень сложности. Приход, расход и остаток. От склада отличается только терминологией. Неужели это так сложно понять?!
Еще раз чтобы было понятно. Я говорю о взгляде кодера на задачи. Склад, взаиморасчеты, резервы, учет спецодежды и т.д. и т.п. Все это один класс задач. Методика везде одна и та же. По сути все это не отличается от складского учета. Мне лень объяснять почему. Разница только в терминах. Для кодера это все в сухом остатке складской учет.
-
Взаиморасчеты кодить не сложнее склада. Это один уровень сложности. Приход, расход и остаток. От склада отличается только терминологией. Неужели это так сложно понять?!
Еще раз чтобы было понятно. Я говорю о взгляде кодера на задачи. Склад, взаиморасчеты, резервы, учет спецодежды и т.д. и т.п. Все это один класс задач. Методика везде одна и та же. По сути все это не отличается от складского учета. Мне лень объяснять почему. Разница только в терминах. Для кодера это все в сухом остатке складской учет.
Всё правильно.
Весь спектр задач раскладывается в такой последовательности:
- первичная информация
- расчётно-экономические показатели
- аналитика
- моделирование
Методики расчётов могут быть одинаковыми, но могут и различаться. Не надо пытаться свести всё к одной методике, но и многообразия порождать тоже не надо. Принципы бухгалтерского учёта применимы только к бухгалтерскому учёту, в связи с его специфичностью. Применение их вне бухгалтерского учёта сопряжены с избыточной сложностью (следствие "упрощенчества").
-
Взаиморасчеты кодить не сложнее склада. Это один уровень сложности. Приход, расход и остаток. От склада отличается только терминологией. Неужели это так сложно понять?!
Я и не спорю, поэтому все же точнее термин Оперативный учет (а не складской). Именно так у 1С и принято. И не надо было выделять отдельно производство. Если есть понятное ТЗ, то кодировать его не сложнее чем склад. А также не надо было только финансы относить на бухгалтерию, это не одно и тоже. Бухгалтерия учитывает все, и склад и финансы, и производство (но уже постфактум, неоперативно, сначала важен количественный и суммовой учет - оперативный, а потому уже на какие счета бухгалтерии все это пойдет).
А с тем что 1С достаточно адекватно представила абстракции согласен. Вот только партионный учет меня всегда удивлял, но сейчас РАУЗ появилась (не знаю, идеал ли это, но во многом лучше партионного учета).
-
...
Что касается подключения технологов к конструированию, то правильнее всё же, на мой взгляд, проведения технологической экспертизы конструкторского решения. Другое дело, что конструкторское решение - это не обязательно комплект конструкторской документации, это может быть эскизный набросок какой-то детали или узла. То есть, привлекать технологов можно не в момент окончания конструирования, а тогда, когда найдено какое-то принципиальное решение. Привлечение для экспертизы - это одно, а постоянное включение технолога в конструкторский коллектив - это совсем другое.
Да, тут вспоминается такой пример (http://grafit-basis.narod.ru/L1/nec_ask_que.html#sdfootnote6anc) (кстати, тоже из его практики) - Вы что-то подобное имели в виду под экспертизой?..
-
...
Что касается подключения технологов к конструированию, то правильнее всё же, на мой взгляд, проведения технологической экспертизы конструкторского решения. Другое дело, что конструкторское решение - это не обязательно комплект конструкторской документации, это может быть эскизный набросок какой-то детали или узла. То есть, привлекать технологов можно не в момент окончания конструирования, а тогда, когда найдено какое-то принципиальное решение. Привлечение для экспертизы - это одно, а постоянное включение технолога в конструкторский коллектив - это совсем другое.
Да, тут вспоминается такой пример (http://grafit-basis.narod.ru/L1/nec_ask_que.html#sdfootnote6anc) (кстати, тоже из его практики) - Вы что-то подобное имели в виду под экспертизой?..
Да. Инженер-конструктор отвечает на вопрос, что (нужно сделать)? А инженер-технолог отвечает на вопрос, как (можно сделать)? "Что" и "Как" имеют внутреннюю взаимосвязь, где первый вопрос (что) первичен (по времени), второй вопрос (как) возникает, после того, как получен ответ на первый вопрос. Если допустить обратное влияние (от технолога к конструктору), то получаем типичную обратную связь, которая позволяет улучшить технологические параметры изделия/продукции/услуги. Поэтому технологическая предпроизводственная экспертиза может иметь положительный эффект. При этом области компетенции конструктора и технолога не должны пересекаться (технолог не должен вмешиваться в работу конструктора и, наоборот, конструктор не должен вмешиваться в работу технолога).
Однако замечу, что, в общем случае, обратная связь не всегда даёт положительный эффект. В некоторых ситуациях отказ от обратной связи может спасти систему от саморазрушения. ("лучшее - враг хорошего").
-
Пример использования Lua:
http://habrahabr.ru/post/149857/ (http://habrahabr.ru/post/149857/)
-
Пример использования Lua:
http://habrahabr.ru/post/149857/ (http://habrahabr.ru/post/149857/)
ох , у меня студент- первокурсник сделал скриптование GULPa и традиционный API интерфейс для физиков - так что свидетельствую Луа достаточно хорош для этого, одна проблема.. появилась зависимость на .NET что не есть гуд в общем случае.
-
Пример использования Lua:
http://habrahabr.ru/post/149857/ (http://habrahabr.ru/post/149857/)
ох , у меня студент- первокурсник сделал скриптование GULPa и традиционный API интерфейс для физиков - так что свидетельствую Луа достаточно хорош для этого, одна проблема.. появилась зависимость на .NET что не есть гуд в общем случае.
Я не знаю что такое gulp, но lua от .net'а никак не зависит.
-
Пример использования Lua:
http://habrahabr.ru/post/149857/ (http://habrahabr.ru/post/149857/)
ох , у меня студент- первокурсник сделал скриптование GULPa и традиционный API интерфейс для физиков - так что свидетельствую Луа достаточно хорош для этого, одна проблема.. появилась зависимость на .NET что не есть гуд в общем случае.
Я не знаю что такое gulp, но lua от .net'а никак не зависит.
1. софтина на 300000 f90 строк для расчетов (фтт-шники, химики, материаловеды). http://projects.ivec.org/gulp/ (http://projects.ivec.org/gulp/)
2. Я тоже так думал....блин :D
-
" LuaInterface" - едрить его...
-
2. Я тоже так думал....блин :D
В смысле? А что там думать то? Вон у меня исходники луа лежат. Голимая сишечка. Встраивай в любое сишное приложение хоть под макосью, хоть под андроидом или там десктопным линуксом. .net там вообще никаким боком.
-
я же сказал - LuaInterface (ему понадобился) - Алексей, я же сказал это ПЕРВОКУРСНИК. правда через неделю будет второкурсником, но это не суть..
-
я же сказал - LuaInterface (ему понадобился) - Алексей, я же сказал это ПЕРВОКУРСНИК. правда через неделю будет второкурсником, но это не суть..
Luainterface это не причина, а следствие - это ведь всего лишь биндинг луавского рантайма для c#. Оно не понадобилось бы если бы у вас там чего-то стороннего на шарпе не было (чего-то самоценного то есть).
Впрочем, какие его годы? :-)
-
Luainterface это не причина, а следствие....
Разумеется ДА - это следствие слабости его навыков и знания ОС (раз использует доступ к системным обьектам через NET - инфраструктуру...) Но естественно , в этой работе я ставил упор на другое - конечный результат. В любом случае, опыт для него полезный - решение задачи заведомо превышающий его уровень развития практически во всех областях. Но увы ЕГО решение оказалось с "побочным эффектом" (хотя я ему говорил о нежелательности появления подобного... но видать в его видении проекта этот аспект занял незначительную нишу).