German Jet

nopik, прочел вопрос и комментарии, пришел к выводу, что вы просто не поняли, что такое 1С.

Начать нужно с того, что фирма "1С" использует бренд "1С" для созданной ею платформы "1С:Предприятие", в котором можно описывать требуемую логику хранения и обработки данных на языке "1С", а готовые для эксплуатации решения называются "конфигурациями 1С" (УТ, УП, УХ и остальные буквы). Если приводить аналоги, то платформа 1С - это JVM, язык 1С - это Java, а конфигурации 1С - это программы, которые могут быть написаны на базе Sping Boot (в 1С - это БСП) или J2EE (более старые решения типа УПП).

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

OData - это стандартный интерфейс платформы, который позволяет получить веб-доступ ко всей функциональности конкретного решения. Обмен данными происходит в две стороны - можно реализовать сложные CRUD-операции.

А возможно-ли то же самое - но наоборот? Т.е. указать адрес сервера, а 1С сама получит объекты обмена и заберет их.

Конечно может! Можем даже расширить абстракции - Операционная Система может забирать данные, серверное железо может забирать данные, Интернет может забирать данные, Вселенная может забирать данные.

Компьютерные технологии только в фильмах Джеймса Кэмерона обладают самосознанием, а в реальной жизни выполняют ровно то, на что их программируют программисты. Хотите реализовать "получит объекты обмена и заберет их" - напишите код, который будет подобное делать (или убедитесь в существовании уже написанного).

В идеале хотелось бы определить на сервере готовые диалоговые(или HTML) формы

Кто вас ограничивает? Изучайте JavaScript и другие веб-технологии, и реализуйте любые веб-формы согласно вашего полета фантазии.

В поставке "1С:Предприятия" есть собственный веб-клиент, для работы с которым необходим работающий веб-сервер (IIS, Apache) и установленная компонента для работы с веб-серверами (раз читали про OData, то должны знать). Это позволяет получить доступ к данным конкретной базы 1С через браузер, но только при условии, что конфигурация 1С написана в режиме совместимости с веб-клиентом (т.е. только новые конфигурации и даже среди них далеко не все).

какие-то стандартные для 1С элементы обмена для передачи таблиц, изображений, содержимого полей, состояний удаленной системы и т.п.

Уже пошли какие-то фантазии. Решения 1С в вебе могут работать со стандартными для веба "элементами обмена для передачи" - это типы JSON и XML - т.е. строки с числами плюс двоичные данные в формате base64

Нужно отображать ход и результаты лабораторных испытаний в 1С с возможностью управления процессом в реальном времени и передачи выбранных полей в виде каких-то стандартных типов приходно-расходных транзакций (такие в 1С вообще есть???) и документов.

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

в виде каких-то стандартных типов приходно-расходных транзакций (такие в 1С вообще есть???)

Из перечисленных терминов в 1С есть только "стандартные типы" - это числа, строки, булево, даты и ряд более сложных типов для работы с функциональностью платформы (работа с ОС, работа с архивами, работа с криптографией и так далее). Про понятие "приходно-расходные транзакции" никогда не слышал. В торговом документообороте есть понятие "приходно-расходных документов", которые еще называют "приходники" и "расходники", которые реализованные в некоторых конфигурациях 1С с торговым и бухгалтерским уклоном (те самые буквы - УТ, УП, УХ). "Транзакция" - это термин из теории баз данных, который позволяет как единую операцию выполнить несколько действий, которые должны одновременно или записаться или отклонится - платформа 1С реализовывает свои варианты транзакций и позволяет программистам описывать собственные для групповых обработок.

По COM я могу передать 1С список любых объектов - но не знаю, как объяснить ей - куда их засунуть. С кодом для COM проблем нет - он есть и будет любой (при чем тут вообще Delphi - непонятно) - но для него нужна, как минимум, Windows. API моего сервера тоже есть - с ним тоже никаких проблем.

Во первых, использование Windows и COM - это для пиратов, или очень богатых; обычные бизнесы, которым нужна стабильная работа и которые не хотят проблем, используют Linux.
Во вторых, по COM вы никуда и ничего не можете передать. Вы с помощью COM создаете справочники, документы и записи регистров, заполняете их вашими данными и записываете в базу. Исключением будут вызовы функций конфигураций, но тут вам и думать не нужно - просто передавайте как параметры ваши "список любых объектов", а их обработку внутри функции уже описал программист конфигурации.

