Elasticsearch, вероятно, самая популярная поисковая система на данный момент с развитым сообществом, поддержкой и горой информации в сети. Однако эта информация поступает непоследовательно и дробно.

Самое первое и главное заблуждение — "нужен поиск, так бери эластик!". Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.

Эта статья является развёрнутым комментарием к другой статье. Обычно я прохожу мимо, но сейчас меня почему-то задело.

Наконец-то руки дошли до продолжения статьи "Истории о моей работе в Нидерландах" — а именно, пришла пора рассказать о деталях переезда и поделиться практическими советами с будущими трактористами. Прошу прощения у всех, кто ждал этого продолжения гораздо раньше. Не буду распространяться о причинах задержки, но поверьте, это были очень напряженные для меня месяцы, и я вряд ли мог взяться за эту статью в тот срок, который озвучивал раньше. Кстати, дорогие мои вопрошающие в личке! Вы, на самом деле, являетесь полноправными соавторами этой статьи, потому что некоторые из ваших умных и иногда неожиданных вопросов мне самому в голову не пришли бы, а другие сделали мою задачу гораздо проще. Вместо того, чтобы обдумывать план статьи, подачу и прочая, прочая, бери формат вопрос-ответ, и дело в шляпе. Уважаемые nightstalker, ATmegAdriVeR, Flem_1, dmtrr, ChingizKhalafov, Carduelis, artem2511, gri_mih, Ommonick, это ваши вопросы, вам от меня огромная благодарность. Надеюсь, от всех читателей тоже.

Ну а начну я все же с краткого рассказа о том, как я дошел до жизни в Нидерландах.

https://www.deviantart.com/mrmarkchilcott/art/Warpig-662451056

Итак, ваш трактор отполирован до блеска, смазан, проведено ТО. Вы в костюмчике с иголочки стоите рядом, позвякиваете ключами и… не знаете толком куда же ехать. Внучатая племянница лучшей подруги двоюродной тети вашей мамы говорит, что лучше страны, чем Германия нет. Васек, товарищ детства, за бутылкой пива рассказал, что если куда и ехать, то в Эмираты. Там дорого-богато, а небоскребов сколько? Владимир Викторович, директор конторы, где вы в студенческие годы подрабатывали, считает, что где родился, там и пригодился, мол, страну поднимать надо. Направлений много, а жизнь одна. Давайте вместе вооружимся цифрами и попытаемся составить хотя бы отдаленно объективный список потенциальных мест дислокации на следующие N лет.

^{Люцерн на фото Олега Ненашева}

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

А в случае с IT-эмиграцией всё ещё хитрее. Российский разработчик, даже никуда не уезжая, постоянно имеет дело с английским. В эмиграции он может столкнуться с другим языком, но и английский никуда не денется. И при этом, поскольку большая часть жизни проходит в онлайне, можно не бросать русский (например, писать на Хабр или записывать подкаст). Получается жонглирование тремя языками.

Как тогда выглядит жизнь IT-эмигранта с языковой точки зрения? И как в этой жизни присутствует русскоговорящее IT-сообщество? Я расспросил шестерых человек, уехавших в самые разные страны, от Норвегии до Австралии. Троих знаю по их докладам на конференциях, которые организуем мы в JUG Ru Group, а другие трое — авторы популярных хабрапостов из хаба «IT-эмиграция».

Привет хабр!

На днях мне в очередной раз на глаза попал код вида

if(someParameter.Volatilities.IsEmpty())
{
    // We have to report about the broken channels, however we could not differ it from just not started cold system.
    // Therefore write this case into the logs and then in case of emergency IT Ops will able to gather the target line
    Log.Info("Channel {0} is broken or was not started yet", someParameter.Key)
}

В коде есть одна довольно важная особенность: получателю крайне хотелось бы знать, что произошло на самом деле. Ведь в одном случае у нас проблемы с работой системой, а в другом — мы просто прогреваемся. Однако модель не дает нам этого (в угоду отправителю, который зачастую является автором модели).
Более того, даже факт "возможно, что-то не так" происходит из того, что коллекция Volatilities пуста. Что в некоторых случаях может быть и корректно.

Я уверен, что большинство опытных разработчиков встречало в коде строки, в которых заключалось тайное знание в стиле "если выставлена эта комбинация флажков, то от нас просят сделать A, B и C" (хотя по самой модели этого не видно).

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

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

Однако если же вы занимаетесь долгоиграющим — добро пожаловать под кат.