1.C. Enterprise

Дневник капитана, дата '20250513'
🔷 Изолента для транзакций 🔷

Перейдем букве 🔤 нашего ACID. Она говорит об изолированности (изоляции) транзакций. Т.е. никак две параллельно идущие транзакции не должны мешать друг другу. Ведь в таком случае могут быть те или иные проблемы, аномалии. Выделяют следующий список аномалий чтения данных (по порядку, начиная с самых «страшных»):

💩 Грязное чтение (dirty read). Когда одна транзакция читает изменения другой незавершенной транзакции. В итоге вторая транзакция может не завершится, и то, что прочитала первая, будет «неправдой».

🎲 Неповторяющееся чтение (non-repeatable read). Случай, когда открытая транзакция прочитает записи один раз, потом до закрытия другой раз, и эти данные будут не совпадать, т.к. их изменила другая (уже завершенная) транзакция.

👻 Фантомное чтение (phantom reads). Похоже на неповторяющееся чтение, но здесь ситуация, когда сами строки по полям остаются теми же, но целые строки добавляются и исчезают. И внутри транзакции по тем же условиям выберется другое количество строк.

В итоге, как я писал, оказалось, что бороться со всеми аномалиями дело довольно дорогое. Поэтому выделили несколько уровней изоляции, которые решают те или иные проблемы. Дальше можете проверить себя. Я буду перечислять эти уровни, а вы постарайтесь понять, какой уровень используется в вашей системе.

1️⃣ Read uncommitted (чтение незафиксированных данных). Это самый низкий уровень, все аномалии в нем могут быть.

2️⃣ Read committed (чтение фиксированных данных). Нет грязного, но есть неповторяющееся и фантомное чтения.

3️⃣ Repeatable read (повторяющееся чтение). Допустима только аномалия фантомного чтения.

4️⃣ Serializable (упорядочиваемость). Нет никаких перечисленных выше аномалий.

В идеальной картине ACID используется уровень Serializable, все чинно, благородно. Но очень медленно. Транзакциям приходится выстраиваться в очередь, чтобы поработать с той же таблицей.

На деле же чаще всего в популярных СУБД (и 1С также) используется уровень Read committed. Скорее всего, и у вас тоже. Т.е. вы не встретите грязное чтение, остальное для вас в порядке вещей.

Следует еще сказать о различных реализациях уровня Read committed, которые не будут давать оператору в транзакции читать незафиксированные данные. Первый способ – это наложение блокировок на читаемые оператором данные. Так работает MS SQL Server. Второй – это использование версионирования. Оператор читает последнюю зафиксированную версию (снимок) данных. Такой метод используется в PostgreSQL. В MS SQL Server тоже есть такой вариант, и он выделен в отдельный уровень - Read Committed Snapshot.

Но а если вы все же захотели поднять уровень изоляции, можно ли это сделать в 1С? И да, и нет. Вообще, борьба с аномалиями и изолированность обеспечивается за счет блокировок. Поэтому в 1С уровни изоляции зависят от режимов управления блокировками в транзакции.

По умолчанию сейчас и для самой конфигурации, и для всех таблиц выставляется режим Управляемый. Это говорит о том, что в СУБД остается уровень Read committed, а всеми остальными блокировками мы управляем сами.

Второй вариант режима, который можно выставить — это Автоматический. Тогда в случае СУБД MS SQL Server уровень повышается до Repeatable read или Serializable. А для PostgreSQL, что интересно, так и остается Read committed. Меняется область блокировки, захватываются не отдельные записи, а целые таблицы.

В стандартном же режиме управляемых блокировок 1С уже не «надеется» на СУБД, а накладывает свои объектные блокировки, которые привязаны к прикладным объектам. В этом же режиме и разработчик может наложить необходимые кастомные блокировки. Но это уже совсем другая история.

Дневник капитана, дата 06.05.2025
🪓Сага о распределенных транзакциях🪓