И я ничего не хочу делать под 1С, для 1С или средствами 1С

Выше куча текста про то, как хотите делать веб-порталы и обработку данных " под 1С, для 1С или средствами 1С", а теперь даете заднюю??? Определитесь чего хотите!!!

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

А вы в этой схеме каким боком? Десятки тысяч (сотни тысяч?) пользователей документооборота 1С ежедневно работают в своих базах и получают все что им там нужно. Или вы тот самый "вымогатель", который хочет встроится в "схему"?

отсюда и вопрос: может ли это... изделие... получать данные извне не специфично к конфигурации как УТ, УП, УХ и остальные буквы, а универсально

Универсально - это и есть через открытые API - OData в вебе и COM на Windows. Все остальные варианты уже специфичны для конкретных конфигураций.

Есть, в принципе, клиент на NativeAPI - но простому пользователю, без редактирования конфигурации (так же как и на COM) доступа к нему нет - а если все таки есть - то скажите, где.

Не существует никаких "клиент на NativeAPI"! NativeAPI - это технология (описание API) для написаний внешних компонент для работы в адресном пространстве работающей базы 1С, как собственных библиотек. Примеры компонент написанных на технологии NativeAPI есть в стандартных торговых конфигурациях - это работа со сканерами штрихкодов, с электронными весами и принтерами чеков.

Если есть документ, описывающий как 1С может запросить объекты с сервера не 1С - то скажите, как он называется.

И наконец-то кольцо замкнулось и мы вернулись к тому с чего начали - у базы 1С, конфигурации 1С, кода 1С, сервера 1С и так далее нет никакой свободы воли - это все платформа для запуска написанного программистами кода. Если кому-то требуется запросить данные с внешнего сервера, то он пишет код или ищет уже готовый, кем-то другим написанный (на гитхабе или инфостарте).

но послушав 5 или 6 лекций по основам языка, я понимаю, что у меня абсолютно нет идей как применить эти знания на практике.

Прикол плюсов в том, что у плюсов наверное один из самых высоких порогов вхождения для написания какого-то полезного кода(по крайней мере среди си-подобных). Плюсы это прям игра в долгую:
1) сначала ты учишь базовые плюсы, которые не касаются стандартов, изучаешь что такое указатели и чем они друг от друга отличаются например int *const от const int * от const int *const и т.д. (непередаваое удовольствие в общем), изучаешь как работают указатели на практике и как работает память, пишешь сам базовые структуры хотя бы list, queue и пары других вещей, мб простую map сделаешь.
2) на плюсах из первого пункта почти никто не пишет сейчас, но они всё равно нужны для понимания языка поэтому дальше изучаешь стандарты c++11 - c++20, основные контейнеры, итераторы и т.д. немного можно коснуться многопоточки, чтобы понимать зачем оно вообще нужно
2.1) Изучение предметной области в которой хочешь работать, плюсовики сильно отличаются друг от друга, т.е. те кто пишут сетевые драйверы обычно не шарят за геймдев и сам код у них будет сильно отличаться, поэтому тебе будет нужно определиться с этой областью и уже изучать ее
2.2) Также тебе придется узнать, что такое системы сборок, т.к. многие либы в плюсах не устанавливаются одной командой как в питоне, а просят скомпилировать их и установить отдельно в системе и установить самому, и тебе самому придется для сборок нормальных проектов освоить хотя бы Cmake и make.
2.3) С кроссплатформенностью сейчас стало гораздо лучше (спасибо c++17 что добавил общее апи для работы с файлами), но если тебе что-то специифическое под винду понадобится, то тебе считай придется учить отдельный язык для винды (на мой взгляд питон было изучать чем апи винды)
3) В общем если ты пункты выше пройдешь, то скорее всего уже сам сможешь найти, что тебе делать дальше

Суть вопроса: есть ли какие-то пет-проекты для плюсов, которые можно реализовать после прохождения новых тем, или может быть плюсы уже не самая актуальная тема и стоит посмотреть в сторону других языков(может Rust?)

С тем сколько ты изучил, ты по сути ничего особо и не напишешь, мб какую-то консольную программу типа справочника с поиском и крудом. Плюсы специфичный язык и я советую его изучать, если тебе он прям нравится или ты очень хочешь стать разрабом на UE, т.к. это специфический язык, если хочешь быстрых результатов, то оставайся в питоне и развивайся в нём, можешь взять промежуточные варианты типа го/явы/шарпа там попроще писать и результаты будут быстрее чем в плюсах

