Программирование, т. 7

да преамбула и так была понятна

я вот и спрашивал конкретно в чем может быть преимущество ноды (как платформы и экосистемы) кроме того что язык JS

 

а вот про "По сути весь современный JS ушел в сторону модульности и ноду лучше всего использовать для построения микросервисной архитектуры. В итоге когда ты хочешь поместить новую логику в приложение - то пишешь новый модуль-микросервис" можно поподробней?

и про JS-модульность, и про то что в ноде есть для микросервисов

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

 

По поводу модульности, почему я так считаю: ты можешь просто почитать Core Concepts топовых JS-фреймворков (Angular, React, Ember etc). Все они поддерживают принцип написания отдельных компонентов. NPM - самая динамично развивающаяся и самая объемная экосистема модулей. Стандарт ES6 откликнувшись на потребности комьюнити ввел в JS нативную поддержку модулей (когда я говорил микросервисы, то скорее имел в виду именно компонентную структуру)

 

Если говорить конкретно про микросервисную архитектуру (в самом прямом понимании этого термина), то в сети есть много статей по каноническим примерам: Netflix, Paypal, которые используют ноду и микросервисы. Многие компании делятся в блогах информацией как и почему они используют ноду или почему мигрировали от монолитных приложений к микросервисам.

 

Примеры:

https://medium.com/the-node-js-collection/netflixandchill-how-netflix-scales-with-node-js-and-containers-cf63c0b92e57

https://thenewstack.io/enterprises-embracing-microservices-node-js/

вот еще про микро сервисы

https://habrahabr.ru/post/323154/

вот еще про микро сервисы

https://habrahabr.ru/post/323154/

я был на этом докладе вживую :)

не очень хороший доклад. хотя возможно он больше рассчитан на тех кто уже активно использует ms архитектуру. тк там было много мелочей потипу "вот смотрите мы тут отслеживаем id реквеста и пробрасываем это в логи, наш мониторинг и базу" - что как бы чисто детали имплементации которые не особо интересны тк это скорее рутина

 

да преамбула и так была понятна

я вот и спрашивал конкретно в чем может быть преимущество ноды (как платформы и экосистемы) кроме того что язык JS

 

а вот про "По сути весь современный JS ушел в сторону модульности и ноду лучше всего использовать для построения микросервисной архитектуры. В итоге когда ты хочешь поместить новую логику в приложение - то пишешь новый модуль-микросервис" можно поподробней?

и про JS-модульность, и про то что в ноде есть для микросервисов

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

 

По поводу модульности, почему я так считаю: ты можешь просто почитать Core Concepts топовых JS-фреймворков (Angular, React, Ember etc). Все они поддерживают принцип написания отдельных компонентов. NPM - самая динамично развивающаяся и самая объемная экосистема модулей. Стандарт ES6 откликнувшись на потребности комьюнити ввел в JS нативную поддержку модулей (когда я говорил микросервисы, то скорее имел в виду именно компонентную структуру)

 

Если говорить конкретно про микросервисную архитектуру (в самом прямом понимании этого термина), то в сети есть много статей по каноническим примерам: Netflix, Paypal, которые используют ноду и микросервисы. Многие компании делятся в блогах информацией как и почему они используют ноду или почему мигрировали от монолитных приложений к микросервисам.

 

Примеры:

https://medium.com/the-node-js-collection/netflixandchill-how-netflix-scales-with-node-js-and-containers-cf63c0b92e57

https://thenewstack.io/enterprises-embracing-microservices-node-js/

 

чет я не понял чем это отличается от того что ты пишешь класс и потом используешь его где хочешь :О

там модульность при сборке какую-то дополнительную магию дает? типа составлять дерево зависимостей ad-hoc и качать только необходимые модули?

или в рантайме подгружаются модули только когда к ним обращаются?

а версионирование модулей как-то менеджится?

 

