Комментарии / Профиль docsvision

11.01.2023 14:32:59

Wed, 11 Jan 2023 14:32:59 GMT

Тикетов было больше 45 000. А как выгружали, мы отвечали на комментарий выше

29.12.2022 08:21:34

Thu, 29 Dec 2022 08:21:34 GMT

всё просто, выгрузка у нас была двойная.
1. В нашей подписке на Zendesk была возмжность выгрузить информацию в по тикетам в json-файл. В выгрузке содержались и поля тикетов, и различные метрики по ним. Но там была только текстовая информация, без файлов.
2. Написали утилиту с использованием API Zendesk, с помощью которой выгружали основную информацию по тикетам в т.ч. и с файлами. Выгружали, формируя html-ки.

В итоге для переноса на новый портал мы использовали данные из json-а, это было удобнее разбирать, а html-ки использовали в процессе работы, чтобы обращаться к старым заявкам при необходимости, пока они не загружены на портал + там были файлы. На новый портал файлы, накопленные за 10 лет мы решили не тащить.

06.04.2022 06:30:43

Wed, 06 Apr 2022 06:30:43 GMT

Не вникал в детали принципа работы, к сожалению, об этом сказать ничего не могу. Насчёт контроля консистентности - всё так. Но в AsciiDoc, вроде бы, и нет необходимости в контроле, потому что позволено вставлять всё и всюду. Есть редкие исключения, но вот так навскидку не вспомнить.
По поводу вставки тэгированных кусков кода не совсем понял. Куски кода вставлять можно. А специально тэгировать их нет необходимости, достаточно у каждого элемента создать уникальный ID.
Но больше всего меня обижает, что conref не вставит другой conref. То есть в источнике заимствования не должно быть заимствований. Include прекрасно справляется с инклудом инклуда.
Полностью согласен. Хотелось бы чего-то проще, но и так лучше, чем XSLT)
AsciiDoc тоже умеет автогенерацию, например, из javadoc, с помощью Antora. Не пробовал, но в далеко идущих планах испытать. Всё же AsciiDoc предлагает большой выбор уже готовых решений, которые можно повторить или использовать.

30.03.2022 09:58:22

Wed, 30 Mar 2022 09:58:22 GMT

У нас внутреннюю документацию для разработчиков тоже пишут в asciidoc, точнее пишет один человек. Хотелось бы больше, но разработчики не очень хотят писать документацию.

Если код и документация хранятся в одном месте, то AsciiDoc однозначно будет удобнее для этих целей, чем DITA.

30.03.2022 08:44:07

Wed, 30 Mar 2022 08:44:07 GMT

Я так понимаю, этот пример из VSCode. В дитой таких проблем не замечал. У неё как раз регламентированная структура, всё довольно чётко.

В основном (на мой субъективный взгляд) docs as code инструменты выбирают ради единого источника. То есть в чём хранить есть разница, возможно как раз от Docx перешли.

Параллельная разработка документации - это для больших команд. Когда есть несколько техписателей. Но и в таком случае, мне кажется, случаи, когда разные люди в разных ветках делают один и тот же документ будут редкими. Они несомненно будут, но редко. И наверняка в таком случае в команде должны быть установлены алгоритмы действий.

30.03.2022 07:36:40

Wed, 30 Mar 2022 07:36:40 GMT

А почему бы и нет? XML - это тоже код. Сколько работал с DITA в vcs, описанных вами проблем не испытывал. Конечно, работал один, но всё же.

30.03.2022 07:33:56

Wed, 30 Mar 2022 07:33:56 GMT

Я не очень хорошо осведомлён о популярности разных инструментов. Могу судить по количеству вопросов на Stackoveflow:

dita: 298
asciidoc: 398
rst: 1182
latex: 9956

Если так посмотреть, то DITA и AsciiDoc примерно сопоставимы по популярности, а латексу в популярности уступают даже дита, аски и рст вместе взятые. Я в начале статьи говорил, что работал с дитой и с аски. Я не работал с рст или латексом, поэтому не могу сравнить с ним. Если вы работали и готовы написать статью, я с удовольствием прочитаю.

