Да, у меня было желание описать и Eclipse, но её у нас используют немногие, да и статья без того получилась большой и развесистой.
Кроме того, на первый взгляд, IDEA поддерживает JavaScript и смежные технологии значительно лучше и в основном из коробки.
Я оставляю за собой право называть статью так, как считаю нужным, и предлагаю читателям самим решать, соответствует ли статья их ожиданиям. Для этого её можно плюсовать и добавлять в избранное, или наоборот, минусовать.
Не разобрал ваше предложение на английском, что откуда invoking?
Цель, повторюсь, была конкретная — не «поиграться», а быстро ввести Java-разработчиков в суть технологии и дать им некий общий базовый уровень понимания того, как с ней работать.
Нигде, ни в заголовке статьи, ни в её содержании, не было речи об использовании node.js в Java-стеке. Задачи такой не ставилось. Смысл статьи в том, чтобы человек с Java-бэкграундом быстро разобрался в новой для себя технологии и начал работу над проектом, который основывается на ней.
Скорее, в затронутых темах. Я решил в этой статье ответить на те вопросы, которые лично у меня возникли, когда я, имея опыт преимущественно на Java/JavaScript, пытался впервые что-то написать на node.js. Интеграция со знакомой мне средой разработки, декомпозиция на модули, тестирование. Заметьте, в статье ни слова про веб. Предполагаю, что у разработчиков на PHP вопросы были бы другие, более веб-ориентированные.
Vagrant — полезная вещь, но практика его использования для развёртывания единообразной рабочей среды программистов сомнительна. Во-первых, разработчики хотят пользоваться разными операционными системами, разными вспомогательными средствами разработки, и мы не хотим чесать всех под одну гребёнку, даже в части используемой IDE. Во-вторых, есть риск прийти к тому, что половина программистов в отделе не будет знать, как настроить и накодить чего-нибудь в экстренных условиях, потому что они умеют только запускать vagrant up, а дальше у них всё само работает. Я предпочитаю всё-таки иметь достаточно простую, но ручную инструкцию, по которой человек может быстренько пройти один раз и разобраться, что и где, и при этом не жертвовать привычной для него средой разработки.
Ну это прям философский вопрос, и ответов на него может быть тысяча. Например, чтобы расширить кругозор, попробовать что-то за пределами своей спрингово-хибернейтовой зоны комфорта (или дискомфорта, у кого как), познакомиться с альтернативными подходами к решению знакомых задач. Приобрести новый ценный опыт, или чтобы обнаружить, что проблемы, на которые ты тратишь километры кода, в другом языке решаются однострочником.
Ну или чтобы собрать все возможные грабли и вернуться в лоно родной Java, зарекаясь и плюясь, что больше никогда и ни за что не будешь писать эту динамически типизированную лапшу из коллбэков.
Иногда понимаешь, что твоя любимая технология упирается в ограничения и не решает твоих проблем, но и готовых решений тебе никто не даст, и тогда нужно просто экспериментировать.
«Установка и настройка nodejs» занимают примерно 1/5 часть статьи. И даже это не самая однозначная задача, если вы хотите, чтобы у всех разработчиков в команде была одна и та же одинаково настроенная версия node.js, независимо от того, какую операционную систему они используют. Например, пользователь Windows зайдёт на официальный сайт, скачает msi и установит версию 0.12.x, а пользователь Ubuntu, воспользовавшись apt-get, вероятнее всего, получит версию 0.10.x. Я не хотел проходить через эти грабли при вводе каждого нового разработчика в проект, и потому написал такой туториал.
Любой туториал пишется под конкретную задачу. Нужных мне туториалов, охватывающих все важные для меня моменты, не нашлось, и я написал свой, думаю, он будет полезен и другим людям.
Синхронизация в обе стороны, изменения на телефоне тоже есть, но конфликты пока исключаются за счёт разделения по ролевой модели (какие-то данные правятся на десктопе, какие-то на телефоне). Средства для разрешения конфликтов в Couchbase Lite тоже есть, так как любое изменение в документе это новая ревизия, и при конфликте обе ревизии сохраняются. Но сами конфликты должны разрешаться в клиентском коде — удалением или слиянием ревизий. Пока что пробовать этот механизм не приходилось.
Он опенсорсный, но проблема была именно в плохой документации — даже при наличии исходников восстановить протокол до полной совместимости непросто. Вот что пишут авторы Couchbase Lite:
Couchbase Lite’s replication protocol is compatible with Apache CouchDB. This interoperability is an important feature, but implementing it was challenging because much of CouchDB’s replication protocol is undocumented.
Да, репликация происходит через REST API. Там всё сделано не очень оптимально, и об этом я как раз собираюсь рассказать в следующей статье. На каждое обращение к REST-сервису создаётся отдельный NSURLConnection (т.е. даже не NSURLSession). Загнать всё в один сокет в такой схеме вряд ли получится.
Для нормальной синхронизации, конечно, нужен нормальный транспортный механизм (не поверх REST), оптимизированный под мобильные устройства и учитывающий их специфику. К сожалению, подобные решения мне попадались только в проприетарном софте. Сейчас как раз ищу что-то подобное или думаю над написанием своего решения.
Realm — это интересная замена Core Data, но там на текущий момент нет каких-либо средств репликации между мобильной и серверной базой данных. В документации есть примеры получения данных из REST-сервисов, но это не репликация. В нашем случае необходима была единая система синхронизации данных между мобильными и десктопными приложениями через централизованный серверсайд.
Разумеется, использование геттеров и сеттеров должно быть разумным. Например, иногда более правильным будет генерировать аксессоры только на определённые поля. Или сгенерировать только геттеры, задавая значения полей в конструкторе. Или переписать геттеры для объектов так, чтобы они возвращали только immutable-значения. Всё это достаточно подробно описано у Блока в «Effective Java». В целом можно сказать, что аксессоры оставляют возможность для достаточно гибкого изменения реализации. Так что я не вижу в их использовании ничего принципиально неверного.
Кроме того, на первый взгляд, IDEA поддерживает JavaScript и смежные технологии значительно лучше и в основном из коробки.
Цель, повторюсь, была конкретная — не «поиграться», а быстро ввести Java-разработчиков в суть технологии и дать им некий общий базовый уровень понимания того, как с ней работать.
Ну или чтобы собрать все возможные грабли и вернуться в лоно родной Java, зарекаясь и плюясь, что больше никогда и ни за что не будешь писать эту динамически типизированную лапшу из коллбэков.
Иногда понимаешь, что твоя любимая технология упирается в ограничения и не решает твоих проблем, но и готовых решений тебе никто не даст, и тогда нужно просто экспериментировать.
Для нормальной синхронизации, конечно, нужен нормальный транспортный механизм (не поверх REST), оптимизированный под мобильные устройства и учитывающий их специфику. К сожалению, подобные решения мне попадались только в проприетарном софте. Сейчас как раз ищу что-то подобное или думаю над написанием своего решения.