Speshilov Alexander

1330
Рейтинг

speshuric



  •   Регистрация: 26.10.2010 (13 лет назад)

  •   Был(а) на сайте: 10.11.2023

Друзья
  • Александр Коваленко
  • Сергей Лобанов
  • Алексей Кожушко
  • Владислав Цылёв
  • Алексей Патюков
  • Евгений Плешивцев
Подписчики 56

Группы

Профессиональный разработчик

Рейтинг 1330

Что такое буквы в 1С

Статья Программист Платформа 1С v8.3 Бесплатно (free) Нет файла Механизмы платформы 1С

Некоторые особенности и неочевидные моменты использования символов в 1С.

18.05.2013    15835    speshuric    6       

34

Составные типы — бесплатный сыр мышеловки производительности

Статья Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free) Нет файла Механизмы платформы 1С

Как работают запросы с составными типами, почему неаккуратное использование составных типов данных может снизить производительность, и как этого избежать.

11.05.2013    99282    speshuric    99       

510

Резервное копирование 1С средствами MS SQL.

Статья Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Windows Бесплатно (free) Нет файла Архивирование (backup)

В этой статье описано самое обычное резервное копирование ИБ 1С при помощи инструментов MS SQL Server 2008 R2, объяснено почему следует делать именно так, а не иначе, и развеяно несколько мифов.

17.02.2013    330892    speshuric    89       

551

Комментарии

DevРегистры сведений 1С. Как это устроено.#170 20.04.23 0:12
(169)
Ну будет, но с оговорками:
1. И у 1С, и у вас условия на ресурсы в срезе ставить можно, но это неправильно. Сами потом отлаживать и устанете.
2. "row_number() = 1" с большой вероятностью угробит производительность.
AdminGit с человеческим лицом для тех, кто устал терять данные#48 11.01.18 8:16
(46) Может это я непонятно объяснил?
1. При коммите гит запишет изменение файла в виде нового object (если не найдёт такой же файл по хешу). Не факт, что гит будет хранить в этом виде потом, но при коммите один фиг - создаст новый object. Я же специально даже ссылочки приложил на почитать.
2. Проблема сравнения - исключительно проблема инструментария. Если инструментарий может показать разницу удобно, то никого не заволнует насколько реально различаются файлы. Так-то и текстовые файлы могут доставить много веселого при сравнении. Помню в какой-то из 1С 8.0 разработчики платформы поломали переводы строк и в модулях были 0x0D0D0A вместо 0x0D0A или как-то так. Это взрывало мозг не только 1С-ному сравнению, но и куче других внешних инструментов. Похожим образом некорректные utf-8 файлы сводят с ума diff tools.
3. Бинарники в репозитариях потому что этот бинарник - часть проекта. Да, гит эффективнее работает с текстовыми изменениями. Но почти любой проект будет содержать не только текст.
4. Я когда разрабыатваю, то коммит - почти как "сохранить", т.е. 10-20 в день - минимум. Ну правда перед пушем делаю squash и вообще причесываю.
AdminGit с человеческим лицом для тех, кто устал терять данные#45 10.01.18 20:59
(41) Не соглашусь. Гиту по большому счету плевать бинарник это, текст или еще что. Более того, почти во всех публичных значимых репозиториях достаточно много нетекстовых файлов, например картинки, документация в pdf, особо нужные версии библиотек, тестовые файлы, драйверы периферийных устройств (которые производители отдают бинарниками). Да, в большинстве случаев diff не получить (хотя картинки некоторые уже сравнивают). Да, бывает, что идентичный по смыслу файл будет отличаться. Но в целом версионирование таких файлов смысл имеет. И по большому счету достаточно удобно версионировать медиа-файлы при работе с аудио и с графикой.