В прошлом посте я кратко сказал про атомарность транзакций. Теперь хочу поговорить, как ее можно добиться в распределенных системах. В 1С мы привыкли, что все операции по какому-либо бизнес-событию происходят в одной системе – монолите. Но в современном ИТ очень много работает на микросервисной архитектуре: совокупности разрозненных систем, между которыми идет обмен данными.

Рассмотрим классическую ситуацию, когда человек оформляет заказ на сайте. После нажатия кнопки ✅Заказать на той стороне должно произойти множество действий: складской сервис зарезервировать товар, другой – списать или начислить бонусы, третий – записать заказ в историю заказов и т.д. Что делать, если один из сервисов сообщил об отказе, в то время как другие уже выполнили операцию? Например, бонусы списались, заказ в историю попал, но на складе вдруг товара не оказалось?

Дальше пойдет много поэтических терминов. Для решения этой проблемы обычно используется паттерн Сага (Saga) ⚔️. Идея его в том, что последовательность разрозненных транзакций в каждом микросервисе как рассказы об отдельных подвигах складываются в единую сагу о приключениях нашего бизнес-события. Если в каком-то из сервисов произошел откат транзакции, должны быть вызваны компенсирующие операции (откат, сторнирование) во всех уже пройденных сервисах.
Но как обеспечить эту согласованность? Тут есть два основных подхода:

🎻 Оркестрация (Orchestration). В данном случае выделяется специальный сервис оркестратор-дирижер, который следит за полным выполнением большой транзакции. С него начинается выполнение операции, он знает все шаги ее выполнения, следит за статусами, отправляет команды отмены нужным точкам при необходимости.

💃 Хореография (Choreography). Здесь нет начальника, каждый сам отвечает за свои действия, танцует свою партию. Сервисы общаются сообщениями между собой через какое-то общее пространство (шина, Kafka, RabbitMQ). Один сервис выполнил, написал БонусыСписаны, другой написал – Ахтунг:ТоварНеЗарезвирован, все другие сервисы получат это сообщение и обработают как необходимо.

Вот такие подходы есть в микросервисах, но вернемся к 1С. Можно привести пример распределенной транзакции, когда надо записать документ в базе и одновременно выполнить операцию в другой системе по REST API. Тривиальным решением может служить следующий кусок кода:

НачатьТранзакцию();
Попытка
    ДокументОбъект.Записать();
    Ошибки = ВыполнитьОперациюПоAPI(ДокументОбъект.Ссылка);
    Если ЗначениеЗаполнено(Ошибки) Тогда
      ВызватьИсключение Ошибки;
    КонецЕсли;
    ЗафиксироватьТранзакцию();
Исключение
    ОтменитьТранзакцию();
КонецПопытки;

Главное в этом коде, что выполнение операции по API стоит после записи документа в нашей БД. Ведь отменить событие в другой системе при ошибке нашей записи будет намного сложнее, нежели запись у нас. Конечно, здесь есть проблема, что мы открываем транзакцию и начинаем длительную операцию обращения к внешним ресурсам. Из-за этого транзакция может надолго зависнуть, что приведет к потере производительности.

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

А сталкивались ли вы с такими распределёнными транзакциями? Какие решения использовали?

Дневник капитана, красивая дата 05*05=25
➖Кислотные транзакции➖

Захотелось рассказать про темы, которые обычно не часто обсуждаются в среде 1Сников: транзакции, блокировки и связанные темы. В первом посте расскажу о самих транзакциях.

Думаю, что такое транзакция знает большинство. Ну, напомню кратко на всякий. Это такие операции с базой данных (в первую очередь), которые выполняются либо все, либо ни одной (при какой-либо проблеме, ошибке). Отдельно часть операций из транзакции выполнять не допустимо.

Еще в 1970-х годах был выдвинут набор требований к транзакциям, который называется ACID 🧪:
Atomicity - атомарность
Consistency - согласованность
Isolation - изоляция
Durability – устойчивость
Разберем каждую букву подробнее.

⚛️ Атомарность
Этот принцип как раз говорит о том, что транзакция неделимая, она может быть зафиксирована либо вся, либо ни одна ее часть. В общем-то, тривиальное требование для транзакции, верно? Да, в обычном случае так оно и есть. Интересней становится, когда у вас сложная система, состоящая из разрозненных узлов. Потом разберем в отдельном посте, как это решается в микросервисной архитектуре, и что можно сделать в 1С.