Если честно, не вижу препятствий, почему нельзя сравнивать диту и аски. И то и другое - инструмент для документации. Как видно из статьи, точки соприкосновения у них есть.

Маркдаун не сравнивал, потому что не вижу смысла. Его легче сравнить с MS Word. Могу сделать сравнение, в принципе, но это не очень интересно.

27.07.2021 14:28:57

Tue, 27 Jul 2021 14:28:57 GMT

Есть случае, когда люди уходят из компании, а позже возвращаются. Но это прям единичные случае. Тут имеется в виду именно сбор обратной связи от сотрудников до и после нововведения. Отзывы поменялись по наблюдениям тим-лидов.

27.07.2021 14:27:08

Tue, 27 Jul 2021 14:27:08 GMT

Да, но когда и команда классная, и новый человек приходит огонь, то хочется добиться синергии и ускорить старт плодотворной работы. И вот развитие системы нам помогло. Процессы у нас были, но разрозненные. По факту не пришлось изобретать велосипед. Просто весь процесс, уже существовавший, был переложен на систему. И результат нас порадовал.

27.07.2021 09:30:01

Tue, 27 Jul 2021 09:30:01 GMT

Онбординг нового сотрудника в компании всегда включал длительный процесс обучения. Ранее оно могло быть избыточно для нового человека и менее структурировано. После ревизии процессов удалось сократить это время.

11.08.2020 10:43:06

Tue, 11 Aug 2020 10:43:06 GMT

Не прописали в тексте статьи, что у нас используется асинхронный режим работы AlwaysOn, т.к. синхронный не устраивает по уровню производительности. Поэтому и нужны описанные в статье сложности.

05.07.2016 14:59:28

Tue, 05 Jul 2016 14:59:28 GMT

График схематичен и, действительно, при расставлении тех или иных акцентов, его можно трактовать по-разному. В данном случае мы хотели донести основную мысль, что у On-Premise есть свои неоспоримые преимущества.

По части «Полнота встроенного решения», что мы понимали в графике:
On-Premise СЭД по определению необходимо внедрять (устанавливать ОС, СУБД, СЭД, настроить под требования), т.е. моментально без проведения этих работ мы не получим типового решения. Под типовым решением в данном примере подразумевалось преднастроенное решение по автоматизации ключевых процессов, которое доступно для работы без необходимости его полномасштабного внедрения, желательно сразу же после оплаты.

Если же понимать под типовым решением функционал СЭД, позволяющий выполнять типовые задачи СЭД после внедрения, то в On-Premise действительно примеров таких решений и, в том числе коробочных, — много.

По части «Средства интеграции с другим ПО», Вы правы — on-premise СЭД умеет интегрироваться с другими системами.
В схематичном графике средства интеграции для различных типов на серединном и примерно одинаковом уровне, т.е. в данном случае понимается, что системы, как Вы и говорите, умеют интегрироваться с другими системами.
В широком смысле для on-premise действительно средства довольно мощные — такие, как внешний API, интеграционные бесшовные шлюзы, при этом часто это уже отдельные подпроекты по внедрению.

Пункт «Длительность Демо доступа» вообще похоже, что задумывался как Киллер-фича для иллюстрации убогости On-Premise.

Здесь речь о персональном демо-доступе, и действительно нам следовало сделать именно на этом акцент, в графике получилось, что это не отмечено. Под персональным демо-доступом понимается поставляемая заказчику СЭД, но еще до покупки, такая среда, где работает только заказчик со всеми реальными конфигурациями под заказчика. On-premise можно протестировать, используя демо-стенды, предустановленные VM, читая инструкции, но полноценное демо-тестирование возможно только с запуском, к примеру, пилотного проекта и, опять же, разворачивая СЭД у себя на мощностях.

"… периодических платежей в модели PaaS предусмотрена только аренда виртуальной инфраструктуры, в отличии от SaaS, где в периодические платежи также закладываются аренда лицензий и решения." Где профит? В единоразовых платежах?

Профит в том, что по сравнению с аналогичным SaaS решением (где включена аренда инфраструктуры и еще лицензий и решения) в предлагаемой PaaS модели сумма периодических платежей состоит только из сумм аренды инфраструктуры и, как следствие, этот платеж не включает компоненты: платеж за аренду лицензий и решения. По расчетам, такая схема выгоднее SaaS на горизонте владения от года, но, может быть, и ранее. Разовые платежи идут за лицензию и лицензии остаются бессрочно у заказчика.

