5 лет назад решил переехать в Москву из провинциального миллионика. Отослал резюме в Parallels, назначили собес с руководителем отдела. Он меня спросил — что ты знаешь про Parallels? Я говорю — ну есть у меня знакомый, работает у вас, раньше жил в моем городе, пересекались как-то, но сейчас не общаемся. Поговорили, в общем с шефом «о том, о сём». На следующее утро прихожу на работу, меня коллега спрашивает — ты чего в Parallels собрался? Я, конечно, был мягко говоря удивлен, т.к. своими планами я ни с кем не делился. Оказывается, мой коллега — хороший знакомый знакомого того работника, о котором я на собесе говорил (а он в одном подъезде жил с шефом, который собес проводил). Город-то провинциальный, все друг друга знают, хотя и миллионный. Вот так я попал в Parallels :)
Немножко не понимаю термин — «модифицированный сценарий сбоки». Сценарий сборки остался без изменений — «mvn package». Просто билдится он фактически из бранча, изменения в котором не коммититятся. Если сильно надо — после mvn versions:set можно создать новый «релиз-кандидат» бранч и билдить артифакты из этого бранча (который добавить в exclude).
Была такая мысль, но номер билда Jenkins — вещь непостоянная. Да и строчек кода не сильно много сэкономишь. Аппроач, по сути дела один — где-то отдельно от pom-файла хранится номер билда. А где он конкретно хранится — это уже дело вкуса.
Проблем нет. В опубликованном в исходниках юнит-тесте в качестве пула потоков используется cachedThreadPool, что означает что максимальное количество потоков будет равно (но может быть и меньше) количеству серверов. Если использовать fixedThreadPool, то количество рабочих потоков можно сократить (например 1 поток на 10 серверов), но тогда есть риск что «медленные» сервера будут тормозить весь процесс обработки. Но и эту проблему можно решить, если выстроить приоритеты для «медленных» и «быстрых» серверов в «револьвере».
Данная статья не описывает законченное решение, а предлагает подход к реализации — отказ от схемы «один поток на сервер» и переход на очередь заданий, которая обрабатывается пулом потоков.
Ну может и может, только программировать и кастомизировать все равно придется.
А если конечными пользователями продукта будет являться еще кто-либо помимо сисадмина, то пускать их в нагиос совсем не прилично.
Конечно нет необходимости изобретать очередной велосипед в стиле nagios. Задачи, кроме тривиального пинга могут быть самые разнообразные, например выполнить последовательность действий через ssh на удаленном хосте или исполнить sql-скрипт. Я уж не говорю о периодическом опросе каких-нибудь веб-ресурсов с целью получения и обработки статистических данных.
Мне не нравится, когда весь проект завязан на определенную библиотеку. Если завтра по каким-либо причинам придется отказаться от icu, то придется из всего проекта выкидывать UnicodeString. А так — написал пару методов, в которых используется icu и нет проблем.
Внутри себя boost::filesystem::path хранит в std::string. В линуксе с utf-8 проблем не будет, но если вы в Windows скормите путь utf-8 (содержащий символы национального алфавита) в boost::filesystem::path, то ничего хорошего из этого не выйдет.
Мне кажется, что когда речь идет о представлении строк «Юникод в Windows», то все понимают что речь идет об UTF-16LE. Да, в Windows свой особый способ хранения строк, может и не совсем удачный. Но и в Линуксе тоже не все гладко. Например, преобразование строки utf-8 в нижний регистр просто так не сделаешь. Да и другие ОС не сразу пришли к utf-8 (во FreeBSD, к примеру, полноценная поддержка utf-8 появилась относительно не так давно).
Пример с SetWindowText немного утрирован. Но он не меняет сути. На самом деле в такой разработке может всегда понадобиться вызвать функцию WinAPI, в которую нужно передать строку. Статья называется «кроссплатформенная работа со строками», а не то как писать «100% кроссплатформенное приложение».
Во-первых, помимо Qt я что не припомню других удачных кроссплатформенных фреймворков для C++. :)
Во-вторых, если бы речь шла о Qt, по статья бы состояла из одного предложения «Для кроссплатформенной работы со строками на C++ используйте класс QString от Qt.»
Хранить можно в чем угодно, весь вопрос только в удобстве. Можно и в Windows строки хранить в utf8, только каждый раз при вызове SetWindowText вам придется делать конвертацию из utf8.
А если конечными пользователями продукта будет являться еще кто-либо помимо сисадмина, то пускать их в нагиос совсем не прилично.
Во-вторых, если бы речь шла о Qt, по статья бы состояла из одного предложения «Для кроссплатформенной работы со строками на C++ используйте класс QString от Qt.»