🤝 Согласованность
Транзакция должна приводить систему из одного консистентного состояние в другое. Это могут быть такие более низкоуровневые требования, как уникальность ключей, отсутствие битых ссылок и т.д. А могут быть и требования, наложенные бизнес-логикой: если деньги с одного счета ушли, то на другой пришли; на складе не может быть отрицательное количество товара и подобное.

Если за первый набор требований отвечает сама СУБД, то о вторых нужно озаботиться разработчикам. Это решается проверками, которые происходят перед или во время транзакции записи данных. Однако интересная ситуация может произойти, когда между проверкой и выполнением операции влезет другой процесс и нарушит логику. Это дело для блокировок, о которых расскажу в другом посте.

🔒 Изоляция
Транзакции должны быть изолированы друг от друга, никак одна начавшаяся или совершенная транзакция не должна "заафектить" открытую другую. Это требование оказалось слишком жестким, поэтому чистая изоляция сейчас почти не используется. Была выделены разные уровни изолированности транзакций, которые в разной степени смягчают это требование. И это тема для отдельного поста.

💪 Устойчивость
Это значит то, что если транзакция завершена, то разные внешние и низкоуровненые факторы не должны удалить изменения, сделанные ею. Т.е. если транзакцию зафиксировали, а через секунду свет вырубили, то после включения ничего не должно потеряться. Здесь можно выдохнуть, нас, как разработчиков логики, это не касается. Это уже все должно работать на уровне СУБД и железок. Но бэкапы все равно делать надо!

Если совсем кратко, то на этом все, дальше я уже напишу отдельные посты по упомянутым темам.

​​Дневник капитана, дата ‘2023-07-28’.
Мой корабль улетел в совсем удаленные части Вселенной, поэтому прошу прощения за долгое отсутствие связи.

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

Я сейчас собираю команду на новый проект и ищу разработчиков. Считаю, что вакансия идеальна для «1Сника-свитчера» на Java. Разработка ведется на специальной платформе чем-то похожей на 1С, необходимы только нормальные знания Java Core и SQL. Но за последний я не волнуюсь, любой уважающий себя 1Сник его должен знать.

Так что если вы занимались Java, даже для себя, в некоммерческих проектах, предлагаю вам посмотреть на эту вакансию. Работать можно и удаленно. Там будет тестовое задание, как раз можно будет проверить себя. Всем успехов!

Всем привет! Уже завтра, 22 декабря встречаемся онлайн: INFOSTART AWARDS 2022 и новогодняя игра “Что Если Тогда”

Присоединяйтесь к эфиру 22 декабря в 19:00 МСК!
➡️Премия INFOSTART AWARDS 2022: узнайте, кто станет лауреатом
Премия Infostart Awards присуждается людям, наиболее ярко проявившим себя в определенной области сферы 1С и подтвердившим свой вклад статьями, разработками, обучающими выступлениями на эту тему.
Эксперты отрасли 1С в прямом эфире объявят лауреатов в 9 номинациях.

➡️ Выиграйте призы
В прямом эфире мы разыграем среди зрителей подарки - эксклюзивное домино для 1С-ников. Инфостарт. Домино - это игра для программистов 1С и всех, кто знает язык запросов 1С. Цель игры - составить запросы, используя ключевые слова и метаданные.

➡️Попробуйте ответить на каверзные вопросы вместе со знатоками
После церемонии награждения лауреатов, пройдет интеллектуальная игра “Что Если Тогда”. Как обычно - все вопросы посвящены тематике 1С.
Для новогодней игры мы собрали сильную команду знатоков-корифеев, экспертов из мира 1С и опытных авторов вопросов.
👉 Присоединяйтесь к эфиру
Когда: 22 декабря в 19:00 МСК

Вот так вот уходишь из 1С, а там такое: https://infostart.ru/job/vacancy/1676535/
Update: Как сказали, это фейк, просто такая дешевая реклама для раскрутки. Так что расходимся, нас в очередной раз...