Скорее всего - специфика Go-задач.

Дело в том что область применения ORM обычно ограничивается CRUD приложениями.
И если мы заходим в область утилит для ETL и BigData то там оказывается что ORM вообще не нужен.
Там работают во первых диалекты SQL, (Spark-SQL, Hive-SQL, MS U-SQL). Во вторых дизайн
entities очень громоздкий (по 500-1000 колонок). И эти колонки еще и двигаются во времени
следуя schema evolution на ходу. Тоесть добавляя новые колонки и расширяя типы от узких к широким.
Представить себе ORM в таких условиях просто невозможно. Кроме того ORM кеширует объекты
в коллекциях языка а это, сами понимаете не вопрос Bigdata и аналитики.

Вообще ORM - это пугало, которым пугают на собеседованиях новичков. Для java-junior знание ORM - уже
приравнивается к знанию сопромата и философии Конфуция. Знаешь ORM - получи должность
в банке и сиди себе с умным видом на митинге.

С моей точки зрения ORM ограничивает сильно в оптимизации запросов. Хинт уже так просто не поставить.

Кроме ORM (Object-Relational-Mapping) есть и другая философия. Не от объектов к реляциям а наоборот.
От базе к объектам. (Фреймворк MyBatis например). В нем причинно-следственная связь перевернута.
Сначала таблицы и хранимые процедуры существовали в БД и уже потом, a posteriori, разработчик
описывает для них мапппинги в обратном направлении.

Существует также миф о том что ORM позволяет лихо прыгать по разным базам. Ни разу я для себя этот
миф не подтвердил. Чем крупнее система - тем плотнее она сидит на лицензии от DBMS, и тем глубже
она использует фичи этой DBMS (язык хранимых процедур особые режимы таблиц и партишенинга)
и совершенно нет никакой надежды что миграция произойдет в один мышко-клик. Скорее наоборот.
Миграция - это боль и слёзы и крупные платежи сектору разработки и облачным провайдерам.
Баги и просадки перформанса в самых неожиданных местах БД.

Хотя для вашего pet-project ORM вполне удобен особенно когда вы тестируете например веб-приложуху
на H2 в перспективе с переходом на Postgres.

Основной стек был Java/Kotlin, сейчас Go - база основная Postgres. Продукты сервисные и внутренние, задачи адаптации и совместимости сразу под многие движки нет.

Ни там ни там не использовали ORM (точнее во времена Spring использовали и гибернейт и JPA и еще что-то, но от всего отказались). Иногда пилим "свой ORM", обычно это кодогенерация (из Yaml и в SQL и в GO) и обслуживает конкретный проект - это делается если система действительно сильно классическая базо-ориентированная и там сплошной CRUD.

Поясняю почему не ORM, точнее поясню почему никакие "фишки" ORM-движов нам не только не нужны, но и вредны некоторые.

1. Переносимость между БД - этой задачи не стоит, у нас не внешние продукты для самостоятельной установки куда угодно, у нас четкий стек баз и есть компетенции их использовать более продвинуто и с использованием всех возможностей, больше чем предлагает ORM
2. Автоматические миграции из кода - это вообще зло - ни один движок не порождает действительно хороших внятных схем, с доменами, дефолтами GENERATE AS, partition by и прочее, никто также не терпит автомиграций только от наката какого-то микросервиса в стек, миграциями управляем очень осторожно как отдельным процессом, тем более в микросервисной архитектуре обычно нет никакого "владельца" одного базы из сервисов
3. Мапинг кортежей в структуры - это на самом деле совершенно не сложно и свои, причем более удобные по поведению прокладыки пишутся за час и складываются в общую библиотеку и там можно лучше зарешать какие-то преобразования в DTO
4. Что касается самих запросов - мы обычно оптимизируем базы вьюхами, функциями и т.п. и соответственно одни и те же структуры порой запитываются из разных источников, то же самое касается кэширования, связывания сущностей и т.п. - базовые вещи легко кодогенерятся и не требуют никакой прослойки библиотечно, сложные все равно писать ручками в хитрые запросы
5. Всякие там каскадные обновления и множественные вставки - по факту это только от лени и в учебных проектах - это все так здорово. на деле лучше немного помучиться и сделать более внятные и явные бизнесовые операции по обновлению данных

