У 2007 Офиса было несколько неприятных глюков, которые исправили в 10-м.
И, заметьте, я не говорил о глюках. Я говорил о скорости загрузки приложения и о том, насколько адекватно восстанавливается простейшее форматирование.
У меня, например, масса претензий к тому, как на моем документе работают макросы (точнее с какой вероятностью они работают ;) ), но это слегка другой вопрос.
Не угадали. Это обычный docx (который OOXML). Из форматирования там используются стили (без извращений), абзацы и таблицы. Все. Т.е. не используются никакие спец.особенности именно МС Офиса.
Каждый раз, когда выходит новая версия аналога MS Office (конкретно пробовал LibreOffice), я пытаюсь понять, смогу я в нем работать или нет. И пытаюсь загрузить один документ. 64-разрядный Ворд его грузит обычно секунд 10. Аналоги начинают от минуты (на том же оборудовании). Причем за последние 10+ лет ситуация не изменилась. Все делается в Винде.
Ну и то, во что превращается примитивное форматирование документа, обычно заставляет меня забыть об аналогах до выхода следующей большой версии.
Т.е. если надо написать служебку на полстранички — аналог прокатит, а для работы — увы.
Ну и да, рибоновский интерфейс Офиса радикально лучше менюшного интерфейса. Речь про работу.
Понятно, что все ИМХО
Это был комментарий на то, что все, покупаемое Майками — только в унитаз годно (все-таки покупался СУБД уже вполне рабочий).
Ну и ИМХО Винда и ДОС — это не приобретение, а собственная разработка. Но спорить не готов
Нету «сервера лицензирования». У кластера серверов есть «сервис лицензирования» (это не отдельный продукт/софт).
Собственно озвученно вами — важное преимущество программных лицензий: они сочетаются в произвольных комбинациях и видах.
Если у вас клиентская лицензия программная, и она одна (например в случае с электронной поставкой), то имейте в виду, что программная лицензия в клиент-серверном варианте расходуется на каждое подключение к базе. То есть запустить конфигуратор и клиент одновременно по сети уже не получится.
Программная клиентская лицензия может искаться клиентским приложением, а может — раздаваться сервером. В первом случае она работает «на компьютер», во втором — «на сеанс». Т.е. до определенного количества лицензий предлагается возможность, как активировать — по-штучно или всем пакетом. Вот по-штучная активация (когда активируется, по сути, однопользовательская лицензия) позволяет на одной лицензии запускать произвольное количество экземпляров клиентского приложения на компьютере.
Другими словами, если вы активируете 5-ти пользовательскую лицензию на компьютер сервера Предприятия, то у вас смогу работать одновременно не более 5 сеансов (не важно, к одной базе или к нескольким). Но с любого компьютера сети. При условии, что серверу разрешена раздача лицензий. Если вы эту же 5-ти пользовательскую лицензию активируете на 5 различных компах, то у вас смогут работать одновременно 5 человек, каждый из которых может открыть произвольное количество клиентских приложений или конфигураторов на своем компе. Но только с этих 5 компов.
При этом во втором случае будут проблемы с веб-клиентами и мобильными клиентами.
Так потому, что умение управлять деньгами автоматически не приходит с ростом дохода. Если человек умеет только тратить весь доход, то он будет его тратить вне зависимости от размера этого дохода. И, сдается мне, что слово «успешные» не просто так закавычено :)
Ну и понты, как известно, дороже денег.
1. Я все-таки разделяю резервный фонд и досрочку. Т.е. важно иметь подушку безопасности, а после ее формирования все «излишки» вкладывать в досрочку. Я для крупных кредитов (типа ипотеки) использую такую схему: стараюсь с самого начала делать частично-досрочные погашения с уменьшением суммы аннуитета. Но оставляя неизменной сумму ежемесячного перечисления в банк. С каждой досрочкой от ежемесячного перечисления остается все больше и больше денег на досрочку. И получается система с положительно обратной связью. А в случае всяких жизненных неприятностей всегда можно уменьшить платеж до необходимого и получить немного «лишних» денег.
2. Это точно :) Поэтому все обязательные перечисления (которые не обязательно платежи за что-то) идут автоматическими переводами по расписанию.
Этот подход понятен. Основные расходы также понятны на год вперед. И есть планирование существенных расходов.
Речь о другом. Например, есть желание купить какую-то вещь, но постоянно откладываешь по разным причинам. И тут видишь эту вещь, она тебе нравится, на нее есть скидка, хорошая погода и т.д. Но в бюджет этого месяца покупка этой вещи не заложена. И есть два варианта поведения: 1. в бюджет не входит — значит «фсад» и 2. свободные деньги есть? «да» — покупаем, «нет» — не покупаем. Вопрос именно про такое.
А то, что есть некий форсмажор, который нельзя отложить (например, медицина, необходимая одежда и т.д.) — это тоже очевидно.
У меня получается, иногда, до 20% расходов за месяц улетает на такие незапланированные расходы. Правда, я отдельно не планирую затраты на подарки и прочее.
А вы жесткое бюджетирование месяца не практикуете? Т.е. если потребность что-то купить «внезапно» возникла в течении уже сведенного месяца — эта покупка не выполняется, хотя и деньги есть и на фин.состояние это не влияет.
Изменение структуры данных задача относительно простая,
Для понимания вопроса — можете озвучить свой реальный опыт по изменению структуры таблиц в боевой БД размером гигов 100 и порядка 100 активных пользователей или ваш опыт чисто теоретический?
По сравнению с задачей доработки бизнес-логики.
При правильной структуре БД доработки бизнес-логики, можно считать, бесплатны. Хотя смотря что называть бизнес-логикой :)
Скорее всего никак :) Ибо речь опять не о том.
…
Дальше будет притянутый за уши пример.
Пример: у вас есть таблица, которая хранит продажи со структурой: Товар, Количество, СуммаРубль, СуммаДоллар
Такая таблица доставит вам массу проблем, как только вы захотите продавать товар не только в долларах. Причем не только для задачи зафиксировать факт. А еще надо отчеты какие-то строить…
Такая таблица: Товар, Количество, Валюта1, Сумма1, Валюта2, Сумма2
Создаст значительно меньше проблем при двухвалютном учете, но трехвалютный уже не потянет. Специфика предметной области даст понимание, нужен нам трехвалютный учет или нет. Вот это и есть структура базы.
А теперь на секунду представляем себе, что самая первая структура данных успешно работала N лет. В базе накоплено X Гигабайт данных, с которыми работают M отчетов и всего остального. И теперь надо это все резко сделать многовалютным. И это надо сделать а) примерно вчера и б) база не будет остановлена больше, чем на пару минут/часов/дней (но всегда меньше, чем надо).
И вот тут сразу забывается качество кода, фреймворк, на котором все написано, и вся прочее. А начинаются размышления на тему: какрыбку съесть и кости сдать за деньги минимально дешево перелить данные из «старой» таблицы в «новую» и как потом сделать так, чтобы весь тот софт, который раньше работал с простыми циферками, стал быстро и правильно (!) работать с непростыми циферками.
На мой непросвященный взгляд — это и есть главная сложность. А на чем и как рисуются формочки и печатаются отчетики — это не самое интересное. SAP вон вполне себе работает на визуальных технологиях терминального века и ничего, живой :)
Ведь не зря вендоры экономического софта меряются не фреймворками и модными технологиями, а [десятками] тысяч работающих в одной базе пользователей и поддержкой актуального законодательства.
Как структура СУБД может повлять на функциональность?
У меня не получается осмыслить эту фразу :(
Но все-таки не стоит уходить глубже, т.к. в этом случае мы скатываемся в предметную область. И без четкого описания обсуждаемого предмета хорошей дискуссии не получится, т.к. стороны будут вольны уточнять постановку в процессе дискуссии :)
получить от меня систему ведения кассы на торговой точке, если только это вам и нужно от 1С
Вот это я точно не посоветую делать на 1с. Особенно, если кэшлайн длинный, номенклатура 700+ тысяч и проходимость хорошая.
И да, у меня будет много вопросов по вашему предложению :)
Если она, как говорится, storage agnostic, то выбор конкретной системы хранения не повлияет на функциональность.
Если вы под этим термином понимаете независимость от конкретной СУБД, то я вообще о другом. Я говорю именно о структуре базы данных. Какие там таблицы, что в них лежит и как эти таблицы связаны. В какой СУБД это лежит — вопрос 145. И если структура базы «плохая» — на функциональность это влияет напрямую и драматически.
Если автоматизировать имеющиеся бизнес-процессы, то это одно.
Если автоматизировать бардак — получится автоматизированный бардак :)
Ещё вариант может быть: ....
А есть такие же, только перламутровые? :)
Я в данном случае не пытаюсь убедить вас в чем-то. Я озвучиваю свой опыт из очень большой практики автоматизации предприятий (10+ лет).
Любая доработка системы является компромиссом между хотелкой заказчика, предметной компетентностью исполнителя и возможностями дорабатываемой системы.
Вы поймите, если я закажу вам систему «как 1с» только дешевле — я от вас если что-то и получу, то очень не скоро. Ну т.е. совсем не скоро. И сильно не факт, что дешевле, чем купить готовое у той же 1С. А если добавить еще несколько хотелок — то, возможно, и никогда не получу.
Ну и (ИМХО): для экономического софта качество базы данных — это ключевое, стратегическое качество софтины. Ибо если существующая структура БД не позволяет обеспечить некоторые хотелки, это тянет за собой столько подпрыгиваний и такой геморой, что хочется убиться.
Эксперты со стороны заказчика должны, прежде всего. разбираться и передать разработчику необходимую ему для реализации часть своих знаний предметной области.
Это не то, чтобы заблуждение, но такое внедрение, скорее всего, будет обречено на провал. Причина очень простая — заказчик будет пытаться всех своих текущих тараканов затащить в новую систему. При этом далеко не факт, что текущие тараканы: а) законны, б) корректны и в) оптимальны с точки зрения бизнеса заказчика. Их тянут по одной причине — они привычны!
Постановщик со стороны исполнителя обязан разбираться в предмете и обладать квалификацией для поддержания корректного и аргументированного спора по предмету.
И качество кода, повторюсь, здесь вторично. Первичная — общая архитектура системы, структура базы данных. Именно это определяет возможность модернизировать систему.
Если, условно говоря, у вас свойство «пол» физ.лица — это булево, то любое качество кода не позволит этой системе быть успешно внедренной на территории некоторых стран :)
У меня нет понимания, как может один человек хорошо разбираться с таком объеме предметной области. А если понимания не будет — будет стандартная софтина, созданная из говна и палок. Не потому, что писатель кривой, а потому, что понимания предмета нет.
Т.е. код и его качество — это вторичный вопрос (увы) по сравнению с качество постановки задачи.
И, заметьте, я не говорил о глюках. Я говорил о скорости загрузки приложения и о том, насколько адекватно восстанавливается простейшее форматирование.
У меня, например, масса претензий к тому, как на моем документе работают макросы (точнее с какой вероятностью они работают ;) ), но это слегка другой вопрос.
Ну и то, во что превращается примитивное форматирование документа, обычно заставляет меня забыть об аналогах до выхода следующей большой версии.
Т.е. если надо написать служебку на полстранички — аналог прокатит, а для работы — увы.
Ну и да, рибоновский интерфейс Офиса радикально лучше менюшного интерфейса. Речь про работу.
Понятно, что все ИМХО
Ну и ИМХО Винда и ДОС — это не приобретение, а собственная разработка. Но спорить не готов
Собственно озвученно вами — важное преимущество программных лицензий: они сочетаются в произвольных комбинациях и видах.
Программная клиентская лицензия может искаться клиентским приложением, а может — раздаваться сервером. В первом случае она работает «на компьютер», во втором — «на сеанс». Т.е. до определенного количества лицензий предлагается возможность, как активировать — по-штучно или всем пакетом. Вот по-штучная активация (когда активируется, по сути, однопользовательская лицензия) позволяет на одной лицензии запускать произвольное количество экземпляров клиентского приложения на компьютере.
Другими словами, если вы активируете 5-ти пользовательскую лицензию на компьютер сервера Предприятия, то у вас смогу работать одновременно не более 5 сеансов (не важно, к одной базе или к нескольким). Но с любого компьютера сети. При условии, что серверу разрешена раздача лицензий. Если вы эту же 5-ти пользовательскую лицензию активируете на 5 различных компах, то у вас смогут работать одновременно 5 человек, каждый из которых может открыть произвольное количество клиентских приложений или конфигураторов на своем компе. Но только с этих 5 компов.
При этом во втором случае будут проблемы с веб-клиентами и мобильными клиентами.
Так потому, что умение управлять деньгами автоматически не приходит с ростом дохода. Если человек умеет только тратить весь доход, то он будет его тратить вне зависимости от размера этого дохода. И, сдается мне, что слово «успешные» не просто так закавычено :)
Ну и понты, как известно, дороже денег.
Понял. Спасибо за мнение.
Да, это понятно. Незапланированные траты с ущемлением текущих обязательных расходов, на мой взгляд, допустимы только в экстренных случаях.
2. Это точно :) Поэтому все обязательные перечисления (которые не обязательно платежи за что-то) идут автоматическими переводами по расписанию.
Речь о другом. Например, есть желание купить какую-то вещь, но постоянно откладываешь по разным причинам. И тут видишь эту вещь, она тебе нравится, на нее есть скидка, хорошая погода и т.д. Но в бюджет этого месяца покупка этой вещи не заложена. И есть два варианта поведения: 1. в бюджет не входит — значит «фсад» и 2. свободные деньги есть? «да» — покупаем, «нет» — не покупаем. Вопрос именно про такое.
А то, что есть некий форсмажор, который нельзя отложить (например, медицина, необходимая одежда и т.д.) — это тоже очевидно.
У меня получается, иногда, до 20% расходов за месяц улетает на такие незапланированные расходы. Правда, я отдельно не планирую затраты на подарки и прочее.
Для понимания вопроса — можете озвучить свой реальный опыт по изменению структуры таблиц в боевой БД размером гигов 100 и порядка 100 активных пользователей или ваш опыт чисто теоретический?
При правильной структуре БД доработки бизнес-логики, можно считать, бесплатны. Хотя смотря что называть бизнес-логикой :)
…
Дальше будет притянутый за уши пример.
Пример: у вас есть таблица, которая хранит продажи со структурой: Товар, Количество, СуммаРубль, СуммаДоллар
Такая таблица доставит вам массу проблем, как только вы захотите продавать товар не только в долларах. Причем не только для задачи зафиксировать факт. А еще надо отчеты какие-то строить…
Такая таблица: Товар, Количество, Валюта1, Сумма1, Валюта2, Сумма2
Создаст значительно меньше проблем при двухвалютном учете, но трехвалютный уже не потянет. Специфика предметной области даст понимание, нужен нам трехвалютный учет или нет. Вот это и есть структура базы.
А теперь на секунду представляем себе, что самая первая структура данных успешно работала N лет. В базе накоплено X Гигабайт данных, с которыми работают M отчетов и всего остального. И теперь надо это все резко сделать многовалютным. И это надо сделать а) примерно вчера и б) база не будет остановлена больше, чем на пару минут/часов/дней (но всегда меньше, чем надо).
И вот тут сразу забывается качество кода, фреймворк, на котором все написано, и вся прочее. А начинаются размышления на тему: как
рыбку съесть и кости сдать за деньгиминимально дешево перелить данные из «старой» таблицы в «новую» и как потом сделать так, чтобы весь тот софт, который раньше работал с простыми циферками, стал быстро и правильно (!) работать с непростыми циферками.На мой непросвященный взгляд — это и есть главная сложность. А на чем и как рисуются формочки и печатаются отчетики — это не самое интересное. SAP вон вполне себе работает на визуальных технологиях терминального века и ничего, живой :)
Ведь не зря вендоры экономического софта меряются не фреймворками и модными технологиями, а [десятками] тысяч работающих в одной базе пользователей и поддержкой актуального законодательства.
У меня не получается осмыслить эту фразу :(
Но все-таки не стоит уходить глубже, т.к. в этом случае мы скатываемся в предметную область. И без четкого описания обсуждаемого предмета хорошей дискуссии не получится, т.к. стороны будут вольны уточнять постановку в процессе дискуссии :)
Да, SQL СУБД.
Конечно нет. Имеется ввиду и то и то.
Вот это я точно не посоветую делать на 1с. Особенно, если кэшлайн длинный, номенклатура 700+ тысяч и проходимость хорошая.
И да, у меня будет много вопросов по вашему предложению :)
Если вы под этим термином понимаете независимость от конкретной СУБД, то я вообще о другом. Я говорю именно о структуре базы данных. Какие там таблицы, что в них лежит и как эти таблицы связаны. В какой СУБД это лежит — вопрос 145. И если структура базы «плохая» — на функциональность это влияет напрямую и драматически.
Если автоматизировать бардак — получится автоматизированный бардак :)
А есть такие же, только перламутровые? :)
Я в данном случае не пытаюсь убедить вас в чем-то. Я озвучиваю свой опыт из очень большой практики автоматизации предприятий (10+ лет).
Любая доработка системы является компромиссом между хотелкой заказчика, предметной компетентностью исполнителя и возможностями дорабатываемой системы.
Вы поймите, если я закажу вам систему «как 1с» только дешевле — я от вас если что-то и получу, то очень не скоро. Ну т.е. совсем не скоро. И сильно не факт, что дешевле, чем купить готовое у той же 1С. А если добавить еще несколько хотелок — то, возможно, и никогда не получу.
Ну и (ИМХО): для экономического софта качество базы данных — это ключевое, стратегическое качество софтины. Ибо если существующая структура БД не позволяет обеспечить некоторые хотелки, это тянет за собой столько подпрыгиваний и такой геморой, что хочется убиться.
Это не то, чтобы заблуждение, но такое внедрение, скорее всего, будет обречено на провал. Причина очень простая — заказчик будет пытаться всех своих текущих тараканов затащить в новую систему. При этом далеко не факт, что текущие тараканы: а) законны, б) корректны и в) оптимальны с точки зрения бизнеса заказчика. Их тянут по одной причине — они привычны!
Постановщик со стороны исполнителя обязан разбираться в предмете и обладать квалификацией для поддержания корректного и аргументированного спора по предмету.
И качество кода, повторюсь, здесь вторично. Первичная — общая архитектура системы, структура базы данных. Именно это определяет возможность модернизировать систему.
Если, условно говоря, у вас свойство «пол» физ.лица — это булево, то любое качество кода не позволит этой системе быть успешно внедренной на территории некоторых стран :)
Т.е. код и его качество — это вторичный вопрос (увы) по сравнению с качество постановки задачи.