Дневник помощника капитана, желтая Дата(2022, 6, 22).
Слышали о таком инструменте на основании ИИ, как GitHub Copilot, который пишет код вместе с программистом? Я решил узнать, можно ли использовать эту штуку для разработки на 1С.
Как обстоят дела сейчас, смотрите в видео: https://www.youtube.com/watch?v=wve0GqAMW3o

Update
Ко мне обратился заказчик, для которого я в свое время делал эти обработки. Сказал, что они все еще используются в его коммерческих продуктах, поэтому публикация этих решений будет для него убыточна.
Так что простите, опен сорса сегодня не получилось. 🤷‍♂️

Дневник капитана, черно-белая дата ‘20220620’.
Еще давно на канале я немного рассказывал о том, как писал алгоритмы генерации двумерных штрихкодов QR, DataMatrix, PDF417 на чистом 1С.
Решил теперь выложить эти разработки в открытый доступ:
статья на Инфостарт,
репозиторий на GitHub.

​​Дневник капитана, нежелтая дата Fri Jun 10.
Сегодня я продолжу рассказ о моем переходе на Java и кратко поведаю какого 1Снику в мире «настоящего» программирования.

Сразу хочу начать с такого дисклеймера: я, пожалуй, пока еще не могу считаться таким тру-тру-тру разрабом на Java. Я устроился в компанию, которая использует платформу собственной разработки – ORM, некий аналог 1С. Там тоже в визуальном режиме создаются таблицы для справочников, документов, делаются для них формы, отчеты, обработчики. Отличие лишь в том, что серверный код пишется на Java, запросы на SQL, а клиентский – на JavaScript.
Но развернуться все равно есть где, есть много разных интересных мини-проектов и задач. Например, я подготовил нагрузочное тестирование на JMeter, теперь занимаюсь написанием интеграции базы и мобильного приложения посредством Kafka. Кстати, сейчас компания ищет новых сотрудников, так что если у вас есть некоторые знания Java или JavaScript, а также желание поработать не на 1С, можете попробовать.

Можно сказать, что мне повезло найти такую вакансию, где мой опыт 1Сника был релевантным, если бы я пошел в чисто Java, то только джуниором, с большой потерей з/п. Да, могу вас расстроить, даже 1Снику с 10-летним стажем тяжело ворваться в мир Java.
Тут вспоминаются издевки, что 1Сники – это не программисты. Конечно, это не так, но язык 1С стоит в стороне от других языков и намного проще и примитивнее. Не знаю, я не могу согласиться с выражением, что, дескать, неважен язык, главное просто решать задачу. Может, я еще не дорос до такого просветления, но в каждом языке есть свои особенности, и только понимая их, можно писать по-настоящему хорошие программы.

Кроме стандартного императивного программирования, из которого состоит 1С, в Java еще есть ООП, Лямбды, многопоточность и многое другое… Вот, например, задания на позицию джуниора, которые не кажутся такими уж простыми. И это только сама Java Core.
А еще есть почти стандартный фреймворк Spring, который использует инверсию управления, внедрения зависимостей, написание аннотаций, так что в начале мозг может взорваться. Кстати, недавно Никита Федькин представил ОСень, аналог, написанный на OScript. Это если захочется, вдруг, теперь можно взорвать голову не на Java.

Получается, если 1Сник все 10 лет только занимался поддержкой типовой Бухгалтерии, то, считай, по «ветке развития» Java он и не продвигался. Но и в экосистеме 1С можно заниматься вещами, которые помогут в работе на других языках. Что я могу перечислить:
• Написание SQL запросов (Это одна из самых сильных черт 1Сников);
• Работа с конкретными базами данных непосредственно (PostgreSQL, MS SQL, MySQL…);
• Интеграции с различными системами посредством REST API;
• Использование таких инструментов как Kafka, Rabbit MQ, Redis, Docker, Jenkins, Kubernetes и другие модные слова;
• Работа через Git, EDT, использование CI/CD.
В экосистему 1С начали внедряться общемировые практики разработки, но еще с отставанием и недостаточно широко.

