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

Место оглавления

WEB

Серьезно пока не занимался. Джентельменский набор: JavaScript и CSS. B качестве среды предпочитаю NetBeans или Visual Studio. На худой конец подойдет и блокнот в виде EmEditor.
В основном способен на несложные сайты вроде этого, справки или отчеты для приложений по ходу основной разработки.
Максимум сложности - динамическое формирование html-контекста с помощью JavaScript вроде создания оглавления страницы на основе иерархического содержимого или переключение видимости, чтобы не использовать технологию фреймов. Собственно все умения присутсвуют здесь. Сайт служит тренировочным полигоном.

СУБД

• ORACLE с 1998г.
  Участвовал в больших и малых проектах по документообороту и картографии. Чисто ORACLE или с 1С-Предприятием в разных позициях.
• PostgreSQL с 2018г.
  Участие в большом проекте картографического документооборота, перекладываемого с ORACLE на PostgreSQL.
• SQLite с 2018г.
  Изучал попутно при создании класса-оболочки для JDBC. Пришлось делать такую штуку в связи с отсутствием в ней приличной именной параметризации и трассировки
• DB/DBF с 1991г.
  Работал с этими форматами пока в страну не пришел по-серьёзному ORACLE. Потом при работе с 1С-предприятием с помощью BDE делал необходимый инструментарий для захода в эту СУБД с заднего крыльца (в файловом варианте).
• 1С-Предприятие
  Занимаюсь с 2000 года с использованием стандартных и нестандартных технологий.
  Эту СУБД до сих пор многие программеры, почитающие себя профессиональными, не признают таковой. Вернее, не понимают, что это полноценная реляционная СУБД нового поколения, более продвинутая, чем традиционные SQL DBMS вроде Оракла и Постгреса.
  Поясню. Первоначально идея СУБД возникла из потребностей хозяйственного учета и это необязательно должен быть именно бухгалтерский учет (то есть с планом счетов, шахматками и т.п.). Вообще-то, исходя чисто из смысла традиций хоз.учета он весь является бухгалтерией, поскольку ведется в журналах, книгах. Bookkeeping. Это в широком смысле. А в узком - да, с привлечением плана счетов и двойной проводки, придуманной Лукой Пачоли (или традиция приписывает ему).
  1С-Предприятие представляет собой компактный конструктор организации учета практически любого типа, который известен на Планете в последние полтысячи лет. Фактически это реализации мечты любого программера, занимающегося учетом, особенно в последних версиях с управляемыми формами. О чем я? Да о том, чтобы не тратить время на рутину с выёжыванием структуры СУБД через поля, триггеры, встроенные процедуры, связные таблицы, вымучиванием экранных и печатных форм. Просто брать каркас (платформу), который все это делает за тебя и отдаваться только процессу выдумывания и кодирования функционала, который тоже может быть очень нетривиальным.

DELPHI

DELPHI примерно с 1994 года. Активно использовал все версии от 1-й до XE-ой. Основной инструмент вкупе с 1С-предприятием на протяжение многих лет.
Из популярных наборов компонентов работал с DevExpress (конечно!) и RX (поначалу).
And of cource TRegExp, разработанный одним питерским(?) гением. Когда ни про регулярные выражения, ни про эту разработку не знал, где-то в 1998 году сделал свой упрощенный вариант на манер анализатора строковых шаблонов match из Paradox'a, который несколько лет исправно служил как его прототип когда-то.
Потом делал свои компоненты, внешние компоненты для 1С-предприятия, в том числе и по технологии Native API. Для них создал удобную фабрику компонентов, позволяющую избавиться от предложенных фирмой 1С схем проектов (весьма многословных с изобилием индийского кода). Достаточно было кодировать только целевой функционал. Была такая фабрика для COM-технологии и для Native API. Для последней 1С предалагала проекты только на С++, но народ нашел способы иммитировать с++ классы паскалевскими структурами и это удалось успешно применить.

C#

C# в Visual Studio использую с 2015 года. Серьезных комерческих проектов не было. В основном воспользовался возможностью изучить VS как свободное ПО взамен жадной DELPHI. По ходу изучения сделал пару задачек, ранее реализованных на DELPHI. О них рассказано ниже. Сама среда и язык понравились больше Pascal, который тоже находил весьма достойным средством, пока не вернулся к парадигме си-подобных языков. На C (голом и с плюсом) программировал еще в 80-х и они были достойной сменой ассемблера.

---

---

Java

Java начал использовать с 2018 года, когда поставили большую задачу. До этого не было нужды изучать.
Язык понравился больше Шарпа возможностью свободно где угодно создавать классы, писать ёмкий, понятный, продокументированный код и удобной системой тестирования. Поначалу я аналогично хвалил Шарп, но в сравнении с Java он поблек, как и сама среда программирования Visual Studio. Она выглядит тяжеловесной и убогой в сравнении с NetBeans. Последнюю полагаю лучшим вариантом в сравнении с IntelliJ IDEA из-за возможности одновременно работать с несколькими открытыми проектами в одном сеансе. Это я в IntelliJ IDEA искал и не нашел, хотя даже консультировался у более опытных коллег и потому взял NetBeans, о чем не жалею. А других вариантов для Java на планете и нет.
Из обширного инструментария Java довольно неплохо освоился с Xml, JDBC и JavaFX. Разумеется и со SWING, который использовал поначалу для создания IDE, но потом из-за его путанности и тяжеловесности переключился на JavaFX.
Xml и JDBC требуют отдельного слова. Поскольку львиная доля написанного за последние 2 года кода (2М, 50 тыс. строк) относилась как раз к этим технологиям. Выяснилось, что JDBC не имеет нормальной именной параметризации. Позиционная хороша для небольших запросов. А если запрос из десятков строк, с десятком именных параметров и каждый из них может использоваться несколько раз? И написание, и отладка таких запросов просто нереальна с позиционным параметризованием. Также как и без внятной трассировки, которой тоже в JDBC нет. Посему пришлось сделать оболочку, которая предоставляла эти возможности. А также некоторые еще вроде механизма событий, которых тоже нет в JDBC. При этом сохранялась возможность работать традиционными методами наряду с продвинутыми. Всё это оттестировал реальными проектами на трех СУБД: ORACLE, PostgreSQL и SQLite.
Что касается XML, также потребовалась обертка, чтобы сократить количество рутинного кода и сделать программный текст более внятным. Просто обернул наиболее часто используемые блоки в статические, перегружаемые методы класса-помощника с активной параметризацией лямбда-функциями. В первую очередь это коснулось запросов xPath.