Alex XYZ

В MSDN это называется extended-length path

Решил стать программистом, но немного неприятно кодить не понимая, что происходит под капотом.

Расслабьтесь и напрягитесь в своем деле, прочитав на Хабре:
Долг знаний

По описанию задачи и вашим комментариям к ответам, думаю, понял, что вам нужно, поэтому следите за руками (решение не стандартное, но полностью решающее вашу проблему):

1. Создайте класс-контейнер, в котором будут сохраняться все ошибки. Назовём его, например, ErrorsContainer:

public class ErrorsContainer
{
    // Пример ошибки
    public object Error23;
}

2. Теперь добавьте класс, который будет возвращать код ошибки по полю класса-контейнера. Назовём его Error:

public static class Error
{
    private static readonly Regex Regex = new Regex(@"\d+", RegexOptions.Compiled);

    public static int Get(string fieldName)
    {
        return int.Parse(Regex.Match(fieldName).Value);
    }
}

3. Сложная часть позади. Теперь можно использовать в коде следующую конструкцию:

int error23 = Error.Get(nameof(ErrorsContainer.Error23));

Теперь у вас в коде будет контроль всех существующих ошибок (они будут расположены в ErrorsContainer) и новые ошибки будут добавляться буквально одной комбинацией (Alt + Enter, Enter в Resharper-е). Главное, не забывать использовать nameof.

Пример добавления новой ошибки (напоминаю, Alt + Enter в Resharper на раскладке IntelliJ IDEA):

утилита jar вам в помощь
Раскрыть архив
jar -xf mysuperwarfile.war
Посмотреть содержимое
jar -tf mysuperwarfile.war

Перезапустил проводник, значок пропал.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Коллега АртемЪ прав, если есть проблема с DNS - смотрите "в какой адрес резолвятся проблемные сайты". Если из командной строки отдается не верный адрес, то это системный DNS кэш, который можно очистить командой ipconfig /flushdns. В большинстве случаев этого хватает. Если из командной строки отдается верный адрес, но сайт не открывается - смотрите в сторону кэша браузера, они тоже кешируют. Обычно с этим помогают справиться плагины типа DNS Flusher, но для начала не плохо просто очистить кэш.

А просто со временем, до всех доходит, что программирование это не интересные исследования, познания неведомого как в фантастике, прикручивание двумя кликами новых движков.
А на деле - это еще и множество рутинной и кропотливой работы, которая по сути - скучная, однообразная, И ее процентов 80.

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

https://www.npmjs.com/package/css-purge

1. Без крайне веских причин, начинать нужно всегда с 3й нормальной формы. В данном случае это вариант с 2мя таблицами.
2. Десятки тысяч записей в месяц - это вообще не нагрузка даже для указанной конфигурации.