Comments 107
Стопятьсот туториалов об одном и том же… Может пора что-то новое писать?
Любой туториал пишется под конкретную задачу. Нужных мне туториалов, охватывающих все важные для меня моменты, не нашлось, и я написал свой, думаю, он будет полезен и другим людям.
Нужных по установке и настройке nodejs?
«Установка и настройка nodejs» занимают примерно 1/5 часть статьи. И даже это не самая однозначная задача, если вы хотите, чтобы у всех разработчиков в команде была одна и та же одинаково настроенная версия node.js, независимо от того, какую операционную систему они используют. Например, пользователь Windows зайдёт на официальный сайт, скачает msi и установит версию 0.12.x, а пользователь Ubuntu, воспользовавшись apt-get, вероятнее всего, получит версию 0.10.x. Я не хотел проходить через эти грабли при вводе каждого нового разработчика в проект, и потому написал такой туториал.
Если уж на то пошло, чтобы у всех было все хорошо, просто используйте Vagrant.
Vagrant — полезная вещь, но практика его использования для развёртывания единообразной рабочей среды программистов сомнительна. Во-первых, разработчики хотят пользоваться разными операционными системами, разными вспомогательными средствами разработки, и мы не хотим чесать всех под одну гребёнку, даже в части используемой IDE. Во-вторых, есть риск прийти к тому, что половина программистов в отделе не будет знать, как настроить и накодить чего-нибудь в экстренных условиях, потому что они умеют только запускать vagrant up, а дальше у них всё само работает. Я предпочитаю всё-таки иметь достаточно простую, но ручную инструкцию, по которой человек может быстренько пройти один раз и разобраться, что и где, и при этом не жертвовать привычной для него средой разработки.
К тому-же, хотите качественных уроков по nodejs, посмотрите как это сделал Илья Кантор learn.javascript.ru/nodejs-screencast. Там и про установку и настройку и даже немного в дебрях libuv покапался.
У меня возникает вопрос: «Для чего Java программисту Node.js»?
Ну это прям философский вопрос, и ответов на него может быть тысяча. Например, чтобы расширить кругозор, попробовать что-то за пределами своей спрингово-хибернейтовой зоны комфорта (или дискомфорта, у кого как), познакомиться с альтернативными подходами к решению знакомых задач. Приобрести новый ценный опыт, или чтобы обнаружить, что проблемы, на которые ты тратишь километры кода, в другом языке решаются однострочником.
Ну или чтобы собрать все возможные грабли и вернуться в лоно родной Java, зарекаясь и плюясь, что больше никогда и ни за что не будешь писать эту динамически типизированную лапшу из коллбэков.
Иногда понимаешь, что твоя любимая технология упирается в ограничения и не решает твоих проблем, но и готовых решений тебе никто не даст, и тогда нужно просто экспериментировать.
Ну или чтобы собрать все возможные грабли и вернуться в лоно родной Java, зарекаясь и плюясь, что больше никогда и ни за что не будешь писать эту динамически типизированную лапшу из коллбэков.
Иногда понимаешь, что твоя любимая технология упирается в ограничения и не решает твоих проблем, но и готовых решений тебе никто не даст, и тогда нужно просто экспериментировать.
То то и оно, что скорее цель этого у вас была «поиграться». Вот если бы тема была invoking js into node.js by JVM, то тогда было бы уместно писать про Java. Сейчас можно заменить Java на .*
Не разобрал ваше предложение на английском, что откуда invoking?
Цель, повторюсь, была конкретная — не «поиграться», а быстро ввести Java-разработчиков в суть технологии и дать им некий общий базовый уровень понимания того, как с ней работать.
Цель, повторюсь, была конкретная — не «поиграться», а быстро ввести Java-разработчиков в суть технологии и дать им некий общий базовый уровень понимания того, как с ней работать.
Да, название «Первое знакомство java-разработчика с node.js с использованием IDEA» было бы адекватнее.
Да не, тут есть зерно: де-факто и де-юре Java-девелопер (не новичок или примазавшийся, а разработчик в полном смысле слова) — это специалист, на голову выше «нодовца» аналогичного уровня. Точка пересечения этих платформ — только веб, то бишь фулл-стек для джавистов. Но сегодня рынок несколько странный — ему не очень нужны веб-ориентированные джависты, но при этом с руками отрываются нодовцы. Отсюда напрашивается вывод: почему бы не сделать downgrade своих skills, при этом увеличивая значительно свои котировки? Так что тут определенный сенс есть.
Другое дело — если заменить в статье слово «Java» на слово «PHP», статья сильно поменяется? В чем состоит ее ориентированность под джавистов? — В IDE, которая подавляюще используется именно для Java? — Это очень сомнительный аргумент.
Другое дело — если заменить в статье слово «Java» на слово «PHP», статья сильно поменяется? В чем состоит ее ориентированность под джавистов? — В IDE, которая подавляюще используется именно для Java? — Это очень сомнительный аргумент.
Скорее, в затронутых темах. Я решил в этой статье ответить на те вопросы, которые лично у меня возникли, когда я, имея опыт преимущественно на Java/JavaScript, пытался впервые что-то написать на node.js. Интеграция со знакомой мне средой разработки, декомпозиция на модули, тестирование. Заметьте, в статье ни слова про веб. Предполагаю, что у разработчиков на PHP вопросы были бы другие, более веб-ориентированные.
> де-факто и де-юре Java-девелопер (не новичок или примазавшийся, а разработчик в полном смысле слова) — это специалист, на голову выше «нодовца» аналогичного уровня
Невероятно толсто
Невероятно толсто
Похоже, нодовцам мои слова не понравились — оценка моего ответа говорит сама за себя. Неужели что-то обидное сказал?
Лишний раз подтвердили свой уровень.
Лишний раз подтвердили свой уровень.
Из того, что на статически типизированных языках проще писать код без «детских» ошибок и механизированно рефакторить его средствами IDE без необходимости тестирования до и после, ибо сами IDE и статическая типизация гарантируют адекватность в простых случаях, и из того, что под Java есть куча всяких интересных средств и библиотек, ещё не следует, что кто-то там кого-то «на голову выше». К тому же в природе существует не особо много чистых «нодовцев»: технология новая, узкая, и обычно каждый владеет кроме неё ещё чем-то.
А мне кажется, я понимаю, что имеет в виду IDVsbruck, хоть он и высказался несколько грубо, за что его и заминусовали нещадно. Если сравнить опытного Java-разработчика, догнавшегося до фуллстэка, и опытного специалиста по фронтэнду, научившегося писать серверсайд на node.js, боюсь, сравнение будет не в пользу последнего. Просто потому, что опытный джавист — это не просто веб-разработчик, а человек, рубящий во множестве различных направлений разработки: от хардкорной многопоточности и низкоуровневых клиент-серверных приложений до всяких крупных интеграшек и энтерпрайзов.
Но при этом он вряд-ли знает как грамотно собрать здоровый SPA например. Это из области сравнения теплого с мягким…
Java — это своя большая вселенная, и, наверное, поэтому я ещё не имел возможности пообщаться с опытными Java-разработчиками, догнавшимися до фуллстэка. Обязательно для каждого находилось что, что, с чем он ещё не имел дела. Самое распространённое — именно многопоточность: новации в версии 1.6 в классе
Unsafe по части атомарных «compare-and-swap» и их обвязки из новых библиотек для многих прошли незамеченными. Я подозреваю, таких во-всём-опытных джавистов в природе существует приблизительно столько же, сколько чистых «нодовщиков» — единицы процентов от числа всех разработчиков.новации в версии 1.6 в классе Unsafe
«Новации» в классе Unsafe и должны проходить незамеченными для большинства разработчиков. Этот класс обходит управление памятью, и реально может пригодиться лишь разработчикам альтернативных JVM-языков или высокопроизводительных узкоспециализированных библиотек, но прикладного программиста, сунувшего туда нос, надо бить по рукам.
Если бы вам пришлось проходить собеседования по этой самой хардкорной многопоточности, которую вы упомянули, то вы бы сейчас не вставали в позу человека, менторским тоном объясняющего очевидные вещи. На этих новациях как раз и построена вся библиотека
java.util.concurrent, через которую осуществляется вся новомодная «легковесная» многопоточность в Java, достаточно посмотреть их код в стандартной библиотеке. Ведь Java-программисты, даже не «опытные», а «прикладные», должны уметь и иметь склонность читать чужой код, тем более стандартные библиотеки. Или за это тоже бить их по рукам?
«X для Y-разработчиков»… это же можно N^2 туториалов написать!
Простите, это что, такой новый стиль быстрого комментария для плюсов? Антихвалебный отзыв?
Мне нравится — я читаю. Не нравится — не читаю.
Мне нравится — я читаю. Не нравится — не читаю.
Новое писать нужно. Но вот такого руководства лично мне не хватало, когда я взялся за Node.js!
То ли я слепой, то ли вы не правы: в каком месте оно для Java-разработчика-то?
Ну так это… IDEA-же :-D
Уже ответил на этот вопрос чуть выше habrahabr.ru/company/cit/blog/259987/#comment_8455691
Это ни разу не ответ на заданный вопрос: при чём тут Java-разработчики?
В заголовке статьи заявлено, что Java-разработчики в своём стеке технологий могут использовать node.js, при этом никаких реальных примеров такого использования в статье нет. В вашем случае нужно или писать для «пользователей Idea» или «JS-разработчиков». Хотя последние и без этой статьи, в большинстве своём, разобрались с даной темой.
А ещё лучше просто убрать слово Java, либо заменить на {lang}.
В заголовке статьи заявлено, что Java-разработчики в своём стеке технологий могут использовать node.js, при этом никаких реальных примеров такого использования в статье нет. В вашем случае нужно или писать для «пользователей Idea» или «JS-разработчиков». Хотя последние и без этой статьи, в большинстве своём, разобрались с даной темой.
А ещё лучше просто убрать слово Java, либо заменить на {lang}.
Да, при том, что статья была опробована на Java-разработчиках и дала требуемый результат.
Нигде, ни в заголовке статьи, ни в её содержании, не было речи об использовании node.js в Java-стеке. Задачи такой не ставилось. Смысл статьи в том, чтобы человек с Java-бэкграундом быстро разобрался в новой для себя технологии и начал работу над проектом, который основывается на ней.
А почему обойдена вниманием среда разработки Eclipse? Которая к тому же ещё и бесплатна, в отличие от IDEA, которая обычно «крякнутая»?
Да, у меня было желание описать и Eclipse, но её у нас используют немногие, да и статья без того получилась большой и развесистой.
Кроме того, на первый взгляд, IDEA поддерживает JavaScript и смежные технологии значительно лучше и в основном из коробки.
Кроме того, на первый взгляд, IDEA поддерживает JavaScript и смежные технологии значительно лучше и в основном из коробки.
Это почему она «обычно крякнутая»?
Хм… а кто мешает пользоваться IDEA Community Edition? Для работы хватает с головой.
Если по работе нужно писать только в рамках Java SE, то возможно. Но все плагины для популярных фреймворков и языков, без которых почти ни один проект не обходится (EE, Spring, Hibernate, веб, работа с базами данных), есть только в платной версии. Плагин для node.js, кстати, тоже в Community Edition недоступен.
Может автору оперативной памяти не хватило?
UFO just landed and posted this here
Что-то не похож choco на менеджер пакетов. Он скачивает ту же msi, ставит её туда же в Program Files, просто в тихом режиме. А в папке lib у него лежат только нугетовые метаданные. Если он всё остальное ставит так же, то это, скорее, не менеджер пакетов, а менеджер сайлент-инсталлов.
И вообще, PostgreSQL 9.4 нет, зато магазин с футболками есть :o)
Если серьёзно, это, конечно, тоже вариант, но я и не пытался в статье осветить все способы установки, как раз наоборот, дать только один конкретный.
И вообще, PostgreSQL 9.4 нет, зато магазин с футболками есть :o)
Если серьёзно, это, конечно, тоже вариант, но я и не пытался в статье осветить все способы установки, как раз наоборот, дать только один конкретный.
Я не понимаю, зачем человеку, который «очень хорошо» или просто «хорошо» знает Java использовать node.js?
Не более ли свято писать нанормальном языке на Java? Есть же как минимум сервлеты, есть же JSP, которые работают на «ура!» в tomcat'e из коробки за могучими плечами nginx'а. Для более тонкой работы молотком можно писать и свои классы и запускать их под нужными учетками прямо в linux, если tomcat (взят как самый простой пример на 1-2-готово) не хватает.
Побудить Java программиста писать на JS backend может только интерес или нужда. Или глупый менеджер, который скажет «Ну ты же на Джава пишешь? Вот тебе и тут Джава [скрипт], на собрании мы утвердили.»
Не более ли свято писать на
будет полезна не только разработчикам из мира Java
Побудить Java программиста писать на JS backend может только интерес или нужда. Или глупый менеджер, который скажет «Ну ты же на Джава пишешь? Вот тебе и тут Джава [скрипт], на собрании мы утвердили.»
Сервлеты и JSP? Вы это серьёзно? Даже в последнем официальном туториале по Java EE раздел про JSP уже отсутствует, отныне «свято» писать веб-слой на JSF. Перечисленные вами технологии по простоте, скорости разработки и отладки даже близко не стоят с написанием бэкэнда на node.js, где сервер поднимается одним файлом из нескольких строк и перезапускается за доли секунды без перекомпиляции и пересборки. Я понимаю, если бы вы привели в пример что-то посвежее и подинамичнее, хотя бы Spring Boot.
У Java есть серьёзные преимущества перед node.js даже в контексте веб-разработки, но сервлеты и JSP это точно не одни из них. Для некоторых не столь фундаментальных задач стек Java слишком тяжёлый, разработка на нём медленная и не очень гибкая. С этим мы сталкивались во многих проектах, и решили поэкспериментировать с альтернативными технологиями.
У Java есть серьёзные преимущества перед node.js даже в контексте веб-разработки, но сервлеты и JSP это точно не одни из них. Для некоторых не столь фундаментальных задач стек Java слишком тяжёлый, разработка на нём медленная и не очень гибкая. С этим мы сталкивались во многих проектах, и решили поэкспериментировать с альтернативными технологиями.
А в чем проблема у Servlet's и JSP? Hotswap на ура просовывает их без перезагрузки сервера. И тот же самый JSF все равно работает поверх servlet'а. Вы очень хитрите или не разобрались в устройстве. Я вот к примеру поднимаю jetty за 20 миллисекунд! Если туда притащить тот же Spring, время запуска увеличится до секунд. Кстати и jrebel никто не отменял.
У чистых сервлетов и JSP проблема, например, в том, что там из коробки недостаточно хорошее разделение между данными, бизнес-логикой и презентацией, и не задан архитектурный паттерн, потому неопытные разработчики часто работают с БД прямо в JSP, а в сервлетах рисуют HTML. Ну просто потому что это же можно сделать, значит, почему бы и нет. Надеюсь, вы не из таких: о)
Hotswap имеет очень ограниченную применимость, так как меняет только код внутри методов и не допускает структурных изменений, для них всё равно приходится перезапускать сервер. JRebel стоит денег, и это ещё один компонент в стек разработки. А теперь посчитайте время на настройку чистой девелоперской машины и разработку на ней простейшего сервера, отдающего динамическую страничку — на Java и на node.js.
Я так понимаю, вы какие-то свои узкоспециализированные задачи решили без дополнительных фреймворков, и у вас Jetty стартует за 20 миллисекунд, и это прекрасно. Но для чуть более сложных задач вам всё равно придётся что-то подключать.
Hotswap имеет очень ограниченную применимость, так как меняет только код внутри методов и не допускает структурных изменений, для них всё равно приходится перезапускать сервер. JRebel стоит денег, и это ещё один компонент в стек разработки. А теперь посчитайте время на настройку чистой девелоперской машины и разработку на ней простейшего сервера, отдающего динамическую страничку — на Java и на node.js.
Я так понимаю, вы какие-то свои узкоспециализированные задачи решили без дополнительных фреймворков, и у вас Jetty стартует за 20 миллисекунд, и это прекрасно. Но для чуть более сложных задач вам всё равно придётся что-то подключать.
У меня свои костыли методы рисования сложных html:
Например JSP выдает
Иногда достаточно найти шаблон страницы, с красивым дизайном, выделить в ней {{content_here}} или как угодно, или просто добавить ssi с регулярками в место для контента для парсинга uri и запросов к бекенду.
Прямых запросов моей динамики никогда нету, они все фильтруются на nginx, модные ссылки
А сервлеты последний раз я использовал в 2007, наверное. Сейчас все на JSP, по сути пишу каждый раз свой API, с которым, скрыто от глаз пользователя, работает nginx. В купе с кешем nginx сайты работают очень быстро.
- старичек ssi
- ngx_http_substitutions_filter_module
Например JSP выдает
{{form_login}}Петя!{{form_account}}, затем эти {{form_account}} и {{form_login}} заменяются в nginx (в фильтре) на нужные мне include virtual в ssi к статичным кускам или к, опять же, динамике. В итоге юзер видит страницу, а JSP отвечает не стеной текста, а парой строк, от силы.Иногда достаточно найти шаблон страницы, с красивым дизайном, выделить в ней {{content_here}} или как угодно, или просто добавить ssi с регулярками в место для контента для парсинга uri и запросов к бекенду.
Прямых запросов моей динамики никогда нету, они все фильтруются на nginx, модные ссылки
example.com/petya и example.com/blog/kogda-ya-bil-na-more это просто регулярки nginx и $1, $2 и сколько душе угодно групп, запросами к бекенду.А сервлеты последний раз я использовал в 2007, наверное. Сейчас все на JSP, по сути пишу каждый раз свой API, с которым, скрыто от глаз пользователя, работает nginx. В купе с кешем nginx сайты работают очень быстро.
Вы забили на миллион существующих шаблонизаторов, написанных для Java, и вытащили веб-слой на отдельный сервер со сторонней технологией. И ещё что-то тут говорите про «зачем переходить куда-то с хорошей, годной Java». Да вы с неё уже перешли, только на собственный велосипед.
Так можно и на SQL забить или на noSQL, давайте хранить данные в файликах как XML! Зачем выносить выборки на SQL сервер, когда можно самому написать, строкой меньше, строкой больше. Сторонняя технология поди ж!
Вот именно, будет 10^6+1 решение. Веб слой — это у меня nginx, юзеры работают с ним, он у меня frontend, java же работает на backend'e, что по логике значит «за-фронтендом». Это nginx решает что отдать юзеру по тому или ному шаблону ситуации и какой JSP что передать. Backend даже запросов не получает в том виде, в котором они приходят на фронтенд.
А вот использование технологии SSI, которая резвее чем пони, в nginx помогает сделать код читабельнее без вставок html и повысить перфоманс. Можно, конечно и в JSP вставлять код из файликов или из динамики, а затем сие выдавать, только я верю, что потеряю в скорости. Я не проверял и не хочу это проверять (но почитаю отчет), так как текущая скорость выше всех похвал.
Логика веба [nginx] завязана на регулярках в конфигах и на тоннах переменных. Если мне этого будет мало, я буду смотреть в сторону lua плагина.
Вы забили на миллион
Вот именно, будет 10^6+1 решение. Веб слой — это у меня nginx, юзеры работают с ним, он у меня frontend, java же работает на backend'e, что по логике значит «за-фронтендом». Это nginx решает что отдать юзеру по тому или ному шаблону ситуации и какой JSP что передать. Backend даже запросов не получает в том виде, в котором они приходят на фронтенд.
А вот использование технологии SSI, которая резвее чем пони, в nginx помогает сделать код читабельнее без вставок html и повысить перфоманс. Можно, конечно и в JSP вставлять код из файликов или из динамики, а затем сие выдавать, только я верю, что потеряю в скорости. Я не проверял и не хочу это проверять (но почитаю отчет), так как текущая скорость выше всех похвал.
Логика веба [nginx] завязана на регулярках в конфигах и на тоннах переменных. Если мне этого будет мало, я буду смотреть в сторону lua плагина.
Жесть какая-то, извините. Но я рад, если ваш стек технологий успешно решает ваши проблемы, желаю удачи в его развитии.
В том-то и дело, что решает и решает успешно и, как Java разработчик как программист, который пишет на java софт и сайты, обертывая последние в nginx'ом, не вижу смысла использовать node.js для последних.
Если смысл имеет — приведите примеры, пожалуйста.
Если смысл имеет — приведите примеры, пожалуйста.
Жесть-не жесть, но помню, что в Apache тоже бы какой-то модуль для обработки некоторых запросов с помощью Tomcat.
Ну это логично. Apache быстро сервит статичный контент, а работу с динамикой передаёт Tomcat. Здесь же весь веб-слой выдернут в nginx.
Насколько я понял, SSI в nginx в случае статических инклудов работает с той же скоростью, что простая отдача статики, так что дополнительных накладных расходов нет, и можно себе позволить делать окончательную сборку отдаваемой страницы в nginx.
SSI у меня как статичный, так и динамичный (virtual) + кеш (для динамики). В случае выдачи SSI'ками из кеша задержек вообще нету.
Apache не использую потому, что незачем (даже php работает с nginx как php-fpm), и потому, что он медленнее чем nginx для статики и больше ест памяти.
Nginx почти сервер мечты.
Apache не использую потому, что незачем (даже php работает с nginx как php-fpm), и потому, что он медленнее чем nginx для статики и больше ест памяти.
Nginx почти сервер мечты.
Apache быстро сервит статичный контент
Простите, «что»?)
Вы очень хитрите
Вот это в точку.
Представьте, что автор этой статьи прекрасно знает о том, что Вы пишите. Теперь предположите, что и все следующие аргументы из разряда «Java — лучше» ему тоже известны. А теперь задайте себе вопрос: раз так, то почему же эти парни вместо Java взяли в руки node.js? Ответ сложен и прост одновременно: хорошие программисты добиваются результата на том стеке, который больше подходит для конкретной задачи.
Я бы хотел перевести разговор в иную плоскость: какой RAD больше подходит для разработки в условиях очень кратких, практически одно- и двухдневных итераций с условием перехода в условный продакшн на финишной прямой такой разработки.
Я не согласен по поводу утверждения, что та или иная технология больше или меньше подходит под конкретную задачу. Я все время и везде слышу эту мантру, но она существует лишь чтобы успокоить холиварщиков. Есть узкоспециализированные технологии для очень ограниченного круга задач, но которые не претендуют ни на что глобальное. Есть хорошие универсальные технологии, проверенные временем, подходящие сразу для большого круга задач. А есть технологии, претендующие на универсальность, в большинстве случаев слишком зеленые, с помощью которых тоже типа можно решить ту или иную задачу. И что странно, и те и другие технологии развиваются и используются. Почему? Просто так сложилось. Кому-то понравилось, кто-то купился на рекламу, кто-то что-то неосилил, кто-то решил извратнуться, кому-то просто стало интересно. Пользователь никогда не делает выбор технологии на основе скурпулезного анализа: для этого он должен в совершенстве владеть всеми сразу, чтобы знать и понимать где есть какие подводные камни.
Ответ простой: та технология, которой Вы наиболее владеете на данный момент. Если это Java с фреймворком — отлично. Если это node.js — ради бога! Если это pyton или perl — флаг Вам в руки!
Вот если у меня проект «для души», где никуда не спешу, и есть время и интерес попробовать на вкус другие технологии, тогда почему нет?
Я бы хотел перевести разговор в иную плоскость: какой RAD больше подходит для разработки в условиях очень кратких, практически одно- и двухдневных итераций с условием перехода в условный продакшн на финишной прямой такой разработки.
Ответ простой: та технология, которой Вы наиболее владеете на данный момент. Если это Java с фреймворком — отлично. Если это node.js — ради бога! Если это pyton или perl — флаг Вам в руки!
Вот если у меня проект «для души», где никуда не спешу, и есть время и интерес попробовать на вкус другие технологии, тогда почему нет?
Вы не правы. Любая технология делается для решения конкретных задач, которые в тот момент стояли перед разработчиками, или преодоления того, что они считали своей проблемой в тот момент. Все технологии в той или иной степени opinionated. Хотя на крайней стороне спектра стоит как раз Java, на которой одинаково медленно и неуклюже пишется всё, зато в стабильно долгие сроки, а стабильные сроки — это тоже очень важно в определённых задачах. Но технология, которая писалась авторами для решения вот этой конкретной проблемы, всегда будет для неё лучше, чем технология, созданная для написания фабрики фабрик решения любых проблем вообще.
Любая технология делается для решения конкретных задач
Для решения каких конкретных задач был придуман Unix? Или язык C? Вот JavaScript был изначально задуман как чисто клиентская технология для выполнения простой логики в браузере, и, собственно, таковой и остается и по сей день. Популярность он приобрел во многом благодаря стараниям и усердию Sun Microsystems по убийству клиентской Java. Node.js — это экспансия технологии в область, для которой он не был изначально предназначен.
Java, на которой одинаково медленно и неуклюже пишется всё, зато в стабильно долгие сроки
Да с чего Вы это взяли? Да, на Java код в целом получается длиннее, но ведь программист не стенографистка! Благодаря статической типизации вкупе с поддержкой IDE код пишется в несколько раз быстрее, чем на языках с динамической типизацией. Отладка занимает гораздо меньше времени, а любые ошибки легко локализуемы. Есть еще такие фазы как моделирование, прототипирование, тестирование и отладка, и поддержка. Как можно на динамическом языке вообще что-то смоделировать? Поэтому уже написание проекта средней сложности на динамических языках доставляет большой геморрой. Даже компании Google и Microsoft понимают, что нужна замена JS на что-нибудь со статической типизацией (Dart, TypeScript).
технология, которая писалась авторами для решения вот этой конкретной проблемы, всегда будет для неё лучше
В большинстве реальных задач конкретных проблем как правило много. Использование единой универсальной технологии, покрывающей их всех, пусть даже не самым оптимальным способом, в итоге будет эффективней, нежели использование N различных технологий и решения проблем с интеграцией.
Для решения каких конкретных задач был придуман Unix? Или язык C?
Жаль, у старины Ритчи уже не спросить, но я думаю, он не просто так писал этот язык, потому что ему захотелось сделать что-нибудь ненужное для своего удовольствия. Язык C преуспел в стандартизации универсальных и портируемых шаблонов процедурного программирования, и за это ему большое спасибо. Думаю, именно для решения этой проблемы он и был разработан, но не берусь судить, так как не имею на нём достаточного опыта.
Да с чего Вы это взяли?
С того, что пишу на Java уже много лет и имею опыт в массе проектов разной сложности и в разных направлениях разработки.
Благодаря статической типизации
Статическая типизация для думающего программиста имеет смысл, только когда в языке система типов нормальная. Scala, Haskell, вот там она действительно даёт плоды. В мейнстримных языках система типов служит, скорее, для исключения совсем уж глупых ошибок (= компенсации криворукости).
вкупе с поддержкой IDE
Давайте называть вещи своими именами, не «поддержкой IDE», а «компенсацией необоснованной сложности благодаря использованию (зачастую) платных монструозных продуктов».
Да, на Java код в целом получается длиннее
Да речь не только и не столько про «длиннее». На Java вообще что-то реально работающее сделать занимает больше времени. У меня ещё свежо в памяти, сколько правильно сформированных файликов нужно было разложить по нужным папочкам, чтобы завелось простейшее веб-приложение на Tomcat, при этом и Java, и Tomcat, и IDE молчаливо разводили руками и не предоставляли абсолютно никаких средств для поиска и исправления проблемы. Хорошо, что в последние годы ситуация немного выправилась, но далеко не до конца. Количество стороннего софта, настроек, кодовых артефактов, которые нужны для решения простейшей задачи, по-прежнему слишком велико.
И забавно, что вы упомянули про прототипирование. Может, в последние годы средства для быстрого прототипирования и начали появляться на Java, но они далеки от того, что хотелось бы иметь. Прототипировать на Java это всё равно что делать макет в масштабе 1:1. Она не даёт абсолютно никаких средств для «срезания углов» при разработке.
Как можно на динамическом языке вообще что-то смоделировать?
О, моделирование, эта священная корова ООПшников. Благодаря этой практике Java-программисты тратят уйму времени на моделирование всего, что движется, и показывают первый результат программы, которая Хоть Что-То Делает, лишь спустя множество человекочасов. А потом на каждое изменение кричат «Да ведь мы же уже так замоделировали! Да что ж вы сразу не предусмотрели! Да тут теперь половину кода переделывать!» Да, для определённых (и, надо сказать, весьма узких) задач моделирование предметки в коде — штука полезная. Но не для тех, в которых не то что модель, а даже метамодель постоянно меняется — а результат нужно показывать в те же сроки.
Поэтому уже написание проекта средней сложности на динамических языках доставляет большой геморрой.
Написание проекта средней сложности на любом языке доставляет геморрой. Я не знаю ни одной платформы, которая бы явно продвигала «на мне легко писать большие проекты!» в качестве своих преимуществ, или у которой это было бы явно заложено при её разработке. Есть мнения конкретных разработчиков о том, где им удобно или неудобно поддерживать крупную кодовую базу, но мнения эти эмпиричны и обусловлены тем, научились ли они «готовить» эту технологию или нет. Для написания больших и сложных проектов единственная нормальная технология — это прямые руки, на любом языке.
Применительно к Java говорить вообще не о чем, модульность там игрушечная, вспомните jar hell. Адекватная система модульности в лучшем случае появится в Java только в следующем году, спустя 21 (!) год после её создания.
У меня ещё свежо в памяти, сколько правильно сформированных файликов нужно было разложить по нужным папочкам, чтобы завелось простейшее веб-приложение на Tomcat, при этом и Java, и Tomcat
Это проблема не Java, а выбранной вами конкретной технологии — servlet, которая является частью стека JEE, довольно тяжелого и неудобоваримого. Более того, это проблема вообще всех фреймворков, где что-нибудь не так сконфигуришь или не следуешь соглашением, и в результате либо тупо не работает, либо выбрасывает ни о чем не говорящую ошибку. Но Java не лимитирована сервлетами и томкетом. Существуют десятки других библиотек и фреймворков для веб разработки разной степени сложности и функционала. Запустить простейший сервер можно вообще одной строчкой без единого дополнительного jar-а.
Благодаря этой практике Java-программисты тратят уйму времени на моделирование всего, что движется
Без этого код быстро зарастет заплатками и наспех склепаным дерьмом, и интегрировать новый функционал станет с каждым разом все труднее. И в один прекрасный момент придется все переписывать с нуля, вместо того, чтобы делать своевременный рефакторинг. Тем более, если представить, чтоб вы пишите код не один…
Адекватная система модульности в лучшем случае появится в Java только в следующем году, спустя 21 (!) год после её создания.
Вроде как OSGI уже давно есть и используется всеми, кому не лень…
Я в курсе всего, что вы перечисляете, и много с чем поработал. Может, потому и не разделяю вашей уверенности. А вы сами-то что используете для быстрого прототипирования на Java? Много веб-приложений на com.sun.net.httpserver.HttpServer написали? OSGi у вас во многих проектах используется? Как впечатления о скорости разработки на этих технологиях?
Причина негативного впечатления от Java в том, что она была испорчена всевозможными фреймворками. Это началось с J2EE и продолжается по сей день. Естественно, когда после каждого изменения требуется перекомпилировать код, перепаковать приложение и передеплоить на удаленный сервер (а иногда и перезагрузить сам сервер), то время разработки увеличивается в десятки раз. Но надо понимать, что это не единственный способ. Если в мире JS для сервера существует только node.js, то для Java для любой задачи всегда есть десятки альтернатив.
Я вместо удаленного Tomcat использую Embedded Jetty, который может конфигурироваться программно (в обход web.xml) и пускаться как отдельное приложение за миллисекунды, «подцепляя» ваше веб приложение из classpath. Для быстрого прототипирования я использую обычный JSP+JSTL без всяких фреймворков. Благо JSP plugin для Eclipse есть и позволяет дебаггить. Для ускорения писанины часть использую Groovy, там, где это разрешается клиентом.
Тот же com.sun.net.httpserver.HttpServer вкупе с Jersey уже дает полноценный restful-сервер.
Со Spring-ом не сраслось. Есть полезные вещи, но многие концепты просто рудиментарны и только усложняют разработку, особенно где нужно выйти за рамки позволенного. Стараюсь его избегать, где только возможно, однако всегда приходится иметь с ним дело (желание клиента — закон).
Еще хвалят Play framework, но лично я не пробовал. Отвращают темплейты, писанные на Scala.
По спецзаказу приходится пользовать JEE стек. Однако, есть отличный контейнер OpenEJB, позволяющий за секунду пускать себя в Embedded режиме и подцеплять EJB из classpath, а также легко писать модульные тесты. Бонусом большое число примеров на каждую технологию стека.
Так что на Java вполне можно быстро и эффективно разрабатывать. Сегодня Java — это огромный набор технологий, зачастую дублирующих друг друга. Эффективность разработки зависит от выбора и от уровня владения технологией.
Я вместо удаленного Tomcat использую Embedded Jetty, который может конфигурироваться программно (в обход web.xml) и пускаться как отдельное приложение за миллисекунды, «подцепляя» ваше веб приложение из classpath. Для быстрого прототипирования я использую обычный JSP+JSTL без всяких фреймворков. Благо JSP plugin для Eclipse есть и позволяет дебаггить. Для ускорения писанины часть использую Groovy, там, где это разрешается клиентом.
Тот же com.sun.net.httpserver.HttpServer вкупе с Jersey уже дает полноценный restful-сервер.
Со Spring-ом не сраслось. Есть полезные вещи, но многие концепты просто рудиментарны и только усложняют разработку, особенно где нужно выйти за рамки позволенного. Стараюсь его избегать, где только возможно, однако всегда приходится иметь с ним дело (желание клиента — закон).
Еще хвалят Play framework, но лично я не пробовал. Отвращают темплейты, писанные на Scala.
По спецзаказу приходится пользовать JEE стек. Однако, есть отличный контейнер OpenEJB, позволяющий за секунду пускать себя в Embedded режиме и подцеплять EJB из classpath, а также легко писать модульные тесты. Бонусом большое число примеров на каждую технологию стека.
Так что на Java вполне можно быстро и эффективно разрабатывать. Сегодня Java — это огромный набор технологий, зачастую дублирующих друг друга. Эффективность разработки зависит от выбора и от уровня владения технологией.
Java прекрасный язык, понятный и без особых болячек перетёкших из прошлых версий.
Но к примеру Web стек на java это боль, и это надо признать. На сегоднийший момент, он не может конкурировать с современными фреймворками и платформами. На сколько можно не любить Microsoft за проприетарность, но они взяли и написали замечательный asp.net mvc, который вобрал в себя лучшее из того что было на рынке, особенно много взяли идей с рельсов.
К сожаления java сейчас топчется на месте, старые библиотеки вроде Hibernate с старыми подходами. Плюс такие компании как typesafe.com и spring source на данный момент тормозят развитие паразитируя на jvm и продвигая собственные разработки и сапорт к ним.
Очень большое комьюнити у java но оно не в состоянии привести java в современный веб.
Пишут конечно куски серверов на java тот же твитер переписал поиск на netty.io но нет полноценного фрейворка уровня рельсов, asp.net mvc или хотя бы express.
Новый jax-rs 2.0 конечно хорош например для написания API, но к нему не хватает нормальной работы с базой к примеру, миграции, работа с assets и прочие прелести что сейчас есть в современной разработке в веб.
Я в курсе про flywaydb.org и прочие библиотеки для миграций, и про www.webjars.org для подключения assets всяких тоже знаю, но это называется «каждый др.чет как хочет».
И пока сконфигурируешь всё это дело, на рельсах или node уже можно прототип написать на половину.
Я люблю java но в вебе ей нечего предложить по сравнению с другими. Хотя в корпоротивном сегменте она и ценится может быть.
но что то я не видел современных проектов на java.
Но к примеру Web стек на java это боль, и это надо признать. На сегоднийший момент, он не может конкурировать с современными фреймворками и платформами. На сколько можно не любить Microsoft за проприетарность, но они взяли и написали замечательный asp.net mvc, который вобрал в себя лучшее из того что было на рынке, особенно много взяли идей с рельсов.
К сожаления java сейчас топчется на месте, старые библиотеки вроде Hibernate с старыми подходами. Плюс такие компании как typesafe.com и spring source на данный момент тормозят развитие паразитируя на jvm и продвигая собственные разработки и сапорт к ним.
Очень большое комьюнити у java но оно не в состоянии привести java в современный веб.
Пишут конечно куски серверов на java тот же твитер переписал поиск на netty.io но нет полноценного фрейворка уровня рельсов, asp.net mvc или хотя бы express.
Новый jax-rs 2.0 конечно хорош например для написания API, но к нему не хватает нормальной работы с базой к примеру, миграции, работа с assets и прочие прелести что сейчас есть в современной разработке в веб.
Я в курсе про flywaydb.org и прочие библиотеки для миграций, и про www.webjars.org для подключения assets всяких тоже знаю, но это называется «каждый др.чет как хочет».
И пока сконфигурируешь всё это дело, на рельсах или node уже можно прототип написать на половину.
Я люблю java но в вебе ей нечего предложить по сравнению с другими. Хотя в корпоротивном сегменте она и ценится может быть.
но что то я не видел современных проектов на java.
Выдуманные причины. Вы можете ничего не конфигурить и написать прототип используя Spring (Spring Boot) или Play (которые можно легко сравнивать с рельсами,asp.net). Разработка Web приложений ничем особо не отличается от других платформ. И почему вы приписываете тулы для работы с базой к языку? Видимо вы просто многого не знаете про Java.
Я говорил в целом о веб стеке который предоставляет java скажем из коробки (EJB, сервлеты, jax-rs и прочее).
Даже Spring Boot не спасает от конфигурирования, всё равно приходится переопределять некоторые вещи в своём конфиге ещё и попутно перечитывая кучу доков а они у них не маленькие. Play далеко до asp.net mvc и уж темболее до рельсов.
Приписываю тулзы, потому что есть пример Microsoft c своим mvc фреймворком, когда они взяли откинули класический asp.net и web forms и переписали всё с нуля и предоставили пользователям современый стек для веба. Почему Oracle так не может?
Даже Spring Boot не спасает от конфигурирования, всё равно приходится переопределять некоторые вещи в своём конфиге ещё и попутно перечитывая кучу доков а они у них не маленькие. Play далеко до asp.net mvc и уж темболее до рельсов.
Приписываю тулзы, потому что есть пример Microsoft c своим mvc фреймворком, когда они взяли откинули класический asp.net и web forms и переписали всё с нуля и предоставили пользователям современый стек для веба. Почему Oracle так не может?
Давайте больше конкретики. Вы прям как автор это статьи слышали звон, да не знаете откуда он. Больше фактов и примеров. Я не знаю почему Play далеко до asp.net и не знаю, что такого может быть в рельсах чего нету в Java world. Webform я не считаю современным стеком для веба. Ибо современный веб это spa.
Вы вообще читаете, Webforms ещё до выхода asp.net mvc были не актуальны. Поэтому и был написан asp.net mvc где была классическая модель запрос/ответ с отдачей html. Я разве писал, что он современнен?
Тогда SPA может только начинало пахнуть.
О какой конкретики может идти речь если вы не вкурсе что происходит в других платформах.
Java web stack так и застрял во временах jsp и класического запроса/ответа.
Spring это исправил и налепил вокруг сервлетов свою кодовую базу.
Нет у java полноценого веб стека, поэтому и появляются вот такие www.ninjaframework.org вещи, где пытаются собрать хоть что то приличное из того что есть.
Может поэтому на гитхабе появляются свои велосипеды от именитых компаний как netflix github.com/Netflix/ribbon или к примеру linkedin github.com/linkedin/rest.li, которые поверх netty.io или grizzly.java.net пишут свои фреймворки на которых живут их сервисы.
jax-rs 2.0 ещё как то можно работать и то тоже надо конфиги, connection pool в app сервере прописать потому что по сути это теже Servlet 3.0.
Расскажите как вы на java пишите SPA?
Тогда SPA может только начинало пахнуть.
О какой конкретики может идти речь если вы не вкурсе что происходит в других платформах.
Java web stack так и застрял во временах jsp и класического запроса/ответа.
Spring это исправил и налепил вокруг сервлетов свою кодовую базу.
Нет у java полноценого веб стека, поэтому и появляются вот такие www.ninjaframework.org вещи, где пытаются собрать хоть что то приличное из того что есть.
Может поэтому на гитхабе появляются свои велосипеды от именитых компаний как netflix github.com/Netflix/ribbon или к примеру linkedin github.com/linkedin/rest.li, которые поверх netty.io или grizzly.java.net пишут свои фреймворки на которых живут их сервисы.
jax-rs 2.0 ещё как то можно работать и то тоже надо конфиги, connection pool в app сервере прописать потому что по сути это теже Servlet 3.0.
Расскажите как вы на java пишите SPA?
Оу оу, парень полегче.
Не переходи на личности и не говори чего я не знаю. Я довольно хорошо знаю, как обстоят дела во многих платформах. И asp.net mvc тоже не является современным)
Свои велосипеды появляются потому что задачи могут быть узкоспециализированными + возможно требование компании.
SPA я на Java не пишу, на Java я пишу API для SPA.
Не переходи на личности и не говори чего я не знаю. Я довольно хорошо знаю, как обстоят дела во многих платформах. И asp.net mvc тоже не является современным)
Свои велосипеды появляются потому что задачи могут быть узкоспециализированными + возможно требование компании.
SPA я на Java не пишу, на Java я пишу API для SPA.
Может для начала перечитаете свои предыдущие 3 комментария, где вы указывали мне чего я не знаю?.. Забавно. Вот вам на досуге почитайте про asp.net mvc новую habrahabr.ru/post/243667 и прослезитесь. Сравните веб стек который предоставляют «МелкоМягкие» и java EE… Сравните как создаются проекты. В asp.net mvc, node, rails вам нужно ввести 2-3 команды и проект готов к началу разработке, ближе всего к этому подобрался projects.spring.io/spring-roo и Spring Boot но это просто надстройка над самим spring, который надстройка грубо говоря над сервлетами.
Ну так опишите, на чём пишите api. Что используете для базы. Как поддерживаете актуальность базы в команде если сегодня добавилась новая таблица или была изменена уже имеющееся.
Те велосипеды это rest фреймворки которые позволяют писать rest api ничего сверх естественного там нет, просто нынешний java EE стек убог вот и велосипедят. Многие стараются следовать JSR 339, многие пишут своё. Я привёл всего два примера, а их куча как и имплиментаций JSR 339. К примеру resteasy.jboss.org и jersey.java.net
Ну так опишите, на чём пишите api. Что используете для базы. Как поддерживаете актуальность базы в команде если сегодня добавилась новая таблица или была изменена уже имеющееся.
Те велосипеды это rest фреймворки которые позволяют писать rest api ничего сверх естественного там нет, просто нынешний java EE стек убог вот и велосипедят. Многие стараются следовать JSR 339, многие пишут своё. Я привёл всего два примера, а их куча как и имплиментаций JSR 339. К примеру resteasy.jboss.org и jersey.java.net
но что то я не видел современных проектов на java.
Ходят слухи, что и Сбербанк и Альфабанк используют Java технологии в личном кабинете пользователя.
Есть еще достаточно известный магазин различных товаров, который более чем полностью реализован на Java (я как бывший инсайдер это говорю).
Еще, на моей скромной практике, почти всегда не хватало «вот этих вот готовых для прототипирования фреймворков». Малейший шаг в сторону — «ну… это не по концепту… Ну вам это не нужно.»
Всё это очень кьютные технологии, хорошо годящиеся для фрилансерства и типовых веб-приложений, но в команде и на крупных проектах, когда задачи каждый день разные, модели большие и часто меняющиеся, а делать надо всегда быстро, они масштабируются очень плохо. Ну вот нужно вам разработать прототип несложного приложения, формочек, скажем, на 40, и сущностей на 100, десяток отчётов, несколько бизнес-процессов, штук пять прикладных ролей и пару админских. Сколько вы будете писать такой прототип на JSP+JSTL, а главное, что вы будете с ним делать, когда заказчик даст отмашку, и разработанный вами прототип нужно запихнуть в команду из 6-8 разработчиков, готовых колбасить? Не забудьте, что разработчикам надо будет прикручивать аутентификацию и авторизацию через какой-нибудь ADFS, интегрироваться со СМЭВ, ещё с какими-нибудь очередями с распределёнными транзакциями, отпиливать модули для ДМЗ, обеспечивать кластеризацию и отказоустойчивость и т.д. А главное, им обязательно придётся несколько раз повернуть вашу прекрасную модель на 180 градусов в разных местах, пока она не согнётся в конька-горбунка. Удачи!
Для всего этого есть Spring)
Помню, что когда для такого дела используешь Java с проверенными технологиями, то ночью спишь спокойно. А когда это какой-нибудь Node.js, то как-то вот не получается. Оно конечно работает, оно конечно даже вполне себе стабильно работает, но почему-то нет покоя. Не знаешь что, где и когда может отвалится.
Для решения каких конкретных задач был придуман Unix? Или язык C?Вроде как язык C был придуман для ускорения и облегчения написания ОС Unix…
Я не очень-то хочу заниматься критикой авторов комментариев, так как уважаю чужое мнение, однако хочу заметить, что через несколько лет, когда у Вас будет больше опыта промышленной разработки в разных проектах как Java, так и на других платформах и языках, Ваше мнение о том, что хороший программист должен ускоспециализироваться только на одном самом крутом и самом мощном инструменте, изменится.
При всех достоинствах Java и при всей «крутости» Java-программистов инструменты будут продолжать развиваться и когда-нибудь некая платформа «X» окончательно похоронит эту замечательную технологию, которой уже исполнилось двадцать лет.
Мы находимся в постоянном поиске, в работе по изучению инструментов под наши задачи, которые позволяют как быстро прототипировать ПО, так и запускать его в опытную эксплуатацию. В связи с этим и возникают задачи «изучить X для опытных Java-программистов», подобные этой. И люди, которые работают в одном с нами направлении, прекрасно понимают, почему мы это затеяли. Обо всей этой кухне мы напишем, я надеюсь, в следующих статьях в блоге Центра Информационных Технологий.
При всех достоинствах Java и при всей «крутости» Java-программистов инструменты будут продолжать развиваться и когда-нибудь некая платформа «X» окончательно похоронит эту замечательную технологию, которой уже исполнилось двадцать лет.
Мы находимся в постоянном поиске, в работе по изучению инструментов под наши задачи, которые позволяют как быстро прототипировать ПО, так и запускать его в опытную эксплуатацию. В связи с этим и возникают задачи «изучить X для опытных Java-программистов», подобные этой. И люди, которые работают в одном с нами направлении, прекрасно понимают, почему мы это затеяли. Обо всей этой кухне мы напишем, я надеюсь, в следующих статьях в блоге Центра Информационных Технологий.
Я против замены Java на node.js, а не против того, чтобы программист использовал node.js и Java. Вероятно, где-то и можно поставить на сервер node.js к java, или поставить php, или ruby и разбить функционал, но это как про козу и баян. Лишние телодвижения для сомнительного удовольствия после долгих подготовок.
С годами я понял, что хороший программист должен обладать навыками столяра, слесаря (работа с металлом) и обладать знаниями техники безопасности при работе с электричеством и иметь мощную спину и руки, чтобы таскать тяжести.
Я (без шуток) верю, что если и не лет через 20, но наступит всемирных хаос и придет апокалипсис. Не обязательно ядерный удар как Fallout, может будет все проще (раскол в обществе, несколько войн, разруха), но ИТ какая она есть — ее не станет. Для паблика она рухнет и останется только дляАнклава для приват персон.
Кем я вижу себя лет через 20 (мне чуть-чуть до 3го десятка) — я вижу «дело», которое само на себя работает и меня снабжает. Связано ли оно с ИТ или нет — зависит от того, куда покатится этот мир.
Зачем вечно быть программистом и linux админом?
Ваше мнение о том, что хороший программист должен ускоспециализироваться только на одном самом крутом и самом мощном инструменте, изменится
С годами я понял, что хороший программист должен обладать навыками столяра, слесаря (работа с металлом) и обладать знаниями техники безопасности при работе с электричеством и иметь мощную спину и руки, чтобы таскать тяжести.
Я (без шуток) верю, что если и не лет через 20, но наступит всемирных хаос и придет апокалипсис. Не обязательно ядерный удар как Fallout, может будет все проще (раскол в обществе, несколько войн, разруха), но ИТ какая она есть — ее не станет. Для паблика она рухнет и останется только для
Кем я вижу себя лет через 20 (мне чуть-чуть до 3го десятка) — я вижу «дело», которое само на себя работает и меня снабжает. Связано ли оно с ИТ или нет — зависит от того, куда покатится этот мир.
Зачем вечно быть программистом и linux админом?
Если вы не понимаете юзкейсов замены Java на node.js, это значит, скорее всего, что вы не сталкивались с настолько динамичными или масштабными задачами. Конечно, это не уровень «своего дела», для таких задач технология вообще не важна особо, можно писать на том, к чему душа больше лежит.
Опишите ваш опыт, когда этот переход пригодился.
Я могу привести множество примеров, когда я сознательно не стал писать на Java и использовал другие технологии, в том числе и node.js, потому что считал, что для этой конкретной задачи эта технология подойдёт лучше. Где-то опыт был позитивным, где-то не очень, но в целом у меня развилось некоторое чутьё на области применимости. У любого грамотного программиста с широким кругозором, который не считает свою любимую технологию серебряной пулей, найдётся с десяток таких примеров. Каждый такой рассказ можно оформить в отдельную статью.
Автор, отличное руководство! Именно такого мне и не хватало, когда я только начинал знакомиться с Node.js.
А причём тут java программисты? Я ничего не увидел сравнений с java или прочего.
А Node на линуксе лучше всего на данный момент ставить с
nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories
В любом случае спасибо за пост, перечитаю потом ещё раз вдумчиво, сейчас пробежался, вроде всё и так знал.
Да и Node устанавливается не только чтобы писать приложения, рубисты ставят Node к примеру он нужен для рельсов, при девелопинге.
А Node на линуксе лучше всего на данный момент ставить с
nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories
В любом случае спасибо за пост, перечитаю потом ещё раз вдумчиво, сейчас пробежался, вроде всё и так знал.
Да и Node устанавливается не только чтобы писать приложения, рубисты ставят Node к примеру он нужен для рельсов, при девелопинге.
Благодарю за отзыв! Чуть выше я объяснял, что задачи сравнивать технологии не было, просто я описал введение в новую технологию с позиции себя как преимущественно Java-разработчика.
Спасибо за ссылку, при написании статьи я её пропустил.
Да, нашим разработчикам уже приходилось устанавливать node, в основном для всевозможных утилит веб-разработки — bower, gulp, brunch и т.д. Но тут стояла задача использовать node именно для разработки.
Спасибо за ссылку, при написании статьи я её пропустил.
Да, нашим разработчикам уже приходилось устанавливать node, в основном для всевозможных утилит веб-разработки — bower, gulp, brunch и т.д. Но тут стояла задача использовать node именно для разработки.
Сорри за офтоп, но я тут нашел очень инетресные уроки по IDEA www.youtube.com/playlist?list=PLPZy-hmwOdEXdOtXdFzyx_XCnrF_oD2Ft
Спасибо за статью. Только вы не описали типичную структуру проекта, best practice, так сказать. По каким папкам все распихать, или все в одной куче лежит?
Sign up to leave a comment.
node.js для Java-разработчиков: первые шаги