| В системе 1С практически невозможно работать с массивами двоичных данных. Ну очень тщательно разработчики платформы оградили программистов прикладных решений от нюансов реализации. Так, например, даже задача прочитать нетекстовый (бинарный) файл и проанализировать его содержимое, а также задача записать такой файл не решаются штатными средствами. А иногда это нужно.
( Пример решения ) | comments: 18 комментариев or Оставить комментарий   |
| Решил я сегодня после обеда зарегистрироваться на сайте connect.microsoft.com и сообщить софтверному гиганту об ошибочке в одной программке. Да ладно, я не жадный. Зарегистрировался. Добавил сообщение. Добавил аттачмент к сообщению. Хотел было добавить комментарий, а мне сервер и говорит человеческим голосом:( Server Error in '/' Application. ) Вот так вот. Ошибка в системе сбора ошибок.
Если кому интересно, то это было на этой страничке | | comments: Оставить комментарий |
| | Меня попросил один хороший товарищ рассказить, как мы организовали работу с конфигурацией при разработке. Чтобы эта информация не пропала, я решил её опубликовать у себя в ЖЖ. Учтите, это не инструкция и не полное описание нашей системы. Это просто небольшой набросок, отражающий фактическую картину.
( ... ) | | comments: 13 комментариев or Оставить комментарий |
| Распиздяйство и Авось. У меня других слов нет о стиле работы замечательной софтверной компании 1С. История страшна и типична.
Когда-то в начале лета 1С стала выпускать более-менее стабильный релиз платформы версии 8.1. Это хорошо, но всё равно еще типовые конфигурации не готовы, всё равно еще никто не рискнёт ставиться. И обещали они, что вот-вот выпустят типовые конфигурации для этого чудо-зверя. Даже супер-графики распространили. Ну, что ж, выпускайте. Обещали они УПП выпустить где-то в июле. Да вот фиг. Не смогли. Ладно, не страшно, делайте как можете. Делали. Как могли. Раз пять сдвигали сроки. К слову сказать сдвигали сроки выпуска типовой УПП вместе со сроком релиза платформы. Отлично. Наверное тестируют, наверное у них там супер-пупер QA сидит. Вышла платформа релиза 8.1.8. Типа вся из себя замечательная и улучшенная относительно 8.1.7. Не, ну есть в этой 8.1.8 недостатки, но это мелочи в общем-то. Прошла еще неделька, еще чуток и, о чудо! Версия "Управление производственным предприятием 1.2.8", которая "предназначена для использования с версией системы 1С:Предприятие 8 не ниже 8.1.8" вышла 16 августа 2007 года.
На текущий момент ни один человек, который хоть издали видел УПП не гложет себя надежной, что ошибок в этой системе нет. Можно сказать, что я уверен, что до выпуска следующего релиза из найдут еще штук 300-500. К этому все, к сожалению, привыкли. Ну и приспособились так жить и работать. Так и в этот раз я не надеялся, что ошибок не будет. Даже был уверен, что будут, т.к. несколько ошибок нашёл и отправил за пару дней до этого (причём в таких участках, где почти гарантированно не исправили). Да, кстати, я по всем ошибкам составляю аккуратные рапорты в 1С и обычно довожу до признания ошибки.
После выхода 1.2.8 1С поставили в план выпуск 1.2.9. Где-то в конце сентября. Нормально. Как раз исправлений наберётся.
Но не тут-то было. Сегодня они поставили в план 21 августа сдать новый релиз! Ни фига себе "путч", подумалось мне. Явно найдена серьёзная ошибка. Эй! Вы на месяц отложили релиз. Вы последний год-два рапортуете о разработке систем автоматизированного тестирования. Чо опять? Ребятки не стали ждать 21 августа и открыли карты прямо сегодня. Итого между релизом 1.2.8 и 1.2.9 прошло 4 дня, из которых 2 выходных. Это не рекорд для 1С, но близко к тому. А теперь, внимание! Какая же ошибка вынудила 1С столь спешно выпустить релиз???
Исправлена ошибка 00092921:
При входе пользователя не с полными правами происходит ошибка.
Бля. Ну... Это... А! Ы!
Перевожу. "Мы, программисты фирмы 1С, ни разу не запустили окончательную сборку прежде чем передавать её пользователям". Представьте себе ОС, в которой допущена ошибка из-за которой любой пользователь, кроме админа не сможет залогиниться...
Нет, ну конечно, франчи и прикладные программисты (мы) легко бы исправили в 90% случаев этот баг. Но суть не в том, что была найдена ошибка, а суть в том, что программу просто никто не запускал. Подобные ошибки я могу вспомнить в УПП многих релизов. Пусть не так явно выражались, но были. Ёлы-палы. Ну что так трудно составить набор простых обязательных проверок (пусть неавтоматизированных), которые проверять тупо каждый раз. Это же просто. Это же делают почти все производители софта. Нанять тупых трёх девочек. Можно мальчиков, но они не такие исполнительные в данном случае, обязательно начнут творчески халявить. У каждой по 500-1000 простых заданий. Перед релизом - день на прохождение квеста. Не прошли - разворот на доработку. Ничего сверхъестественного. Да, можно это и автоматизировать. Но начните с малого. Пожалуйста.
Если кто-то сильно умный мне скажет, что у них может не быть таких данных на которых ошибка проявляется, то он пойдёт лесом. Ибо тупые "сопровождатели" половину писем от меня предлагают переслать им БД, "чтоб разобраться". Хотя проблема отслеживается и на стандартной демоконфе. | | comments: 30 комментариев or Оставить комментарий |
| Верить нельзя никому. Особенно при внедрении 1С:Предприятия.
Руководству (оно же сейчас у меня заказчик) нельзя верить. Они даже не знают, чего хотят. А уж если делать то, что они думают, что надо сделать, для того, чтобы добиться того, что они якобы хотят... Только если это зафиксировано на бумаге, ими подписано, и я предупредил, что делать надо по другому, да еще и предложил вариант того, как это делать.
Нельзя верить пользователям - они вообще говорят не то, что видят, делают не то что им говорится, не делают того, что их просили сделать и являются самым сбоегенерирующим компонентом системы.
Верить нельзя себе - человек не робот, все совершают ошибки. Даже я (иногда). Даже если кто-то за мной должен искать ошибки, то рано или поздно он пропустит ошибку. Причём скорее рано, т.к. тривиальные ошибки я и сам могу увидеть, поэтому останутся нетривиальные плохообнаружимые.
Верить нельзя разработчикам типовых конфигураций 1С. Я, ежли честно, вообще с трудом представляю, как продукт с таким количеством ошибок хоть иногда выдаёт верный результат. Это как мягко посадить He-111 без полутора крыльев и хвоста с неработающим двигателем.
Конечно, верить службе поддержки 1С тоже ни в коем случае нельзя. Там вообще система похожа на помесь глухого телефона со страусом. Т.е. сначала играют в глухой телефон, перевирая начальное обращение и просто не читая его, а потом пытаются спрятать голову в песок и подождать, пока всё само уляжется.
Верить разработчикам платформы 1С? Только не это! Они же вообще сидят как будто в другом мире. Проблемы негров шерифа не ебут. "Ошибка не воспроизводится". Да хуй вас знает, как она там не воспроизводится, но я половину знакомых программистов 1С на всеразличных платформах просил повторить - у них "воспроизводится". Т.е. падает программка нафиг.
Думаете "тем парням из MS" поверю? Гыыы! Посмешили. Вот прямо сейчас ищу, почему же на вполне безобидном запросе MS SQL 2005 с любыми SP валится. И это "супер-пупер надёжный сервер". Которому уже несколько лет. И у которого уже SP2 и девятая версия... А ведь у них контроль за качеством повыше будет, чем у перечисленных.
Производители железа - тоже козлы ненадёжные. Так и норовят подъебать - то винт (новый, серверный, SCSI, 15krpm) осыплется, то конденсаторы на мамке вспухнут. Разработчики железа, правда, ни разу не лучше. Именно они закладывают половину глюков в технический дизайн изделий.
Однако...
....Можно верить и в отсутствие веры,
Можно делать и отсутствие дела....
Угу. | | comments: 16 комментариев or Оставить комментарий |
| Выкладываю рабочую инструкцию-памятку по переходу с 8.0 на 8.1. Может кому пригодится. Учтите, что это сугубо рабочий документ для достаточно опытных одинэсников и "нажмите кнопку далее" там не найти.
( Объёмистый текст )
Если у кого-то есть вопросы - отвечу | | comments: 27 комментариев or Оставить комментарий |
| Немного теории
В MS SQL индексы бывают кластерные и некластерные. Отличаются тем, что у кластерного индекса последний уровень является страницей с записями, а у некластерного последний уровень содержит ссылки на страницы с записями, и, соответственно, в некластерном 2 соседние по порядку записи могут значительно чаще находиться на разных страницах, чем в кластерном индексе. Очевидно, что для одной таблицы больше одного кластерного индекса не создать. С точки зрения производительности только что построенный кластерный индекс будет эффективнее для выборки чем некластерный, но для вставки записей он будет несколько медленнее.
MS SQL построен так, что кластерные индексы крайне неэффективны на "псевдослучайных" ключах, к которым относятся уникальные идентификаторы объектов данных в 1С и конкатенация таких идентификаторов, зато такие индексы отлично подходят для индексирования "человекочитаемых" строк и последовательно возрастающих номеров.
В 1С 8.0 есть таблицы с кластерными индексами и без таковых. В целом деление достаточно разумное. Так, кластерные индексы есть у справочников (часто по наименованию), у документов (по порядку), у табличных частей (по объекту и номеру строки), перечислений и т.п., но нет у большинства таблиц, не имеющих объектного представления (регистры сведений, регистры накопления, регистры бухгалтерии, вычисленные итоги, таблицы регистрации изменений и т.п). Всё логично и правильно. Почти.
( Проблема и решение ) | | comments: 4 комментария or Оставить комментарий |
| Крайнее 2-3 недели рабоа с 1С 8.0 у меня напоминает нескончаемый танец с шаманским бубном. Дело в том, что среда разработки решения не даёт прикладному программисту полного контроля над такой важной частью структуры БД, как индексы. В общем-то доступных инструментов большинству программистов 1С, которых я повидал, более чем достаточно. Каждому третьему "одинэснику" вообще придётся объяснять, что такое "индекс" (я не шучу!). А уж даже чем отличается индекс по двум полям в одном порядке и в другом - это в среднем понимает один из десятка. Но я отвлёкся. По сути набор индексов для таблиц достаточно сильно ограничен, если сильно упрстить, то получается, что для каждой таблицы есть несколько предопределённых индексов и несколько дополнительно заданных разработчиком. Причём все они некластерные и почти все неуникальные. Причём почти всегда индексы создаваемые разработчиком - для одного поля (формально это не так, но по смыслу - очень близко к этому). Так вот нехилую часть времени приходится уделять тому, чтобы запросы в 40ГБ базе на многомиллионнозаписевых таблицах выполнялись за разумное время. Приходится создавать/убивать индексы, приходится реструктуризировать запросы и таблицы.
Ну и наткнулся я на достаточно специфичную особенность оптимизатора MS SQL. Пусть есть таблица проводок. Нам интересны сейчас только 4 её поля:СчетДТ - Счет дебета, FK на таблицу счетов
СчетКТ - Счет кредита, FK на ту же таблицу счетов
ДатаПроводки - дата для каждой проводки
НекоторыйРеквизит - поле, по которому группируются результаты (оно нам не нужно) Есть в этой таблице еще с десяток-полтора полей, но они никак на демонстрируемую особенность не влияют.
Есть индексы, которые определяются системой и разработчик прикладного решения на них не влияет:1. СчетДТ, Период
2. СчетКТ, Период
3. Период, НекоторыйРеквизит Все остальные индексы нам никак не подходят. Статистика в нормальном состоянии, индексы тоже.
Выполняется запрос:SELECT [Проводки].[НекоторыйРеквизит], COUNT(*)
FROM [Проводки]
WHERE ([Проводки].[СчетДт] = @P1 OR [Проводки].[СчетKт] = @P1)
AND [Проводки].[ДатаПроводки] >= @P2 AND [Проводки].[ДатаПроводки] <= @P3
GROUP BY [Проводки].[НекоторыйРеквизит] Для этого запроса MS SQL использует индекс (3). Выполняется несколько секунд, т.к. в этом периоде около млн. записей. Уродство. Я переписал запрос:SELECT [Проводки].[НекоторыйРеквизит], COUNT(*)
FROM [Проводки]
WHERE ([Проводки].[СчетДт] = @P1 AND [Проводки].[ДатаПроводки] >= @P2 AND [Проводки].[ДатаПроводки] <= @P3) OR
([Проводки].[СчетKт] = @P1 AND [Проводки].[ДатаПроводки] >= @P2 AND [Проводки].[ДатаПроводки] <= @P3)
GROUP BY [Проводки].[НекоторыйРеквизит] И чудо свершилось. Теперь используются индексы (1) и (2) которые почти мгновенно отбирают пару тысяч записей и уже потом аггрегируются результаты.
ЗЫ MSSQL2005, но в 2000 - то же самое. Запросы привёл на SQL чтобы тем, кто не знает 1С было понятно | | comments: 3 комментария or Оставить комментарий |
| | Срочно надо переползать с SQL Server 2000 на SQL Server 2005. На сложных запросах 2005-й ведёт себя значительно адекватенее. Ссобенно это проявляется с конструкциями "select ... from .... left join b on .... where b.id is null" к которым приходится прибехать из-за отсутствия exists и коррелированных подзапросов. | | comments: 9 комментариев or Оставить комментарий |
| Пользователь жалуется на проблему.
Марина Павловна : "Ну я посмотрю сейчас код. [имея в виду исходный код]"
Пользователь: [Самоуверенно] "Я и так могу сказать!"
...Все удивлёно смотрят на пользовательницу...
Пользователь: ноль-сто-двадцать-один-тридцать-один! [код элемента справочника] | | comments: Оставить комментарий |
| 1С 8.0. Встала задачка отформатировать текст. Ну т.е. есть длина строки в символах, есть текст почти без разделителей строк, нужно разбить по строкам. Желательно предусмотреть возможность управления выравниванием (влево, вправо, в центре, по ширине). Используется данный кусок, например, при создании электронных писем.
( Элегантное решение с комментарием ) | | comments: 4 комментария or Оставить комментарий |
| Я вышел на работу почти 2 января. Ну в Синар - 3-го. Не суть важно. 13 месяцев назад я знал, что это будет самое "весёлое" время. Во многом состояние нашего отдела мне напоминает маёвку. Не... не ту маёвку, которую видело большинство студентов НГУ. А ту, которую видели ДНДшники. Локальный ПИЗДЕЦ районно-городского масштаба. К которому готовились долго, но всё равно приготовились не полностью. Причём помещение именно нашего отдела напоминает ОПОП в 20-21 час. Куча абсолютно разного народу, все заняты своим делом, старшие групп следят за своими группами, все заебались, периодически кричим друг на друга и на посетителей, но не со зла а просто чтобы быстрее дошло. 70% отдела куда-то выбежали мелкими группами на помошь, самые боссы разруливают различные вопросы со смежными отделами. Тяжелее всех, конечно, тем кто на скамейках техподдержке - они берут на себя основной удар. Но там более менее всё понятно... А вот что делается на периферийных направлениях... Принимаются компромиссные или бескомпромиссные решения, разборки с чужими и своими, нехватка ресурсов (времени, людей и пр.). И что самое забавное - вознаграждение непропорциональное моральным затратам да и риск получить по башке даже от своих. Такой вот штаб внедрения. Чуть-чуть утрировано и преувеличено, но всё же именно так: достаточно весело и интересно (несмотря на то что абсолютно серьёзно и достаточно тяжело). | | comments: Оставить комментарий |
| 1. В ходе ожесточённых боёв с тупыми бухами были отвоёваны несколько пунктов в инструкции по внесению документов продаж внутри холдинга.
2. Был утрачен и снова восстановлен контроль над работой одного из отделов. Они два дня вколбашивали криво номенклатуру. Потом это всплыло. Ничего. Ударно переколбасили правильно.
3. Снабженцы и маркетинг откровенно пытаются саботировать внедрение. Пиздюлей они получили.
Пиздец. День за три точно можно считать. И фронтовые 100 грамм наливать по утрам. Эх...
****
Вышла 1С 8.1. Из весёлого:
1. Описание встроенного языка. В 7.7 - 2 тома, в 8.0 в ранних релизах 3 тома, в поздних 4 тома, в 8.1 7 (!) томов. Я аж прям присел... Доступно и всерьёз...
2. XDTO и Web-сервисы. Наконец-то.
3. Улучшили работу с XML. Послали нах MSXML.
4. Добрались до возможности отладки кода, выполняемого на сервере (раньше отладчик не умел этого). А уж как развился сам сервер приложения...
5. Теперь сервер приложения может жить под линухом, а БД может жить под PostgreSQL.
6. Full Text Search
7. Более гибкое управление блокировками.
8. Отчетно-анализная подсистема стала еще более зверской.
Мы будем переходить на неё в марте (обещают релиз УПП соответствующий). Переход более-менее прозрачный. | | comments: 11 комментариев or Оставить комментарий |
| | Tags: | 1С | | Time: | 09:49 am | | Настроение: | убилбы |
|
| Предыстория. Один программист 1С написал кривую обработочку, которая слегка закосячила данные в базе при достаточно хитром её (обработочки) использовании. Второй программист поправил первую обработочку и написал вторую обработочку, которая ищет косяки, натворённые старой версией первой обработочки. И по поводу алгоритма работы второй обработочки такая вот фразочка:
"обр. ищет все несоответствия коэф-та ед. изм. дока, взятого из спр-ка ед. изм. коэф-ту ед. изм., указанным в самом доке." | | comments: 2 комментария or Оставить комментарий |
| |
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
speshuric