Speshilov Alexander

981
Рейтинг
+1 за сутки

Alexander Speshilov
speshuric



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

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


Группы

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

Рейтинг 981

Обслуживание индексов и статистик MS SQL Server 120

v8 Абонемент ($m)

Готовый и эффективный скрипт для регулярного обслуживания индексов и статистик.

1 стартмани

06.02.2014    56180    334    61    

WMI-обозреватель 28

v8 Абонемент ($m)

Небольшая обработка для отладки WQL запросов WMI.

1 стартмани

05.06.2013    11446    43    5    

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

v8 Бесплатно (free)

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

18.05.2013    9528    6    

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

v8 1cv8.cf Бесплатно (free)

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

11.05.2013    51995    98    

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

v8 1cv8.cf Бесплатно (free)

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

17.02.2013    168526    79    

Комментарии

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.
AdminВсем нужен эксперт#89 12.05.17 2:42
(88) Ну и посмотрите внимательно на свои результаты.
1. Варианты 3 и 4 по факту меняют план запроса, остаётся сравнивать однократный запуск 1 и 2.
2. Writes поровну. Чтений почти поровну. Duration отличается на 22% ( (135-104)/135 ). Отсутствие индексов, если эта ВТ используется почти гарантированно будет дороже.
3. Формулировка в 3 и 4 неправильная: не "Индексы", а "Индекс" - на ВТ он в 1С всегда один. Это важно.
УчетУправление инцидентами#1 03.03.17 11:48
(0) Лучше переименовать ваши "инциденты" в "обращения". Использовать общеупотребимые термины в неправильном смысле - плохая затея.
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 - он не выигрывает и не проигрывает, но заметно другой.