31.08.2015 07:29:41

Mon, 31 Aug 2015 07:29:41 GMT

Метод этот, несомненно, интересный, но, боюсь, в нашем случае неприменим – для тяжёлых фич такие оценки будут из разряда потолочных.

28.08.2015 08:47:31

Fri, 28 Aug 2015 08:47:31 GMT

У нас – супергерой :) Если серьёзно, то мы в производстве пересмотрели подход к оценкам, ещё на этапе анализа каждая фича проходит трёхуровневое ревью – главным бизнес-аналитиком, архитектором и представителем группы тестирования. Это значительно повышает шанс на обнаружение неучтенных нюансов и возможных проблем, хотя и повышает в целом время, затраченное на проектирование.

28.08.2015 08:06:51

Fri, 28 Aug 2015 08:06:51 GMT

Согласна с Вами. В проектах по внедрению проблема изменений ощущается острее, чем при разработке продукта. В продукте мы обобщаем требования и можем «сгладить острые углы», при работе же с одним заказчиком – приходится отстаивать с боем каждую доработку.

28.08.2015 07:52:46

Fri, 28 Aug 2015 07:52:46 GMT

Да, разумеется, архитектор проводит оценку и может выявить внутрисистемные связи с точки зрения разработки. Однако определение «айсберга» на уровне бизнес-логики – задача целиком аналитика.

13.08.2015 10:58:17

Thu, 13 Aug 2015 10:58:17 GMT

Имелось в виду свидетельство о регистрации программы для ЭВМ в Роспатенте. Срок полезного действия в нем не указывается, он определяется внутренним распоряжением (или учетной политикой) компании. По поводу сроков – могу судить только о нашем опыте (при правильно заполненных документах) – минимум был 8 месяцев.

13.08.2015 10:57:12

Thu, 13 Aug 2015 10:57:12 GMT

1. За поправку спасибо – восполняю юридические пробелы:
• Договор об отчуждении исключительного права: происходит полное отчуждение (уступка) исключительного права от правообладателя третьему лицу.
• Заключение лицензионного договора: исключительное право передается третьему лицу лишь в установленных договором пределах, само же исключительное право остается у правообладателя.

2. Любой тип имущества предприятия должен быть отражен в его балансе, в том числе интеллектуальная собственность. Постановка ПО на баланс нужна для того, чтобы обозначить исключительные права на собственную разработку. В бухгалтерском учете исключительные права на объекты интеллектуальной собственности учитываются в составе нематериальных активов.

13.08.2015 07:30:43

Thu, 13 Aug 2015 07:30:43 GMT

Согласно п. 2 ст. 40 Налогового кодекса РФ достаточно удерживать разброс цен в пределах 20%, чтобы не давать повода налоговым инспекторам сомневаться в правильности применения таких цен при расчете налога на доходы и НДС.

Предпоследний вопрос – про себестоимость, конечно. В общем случае, амортизируемым признается имущество со сроком полезного использования более 12 месяцев и первоначальной стоимостью более 40 000 рублей.
Если стоимость НМА менее 40 000 рублей, затраты списываются не через амортизацию, а в виде материальных затрат или расходов будущих периодов.

12.08.2015 14:48:36

Wed, 12 Aug 2015 14:48:36 GMT

1. Каждая новая версия, если вы хотите продавать ее отдельно, со своим наименованием, ставится на баланс аналогичным образом. Чтобы не ставить их все на баланс и предлагается такой вариант – ставим основную версию, а продаем «основная, +…»

2. Если вы обновляете первоначальную версию и продаете далее уже ее новый вариант – эти расходы могут учитываться в расходах для целей налогообложения прибыли (уменьшают прибыль), не изменяя стоимость первоначальной версии.

3. Переоценку существующих активов можно осуществлять не чаще 1 раз в год по коэффициентам росстата, если вы считаете это необходимым.

Для ежемесячного выпуска новых версий я бы выбирала вариант 1.