1. На усмотрение автора
3. Я специально уточнил, что именно gerrit, насчет gitlab/githab/linux sshd не могу сказать. Но с gerrit однозначно был такой косяк, который привел в ступор сотрудников, которые переустанавливали систему. Не сразу нашли, в чем проблема.
1. Автор верно указал, что необходимо сделать тестовое подключение из putty к git-серверу, но важен еще момент, что именно в putty можно добавиь ключ сервера как доверенный, иначе plink будет ругаться.
2. pagent есть смысл добавить в автозапуск, указав в качестве аргументов файлы с ключами
3. ВАЖНО: версия plink 0.63 зависает при git clone, по крайней мере при выкачивании из gerrit, поэтому следует пользоваться версией 0.62
Я неточно сформулировал изначальную мысль в статье, поправил насчет статической ссылки. В сохранении ссылки на Injector плохо только то, что привязка к Guice становится сильнее, но не более. Официальные гайды не делают рекомендации избавляться от упоминания Injector в коде.
1. Плохо сохранять ссылку на injector именно в статическом поле. В хорошем случае в том же Guice создается Injector (явно или нет — как, например, в Guice-тесте testng), из него достаются все объекты и после этого ссылка на инжектор теряется. Если нужно динамическое создание объектов, есть сущность Provider, но ее будет недостаточно, например, для такого примера:
final String className = config.getProperty("serviceImpl");
// Class.forName(name) and check required interface for type safety
final Class<? extends Service> serviceClass = Reflection.classForName(className, Service.class);
final Service service = injector.getInstance(serviceClass);
В классе фабрике с подобным методом следует просто объявить Inject Injector injector (в поле, либо в аргумент конструктора), никакой статики, InjectorUtil — всего лишь временное явление для упрощения рефаторинга.
2. Фреймворконезависимость — это тема отдельной статьи (частично готова), а этот материал именно о рефакторинге существующего проекта с выбором конкретного фреймворка. Вообще говоря, для DI-независимости нужно знать хорошо все DI, которые вы собираетесь поддерживать, потому что они хоть и декларируют JSR-330-совместимость, делают это по-разному. Взять к примеру дефолтные scope'ы в spring и guice (соответственно, eager singleton vs prototype), дело тут вовсе не в примере с InjectorUtil.
Idea, кстати, давно уже анонимные классы сворачивает в lambda-выражения — с одной стороны hint как это должно выглядеть, с другой, как я понял, готовый инструмент преобразования по всему проекту.
Я не об этом, между next и val нет синхронизации, но если рассматривать как аналогию AtomicInteger get/incrementAndGet, то для примера пойдет, а в боевой реализации я бы без нужды метод val добавлять не стал. Это все условности, поэтому не стоит придавать этому большое значение.
Стоит заметить, что в варианте неблокирующего оптимистичного алгоритма есть существенный недостаток: при высокой конкуренции вероятность получить false на compare-and-swap становится достаточно высока, особенно с большими значениями BigInteger (что приведет к большому числу переповторов впустую), поэтому есть смысл подумать о других вариантах, например synchronized/ReentrantLock.
Кроме того, пожалуй, метод val() излишний в api, потому что класс в таком виде становится не Thread safe (условно, конечно, но его контракт несколько странный).
Позвольте, задам вопрос.
Стою перед выбором БД для задачи хранения текущих транзакций. Запросы примерно в таком порядке: insert, 5x update, delete. Select относительно редко и характерен для нештатных ситуаций — в нормальном случае транзакции хранятся в памяти приложений и из базы выгребаются либо на старте, либо при разгребании очереди. Никакой логики в БД (даже вероятно, без использования foreign key), только критически надежное хранение данных, размер записи низкий — до единиц килобайт, в таблице не более 100000 записей. Поток запросов — до 10000 в минуту, относительно низкий. Сам люблю psql, но в данном случае не уверен, что он будет лучшим выбором. nosql как-то для финансовых транзакций рассматриваю с опаской (возможно, стереотипы). Пока предварительно решил использовать mysql.
Что касается postgres, смущает vacuum, насколько помню, он может сильно подтормаживать выполнение текущих запросов в БД. Если я в чем-то заблуждаюсь, прошу меня поправить.
Вспомнился сетап, криво локализованный на русский язык. Он заканчивался кнопкой с феерической надписью «Финский». Недолго поразмыслив, стало ясно, что это перевод «Finnish» (вместо «Finish»).
3. Я специально уточнил, что именно gerrit, насчет gitlab/githab/linux sshd не могу сказать. Но с gerrit однозначно был такой косяк, который привел в ступор сотрудников, которые переустанавливали систему. Не сразу нашли, в чем проблема.
2. pagent есть смысл добавить в автозапуск, указав в качестве аргументов файлы с ключами
3. ВАЖНО: версия plink 0.63 зависает при git clone, по крайней мере при выкачивании из gerrit, поэтому следует пользоваться версией 0.62
Простите за качество
В классе фабрике с подобным методом следует просто объявить Inject Injector injector (в поле, либо в аргумент конструктора), никакой статики, InjectorUtil — всего лишь временное явление для упрощения рефаторинга.
2. Фреймворконезависимость — это тема отдельной статьи (частично готова), а этот материал именно о рефакторинге существующего проекта с выбором конкретного фреймворка. Вообще говоря, для DI-независимости нужно знать хорошо все DI, которые вы собираетесь поддерживать, потому что они хоть и декларируют JSR-330-совместимость, делают это по-разному. Взять к примеру дефолтные scope'ы в spring и guice (соответственно, eager singleton vs prototype), дело тут вовсе не в примере с InjectorUtil.
Кроме того, пожалуй, метод val() излишний в api, потому что класс в таком виде становится не Thread safe (условно, конечно, но его контракт несколько странный).
Стою перед выбором БД для задачи хранения текущих транзакций. Запросы примерно в таком порядке: insert, 5x update, delete. Select относительно редко и характерен для нештатных ситуаций — в нормальном случае транзакции хранятся в памяти приложений и из базы выгребаются либо на старте, либо при разгребании очереди. Никакой логики в БД (даже вероятно, без использования foreign key), только критически надежное хранение данных, размер записи низкий — до единиц килобайт, в таблице не более 100000 записей. Поток запросов — до 10000 в минуту, относительно низкий. Сам люблю psql, но в данном случае не уверен, что он будет лучшим выбором. nosql как-то для финансовых транзакций рассматриваю с опаской (возможно, стереотипы). Пока предварительно решил использовать mysql.
Что касается postgres, смущает vacuum, насколько помню, он может сильно подтормаживать выполнение текущих запросов в БД. Если я в чем-то заблуждаюсь, прошу меня поправить.