Заканчивая, может показаться, что заметка у меня получилась какая-то в пессимистичном ключе, не вдохновляющая… Однако все можно сделать, в ИТ приходят и в 40 из совсем других областей, поэтому все же программисту 1С будет переключиться намного легче. Главное – это настоящее желание, а к нему придут усердие, силы и время.
В следующий раз я расскажу о процессе обучения на своем личном опыте.

В эту пятницу, 3 июня пройдет летняя онлайн-игра “Что Если Тогда” для 1C-специалистов.🧐

Знатоки команды “Асы Одина” VS команда зрителей.🔥

👀Смотрите игру и попробуйте отгадать ответы на каверзные вопросы про 1С.

⏰Начало игры в 19:00 по московскому времени.
⚡️Зрители определят лучшего знатока и автора вопроса.

Команда Инфостарта, знатоки и авторы вопросов гарантируют захватывающее шоу и отличное настроение💥

👉Присоединиться к игре и познакомиться с командой “Асы Одина” - https://infostart.ru/webinars/1658007/

​​Дневник капитана, нежелтая дата Fri May 20.
Мой корабль совершил крутой разворот и отправляется в другую неизведанную галактику.

А если более прозаично, я решил пока оставить 1С и уйти в Java разработку.
Мне уже стало «тесно» в стеке 1С, не хватало выразительности и глубины языка, а также поднадоели однотипные задачи по схожей тематике.
Мысли о «побеге» посещали меня в фоновом режиме очень давно, лет 10, наверное. Но активная стадия поиска и перехода у меня началась около трех месяцев назад. Я стал больше заниматься, выложил резюме, начал откликаться на предложения. В итоге могу сказать, что мне повезло, я нашел работу с не очень большой потерей по зарплате.

Но это не значит, что я порвал с 1С окончательно. Через две недели буду проводить игру Что Если Тогда с командой Артура Аюханова. В октябре собираюсь принять участие в конференции Инфостарт. У меня еще есть разработки, которые хочу довести до ума и поделиться ими с общественностью.
Также хотел бы применить знания Java, чтобы принять участие в развитии инструментов для разработчиков 1С. Думаю заняться либо развитием BSL LS, либо написанием плагинов для EDT.

Так что в полку «свитчеров» прибавилось. Хотя, может, через некоторое время я осознаю свою глубокую ошибку и вернусь в лоно родной 1С.
Если вам интересна эта тема, пишите комменты, спрашивайте. Буду тогда писать заметки «капитана дальнего плавания» дальше.

Митапы Инфостарта вернулись! И теперь они БЕСПЛАТНЫЕ! 🔫💣🚀
Первый митап 2022 года будет посвящен внедрению и применению DevOps-практик в командах разработки на 1С и пройдет 18.02.2022. Модераторы - Артур Аюханов и Александр Кунташов 💥💥💥
Что тебя ждет:
✅Максим Савельев - От хранилища к ГитХаб Флоу: наш опыт перехода
✅Юрий Гончарук - Тестирование обменов КД 3.0
✅Андрей Истомин - Опыт внедрения DevOps-практик с помощью Gitlab
✅Сергей Голованов - Докер и 1С: выполнение тестов в windows-контейнерах
✅Дмитрий Шерстобитов - DevOps без тормозов
✔️Круглый стол "Проблемы внедрения DevOps-практик в командах разработки на 1С"
Стань участником! Кликай ➡️ https://clck.ru/avxoc

Инфостарт снова хочет захлестнуть нас своей волной митапов. На этот раз бесплатных!

​​Дневник капитана, желтая дата ‘20211228’.

На прошлой неделе прошла новогодняя игра «Что Если Тогда». Спасибо знатокам, музыкантам, организаторам, телезрителям за классное мероприятие. Если вам интересно, как прошла игра, можете прочитать отличную заметку Вики Дорохиной. Но я сейчас не об этом.