Итого - ORM бы дал нам выигрыш если бы требовалась переносимость, если бы проекты были бы совсем рутинные и если бы не было компетенций по работе с БД. Для сложных внутренних проектов с наличием квалифицированных разработчиков БД - ORM как пятая нога собаке.

Еще раз подчеркну - в контексте - ORM - как "некая либа которая делает ORM и такая няшная, все умеет", если мы говорим про ORM как тип операции (Object Relation Mapping) то естественно такие операции есть и вспомогательные функции для этого тоже.

Вы, фактически, пытаетесь использовать паттерн проектирования Active Record. Почитайте про достоинства и недостатки этого паттерна, посмотрите как его лучше готовить, и можете смело применять, если это подходит вашей программе и вам это удобно.

Однако, лично я считаю этот паттерн вредным, потому что он намешивает всё в одну кучу. Это моё субъективное мнение, и я вам его не навязываю. Я бы отделил мух от котлет, и оставил бы структуру чистой, т.е. только данные и какие-то методы, которые работают конкретно с этими данными из структуры, а взаимодействие с базой данных организовал бы через паттерн проектирования Repository. Т.е. мы делаем уже отдельную структуру ProductRepository, которая содержит в себе методы, принимающие и отдающие структуру Product, и уже в этих методах реализуем вызов базы данных.

Я набросаю вам простенький интерфейс для использования этого паттерна, а конкретную структуру, реализующую этот интерфейс вы уже напишете сами. Интерфейсы использовать в таких случаях считаю вообще обязательным условием. Например, так нам будет гораздо проще тестировать код, всё становится гораздо гибче. Ведь структурку Product вы сможете без проблем использовать не только при работе с базой, но и при передаче данных в другие системы, не волнуясь о лишних методах, висящих на ней. Так же вы сможете легко менять реализации репозитория, не меняя бизнес-логику проекта. (Это позволит, например, легко заменить базу данных)

package models

type Product struct {
	ID    int    `json:"id"`
	Title string `json:"title"` //Название
	Price int    `json:"price"` //Цена
}

type ProductGetter interface {
    GetAll() ([]Product, error)
    GetByID(id int) (Product, error)
}

type ProductCreator interface {
    Create(product Product) (Product, error)   
}

type ProductUpdater interface {
    Update(product Product) (Product, error)
}

type ProductDeleter interface {
    Delete(id int) error
}

type ProductRepository interface {
    ProductGetter
    ProductCreator
    ProductUpdater
}

Если одну дату вычесть из другой даты, то получите количество дней в виде вещественного числа.
Добавив немного математики вычисления остатков, получите все компоненты разницы дат:

select trunc(sysdate - to_date('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS')) days,
   mod(trunc((sysdate - to_date('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS')) * 24), 24)  hours,
   mod(trunc((sysdate - to_date('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS')) * 24 * 60), 60) minutes,
   mod(trunc((sysdate - to_date('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS')) * 24 * 60 * 60), 60) seconds
from dual

Вариант 2:

select extract(day from (sysdate - to_timestamp('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS'))) days,
       extract(hour from (sysdate - to_timestamp('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS'))) hours,
       extract(minute from (sysdate - to_timestamp('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS'))) minutes,
       extract(second from (sysdate - to_timestamp('03.10.2004 17:03:28', 'DD.MM.YYYY HH24:MI:SS'))) seconds
from dual

