Спасибо, соглашусь со всем, кроме негатива к ответу «Мне в другом месте больше предложили». Для меня бы такой ответ препятствием не стал.
Возможно Вам и не нужно нанимать такого человека, но лишь потому, что с таким типом людей в Вашей команде не принято работать, например. Или Вы не умеете. Или культура другая.
Но для Вас же будет лучше, если человек ответит на этот вопрос именно так. Если это честный ответ (а такой ответ, видимо, честный), то Вы не совершите ошибки в найме.
Магазин: medgadgets.ru. Событие произошло сегодня, и по телефону сотрудники магазина сказали, что предполагают время ожидания 2 дня (что, если так, то полностью меня устраивает). Так что пока к ним претензий у меня нет. Особенно, если для замены мне не придется ехать к ним в Котельники.
Да, а доработка крепления штекера, мне кажется, была бы не лишней.
Закупил сегодня два устройства. И сразу же одно из них потребуется вернуть. Причина: при попытке вставить коннектор в разъем — разъем благополучно отломился вовнутрь устройства.
Во втором устройстве подключение прошло успешно, но вставлять коннектор было страшно, т.к. идет туго а с фотографий понятно, что разъем припаян к плате и ни как не прикреплен к корпусу!
Позвонил в магазин, сказали, что у них уже обращались покупатели с такими проблемами. Напишут Вам и будут ждать.
Во-первых: конечно, я надеюсь на то, что получится быстро заменить устройство без лишней волокиты.
Во-вторых: может быть разъем закрепить с упором в плату или использовать разъем с более мощными силовыми элементами крепления?
Думаю, Вы «невкурили». Статья о том, что до ее прочтения Вы (по крайней мере я уж точно) не смогли бы объяснить даже потенциальную возможность ускорения выборки от order, и свели бы это к неточностям измерения, кэшу и т.д.
Ан нет, есть еще одна не тривиальная причина. Автору — спасибо!
Ну и, если уж быть занудным, причин передать 30 тыс строк с БД я могу придумать десятки.
Хотя я не имею отношения к системе, но, думаю, мое предположение верное.
А именно:
1. т.к. как я понял, цель системы в максимизации прибыли через формулу «минус затраты от запасов плюс цена рисков задержанных заказов».
2. то анализируя потребление товаров в рамках всей компании (а не одного заказа)
3. можно уменьшить резерв практически не увеличив риски задержки сборки.
4. Уменьшение резерва происходит через автоматическое управление заказами у поставщиков
Т.е. в зависимости от предсказуемости и «рваности» потребления а также стоимости риска задержки запасы снизятся в идеале до нуля а в реальности на некоторый процент.
Т.е. никакого противоречия с тем, что какие то резервы остаются — нет. Это только мне очевидно?
Что бы не казалась автору данного комментария, считаю его минимум бесполезным. А что Вы будете делать в таком случае и что Вы ожидаете услышать в ответ?
Сродни вопросу: «а что делать, если товара на складе нет, а его нужно срочно отгрузить?». Что, что — страдать.
Просто для справки: все биржевые учетные системы, а также депозитарного учета и регистраторы работают с учетом в будущем времени. Основная площадка на ММВБ работает в режиме Т+2, когда сделка регистрируется сейчас а приход по ней будет учтен через два дня.
Хейтерство не к статье и не к тому, что человек самостоятельно изучил ЯП, сделал и бесплатно распространяет программу. Это как раз вызывает уважение и благодарность.
Напрягают комментарии. В них автор, с моей предвзятой точки зрения, повышает градус напряжения. Особенно часто встречаются конфликтогены через проявление позиции превосходства.
Тут выше эпичный тред с lair. Не ввязываясь в ценность научной составляющей я присоединюсь к вопросу: в чем ценность этого подхода учета?
Пока сама система похожа на обычный складской учет с функцией «объединения дублей». Или, обычный забалансовый учет. Но, возможно, в концепции есть идея, которая должна получить развитие. Или есть важные отличия, на которые нужно обратить внимание?
Нашел цены в штатах. Кстати NX-1020 более низок по характеристикам, чем, к примеру SuperServer 5028R-WR на E5-1680 v3. У вас в поставках пока, видимо, не отработан Haswell-EP.
Посмотрел на сайте предоставляемое оборудование. Интересуюсь, а есть ли (когда планируются) сервера на E5-1600 серии? У СуперМикро они уже давно поставляются.
Еще, расскажите о политике ценообразования, если мы сами закупим СуперМикровские сервера и захотим использовать Nutanix. Из чего тогда будет складываться стоимость?
А, точно! Сорри, статья в комментах есть, спасибо. Сейчас буду читать. А вот еще вопрос вдогонку. У меня на моих малых потребностях испольуется ESXi 5.5, и одна из проблем — это скорость копирования данных через NFS. При том, что сетевые интерфейсы позволяют копировть 1Гб/с реальная скорость ниже 10Мб/с. Я думал, это моя личная проблема но 12тыс. запросов говорят иначе.
Так вот, суть вопроса. Если вы поставляете свое хранилище в ESXi через NFS, то подтверждаете ли вы проблему низкой производительности NFS и как ее побороли?
Даже так: я бы с удовосльтвием прочел статью про отличие Вас от VSAN. Да и Вам было бы приятно написать ее, особенно если Вы лучше такого именитого вендора по всем параметрам. Если у Вас есть список статей к написанию, поставтье в очередь, плиз :)
Понял. Вендорлок конечно, неприятно, но и к вам я привязан буду чуть более чем полностью.
А можете дать преимущества по техническим характеристикам?
Напимер, может быть у Вас гибкая настройка избыточности хранения или лучшая кеширующая прослойка из SSD?
Сорри за вопрос, я не так хорошо разбираюсь в виртуалзизации, как хотелось бы. Как понимаю, nutanix вынуждает покупать меня их оборудование.
А нет ли решений от поставщиков гипервизоров по распределенной файловой системе? Например, что нибудь от самой vSphere?
В задаче Fifo/Lifo главной проблемой в оперативном списании, наверное можно назвать связывание расхода с приходом один ко многим. Основные подходы в решении: создание промежуточных итогов, хранение связей расхода и приходов.
Такой подход позволяет быстро посчитать себестоимость расхода следующей транзакции, но значительно усложняет работу в случае, если вносятся правки задним числом, или транзакции приходят не по порядку в течении дня и нужно также инициировать пересчет уже совершенных сделок. Также повышает денормализацию и связанность данных в БД, что приводит к эскалации блокировок при реальных нагрузках.
Считаю, что сейчас эту проблему нужно решать не так, как 10 лет назад. А именно, вместо того, чтобы мыслить на уровне реляционной БД с хранением связей и остатков, можно поддерживать списки транзакций актуального периода в оперативной памяти. Например, при нагрузке 1 млн транзакций в час, и предположению, что активный период изменений может составить календарный месяц, ну и пускай 60 байт на запись транзакции, то получается менее 16Gb памяти в потокобезопасной структуре.
При этом в памяти можно делать дорогие операции просмотра всех транзакций 1 клиента по 1 товару от начала периода, в хранилище же помещать только факт совершения транзакции.
Ну вот даже в Вашем примере если бы печатал клиент: при подключении терминала он связывается с ближайшим принтером в процессе установки клиента штатным администратором (который не должен обладать компетенциями в Вашей учетной системе). Клиент печатает на принтер «по умолчанию».
Если печатает сервер печати, то:
1. При установке принтера его нужно как то зарегистрировать на сервере печати.
2. При установке клиента нужно указать, на какой принтер (из зарегистрированных на сервере печати) выдавать печать.
Оба этих действия должен совершить уже не просто админ, а специалист в ERP системе. Т.е., мне кажется, схема усложнилась. А что взамен?
Я честно хочу понять преимущества. В статье сейчас об этом написано следующее:
Изначально решение что называется было «в лоб». Использовался виндовый спулер и печать осуществлялась через стандартные процедуры. Собственно, такое решение продержалось недолго, ровно до того момента, как потребовалось реализовать печать с сервера приложений, а не из клиентского приложения.
Далее статья о том, как Вы героически решали и решили проблемы, связанные с централизованной печатью.
Не плохо. А точно это правильно, что печать идет централизованно?
Мне кажется вот потенциальные проблемы:
А если у сервера приложений вообще нет доступа до принтера пользователя?
Если клиентское приложение уже локально имеет открытый отчет (печатную форму), то не выгодней ли ей самой отвечать за печать децентрализованно, чтобы не нагружать центральный сервер?
Если пользователей много, то можно легко децентрализовать принтеры и каждый печатает на свой принтер (нет проблем поиска своего документа среди чужих). Плюс децентрализованная печать не умрет сразу вся. Плюс, если пользователей много, то у разных пользователей (и их принтеров) свои админы, что децентрализует настройку принтеров.
Возможно Вам и не нужно нанимать такого человека, но лишь потому, что с таким типом людей в Вашей команде не принято работать, например. Или Вы не умеете. Или культура другая.
Но для Вас же будет лучше, если человек ответит на этот вопрос именно так. Если это честный ответ (а такой ответ, видимо, честный), то Вы не совершите ошибки в найме.
Да, а доработка крепления штекера, мне кажется, была бы не лишней.
Во втором устройстве подключение прошло успешно, но вставлять коннектор было страшно, т.к. идет туго а с фотографий понятно, что разъем припаян к плате и ни как не прикреплен к корпусу!
Позвонил в магазин, сказали, что у них уже обращались покупатели с такими проблемами. Напишут Вам и будут ждать.
Во-первых: конечно, я надеюсь на то, что получится быстро заменить устройство без лишней волокиты.
Во-вторых: может быть разъем закрепить с упором в плату или использовать разъем с более мощными силовыми элементами крепления?
P.S. второе устройство работает замечательно.
Ан нет, есть еще одна не тривиальная причина. Автору — спасибо!
Ну и, если уж быть занудным, причин передать 30 тыс строк с БД я могу придумать десятки.
А именно:
1. т.к. как я понял, цель системы в максимизации прибыли через формулу «минус затраты от запасов плюс цена рисков задержанных заказов».
2. то анализируя потребление товаров в рамках всей компании (а не одного заказа)
3. можно уменьшить резерв практически не увеличив риски задержки сборки.
4. Уменьшение резерва происходит через автоматическое управление заказами у поставщиков
Т.е. в зависимости от предсказуемости и «рваности» потребления а также стоимости риска задержки запасы снизятся в идеале до нуля а в реальности на некоторый процент.
Т.е. никакого противоречия с тем, что какие то резервы остаются — нет. Это только мне очевидно?
Сродни вопросу: «а что делать, если товара на складе нет, а его нужно срочно отгрузить?». Что, что — страдать.
Напрягают комментарии. В них автор, с моей предвзятой точки зрения, повышает градус напряжения. Особенно часто встречаются конфликтогены через проявление позиции превосходства.
За статью и программу автору большое спасибо.
Пока сама система похожа на обычный складской учет с функцией «объединения дублей». Или, обычный забалансовый учет. Но, возможно, в концепции есть идея, которая должна получить развитие. Или есть важные отличия, на которые нужно обратить внимание?
Еще, расскажите о политике ценообразования, если мы сами закупим СуперМикровские сервера и захотим использовать Nutanix. Из чего тогда будет складываться стоимость?
Так вот, суть вопроса. Если вы поставляете свое хранилище в ESXi через NFS, то подтверждаете ли вы проблему низкой производительности NFS и как ее побороли?
А можете дать преимущества по техническим характеристикам?
Напимер, может быть у Вас гибкая настройка избыточности хранения или лучшая кеширующая прослойка из SSD?
А нет ли решений от поставщиков гипервизоров по распределенной файловой системе? Например, что нибудь от самой vSphere?
Такой подход позволяет быстро посчитать себестоимость расхода следующей транзакции, но значительно усложняет работу в случае, если вносятся правки задним числом, или транзакции приходят не по порядку в течении дня и нужно также инициировать пересчет уже совершенных сделок. Также повышает денормализацию и связанность данных в БД, что приводит к эскалации блокировок при реальных нагрузках.
Считаю, что сейчас эту проблему нужно решать не так, как 10 лет назад. А именно, вместо того, чтобы мыслить на уровне реляционной БД с хранением связей и остатков, можно поддерживать списки транзакций актуального периода в оперативной памяти. Например, при нагрузке 1 млн транзакций в час, и предположению, что активный период изменений может составить календарный месяц, ну и пускай 60 байт на запись транзакции, то получается менее 16Gb памяти в потокобезопасной структуре.
При этом в памяти можно делать дорогие операции просмотра всех транзакций 1 клиента по 1 товару от начала периода, в хранилище же помещать только факт совершения транзакции.
Если печатает сервер печати, то:
1. При установке принтера его нужно как то зарегистрировать на сервере печати.
2. При установке клиента нужно указать, на какой принтер (из зарегистрированных на сервере печати) выдавать печать.
Оба этих действия должен совершить уже не просто админ, а специалист в ERP системе. Т.е., мне кажется, схема усложнилась. А что взамен?
Я честно хочу понять преимущества. В статье сейчас об этом написано следующее:
Далее статья о том, как Вы героически решали и решили проблемы, связанные с централизованной печатью.
Мне кажется вот потенциальные проблемы:
А если у сервера приложений вообще нет доступа до принтера пользователя?
Если клиентское приложение уже локально имеет открытый отчет (печатную форму), то не выгодней ли ей самой отвечать за печать децентрализованно, чтобы не нагружать центральный сервер?
Если пользователей много, то можно легко децентрализовать принтеры и каждый печатает на свой принтер (нет проблем поиска своего документа среди чужих). Плюс децентрализованная печать не умрет сразу вся. Плюс, если пользователей много, то у разных пользователей (и их принтеров) свои админы, что децентрализует настройку принтеров.
Т.е. зачем вообще централизовать печать?