Круто. А как все же решили задачу заливки контента в миллион позиций на сайт? У нас объем был не так велик, но все равно мы делали «двойные» таблицы (с активной номенклатурой и номенклатурой для замены), заливали в «20» потоков (по числу ном. групп). А потом аккуратно все меняли, с учетом того, что у пользователей в текущей корзине \ заказах. Самое неприятное было с той номенклатурой, которая с одной стороны, выходит из ассортимента, а с другой висит в корзине…
Это обманчивое впечатление. 1С не пряник, но я работал с тем же DAX. Они ГОД делали учет счет-фактур (это был 12 год вроде и большие изменения в законодательстве). И вот после этого с DAX работать перестал. Хотя платформа там одна из лучших.
Да, платформа у них не самая лучшая и нафига делать встроенный механизм расчета уравнений =))
«Я понимаю, на 1с писать Фейсбук никто не станет, но все же просить под столько клиентов воооот такую по мощности железку — кажется, об оптимизации разговора нет в принципе.»
на 5000 юрезов в 1С нужен что то типа супер-дома. Правда тот же DAX на 5000 пользователей стоит как 10 таких супер-домов =)))
«Сейчас в эту дверь войдёт пингвин в сомбреро. Зачем он пришёл и что он скажет?»
Могу я задать уточняющие вопросы по ТЗ, извините по пингвину?
1. Кто является Спонсором Проекта?
2. Есть ли у него четкое представление, какого цвета и размера будет пингвин? Или нам нужно подобрать среднестатистического пингвина?
3. Если требуется сомбреро, логично, что он не будет работать на стройке? А если будет, может под сомбреро мы пристроим заплатку, ой, строительную каску?
4…
«По стоимости рабочих мест и лицензий нельзя все сказать так однозначно, есть определенная вариативность»
Спасибо. В «мое время» был большой Excel с прайсом.
«Значит кому-то эта информация была нужна.»
Задач много. Отслеживать гарантию, например. Для чего в отгрузочных документов должны быть пробиты серийники. Отслеживание отсрочки платежа (читай комиссия). И т.д.
«С пачкордами такая же ситуация – для чего вы вводили отдельные артикулы?»
Потому что есть 3 системных интегратора, для которых важен цвет. И большая часть покупателей использует артикулы производителя и им не хочется принимать товар по «левым» штрих-кодам и артикулам.
«Кстати, система позволяет вести все позиции под одним артикулом с указанием аналитики Цвет. Этот вариант скорее всего облегчил бы вам жизнь в описанной ситуации.»
Может. Но аналитик всего 9 (можно больше но там идет ограничения по индексации). Склад, ячейка, ГТД, НДС, и т.д. много важнее…
И опять задача перерезервирования по аналитикам. Потому что на складе лежат 20 коробок с пачкордами и открыты белые и желтые и по ним еще есть остаток, а выписаны зеленые. Открывать лишнюю коробку склад не хочет. И отгружает желтые и белые.
«А что не так с поддержкой ТСД в DAX?»
в 3.0, 4.0, 2012 ее не было от слова совсем. Например задача собрать заказ на ТСД, когда ТСД должен управлять кладовщиком… вообщем стандартные складские задачи.
Интересно, а сколько стоит рабочее место? Оно тоже стало именным? в DAX стоило 3000 евро за именного пользователя + обязательная поддержка каждый год.
С DAX я работал давно. Но что бесило, так это отсутствие развития функционала 3,4,2012 версии были практически идентичными, за редким исключением (например функциональность СФ. Которую пилили долго и печально).
Например, перерезервирование. Когда вам нужно отгрузить товар с уникальным серийником, но работник склада, не должен его искать, а просто взять первый из ячейки, хотя бы потому что в ячейке 10 коробок с оперативной памятью, и не перебирать их нет ни какого смысла. Но учет нужно вести именно по серийникам. Причем если вы взяли память, которая лежит под другим резервом, они должны «поменяться местами».
А совсем смешно было с пачкордами, которые есть белые, жёлтые, серые, синие… у каждого свой артикул. Но почти для всех заказчиков «моновсеравно» какой цвет будет отгружен… А вот для склада нет. Они не хотят отгружать последнюю коробку желтых. Потому что есть 3 заказчика, для которых важен цвет =))) И опять перерезервирование по заменителям…
А поддержка ТСД? Ну что стоило сделать ее стандартной. DAX очень хорошо переваривает очень большие склады. Замечательно переваривает. Но ТСД?
И вот эта «доработки» шагали из версии в версию. А микрософт был абсолютно не заинтересован в включении ее, да и многих других, в продукт.
Как интересно сейчас, появилась поддержка ТСД? А смена резервов? Или как раньше у интегратора есть свой слой, который закрывает данные пробелы?
«К примеру, счётчики с удалённым контролем показаний по электролинии, или даже через модуль мобильной связи. „
Вот это очень интересно. Например, как наиболее дешево уметь опрашивать счетчики удаленно (или находясь рядом с ним, к-нить девайсом) в поселке на 2 трансформатора и 100 домов?
Итак, Устав проекта более статичен, чем План управления проектом. Он определяет суть самого проекта, он есть распоряжение от Заказчика (или Спонсора) к Руководителю проекта (далее «РП»)
Мы начинали с фиксации нарушений. Т.е. для каждой задачи выполняемой в Проекте, фиксируются любые отклонения.
Потом отклонения нормировались, ранжировались, определялись стратегии управления.
Ну например (из очень старого проекта):
1. Нет ошибки. Заказчик отозвал ошибку сам.
2. Нет разрешение на перенос, обращение закрыто Заказчиком
3. Ошибка переноса
4. Проверка того, что не передавалось
5. Не отражены \ не приняты затраты Заказчиком
6. Требование в обоснование затрат
7. Грубость Заказчика
8. Оскорбления Заказчиком
9. Решение по телефону
10. Игнорирование изменения рамок при проверке
11. Изменение рамок Заказчиком
12. Расширение первоначальных рамок Заказчиком
13. Уточнение рамок Заказчиком
14. Задержка в переносе на рабочую
15. Нарушение сроков выполнения Исполнителем
16. Нереалистичный срок решения
17. Срок выполнения изначально не установлен
18. Срок выполнения изначально не установлен, но Заказчик требует быстрого выполнения
И т.д.
После того, как нарушения стали понятны и устав заработал.
Помнится в 2000 производители материнок начали делать двойной БИОС. Что бы можно было бы откатится до прошлой прошивки. Некоторые особо интересные решения предусматривали обновления прошивок 2-3 способами.
Может и производители касс придут к давно разработанному решению.
— Ubunty-Mate 18.04.1 х64. Настройки стандартные.
— PostgreSQL 11.1 (который про, для 1С). Настройки стандартные.
— intel core duo T5850 2,1Ггц. SSD Samsung 960 evo 250Гб. Ram 3 Гбайта.
pgbench -i -s 100
pgbench -c 10 -T 60: tps = 1169
pgbench -c 99 -T 120: tps = 1113
pgbench -c 99 -T 120 -j2: tps = 1201
pgbench -c 99 -T 120 -j4: tps = 1197
pgbench -i -s 1000
pgbench -c 10 -T 60: tps = 1009
pgbench -c 99 -T 120: tps = 1011
pgbench -c 99 -T 120 -j2: tps = 1064
pgbench -c 99 -T 120 -j4: tps = 1048
Размер базы получился при -s 1000 г-то 15 Гбайт.
Да, платформа у них не самая лучшая и нафига делать встроенный механизм расчета уравнений =))
«Я понимаю, на 1с писать Фейсбук никто не станет, но все же просить под столько клиентов воооот такую по мощности железку — кажется, об оптимизации разговора нет в принципе.»
на 5000 юрезов в 1С нужен что то типа супер-дома. Правда тот же DAX на 5000 пользователей стоит как 10 таких супер-домов =)))
Извините если что, это я так ответил.
Могу я задать уточняющие вопросы по ТЗ, извините по пингвину?
1. Кто является Спонсором Проекта?
2. Есть ли у него четкое представление, какого цвета и размера будет пингвин? Или нам нужно подобрать среднестатистического пингвина?
3. Если требуется сомбреро, логично, что он не будет работать на стройке? А если будет, может под сомбреро мы пристроим заплатку, ой, строительную каску?
4…
Спасибо. В «мое время» был большой Excel с прайсом.
«Значит кому-то эта информация была нужна.»
Задач много. Отслеживать гарантию, например. Для чего в отгрузочных документов должны быть пробиты серийники. Отслеживание отсрочки платежа (читай комиссия). И т.д.
«С пачкордами такая же ситуация – для чего вы вводили отдельные артикулы?»
Потому что есть 3 системных интегратора, для которых важен цвет. И большая часть покупателей использует артикулы производителя и им не хочется принимать товар по «левым» штрих-кодам и артикулам.
«Кстати, система позволяет вести все позиции под одним артикулом с указанием аналитики Цвет. Этот вариант скорее всего облегчил бы вам жизнь в описанной ситуации.»
Может. Но аналитик всего 9 (можно больше но там идет ограничения по индексации). Склад, ячейка, ГТД, НДС, и т.д. много важнее…
И опять задача перерезервирования по аналитикам. Потому что на складе лежат 20 коробок с пачкордами и открыты белые и желтые и по ним еще есть остаток, а выписаны зеленые. Открывать лишнюю коробку склад не хочет. И отгружает желтые и белые.
«А что не так с поддержкой ТСД в DAX?»
в 3.0, 4.0, 2012 ее не было от слова совсем. Например задача собрать заказ на ТСД, когда ТСД должен управлять кладовщиком… вообщем стандартные складские задачи.
Мы писали клиент ТСД с нуля. Долго и печально.
С DAX я работал давно. Но что бесило, так это отсутствие развития функционала 3,4,2012 версии были практически идентичными, за редким исключением (например функциональность СФ. Которую пилили долго и печально).
Например, перерезервирование. Когда вам нужно отгрузить товар с уникальным серийником, но работник склада, не должен его искать, а просто взять первый из ячейки, хотя бы потому что в ячейке 10 коробок с оперативной памятью, и не перебирать их нет ни какого смысла. Но учет нужно вести именно по серийникам. Причем если вы взяли память, которая лежит под другим резервом, они должны «поменяться местами».
А совсем смешно было с пачкордами, которые есть белые, жёлтые, серые, синие… у каждого свой артикул. Но почти для всех заказчиков «моновсеравно» какой цвет будет отгружен… А вот для склада нет. Они не хотят отгружать последнюю коробку желтых. Потому что есть 3 заказчика, для которых важен цвет =))) И опять перерезервирование по заменителям…
А поддержка ТСД? Ну что стоило сделать ее стандартной. DAX очень хорошо переваривает очень большие склады. Замечательно переваривает. Но ТСД?
И вот эта «доработки» шагали из версии в версию. А микрософт был абсолютно не заинтересован в включении ее, да и многих других, в продукт.
Как интересно сейчас, появилась поддержка ТСД? А смена резервов? Или как раньше у интегратора есть свой слой, который закрывает данные пробелы?
Вот это очень интересно. Например, как наиболее дешево уметь опрашивать счетчики удаленно (или находясь рядом с ним, к-нить девайсом) в поселке на 2 трансформатора и 100 домов?
Вот и договаривались с Заказчиком в усилении контроля над проблемными местами. Ну и устав изменить под это.
Мы начинали с фиксации нарушений. Т.е. для каждой задачи выполняемой в Проекте, фиксируются любые отклонения.
Потом отклонения нормировались, ранжировались, определялись стратегии управления.
Ну например (из очень старого проекта):
1. Нет ошибки. Заказчик отозвал ошибку сам.
2. Нет разрешение на перенос, обращение закрыто Заказчиком
3. Ошибка переноса
4. Проверка того, что не передавалось
5. Не отражены \ не приняты затраты Заказчиком
6. Требование в обоснование затрат
7. Грубость Заказчика
8. Оскорбления Заказчиком
9. Решение по телефону
10. Игнорирование изменения рамок при проверке
11. Изменение рамок Заказчиком
12. Расширение первоначальных рамок Заказчиком
13. Уточнение рамок Заказчиком
14. Задержка в переносе на рабочую
15. Нарушение сроков выполнения Исполнителем
16. Нереалистичный срок решения
17. Срок выполнения изначально не установлен
18. Срок выполнения изначально не установлен, но Заказчик требует быстрого выполнения
И т.д.
После того, как нарушения стали понятны и устав заработал.
Может и производители касс придут к давно разработанному решению.