План такой:
1) Прислушаться к внутреннему голосу, к позывам и стремлениям души и к ее же воплям и стенаниям. Может в этом месте работы есть коллектив\начальник\директор который фактически заставляет вас работать под принуждением (страх наказаний, сказки про великую и единственную достойную компанию, обесценивание труда, перекладывание ответственности за собственные ошибки и т.п.). Думаете крепко, разбираетесь в себе и окружающем мире.
2) Если не устраивает только коллектив\организация, но к данному виду деятельности не наступило выгорание - растите вширь. Лучше быть админом в 10 организациях на полставки, чем просиживать штаны в одной и на 1 ЗП. Да, будет сложно, особенно на этапе взятия каждой новой организации и наведения там порядка. Да, придется стать быстрее, мобильнее, размоются границы рабочего времени. Придется подготовить кучу оптимизаций и домашних заготовок по профилю админства. Но потом поймете, что развернуть "из коробки" пустой рабочий комп с парой десятков тяжелых программ - можно за 15 минут, а не за два дня. А оставшиеся два дня отдыхать. И оказывается, что на работу можно не ходить, и можно ни кому не отчитываться - если в рабочее время появились личные дела. Тут еще ЗП ощутимо подросла... Только тип организаций выбирайте комфортный для себя. И избегайте мест концентрации стресса, скандалов, клинического крохоборства, самодурства и кумовства.
3) Следующим шагом станет многостаночность. При чем вторая профессия - должна расти не в сфере ИТ, но быть синергической к ИТ в вашем случае. Возможно придется вспомнить прежнее образование, старый рабочий опыт, или искать что-то вообще новое. Но главное - что специалист совмещающий знания и опыт в двух областях - существенно лучше, чем 2 разных специалиста. Востребован он реже, но где востребован - там его ценят. Куда расти - совета не дам, тут именно важен сам принцип. Если душа лежит - можно второе/третье/пятое направление выбирать из совсем новых веяний (прикладное применение ИИ и т.п.) - конкурентов минимум, специально обученных вообще нет.
4) Набирать опыт в управленческих и организационных вопросах. Это всегда полезно, хотя сложнее, чем быть "принеси-подай". Учиться общаться с разными людьми, понимать задачи бизнеса, приоритеты. Уметь корректно спорить, отстаивать свою точку зрения.
5) Периодически повторяем п. 1.

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

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

Что лично вижу сейчас. На данный момент почти каждая вакансия senior вакансия на golang, которую приносят приятные девушки HR содержит требование 3 лет в Golang или опыт работы senior на другом стеке с желанием переучиться на go.

На менее хайповых стеках такое тоже бывает. Бывают готовы обучать на редкие языки - ruby, например вспоминают пару раз в год. Лет 7 назад также массово вербовали на nodejs. А сагитировать с PHP в Python так вообще святое дело. Такое происходит и на позиции мидлов. На тот же go в крупные компании часто достаточно хорошего опыта мидла и желания изучать go. Зп будет из грейда мидла.

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

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

Во первых, если вам нужно установить связь между этим

public List<CodeSnippet> LikedCodeSnippets { get; set; } = new List<CodeSnippet>();

И этим

public List<User> UsersWhoLiked { get; set; } = new List<User>();

Вам нужна дополнительная таблица. Почему? Потому что тут связь много-ко-многим. Вот она:

public sealed class UserCodes
{
    public int UserId { get; set; }
    public User User { get; set; }

    public int CodeId { get; set; }
    public CodeSnippet Code { get; set; }
}

Через эту таблицу далее конфигурируете связь много-ко-многим

Что значит эта запись?
public User User { get; set; } = null!;

В чём смысл говорить, что она null и ставить ! как обозначение того, что она not null?

На каких-то курсах предусмотрено гарантированное трудоустройство в договоре.

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

Пробовала сама изучать Excel, SQL-это нужно в аналитике данных, создала резюме, откликалась на вакансии на hh.ru без результатов.

Если самостоятельно не смогли изучить на нужном уровне - значит курсы не помогут.
Как минимум я бы тут посоветовал глянуть план обучения с курсов (там буквально список тем пишут) и сравнить с тем, что вы сами умеете.
Также не забывайте свои навыки сравнивать с тем, что пишут в вакансиях. На каждую строчку из требований у вас должно быть что-то типа "я точно это могу", а не "ну это я вроде чуть-чуть трогал, формально"

Если со знаниями проблем нет, то курсы вам ничего не дадут - смотрите в своё резюме, оформляйте его так, чтобы в хорошем ключе выделиться на фоне других соискателей, пробуйте писать напрямую рекрутерам, подавайте заявки на стажировки, не чурайтесь откликами в мелкие или непрофильные компании (вам на этом этапе опыт нужен. Крупные компании часто даже не рассматривают кандидатов без опыта)

- Я считаю, что свой кастомный маппер - это отличное решение. Чтобы быть уверенней, обязательно напишите тесты. Как unit, так и интеграционные, например, с помощью testcontainers.

- Можете вместо pgx посмотреть в сторону sqlc. У него совершенно другой подход. Вы пишете запрос со всеми джойнами, а он вам автоматически генерирует код со всеми структурами и функциями. Правда, там по джойнам практически отсутствует документация, но уж погуглите.

- Ну, и если совсем сложно... то... может одним глазком глянуть в сторону ORM? Я никому не расскажу...