Мой склад или другие saas как работают? если работают конечно.
Тоесть все что вы умеете, это вручную вносить какие-то цифирки и генерировать отчеты? Тогда не называйте себя системой учета.
набивает накладную 99 позиций тут свет погас. И что?
Нормальная учетная система включается и продолжает работу с 99 позиции. Есть така весчь — ACID. Слыхали, нет?
нулевая. Потому что нет никакого XML хранилища.
Есть один большой XML в котором хранится много всего. Он не называется хранилищем поэтому он гарантированно всегда консистентен, я понял.
есть таблица документов в которой одна запись — один документ независимо от его структуры и сложности.
Либо записалось либо нет.
А, тоесть авария в процессе записи даже не рассматривалась. Вот все глупые — начиная от mysql и sqlite и заканчивая oracle и mssql — «они тупые», они че-то тестят, какие-то глупые аббревиатуры пишут, и только я один самый умный «либо записал либо нет вне зависимости от структуры». А заодно и от настроек ОСи, драйверов, винта и прочих обстоятельств.
В целом. Вы просили в начале вашей статьи критику и подсказки о промахах. Но критику вы не воспринимаете и подсказок не понимаете. Не только моих — об XML в этом топике не высказался только ленивый. Опять — все глупые, вы один самый умный? Тогда критику просили-то зачем?
ну не всем нужно подключать торговое оборудование.
Кому и зачем нужна учетная программа для малого бизнеса, которая не умеет работать с торговым оборудованием? В таких случаях ексель любому софту фору даст. Кроме того, как я уже говорил, через два месяца (или год и два месяца — в зависимости от большой политики) в нашей с вами стране любая учетная система должна будет работать как минимум с фискальным регистратором. И да — даже привел реальный сценарий работы с ним.
так прога часть конкретного оборудования на конкретном месте.
Тоесть если надо подключать торговое оборудование, «кросплатформенность» в пролете? Это уже не смешно.
то же что и с чудо 1С. Либо успел сохранить документ либо нет.
На всякий случай напоминаю, что я с 1С не работаю от слова «вообще» и в целом отношусь к этому поделию довольно прохладно. Мягко говоря.
Но интересовало другое — какова вероятность превращения в винигрет XML-хранилища в случае сбоев, в том числе аппаратных? И каким образом получена эта цифра (я о вероятности)? Какие тесты проводились?
Вы же не думаете, что у вас в малом бизнесе везде будут серверные стойки с двумя независимыми входными линями питания и УПС-ами?
Не понимаю проблемы.
Вот когда по вине вашего «либо сохранил либо нет» фирма понесет убытки, или хотя бы кто-то пару раз будет наново вносить накладную на сотню позиций (еще лучше — расходную), вот тут то понимание и придет.
в таком случае нужен драйвер для каждого типа оборудования. Новое оборудование и 1с уже беспомощна.
Как я уже писал, с новым оборудованием все равно идет инструкция по подключению к 1С. А вам (и нам) надо самостоятельно писать драйвер. Без этого ваша (наша) супер-мега-учетная система никому не нужна.
Я думаю один из вариантов — програмулька на делфи, к примеру, которая работает с dll и в другой стороны дергает API.
А как же тогда заявленная кроссплатформенность и опенсорсность?
нет там никаких проблем. опять же речь о малом бизнесе — не бувдет там тысяч запросов в секунду
Зачем тысяч? Вот реальная ситуация. Бух делает отчет. Например, «взаиморасчеты с поставщиком». Менеджер забивает накладную от этого же поставщика. В торговом зале продается тот же товар, который есть в накладной менеджера. Мигает свет из-за коротнувшего холодильника. Фильтры/упсы есть не на каждом компе/свиче. Вопросс — что станется с чудо-XML-ем?
Не знаю насчет 1С, так как сам «работаю» очередную… нет, ни в коем случае не убийцу. Удобный для нас аналог с массой такого чего у 1С никогда не было и не будет, скажем так. Так вот, практически для всего встреченного оборудования есть драйвер/dll с инструкцией настройки под 1С и (иногда по отдельному запросу) описание протокола. Тоесть, либо набор инструкций для «1С-ника», либо писать самому. Мы — пишем сами.
Касаемо того, что сабжевая система предусматривает АРІ для подключения wince — это хорошо. Да вот только во-первых в сканерах штрих-кодов и весах wince нету, а есть только описание последовательностей байтиков да dll-ка. Ну и во-вторых как-то не очень сочетаются между собой слова «современное оборудование» и «wince».
И как раз потому, что хабр — технический форум, мне, как «борцуну с 1С» интересно, как мои соотечественники собираются подключать, например, фискальный регистратор к каждому торговому месту для обеспечения требований законодательства. А в регистраторах — на минуточку — тоже wince нету. А есть протокол и есть нюансы типа «регистратор ответил что чек №123 проведен, но в z-отчете этого чека почему-то нету». И без розруливания этих нюансов учетная система не нужна от слова «совсем».
И это еще не касаясь вопросов реальной многопользовательской работы с гигантским чудо-XML-ем.
Ни разу не встретил слов «сканер штрих-кодов», «ТСД», «кассовый аппарат», «весы» и т.д. Сабжевая система что — принципиально не работает с торговым оборудованием?
Ну, боюсь, что я вашу статистику не сильно улучшу и ничего нового не расскажу. Во-первых, chef/puppet действительно не умеют оркестрацию, насколько мне известно — они просто не для того создавались. Из этого следует, что ни кластер ни просто несколько взаимосвязанных серверов они обновить не смогут. Во-вторых, puppet — не предназначен для деплоя приложений. Да, из-за того что он может управлять конфигурацией пакетного менеджера (и по ряду других причин) с его помощью очень удобно установить или обновить много-много пакетов, в том числе в определенном порядке. Но — это все будет делать не шеф/паппет, а пакетный менеджер.
Вы все это, конечно, и без меня знаете; я просто не хочу потерять контекст беседы.
Так вот. При всем при этом чтобы обновить в определенном порядке взаимосвязанные сервисы на разных нодах, надо все равно изобретать велосипед. Либо как вы описали выше — отдельным процессом менять конфигурацию SCM и потом принудительно дергать агента. Мы склонились к идее пакетировать (deb/msi) разрабатываемый софт и писать его (софт) с учетом возможных неконсистентных состояний. При том новые пакеты викладываются либо во время технологичных окон, либо в периоды минимальной нагрузки на систему.
P.S. Беглый гуглеж говорит, что puppet enterprise умеет какой-то orchestration. В жизни не видел РЕ, так что ничего по этому поводу сказать не могу.
Да-да, мы в курсе о вашем зубе и даже помним что вы обещали продолжение вашей статьи. Неплохо бы выполнить обещание. Без этого… Скажем так, приведенный вами пример я разрулю. При том что опыта работы с паппетом у меня, скажем так, ровно столько, сколько можно научиться самому управляя несколькими десятками не особо сложных серверов.
Да, присоединяются. Примерно так же, как они присоединяются к интернету, например. Вы же не будете утверждать, что интернет монополизировал рынок?
Другими словами, ядро Linux — просто удобный инструмент, который, благодаря лицензионной модели, не пренадлежит какой-то одной корпорации и который все могут использовать.
Ну и, чтобы два раза не вставать — sisco ios ни разу не линукс. Нету под рукой статистических данных, но все же сомневаюсь что под этой ОС работают (всего лишь) единицы процентов сетевого оборудования в мире.
Надо правильно прочесть:
Три, четырнадцать, пятнадцать,
Девяносто два и шесть
Вполне себе от зубов :)
Тоесть все что вы умеете, это вручную вносить какие-то цифирки и генерировать отчеты? Тогда не называйте себя системой учета.
Нормальная учетная система включается и продолжает работу с 99 позиции. Есть така весчь — ACID. Слыхали, нет?
Есть один большой XML в котором хранится много всего. Он не называется хранилищем поэтому он гарантированно всегда консистентен, я понял.
А, тоесть авария в процессе записи даже не рассматривалась. Вот все глупые — начиная от mysql и sqlite и заканчивая oracle и mssql — «они тупые», они че-то тестят, какие-то глупые аббревиатуры пишут, и только я один самый умный «либо записал либо нет вне зависимости от структуры». А заодно и от настроек ОСи, драйверов, винта и прочих обстоятельств.
В целом. Вы просили в начале вашей статьи критику и подсказки о промахах. Но критику вы не воспринимаете и подсказок не понимаете. Не только моих — об XML в этом топике не высказался только ленивый. Опять — все глупые, вы один самый умный? Тогда критику просили-то зачем?
Кому и зачем нужна учетная программа для малого бизнеса, которая не умеет работать с торговым оборудованием? В таких случаях ексель любому софту фору даст. Кроме того, как я уже говорил, через два месяца (или год и два месяца — в зависимости от большой политики) в нашей с вами стране любая учетная система должна будет работать как минимум с фискальным регистратором. И да — даже привел реальный сценарий работы с ним.
Тоесть если надо подключать торговое оборудование, «кросплатформенность» в пролете? Это уже не смешно.
На всякий случай напоминаю, что я с 1С не работаю от слова «вообще» и в целом отношусь к этому поделию довольно прохладно. Мягко говоря.
Но интересовало другое — какова вероятность превращения в винигрет XML-хранилища в случае сбоев, в том числе аппаратных? И каким образом получена эта цифра (я о вероятности)? Какие тесты проводились?
Вы же не думаете, что у вас в малом бизнесе везде будут серверные стойки с двумя независимыми входными линями питания и УПС-ами?
Вот когда по вине вашего «либо сохранил либо нет» фирма понесет убытки, или хотя бы кто-то пару раз будет наново вносить накладную на сотню позиций (еще лучше — расходную), вот тут то понимание и придет.
Как я уже писал, с новым оборудованием все равно идет инструкция по подключению к 1С. А вам (и нам) надо самостоятельно писать драйвер. Без этого ваша (наша) супер-мега-учетная система никому не нужна.
А как же тогда заявленная кроссплатформенность и опенсорсность?
Зачем тысяч? Вот реальная ситуация. Бух делает отчет. Например, «взаиморасчеты с поставщиком». Менеджер забивает накладную от этого же поставщика. В торговом зале продается тот же товар, который есть в накладной менеджера. Мигает свет из-за коротнувшего холодильника. Фильтры/упсы есть не на каждом компе/свиче. Вопросс — что станется с чудо-XML-ем?
Касаемо того, что сабжевая система предусматривает АРІ для подключения wince — это хорошо. Да вот только во-первых в сканерах штрих-кодов и весах wince нету, а есть только описание последовательностей байтиков да dll-ка. Ну и во-вторых как-то не очень сочетаются между собой слова «современное оборудование» и «wince».
И как раз потому, что хабр — технический форум, мне, как «борцуну с 1С» интересно, как мои соотечественники собираются подключать, например, фискальный регистратор к каждому торговому месту для обеспечения требований законодательства. А в регистраторах — на минуточку — тоже wince нету. А есть протокол и есть нюансы типа «регистратор ответил что чек №123 проведен, но в z-отчете этого чека почему-то нету». И без розруливания этих нюансов учетная система не нужна от слова «совсем».
И это еще не касаясь вопросов реальной многопользовательской работы с гигантским чудо-XML-ем.
Вы все это, конечно, и без меня знаете; я просто не хочу потерять контекст беседы.
Так вот. При всем при этом чтобы обновить в определенном порядке взаимосвязанные сервисы на разных нодах, надо все равно изобретать велосипед. Либо как вы описали выше — отдельным процессом менять конфигурацию SCM и потом принудительно дергать агента. Мы склонились к идее пакетировать (deb/msi) разрабатываемый софт и писать его (софт) с учетом возможных неконсистентных состояний. При том новые пакеты викладываются либо во время технологичных окон, либо в периоды минимальной нагрузки на систему.
P.S. Беглый гуглеж говорит, что puppet enterprise умеет какой-то orchestration. В жизни не видел РЕ, так что ничего по этому поводу сказать не могу.
Рано или поздно все равно надо будет переходить на следующую LTS, тогда разбор таких вот мелочей занимает слишком много времени и нервов.
Я не ерничаю, мне действительно интерессно.
лучше написать
Тогда во-первых не надо будет менять скрипт после перехода на другую версию ОС, а во-вторых скрипт будет работать и на классическом debian.
Другими словами, ядро Linux — просто удобный инструмент, который, благодаря лицензионной модели, не пренадлежит какой-то одной корпорации и который все могут использовать.
Ну и, чтобы два раза не вставать — sisco ios ни разу не линукс. Нету под рукой статистических данных, но все же сомневаюсь что под этой ОС работают (всего лишь) единицы процентов сетевого оборудования в мире.