Если даже бабушки работают с Linux GUI — можно ли утверждать, что администратор Linux тоже сможет работать с Linux Gui? Ответ на этот вопрос не так очевиден, достаточно сделать небольшое путешествие от простого запуска инсталлятора под root, до мониторинга с графиками.

В 1С нет проблем с инструментами для создания мультиязычного интерфейса, а код можно писать и на русском и на английском в отличии от «нормальных языков» программирования. Однако перевод данных (справочников, текстовых значений реквизитов) по‑прежнему представляет собой непростую архитектурную задачу. Но элегантный выход есть.

Прошел год с последнего 1С DevCon и 13-14 апреля будет новый, самое время попросить у 1С подарки на новый год. Главное попросить правильно

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

File system level backup  в Postgres это первое чему нужно научится при использовании Postgres . Никакие pg_dump \ pg_restore не заменят Полный бэкап на уровне файлов. File system level backup это первая ступень для подготовки к Continuous archiving. Понимание архитектуры хранения – это фундамент, по которому можно понять сможете ли Вы жить с Postgres на больших объемах или у Вас другой путь?

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер), до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя  было сделать проще как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей то лабораторной работы? Статья адресована прежде всего специалистам 1С избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

1С в своих типовых конфигурациях активно использует формирование отчетов в фоне, даже печатных форм документов. Последние несколько месяцев это стало раздражать. Как сохранить психическое здоровье, вероятные причины, обходной путь и как жить дальше?

В Postgres достаточно подробная документация, и видимо поэтому , при инсталляции Postgres для 1С большинство параметров приходится выставлять самим. Параметров в Postgres много, а составить эффективную комбинацию не так просто. Все упрощается если рассмотреть профиль нагрузки, например, 1С это прежде всего профиль OLTP нагрузки – так устроены его метаданные (объекты).  Если сосредоточится на оптимизации профиля OLTP, понимание Postgres сразу упростится.

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при маштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3,  складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

Непреднамеренный тест чат бота Ростелекома, дал повод задуматься о том что ИИ уже побеждает человека.

Кто не любит убирать мусор? Думаю практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

В 1С у нас есть редкая свобода перехода с одной СУБД на другую (MS SQL, Oracle, Db2, Postgres). Но чем больше база, тем больше цена свободы. Данная статья позволяет спрогнозировать время, которое Вы потратите на переход с MS SQL на Postgres простой конвертацией через Dt.

1С работает с СУБД  Postgres более 10 лет, а сейчас это единственный легальный вариант для инсталляций в России. Много ли мы потеряем в производительности по сравнению с MS SQL ? Выдержит ли Postgres 15.2 жесткий Highload со стороны 1С? Цель этой статьи - ответить на данные вопросы, с цифрами, которые можно использовать при расчете архитектуры.

При работе с ORM (object relation mapping) все время преследует ощущение постоянного создания монолитного приложения — один раз привязался к какой‑либо сущности (например, справочник Контрагенты) и весь код заполнен ссылками на эту конкретную реализацию. Можно ли независимо разрабатывать в ORM совместимые между собой справочник «Контрагентов» и использующий его документ «Платежное поручение», но при этом избежать жестких зависимостей? Спасут ли нас микросервисы? Пример на аннотациях Java демонстрирует как это возможно делать.

 ORM (Object‑Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM.  В предыдущих частях показана глубина проблемы

Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? / Хабр (habr.com)

Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД / Хабр (habr.com)

В этой части предложено решение со стороны СУБД (MS SQL , Oracle, Postgres)

ORM (Object‑Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM. В предыдущей части статьи Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? были изложены результаты теста, в этой статье ответы на самые часто задаваемые вопросы и новый тест.

ORM (Object-Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM . Причины приоткрывает данная статья.

Некоторые структурные проблемы в запросах 1С поменять невозможно без изменения платформы. Сколько производительности мы на этом теряем? На примере простого регистра сведений видно, что достаточно много.

Большие объемы данных вынуждают глубже смотреть в логику работы оптимизатора СУБД. Ваше понимание о выборе селективного индекса может расходится с логикой выбора оптимизатора SQL. Это еще больше привязывает конкретную систему к конкретной СУБД. Построение хорошего запроса к СУБД попрежнему остается искусством, а искусственный интеллект пока еще туда не добрался. Кто больше виноват - 1С или MS SQL - решать Вам.

Почему при росте объемов базы 1С все становится медленней, даже если все индексы правильно сделаны? В статье на простом примере с регистром сведений показана причина и как этого избежать. Кто виноват больше 1С или MS SQL решать Вам :)