На игре использовалась конфигурация собственной разработки для подсчета очков, выбора вопросов, показа картинок… Были замечания по функционалу этого приложения, в частности к тому, как реализован волчок. Да, действительно, это было сделано на коленке незадолго до самой игры.

Так вот, у вас есть возможность «приложить руку» к этой разработке. Я выложил конфигурацию на GitHub. Мы собираемся продолжать проводить игры, возможно, следующая игра состоится уже через пару месяцев, так что стильное приложение-компаньон нам точно пригодится.

Плюс это еще можно считать способом попрактиковаться в совместной разработке сообществом на GitHub. К сожалению, в 1С довольно мало open-source проектов и мало активностей. Если обычный 1Сник может стесняться делать что-то в крутых разработках, то в моем репозитории боятся нечего, там все максимально примитивно и just for fun.

Так что буду рад вашим пул-реквестам, вот и сам репозиторий: https://github.com/KonstantinHeinrich/WhatIfThen

Объявляем двухчасовую готовность!
Сама игра будет проходить в Zoom.
Также будет вестись прямая трансляция в YouTube.
Чат в Zoom будет закрыт, чтобы мы не отвлекали знатоков. Поэтому заходите в группу Telegram, там можно будет выдвигать версии, обсуждать вопросы и все остальное.

​​Дневник капитана, желтая Дата(2021, 12, 17)

Меньше чем через неделю, в ближайший четверг 23 декабря в 19:00 в онлайн формате пройдет уже четвертая интеллектуальная 1С:Игра Что Если Тогда.

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

Что еще приятно, теперь вопросы будут по-настоящему от телезрителей. Спасибо откликнувшимся, у нас уже накопилась приличная пачка вопросов, которой мы можем мучать знатоков. Но чем больше, тем лучше, поэтому если у вас есть идеи, присылайте их мне в личку. Авторы вопросов будут приглашены почетными гостями в нашем элитарном клубе, и после игры автор лучшего вопроса уйдет с подарком.

Но вообще мы ждем всех, кому интересны интеллектуальные состязания, тема 1С, душевная музыка и приятное общество. Заходите в четверг, в 19:00, к нам в Zoom. Подробности здесь

​​Дневник капитана, желтая дата ??.??.????.
Загадочный символ ?

В последнее время товарищ @SeiOkami так разошелся с викториной на своем канале, что открыл скрытый зарезервированный знак в языке 1С. Это символ вопроса ?. Ему посвящены викторины раз и два.

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

Раз = 0;
? = 1;

То в переменной Раз будет лежать единица.

Знак ? «забирает» себе не только названия переменных, но и методов. Именно поэтому код из викторины:

Сообщить = 1;
Сообщить(?);

покажет единицу, т.к. происходит вывод переменной Сообщить.

Как же можно применить этот волшебный символ? Во-первых, как уже предложил SeiOkami, наконец-то у нас появился краткий инкремент!

МояПеременная = 0;
МояПеременная = ? + 1; 
Сообщить(МояПеременная); // Выведет 1

Эту операцию можно использовать со всеми стандартными операндами: +, -, *, /, %.

Можно сделать еще более краткую запись преобразования переменной. Например:

МояПеременная = 5;
? = ? + 1;
? = ? * 2;
? = ? / 3;
Сообщить(МояПеременная); // Выдаст 4

Или вот так собирать строку:

МояСтрока = "";
? = ? + "Привет, ";
? = ? + "Мир ";
? = ? + "1С!";

Жаль, что нельзя так преобразовывать переменные через функции. Код МояСтрока = СокрЛП(?); выдаст ошибку Переменная не определена (СокрЛП), т.к. ? возьмет имя метода слева.

Какие еще есть примеры применения? Бывает, надо собрать структуру из переменных с тем же именем, чтобы передать ее куда-то дальше. Теперь можно писать так:

Структ = Новый Структура("ПеременнаяРаз,ПеременнаяДва,ПеременнаяТри");
Структ.ПеременнаяРаз = ?;
Структ.ПеременнаяДва = ?;
Структ.ПеременнаяТри = ?;

Можно обращаться и к полям знака ?. Например, следующий код выведет всех родителей ссылки:

ТекущаяСсылка = ПереданнаяСсылка;
Пока Не ТекущаяСсылка.Пустая() Цикл
    Сообщить(ТекущаяСсылка);
    ТекущаяСсылка = ?.Родитель;    
КонецЦикла;

Еще можно сокращать логические условия. Вот проверка вхождения даты в диапазон: ДатаНачала < МояПеременнаяСДатой И ? < ДатаОкончания. А какие вы можете придумать примеры для этого магического символа?

Происхождение этой багофичи также загадочно, как и она сама. Известно лишь, благодаря тому же хакеру SeiOkami, что ? работает как в версии 8.0, так и в последних 8.3. Т.е. разработчики платформы, думаю, о ней не могут не знать, но не трогают. Может, эта функция была задумана изначально в 8-й платформе, но от нее отказались. Может, это какие-то «неубранные отходы» от тернарного оператора.
Понятно, что на проде это использовать не следует, так, только поиграться. Но я хочу сказать, платформщики, если вы меня слышите, не убирайте, прикольная функция же! Наоборот задокументируйте, ну и еще доработайте, чтобы ? только переменные брал, методы игнорировал. Предложение по развитию платформы написать что ли… 🤔

Друзья, товарищи, коллеги.
Я организую сбор средств для семьи Павла Чистова.

Всё собранные деньги будут перечислены жене Павла Темире (когда получится с ней связаться).

Пополнить счёт можно с помощью ссылки:

https://www.tinkoff.ru/rm/gryzlov.nikita3/fS29P81300

Либо совершив банковский перевод по реквизитам:

РУБЛИ:

Банк-получатель:
АО «Тинькофф Банк»

Номер счета:
42301810600005342856

Корр. счет:
30101810145250000974

БИК:
044525974

Получатель:
Грызлов Никита Алексеевич

Назначение платежа:
Перевод средств по договору № 8156376462 Грызлов Никита Алексеевич НДС не облагается

ИНН:
Укажите ваш ИНН, если его нет, поле оставьте пустым (при строгой необходимости заполнять поле – укажите 7710140679)

КПП:
Поле оставьте пустым (при строгой необходимости заполнять поле – укажите 771301001)

—

ДОЛЛАРЫ:

Банк-корреспондент (Intermediary)
JPMORGAN CHASE BANK, N.A. NEW YORK, NY US

SWIFT банка-корреспондента (Intermediary’s Bank SWIFT)
CHASUS33

Счет в банке-корреспонденте (Intermediary’s Bank Account)
464650808

Банк получателя (Beneficiary Bank)
Tinkoff Bank

Адрес банка получателя (Beneficiary’s Bank Address)
Bldg. 26, 38A, 2 Khutorskaya str., Moscow, 127287

SWIFT банка получателя (Beneficiary’s Bank SWIFT)
TICSRUMM

Получатель (Beneficiary)
Gryzlov Nikita Alekseevich

Счет получателя (Beneficiary’s Account)
42301810600005342856

Назначение платежа (Payment Details)
Own funds transfer under Agreement № 8156376462 Gryzlov Nikita Alekseevich. Without VAT.

—

ЕВРО:

Банк-корреспондент (Intermediary)
J.P.MORGAN AG FRANKFURT AM MAIN, DE

SWIFT банка-корреспондента (Intermediary’s Bank SWIFT)
CHASDEFX

Счет в банке-корреспонденте (Intermediary’s Bank Account)
6231608701

Банк получателя (Beneficiary Bank)
Tinkoff Bank

Адрес банка получателя (Beneficiary’s Bank Address)
Bldg. 26, 38A, 2 Khutorskaya str., Moscow, 127287

SWIFT банка получателя (Beneficiary’s Bank SWIFT)
TICSRUMM

Получатель (Beneficiary)
Gryzlov Nikita Alekseevich

Счет получателя (Beneficiary’s Account)
42301810600005342856

Назначение платежа (Payment Details)
Own funds transfer under Agreement № 8156376462 Gryzlov Nikita Alekseevich. Without VAT.

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