German Jet

То, о чем вы пишите называется "скин" или "шкурки". Это достаточно производительный способ для отрисовки, но на этом плюсы этого подхода заканчиваются и начинаются минусы:
1. Масштабированию такой подход поддается с трудом (например, несколькими размерами карт скина)
2. В рантайме модификация такого скина тоже выполняется с трудом (никто этого не делает)
3. Как правило, скин (как в aimp) не универсальный, а для конкретного расположения элементов управления.
Это все называется растровый скин.

Сейчас в большинстве своем применяется подход с векторной отрисовкой контролов. Это менее производительно, но более гибко все работает и нет проблем с масштабированием (разным DPI экранов). Ну и позволяет менять что угодно где угодно во время выполнения приложения (типа тени, свечение, цвета и т.д.)

Так что, я не советую искать растровый вариант отрисовки для C#. Да и вообще для любых GUI. Изучите, как сейчас происходит кастомизация контролов в GUI.

Можешь просто погуглить "красивый UI WPF или Avalonia" и увидеть пример (видео гайды есть)

Есть два разных снимка.
1. снимок ФАЙЛОВОЙ системы (Production Checkpoints у hyper-v)
2. снимок файловой системы и ОПЕРАТИВНОЙ памяти (standart)

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

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

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

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

p.s. если перед созданием снапшота сервер базы данных остановить, то проблем никаких это не создаст.

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

1. Приблизительно сформулируй свой будущий профиль
2. Иди на хх ру и отфильтруй вакансии по своему профилю, указав в фильтре "расширенное описание вакансий"
3. Если у тебя нет их api, а его скорее всего нет, то открой код страницы и найди внизу объект со всеми данными
4. из полученного объекта забери объект "vacancies": []
5. Сконвертируй json в csv
6. Открой csv в excel
7. Сделай сводную таблицу с чем хочешь - там 342 колонки и, как мне кажется, они включают вообще все
8. Далее, к примеру, можешь отобразить себе вакансию с тегами скиллов, зарплатой и кодом валюты.
9. Из получившегося списка ты можешь сформировать пул скиллов и зарплаты к ним

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

upd И не забудь в фильтре что-то исключить 'пример для примера" :))

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