просто то что я видел поверхностно в JS`e по модульности через какойнибудь require - выглядит как обычный импорт в java, с++, etc

 

про сами по себе микросервисы мне все известно

не понятно чем здесь нода лучше и не является просто "yet another stack"

Изменено 18 апреля 2017 пользователем Just.Doit

Я не против ноды, но не понимаю для чего он может пригодиться. Ну ок, сложнее лендингов он может распарсить ответ и распихать по 3рд пати системам реквесты, а какую бизнес-логику он может делать? Биллинг, аналитику, хдс, мл, кешинг, ещё 100500 направление? Для чего он годиться, кроме парсинга json И распихивания его кусочков в другие системы?

мой коллега на проекте очень любит массивы, вместо привычных мне коллекций типа ArrayList

а вы чо почем?

коллега у тебя дебил, только если он не разрабатывает высокоперформансный код

массивы ковариантны, что ошибка в джаве

нету мощи стандартной библиотеки коллекций

сейчас в высокоуровневом коде (абстракции и апи библиотек) почти нигде не используются массивы (поправьте если не прав)

так на скорую руку из стоящих использований - только вездесущий byte[]  :)

 

сам был жертвой того что написал апишку для парсера на массивах а потом заебался с ней работать и переписал на листы

+ был легаси в котором использовались массивы - тоже гемор еще тот

пока не нужно сверхоптимизировать критичный (ботлнек) участок кода - нахуй они не нужны

 

но возможно какой-то кейс я пропустил

java array = c++ array
java ArrayList = c++ std::vector
?

java array = c++ array

java ArrayList = c++ std::vector

?

Да

коллега у тебя дебил, только если он не разрабатывает высокоперформансный код

массивы ковариантны, что ошибка в джаве

нету мощи стандартной библиотеки коллекций

сейчас в высокоуровневом коде (абстракции и апи библиотек) почти нигде не используются массивы (поправьте если не прав)

так на скорую руку из стоящих использований - только вездесущий byte[]  :)

 

сам был жертвой того что написал апишку для парсера на массивах а потом заебался с ней работать и переписал на листы

+ был легаси в котором использовались массивы - тоже гемор еще тот

пока не нужно сверхоптимизировать критичный (ботлнек) участок кода - нахуй они не нужны

 

но возможно какой-то кейс я пропустил

ну я читал типа +/- использования того или иного варианта и было мнение, что массивы стоит юзать, только если объем маленький и ты знаешь его размер всегда + не нужно вставлять и удалять 

Где верстальщик может своё портфолио расположить? Есть какие то проф ресурсы, где можно выложить дизайн с примером верстки?

 

коллега у тебя дебил, только если он не разрабатывает высокоперформансный код

массивы ковариантны, что ошибка в джаве

нету мощи стандартной библиотеки коллекций

сейчас в высокоуровневом коде (абстракции и апи библиотек) почти нигде не используются массивы (поправьте если не прав)

так на скорую руку из стоящих использований - только вездесущий byte[]  :)

 

сам был жертвой того что написал апишку для парсера на массивах а потом заебался с ней работать и переписал на листы

+ был легаси в котором использовались массивы - тоже гемор еще тот

пока не нужно сверхоптимизировать критичный (ботлнек) участок кода - нахуй они не нужны

 

но возможно какой-то кейс я пропустил

ну я читал типа +/- использования того или иного варианта и было мнение, что массивы стоит юзать, только если объем маленький и ты знаешь его размер всегда + не нужно вставлять и удалять 

 

все верно. но только с точки зрения производительности

ну это вот всё преждевременные оптимизации.

поддерживаемость кода ухудшается, при этом производительность роли не играет, тк на большинстве задач процент времени работы кода в значительной больше идет на I/O (db, http, file) и на сериализацию/десериализацию, или скажем на ожидание конца какойто блокировки

 

и переписав код на сверхоптимизированный даст типа +10% к производительности. при этом сделает код неподдерживаемым

Вы чего все тут бэки согласно опросу ? 

 

ну я читал типа +/- использования того или иного варианта и было мнение, что массивы стоит юзать, только если объем маленький и ты знаешь его размер всегда + не нужно вставлять и удалять 

все верно. но только с точки зрения производительности

 

на самом деле не только, есть ситуации когда ты точно наперёд знаешь размер массива и юзаешь доступ только по индексу, тут проблема что в пустой список list[0] = x ты не вставишь ничего

и пусть даже ты заполняешь его в правильном порядке, т.е. .add()-ами ты получишь такую же структуру, но всё-равно ну его в пизду и лучше чтоб всё было всегда по индексу

Изменено 19 апреля 2017 пользователем TheDeadSkin

Вы чего все тут бэки согласно опросу ? 

Нет, половина - веб-макак (если не больше), но мы люди воспитанные и не мешаем ентерпрайз-макакам спорить о массивах

 

 

с чего ты взял что в джаве массив это проблема?

чет я не понял чем это отличается от того что ты пишешь класс и потом используешь его где хочешь :О

там модульность при сборке какую-то дополнительную магию дает? типа составлять дерево зависимостей ad-hoc и качать только необходимые модули?

или в рантайме подгружаются модули только когда к ним обращаются?

а версионирование модулей как-то менеджится?

 

просто то что я видел поверхностно в JS`e по модульности через какойнибудь require - выглядит как обычный импорт в java, с++, etc

 

про сами по себе микросервисы мне все известно

не понятно чем здесь нода лучше и не является просто "yet another stack"

 

Так никакой магии и нет. С точки зрения языка как такового - JS это куча костылей и залатанных дырок и require/export/import - это по сути способ создания областей видимости, которые в других языках поддерживаются нативно.

 

Чем лучше Нода за меня отвечают те, кто мигрировал с других технологий на Ноду (я потому и кинул ссылки). Аргументы:

"Мы имеем тот же функционал и производительность, при этом объем кода сократился на 30%, а количество файлов на 40%"

"Нода позволила нам сократить количество серверов в 10 раз"

 

Как инструмент в вакууме - JS - это решето (отсюда TypeScript, commonJS/requireJS, тот же lodash, который давно можно запилить в сам язык, а не ставить в каждом проекте).

Но при наложении на реальные бизнес-нужды - это оказывается самым удачным решением для многих.

Хороший Java-инженер вырастает за 3-4 года, при этом они дорого стоят, а Java - очень многословный язык и если у тебя 400 девелоперов, то все усложняет разработку и поддержку кода.

 

JS - низкий порог вхождения, гибкость, очень большая экосистема, обширный рынок хороших инженеров и их относительная дешевизна

 

Все упирается в вопрос - "зачем платить больше?"

Изменено 19 апреля 2017 пользователем Lionell

Варианта про 1С нет, значит я тестер 

Вы чего все тут бэки согласно опросу ? 

я вообще игры делаю, меня куда, индига в опросе нет 

Можно как-то пофиксить опрос чтобы человек мог проголосовать в новом вопросе?

да тот опрос норм в принципе был, мог и не менять