d-stream

В принципе вариант с "очередями" достаточно удобен:
в исходящую очередь выкладываются изменения по триггерам, потом, позже из этой очереди записи выгребаются неким обработчиком, возможно с "украшательством" в виде добавления в выгрузку референсных данных и т.п.
Там же можно хранить число попыток отправки и lasterror
Из плюсов - в грязную очередь могут влететь несколько записей на выгрузку одной и той же сущности (к примеру манагер вбил комментарий к клиенту, сохранил, подумал, поправил коммент и снова сохранил = 2 записи), а к отправке уже можно группировать по id сущностей (если конечно по логике не требуется историчность).

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

Если вкратце, то практически любой язык программирования как таковой осваивается за несколько дней. А вот все что вокруг - те же фреймворки - их только общий обзор может занять месяцы.
Соответственно когда говорят просто "c#" или "visual c#" - то скорее подразумевают опыт относительно фреймворков. Если же говорят о чем-то специфичном, то там во главе угла именно специфичность, а язык указывается вторично

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

По-моему тут с sql запроса надо бы идеологию сменить

что мешает обернуть в isnull Subscribers.FIO и вываливать в таком случае id или еще что-нибудь?

Так по БД или гриду?

Лично мои ощущения от java-приложений - скорее негативные. Даже притом что это приложения от мастодонтов типа HP, Avaya, клиент-банки, кучки специфических порталов и т.п. Некие ощущения неустойчивости, тяжести, нестабильности.

Поэтому на мой взгляд для не очень мультиплатформенных приложений - лучше реализовывать на дотнете - то бишь "на C#". То что есть .net framework для работы с офисными данными и приложениями - ну как бы "от производителя", то есть наиболее информированные. Ну а изобразительные возможности - WPF и будет счастье.
Мультиплатформенность - можно посмотреть как минимум в сторону UWP для win-платформ, или слегка ужать свои порывы и смотреть в сторону mono/xamarin - тогда собственно ПРИ ДОЛЖНОМ ПОДХОДЕ вполне можно даже говорить о мультиплатформенности от win до андроидов-яблок-линуксов

ftp://ftp.rfc-editor.org/in-notes/rfc821.txt
VRFY

Но это не обязательная к реализации команда протокола.

Ну наверное VerticalAlignment в stretch и высоту не задавать, разве что MinHeight

1. i3 и i5 бывают очень разных поколений
и какой-нибудь i3 64xx вполне "сделает" i7 14xx

2. Я бы расставил по приоритетам так:
Диск
Память
Процессор

Так что если ценовая дельта между процессорами позволит прикупить еще памяти - imho будет лучше

p/s/ i7 35xx 8гб ОЗУ и SSD - в принципе вызывает дискомфорт только долгая загрузка полного solution с over 500 проектов, поэтому для повседневной жизни пользую Unload Project (благо архитектура проекта позволяет сделать это)

Корректный вариант: предобразование Фурье, естественно перед этим избавиться от "обрезания", далее оттуда получаем основную гармонику.

Малокорректный вариант (в свое время видел в практическом использовании у сейсмологов): находить некую "ось" ("ноль") и считать полупериодом соседние пересечения оси.

"ось"\"ноль" - видимо аппроксимировать полиномом первого порядка из среднеквадратичного.

Вариант Light: копируем текст JSON в клипборд, в VS выбираем Edit-> Paste Special