Если закарываться внутрь движка, то на самом этапе коммита работа с "полностью изменяющимися бинарниками" и "на небольших текстовых отличиях между версиями" практически идентична. Файл изменился? В индекс! Хотя и Evil Beaver в (9) прав - если репозиторий состоит из больших и сильно меняющихся файлов, то он будет расти гораздо быстрее, чем при небольших компактных отличиях.
AdminGit с человеческим лицом для тех, кто устал терять данные#40 10.01.18 7:52
(2)
Цитата
Использовать гит для версионирования бинарных да и вообще любых не текстовых файлов, не имеет смысла.
Почему это? Ну да, если файл сжатый, то object в папке .git на каждую версию будет того же размера, что и сам файл. Да, тот же sourcetree не покажет дифф, но версионирование вполне имеет смысл и тот же GitLab обращает внимание на особенности работы с нетекстовыми данными (в частности для гейм-девелопмента).
AdminРезервное копирование 1С средствами MS SQL.#66 20.11.17 0:17
(65) Это лог конкретного джоба. Его можно посмотреть в свойствах джоба и шага. Дальше зависит от настроек.
AdminРезервное копирование 1С средствами MS SQL.#62 29.06.17 14:21
(60) Зеркальную резервную копию делать при помощи "MIRROR TO", но насколько я помню в maintenance plan это не настраивается, надо писать скрипт. Способ обхода - копировать после создания (это можно настроить). Пример есть и в статье и в справке
(61) Речь о предложении "MIRROR TO" из синтаксиса BACKUP DATABASE.
DevМетод определения и списания партий по ФИФО, реализованный в запросе#2 03.03.17 10:31
(0) Это вообще на количестве проводок больше 10000 работает?
DevДобавляем http-ссылки на самописную систему учета задач#13 10.02.17 10:04
(12) Каждый из перечисленных чем-то хорош. BB очень даже интересен, когда есть hg-шники или когда весь остальной стек atlassian куплен (какими же дешёвыми кажутся лицензии 1С по сравнению с набором jira+conf+bitbucket, с учетом того что каждый год надо платить по половине начальной стоимости!).
Более того, git вполне позволяет в одной организации держать несколько разных source control серверов. Просто те, кого не устраивает общий продукт, настраивают зеркальный push со своей песочницы - так как минимум история коммитов сохраняется.
DevДобавляем http-ссылки на самописную систему учета задач#11 09.02.17 21:34
(8) Ни в коем случае не подумайте, что мне что-то в вашем решении не понравилось. Нормальное решение, хорошо оформленная статья.
Просто немного удивило, что с вашими требованиями (закрытые бесплатные репозитарии, хотите больших объёмов) вы остановились BB.

Лично мне gitlab нравится гораздо больше.
1. Устанавливается реально просто.
2. Активно развивается (как обратная сторона - есть куда развиваться). За прошедший год авторы столько всего сделали, что я даже удивляюсь.
3. LDAP - это в первую очередь возможность подтянуть пользователей из active directory.
4. Сервис по code review - это же обычные мерж реквесты. Они там примерно аналог PR в bitbucket и github.
5. С продуктами atlassian интеграция, конечно, хуже чем в BB, но уж ссылки на тикеты подсвечивает.
6. Главное преимущество в том, что из альтернатив - единственный продукт, который можно установить локально абсолютно бесплатно и без ограничения по пользователям и с достаточным для комфортной работы функционалом. На моей нынешней работе есть куча ограничений по доступу к BB, потому что не куплено достаточно лицензий (аналитикам и другим "неразработчикам" не дают доступ).

На самом деле между gitlab/bitbucket/github примерный паритет по фичам и они очень похожи. У каждого из них есть свои фишки, но в целом для разработчика на 90% всё равно каким из них пользоваться. Чуть-чуть в стороне стоит upsource - он не выигрывает и не проигрывает, но заметно другой.
DevДобавляем http-ссылки на самописную систему учета задач#5 09.02.17 14:22
Решение интересное, но не проще ли было поднять свой гитлаб? Бесплатно. Нет ограничений на размер и количество пользователей. Захостить можно почти где угодно. Ставится за несколько минут. API, трекер, CI (правда очень "самобытный"), wiki, интеграция с LDAP.