node.js

В js даже наследования нет нормального. Какая речь может быть о серверном программировании? Я чего-то не понимаю?
Чем руководствуются заказчики при выборе node.js или подобной технологии?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

так і є. всі через посредників, а нода напряму.

Можно ссылочку на гитхаб, или пример кода...Интересно как это они обходятся без ц-шной прокладки?

насправді я пожартував. бачу є нерозуміння як взагалі процесор виконує програми. тому спочатку вартує в тому напрямку погуглити. хоча можливо ти про jit говориш. незрозуміло про сішну прокладку.

Я просто читал на одном форуме,про организацию ассамблерных вставок под архитектуру V8.Хотел узнать есть ли такая возможность у node.js?

Вам нужно определенно прочитать все, что есть по ноде и V8 на Хабре, и посмотреть лекции и скринкасты в ютюбе, потому, как все уже 100 раз изложено и даже на сайте ноды все разжевано. Нода — это обертка вокруг V8, дающая API, а вот V8 транслирует JS налету даже не в ассемблер, а в машинный код. Потом происходит статистическая оптимизация этого машинного кода после определенного времени его работы, он становится быстрее, переменные становятся типизированными, массивы и хеши сначала это массивы и хеши указателей на объекты, а потом становятся типизированными. Постепенно переменные спускаются от объекта, к типу, потом в регистр процессора или стек. На каждой платформе это происходит по-разному. А по поводу ассемблерных вставок, то почему Вы думаете, что они быстрее чем Си? Можно и на ассемблере написать медленно, а на Си быстрее. Нода — позволяет любую библиотеку Си или ассемблера скомпилированную в бинарный вид на нужной платформе (и при соблюдении определенного протокола вызовов и экспорта) загрузить в адресное пространство V8 и оттуда вызывать функции.

Спасибо за комментарий. Я нашел информацию на форуме и просто решил обсудить, для того что бы узнать мнения других людей .Надеялся на «волшебные» методы о которых я плохо проинформирован...

В принципе наследование уже не в фаворе почти во всех ситуациях, почти всегда лучше применить композицию. Но если надо, то наследование соорудить можно элементарно

Да ну JavaScript — не ООП язык, а прототипной парадигмой. Вообще, парадигм программирования много (функциональное программирование, конечные автоматы, событийное, процедурное, декларативное, параллельное программирование с моделью акторов), не нужно везде зацикливаться на наследовании. Будто помешались все, прочитав Гради Буча или что-то типа того. Но во всех парадигмах есть общее — построение абстракций предметной области. Объект и класс — это форма абстракций в ООП, а абстракции параллельного панорамировании — это актор и собщение и т.д.

Вот уже тоже использую...Хотел узнать такой вопрос — сохранение информации в БД, т.е. insert,лучше делать в файловую или реляционную Б.Д.(на эти данные больше ничто не ссылается.) Как это выглядит на практике(на форумах мнения расходятся...)Поделитесь опытом-если не секрет, конечно...

Что такое файловая БД?

Данные пишутся/читаются не в таблицы, а в txt файл...

если задаёшься такими вопросами, то пиши в реляционную — с ней проще работать и сложнее накосячить

Если реляция то только Postgre SQL,насколько я понял node.js была разработана именно для nosql DB...

Нода не разработана для noSQL, откуда Вы этого набрались? Нода — вообще не для работы с СУБД разработана, это все равно, что сказать, что рука специальна разработана чтобы бить морду, на основании того, что подавляющее большинство морд было побито именно рукой.

Нет, файловые операции — это полный бред, удобных запросов нет, стандартов и совместимости нет, и наконец — файловые операции — это очень медленно. Нода может писать в оперативную память, а потом, в ленивом (lazy) режиме можно сохранять из памяти в СУБД (можно в Mongo, можно MySQL или PostgreSQL, или др.).

И что из этого? Я знаю, как работать с файлами в ноде, но ни кто в здравом уме не будет использовать файлы вместо базы данных. Это совершенно не сравнимые решения. Если Вам нужно хранить 50 миллионов текстовых документов по 50кб и их выдавать по определенным урлам, то используйте файлы, но это не база данных. А если есть база данных товаров с параметрами: цена, марка, размер, вес и т.д. И нужно делать запросы выбора данных по определенному условию к этим параметрам, то Вы не построите это в файлах. Или Вам придется написать свою СУБД с индексами, языком запросов, оптимизацией планов исполнения и т.д.

Нет не писать свою СУБД, вроде как есть «приблуды» для большинства популярных СУБД ни Гитхабе...
Я имел ввиду использовать не как основную БД, а как вспомогательную.Основная часть хранится на реляции,а вспомогательная в файлах т.е. данные, на которые ничто не ссылается(например в Facebook — все построено на nosql решениях).

1. Приблуды для бего? 2. Так в файлах или в nosql? Это разные вещи.

Не ясно о чем Вы говорите, пример или ссылку плиз.

В общем есть задача.Необходимо вывести набор графиков на странице, данные для которых необходимо подготовить используя агрегатные операции.варианта два-это делать в БД в отдельной таблице или на клиенте, потом приготавливать джейсон и пулять строку, либо используя отдельные текстовые файлы под данные, для того что бы вывести их на графики,проведя вначале агрегатные операции над входящими данными...

Данные поступают постепенно, можно их писать в СУБД, а потом делать запрос, объединяющий (консолидирующий, суммирующий, вычисляющий среднее значение за период или другую функцию за период) и уже результаты запроса отдавать в JSON клиенту. Но можно проще сделать, построить в оперативной памяти массив, и писать данные и в базу для хранения и в массив, делая вычисления не в момент запроса к статистике, а в момент вставки данных. Таким образом, в любой момент Вы отдадите этот массив в виде JSON в ответ на запрос.
Каким боком Вы тут хотите применить файлы — до сих пор не ясно. Они ни чем не могут пригодиться тут.

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

нода предоставляет возможность джаваскрипта. Джаваскриптом сагрегировать сможете? И сохранить в нужный массив.

Стройте агрегаты в РСУБД, таблицы которые содержат предыдущие вычисление.

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

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

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

почему бы не делать это средствами БД? они для этого и предназначены, т.к. в памяти инстанса это делать не айс, да и медленно

не знаю как во взрослых БД, а вот mysql на запросах с агрегацией большого кол-ва записей во времени — тормозит.

Для ноды естественно делать это в памяти при вставке данных, т.е. копия пошла в базу и сразу добавились данные к статистике в памяти, это как раз удобно, да и быстро.

окей, я смотрю вы архитектор. а что если инстансы падают периодически, или у вас более-менее серьезный проект, и их запущено 7 инстанс на машину из кластера хотя бы в 10 машин, вы только что откушали достаточное кол-во памяти, и потратил дополнительное время процессоров, т.к. БД намного быстрее ноды для обработки данных (хотя последнее и не обязательно, если особых вычислений нет), и затратили дополнительно время разработки системы, т.к. плюс логика обработки этого кеша, и немного усложнили систему. на лицо — затраты выросли, производительность скорее всего осталась на том же уровне, но железа надо больше. ничего не смущает?

Я не знаю почему инстансы должны постоянно падать, или это так может принято в определенных кругах? Думаю, что падение инстанса — это редкая ситуация, но согласен, что ее тоже нужно обрабатывать. Представьте: запущено 12 инстансов на одном сервере или 128 инстансов на разных серверах, между инстансами есть IPC и/или MQ, т.е. они могут синхронизировать часть своего состояния, обмениваясь сообщениями, кроме того, состояние инстансов сохраняется в сериализованном формате в какой-либо persistent starage, из которого инстансы и подымают обратно свое состояние при перезапуске. Тут нужно определиться с понятием состояниея: 1. есть системное состояние всей системы вцелом, оно во всех инстансах одинаковое, 2. есть состояние сессий, оно «прилипает» к процессам, при помощи ip sticky или session sticky методик, оно временное и может сохраняться, а может и нет, его потерять не страшно, оно или пересчитается или подымется, 3. есть состояние пользователей, которое обязательно персистируется в БД и может перетекать между процессами и так же «прилипает» к процессам, оно не теряется в любом случае, 4. есть состояние объектов предметной области, оно должно быть одинаково для всех процессов, для чего и есть MQ или брокеры машины состояний, т.е. состояние объектов синхронно почти в реальном времеи во всех процессах и его потерять невозможно. Поэтому нужно решить, что именно за статистика и к какому типу состояния ее можно отнести и как именно обрабатывать.

БД намного быстрее ноды для обработки данных
Это только если мы говорим про моментальные вычисления, но я же и предлагаю перейти на другую стратегию вычислений — на аддитивные вычисления, БД в этом случае будет медленнее. Смысл аддитивных вычислений в «размазывании» их во времени, т.е. самый простой пример, Вам поступает на вход последовательность чисел, нужно выдавать среднее значение, минимальное и максимальное. Пусть в БД их накопится стопицотярдов, и их пересчитывать их будет медленно, а в памяти хранится несколько переменных и нужно при поступлении нового числа A сделать: countA++; maxA = max(maxA, A); minA = min(minA, A); avgA = (avgA+A)/countA; И что быстрее?
Я не знаю почему инстансы должны постоянно падать, или это так может принято в определенных кругах?
Думаю, что падение инстанса — это редкая ситуация, но согласен, что ее тоже нужно обрабатывать.
правильно, это я и имел ввиду
Это только если мы говорим про моментальные вычисления, но я же и предлагаю перейти на другую стратегию вычислений — на аддитивные вычисления, БД в этом случае будет медленнее.
это достаточно частный случай, однако полностью соглашусь, если таковы требования к системе, то решение более чем оправдано.

я имел ввиду, когда аналитика должна быть более.... комплексной что ли. не думаю что получится таким методом расчитывать LTV, или корректировать прогноз на основе многофакторной модели (т.к. будет требоватся перерасчет с учетом истории) и различные KPI

хотя соглашусь, что если задача выдачи оперативной СТАТИСТИКИ, то да, ваш подход имеет место быть

Пусть в БД их накопится стопицотярдов, и их пересчитывать их будет медленно, а в памяти хранится несколько переменных и нужно при поступлении нового числа A сделать: countA++; maxA = max(maxA, A); minA = min(minA, A); avgA = (avgA+A)/countA; И что быстрее?

facepalm, а что вам в рдбмс мешает сделать то же самое что и в памяти и не накапливать стопицотярдов и каждый раз пересчитывать агрегат по всей таблице, не знание sql? для ваших «аддитивных вычислений» похоже выбор инструмента зависит куда меньше от внутреннего устройства обработки данных, чем от специфики выбранного нтерфейса интеграции.

Для работы с аргегатами в аналитических приложениях уже давно люди применяют многомерные базы, и не изобретают своих велосипедов, как бы им быстро закешить нужную сумму на основании первичной статистики, а потом через еще кучу интеграционных интерфейсов mq все это синхронизировать в приложении.

Я привел простой пример для иллюстрации принципа аддитивности, но максимальных результатов использование памяти в связке с mq и другими нереляционными приемами, дает при сложных задачах. В оперативной памяти можно строить такие сложные произвольные структуры данных, для построения которых нужны сотни и тысячи запросов, а реляционная модель неприемлема. Вы же сидите в своей корпоративно-финансовой расчетной отрасли, в которой принято мыслить таблицами, но существуют такие структуры данных, как графы, стеки, многосвязные деревья, уйма разновидностей списков, слабосвязанные данные, очереди, множества и т.д. И структуры эти могут быть не статическими, а живыми, т.е. в них могут быть реализованы потоки, симофоры, шины, сообщения, таймеры, мьютексы и т.д.

вы привели просто пример, который совершенно ничем не подкрепляет ваш тезис в отношении

Это только если мы говорим про моментальные вычисления, но я же и предлагаю перейти на другую стратегию вычислений — на аддитивные вычисления, БД в этом случае будет медленнее.
ок, давайте пример со сложными структурами где обход произвольного порядка ссылок на обьекты в памяти и аргегация скалярных атрибутов, будет происходить быстрее чем бинарный поиск по индексу пусть и сложной, но нормализированной схемы данных; и/или где внутренний механизмы ограничения целостности в рдбмс будет давать сбои чаще, чем при использоавании распределнных многопоточных вычисленний в памяти(про «накладные расходы» и отказоустойчивость таких механизмов я промолчу).

Представьте, что у нас есть 100 датчиков на производственной линии, которые с разной интенсивностью присылают на сервер свои измерения, задача сервера — вырабатывать управляющие воздействия для 30 транспортных модулей, которые поставляют со склада материалы и заготовки на разные позиции обработки на производственной линии. Для этого, сервер имеет такой инструментарий: 15 цифровых фильтров, реализованных в виде алгоритмов обработки сигналов с историей; модель производства, реализованная в виде сети Петри на структурах данных в памяти, при чем, модель «живая», в нее поступают данные и она в реальном времени отрабатывает считает 300 формул с промежуточными показателями и отрабатывает 200 логических правил, перемещая маркеры в новые позиции и вырабатывая поток команд. Далее сервер имеет 15 императивных сценариев на специализированном языке, которые готовят принятия решений, 70 декларативных правил, которые проверяют принятые решения на предмет непротиворечивости, исключения аварийных ситуаций и т.д. В системе крутится очень много данных, но они не имеют реляционной природы, их обработка не может быть сведена к триггерам, потому, что большинство этих алгоритмов работают непрерывно, а другая часть работает дискретно, но с сохранением состояний между итерациями. Максимально используется оперативная память, сложные структуры данных (стеки, деревья, графы, потоки, семафоры и т.д.). В базу данных же записываются только показания датчиков (и то, уже консолидированные за период времени, не каждые же 10 миллисекунд писать), результаты принятия решений, т.е. по суть — логи этих всех процессов.

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

первично было так

БД намного быстрее ноды для обработки данных

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

Вы же сами предлагали использовать БД для вычислений агрегатов? Вот Вам и агрегат. Но дело в том, что сложные структуры данных, непрерывные алгоритмы над этими структурами данных и машины состояний — это вообще другое, бут БД не поможет, только RAM+CPU. И таких задач гораздо больше в реальном народном хозяйстве, чем подсчет чужих денег в системах, где все квантуется по банковским дням. Нода же прекрасно работает уже и на контроллерах, генерируя машинный код из джаваскрипта и имея доступ к портам для асинхронного I/O.

Но дело в том, что сложные структуры данных, непрерывные алгоритмы над этими структурами данных и машины состояний — это вообще другое, бут БД не поможет, только RAM+CPU.
что вы пытаетесь своими повествованиями доказать? что есть алгоритмы, которые неудобно реализовывать используя таблицы и sql? об этом речь не шла.

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

Я показываю, что есть структуры данных, которые неотделимы от алгоритмов их обработки — это раз, а второе — что есть структуры данных, естественным представлением которых является не реляционная форма, а граф, дерево или вообще буфер. База данных — это инструмент вторичной обработки данных, потому, что интенсивные потоки данных не могут быть вставлены в БД без предварительной консолидации в памяти. Любые интенсивные потоки, например, посты и лайки в соцсетях, измерения от датчиков, координаты объектов в системах трекинга транспорта, потоки считанных идентификаторов RFID и многие другие потоки — поступают в системы обработки с интенсивностью в тысячи, десятки тысяч, сотни тысяч и миллионы в секунду. В таких условиях вся первичная обработка происходит в памяти, потом данные уплотняются, ставятся в очередь для записи в БД, потому, что БД не сможет делать такие интенсивные вставки данных. Вы ратуете за БД-центрический подход, да, он существует и имеет свое применение, но он не серебряная пуля, он возможен в очень малом проценте систем. Так, где пользователь раз в 5 минут сохраняет форму — это вполне такой подход.

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

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

maxA = max(maxA, A);
сделать в память и это у вас получиться быстрее чем суммирование данных через sql из большой таблицы, то подход с использование бд автоматически более медленный при расчете аргегатов.

Это иллюстративный пример, но сам принцип остается

stateA = f(stateA, A)
где stateA — это структура в памяти, занимающая, возможно, сотни мегабайт, A — новая порция информации, поступающая в систему, f — сложная функция с состоянием. И это таки быстрее, чем писать в базу. В общем случае, это первичная обработка, а база — вторичная. А то, что иногда, этот шаг можно пропустить и писать сразу в базу — это частный случай.
f — сложная функция с состоянием
 И это таки быстрее, чем писать в базу.
вы хоть помните о чем вообще речь шла в ветке? :) о подсчете агрегата, динамической статистике на разных временных промежутках и хранении данных. Вы доказывали, что посчитать аргегат в памяти можно быстрее чем в базе, потому что в базе храниться вся таблица, а в памяти можно это быстро сделать инкрементом.

Теперь уходите в сложные вычисления, которые в базе делать никто и не будет. И которые вероятно вообще не имеют никакого отношения к к подсчету агрегата, а если и имеют то в ваших сложных вычислениях 90% это подготовка скалярных данных, остальные 10% работа со однотипными значениями, по которым и производиться агрегирование.

Вопрос был вообще о том, где хранить подготовленный агрегат, в БД или в файловой системе. Поэтому я и отвечаю — лучше в памяти. Потом вопрос изменился: где его подготавливать, ответ: в некоторых случаях удобнее подготавливать в БД, а в других — в памяти. Но уж не на диске — это точно. Из памяти его быстрее отдавать, можно хранить готовый буфер, наполненный прямо JSON-ом. Делать фильтры на агрегат — можно или на клиенте уже или в памяти сервера или в БД, тут все зависит от размера этого агрегата. Например, гугл-аналитикс, когда показывает графики, то делает часть фильтрации на стороне сервера (выборка по определенному домену и периоду), а часть в памяти браузера вообще (из полученных данных выбирает срез). Считать агрегаты раз в сутки — такое встречается все реже и реже, в основном, в банковском секторе. И даже в финансовых и банковских системах сейчас тенденция на максимальное использование оперативной памяти, типа BigMemory, BigData, посмотрите вот что: terracotta.org/...ducts/bigmemory

Это прекрасно делается на ноде. Тут, как я понял, задача такая, что нужно давать оперативную статистику по большому объему данных. Есть два пути, как я уже сказал: 1. Вставлять в базу и пересчитывать каждый раз при запросе или раз за период (час, 2 чала, день...) 2. Считать в оперативной памяти и отдавать прямо из памяти — плюсы: всегда актуальные данные без отставания, очень быстро отдается, нагрузка по подсчету размазывается на большое время и не ощутима.

например в Facebook — все построено на nosql решениях
Это не так. FB конечно использует nosql, но если память мне не изменяет, лет 6-7 назад у них было около 5,000 mysql серверов. Не думаю что за последнее время эта цифра сильно снизилась
Нода может писать в оперативную память, а потом, в ленивом (lazy) режиме можно сохранять из памяти в СУБД (можно в Mongo
но не стоит
ruby-ru.livejournal.com/...=555044#t555044

Вроде популянее всего nosql БД типа Mongo DB.

Мы используем ноду в продакшене год и счастливы с ней. Много опубликовали на ноде в оупенсоурс на гитхаб, и за последний год многое еще появилось. Сейчас можно найти для ноды почти все, что душа пожелает, а написать — тем более. Но на Украине как-то мало еще людей используют эту платформу, предлагаю нам как-то найтись и собираться небольшим кругом раз в 2-3 месяца, чтобы обменяться последними наработками и обсудить архитектурно-технологические вопросы.

Impress: многоцелевой сервер приложений для Node.js — habrahabr.ru/post/194250
Делаем админпанель для MySQL и MongoDB на Node.js — habrahabr.ru/post/192302
Паттерны JavaScript модулей в Impress для node.js и браузеров — habrahabr.ru/post/183188
Прототип тоталитарного фреймворка для node.js — habrahabr.ru/post/182714

Мы его используем в продакшине уже года три. Включая одну критически важную систему для бизнеса и ряд вторичных внутренних систем, которые не напрямую наружу, но обеспечивают функционирование других систем. HTTP/Socket — сервера, частично с логикой и обработкой данных. Работает 24/7 * 365 и это было одно из самых приятных в разработке из всего проекта. Есть даже внешние интерфейсы к биржам, но в основном это промежуточная обработка и раздача финансовых данных.

Интересно было бы узнать сколько тех, кто таки пишет (или хотя бы пробудет писать) на ноде (уже) сегодня; подозреваю народу будет не густо :)

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

а почему не

том так ли нужны все оопшные штуки

вообще?

чем серверное по принципиально отличается от не серверного?

— Куме, а ви знаєте, як вони на тестовий фреймворк кажуть?
— Як?
— Мооочааа!!!

— Ух, узяв би сокиру, і рубав, і рубав.

Полагаю, когда тут пишут про «сложные приложения», которые на Node.js не написать, подразумевается энтерпрайз-скейл-говнокод с классами на 3000 строк? То еще ООП. :-)

Как будто проект на миллион строк не может быть модульным.

Вы действительно уверены в существовании других языков?

Откуда вам известны мои навыки?

Предположил из фразы «наследования нет нормального».

прототипная пародигма реализована с багами, с достаточно большим списком.

пародигма

От слова Парить?

реализована с багами, с достаточно большим списком

Какими, например? Может все в недостатке понимание парадигмы?

я читал на блогах и в мануале. вы можете поискат, если хотите))

Действительно,

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

Я конечно буду некропостером, но просто не могу удержатся. В JavaScript есть наследование, объекты, а классы прописываются тут в конструкторе.

Там повноціне, функціонуюче ооп, є і інкапсуляція, і наслідавання, і поліморфізм. Просто ви не звикли що для створення класу не треба писати оператор класс, що функцію можна зберегти в змінну та до настільки гнучких можливостей у наслідуванні та створені об`єктів.

тоді я з вами погоджуюсь.

Вот за что я не люблю скриптовые языки — это за эти «var», за отсутствие строгой типизации.

Почему не Грейлс?
Запустить налаженный новый проджект на греилсе — 2 комманды выполнить.

Если понадобится, джаву подключить — нефиг делать.

с грейлсами надо мавен подключать

И сразу становится ясно что устриц то товарищ и не кушал grails.org/...e/conf.html#ivy

с грейлсами надо мавен подключать.

Чё? Нету там никакого мавена. Тобиш он есть, но дето внутри. Из грейлсовой консоли одной коммандой внешние плагины доставляются.

Плюс перфоманс — ноде.жс показывает весьма приличный перфоманс, явно быстрее и рельсов и грельсов.

Ага, только если под греилс перформанса будет нехватать, подключаеш джаву и вперед. А с ноджс че делать? переписывать все на цепепе?

Плюс он гламурный и хипстерский — в общем воспринимается приятно:))

Рельсы всегда были и еще будут гламурными и хипстерскими (и грельсы как унаследовавшые многое тож можно перечислить). А ноджс популярен потому что массам впадлу два языка учить. Это не «гламур и хипстерство» а быдлизм.

Мавен там есть просто над ним обертка настроена, ну все равно он всплывет при сложных задачах.

О, эксперты снова в деле. Какой там мавен если там ivy?

Ну да, и получается как в анекдоте, не мавен а ivy, не «надо подключать» а уже подключен, и вообще уже оказывается не мавен а только его репозиторий, который на самом деле подключается разкоментированием одной строчки. Скоро тебя еще озарит для полноты картины что grails из maven central совсем не плагины берет.

А груви это просто синтаксический сахар для джавы

Ну конечно. Динамический язык, с метапрограммированием и замыканиями — синтаксический сахар для джавы. Ну в таком случае и скала и кложур — точно также синтаксический сахар для джавы.

Река хоть и течет, но ничем от моря не отличается, потомучто молекулы воды и, и рыба плавает. Тучи это сладкая вата но из той же воды. Огурцы ростут но они мне не особо нужны.

Ну серьезно, в джаве замыкания тоже есть просто синтаксис через классы.

Идиоматика юзания абстрактных класов и замыканий — сильно отличается. В жабе абстрактные класы используют, только если никуда не дется. Ибо это некрасиво\громоздко. Свой определенный плюс в этом есть. В жаба скрипте замыкания используют везде, где нужно и где нет. Потому что просто.

Замыкание это теперь анонимный класс? Что же за ужасы вы тут рассказываете.

В случае анонимного класса замыканием выступает его метод.

Не только. Весь класс, на сколько я помню, возможно присваивать полям значения из верхнего скоупа.

Замыкание — это просто анонимный класс записанный без синтаксического мусора.

Скорее наоборот. Анонимный класс — это замыкание (его «частный случай»).

Можно писать на CoffeeScrtipt без var. Я тоже всегда был приверженцем строгой типизации, но на практике ее значимость, кажется, преувеличена. И да, node.js, вероятно, еще недостаточно «взрослый» для некоторых задач, но на нем очень приятно создавать утилиты командной строки, JSON API, небольшие веб-приложения.

отсутствие строгой типизации
  1. php — динамическая типизация
  2. C# 4.0 поддерживают новое ключевое слово dynamic, которое разрешает динамическую типизацию
Вот уж M$ то сто пудов повелось на тренды, а php поддерживал динамику, когда это даже еще не было популярно!

довольно симпатичная технология при первом знакомстве

На практике это не значит вообще ничего.

Главное — чтобы потом допиливать можно было спокойно, а не хватаясь за голову на тему «ну и как/куда здесь это приделывать??».

Как себя ведёт технология в условиях большого проекта с изменяющимися требованиями — это несравнимо важнее, чем «симпатичность» и т.п.

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

мыслите большими монолитными приложениями, SOA не знать

backbone отлично и на сервере смотрится

Есть еще такой вариант «стека» для нода — blog.mongodb.org/...s-angularjs-and :)

Сударь, вспомните Великих: «предпочитайте композицию наследованию» © и не говорите глупостей.

похоже смысл был другой.
фраза вырвата из контекста, переводчик наверное не читал страуструпа.
наследование is-a.
композиция/агрегация has-a

правильно?

По мойму, тут цитируют ГОФ, а не Страустрапа.

у гоф и страуструпа разный ооп?

у гоф и страуструпа разный ооп?

Если я правильно помню ГОФ (оч слабо помню). То таки да! В корне разное!

В чем суть корня разности?

В чем суть корня разности?

100502 сегодня не будет

ООП везде разный. И смысл в ГОФе именно: «предпочитайте композицию наследованию», без всяких контекстов. С очень наглядным примером. Советую ознакомиться.

например
Car имеет wheel — has-a
Ford наследует Car — is-a

в таком случае нужно предпочитать композицию наследованию?

У вас 30 видов колёс, 50 видов рулей, 100 видов моторов и т.д и из всего этого вам надо сотставить машину. Комбинаторику знаете? Считайте.

Зачем мне 30? такой подход противоречит куче принципов проектирования.

С того, что пример с машинами неподходящий. Скажем у вас есть помещение. Вы можете унаследовать от неё комнату с окном, комнату с дверью, комнату со столом, комнату с окном и дверью, комнату со столом и окном, комнату со столом и дверьью. Или ничего не наследовать, а собрать любую комнату из помещения, стола, двери и окна. Пример, конечно, так себе, лучше посмотрите оригинал.

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

Не так. У вас есть комната, у неё коллекция айтемов. В эту коллекцию вы и вносите двери, столы и т.д.

Профит тем больше, чем больше типов айтемов.

javascript хороший годный язык

если так уж тяжело без «нормального» наследования, то его можно имитировать

выбирают потому, что на ноде легко разрабатывать

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

В js даже наследования нет нормального.

Какое ООП (и наследование) считать правильным — вопрос мутный. js — использует концепцию прототипов, её надо понимать. «Нормальное» наследование доволно легко имитируется. Не хотите сами — есть много библиотек, тот же MiscrosoftAJAX или Prototype.

Ну а профит, как я понимаю, использование одно и того же языка и на клиенте, и на сервере. Ну и модно. А вообще, гадость этот ваш JavaScript.

Несколько раз перечитывал чтобы понять что такое

мутный. js

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

Ноде жс — г0вно! А те кто его юзают — безмозглые бкодеры!

Автор — вы странный товарищ. JS — язык для браузера, а не для сервера, и в браузере, как ни крути, он работает достаточно хорошо, даже с тем наследованием, какое есть.

Работаю с Node.js, согласен, что для крупного приложения это не лучший выбор. И да, первое, с чем сталкиваешься, и к чему нужно привыкнуть — колбэки.

Огромный плюс у Node — больший и живой комьюнити и количество готовых модулей.

вы наверное мне не поверите, но коллбеки есть везде, где используется асинхронность. К тому же, вы мне наверное снова не поверите, но с ними уже умеют давно работать через future/deffered. Вы так неодоцениваете язык и технологию, что даже аргументировать свою позицию пытаетесь личными факторами.

Личные факторы вроде того, что я прежде не работал с асинхронностью?

Личные факторы вроде того, что я прежде не работал с асинхронностью?

php? php!

Я могу себя поправить. Я сейчас не работаю с PHP. Я работаю с JS. Просто скажем так, в моей практике работы с JS я не сталкивался с такими задачами, как рабта с файловой системой или с базой данных. В обычной практике при работе в клиенте у меня нет необходимости ждать выполнения сразу нескольких функций перед тем, как переходить к выполнению следующих.

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

В обычной практике при работе в клиенте у меня нет необходимости ждать выполнения сразу нескольких функций перед тем, как переходить к выполнению следующих.

Странно, у вас в профиле значится backbone.js, в которой часто нужно ждать выгрузки данных в модель, а если это REST — то получения от связанных ресурсов, перед рендером UI.

Я в курсе разницы серверного и клиентского подхода, но в случае с JS — событийная модель работает на обоих уровнях.

На стороне клиента мне не нужно делать синхронные запросы в БД в асинхронной среде. Я пишу приложение на ноде, и несмотря на опыт в JS, над подобными задачами приходится задумываться. Проблем нет, когда делается одна блокирующая операция. Когда их количество растет, нужен некий паттерн, в котором не было необходимости при работе в клиенте.

на стороне клиента вам приходится делать асихронные запросы к бэкенду для выгрузки данных, иногда ресурсы апи зависят друг от друга, вы делаете что? Скорее всего рисуете callback на событие синхронизации родительского ресурса, внутри которого уже выгружаете зависимые, при сложной структуре зависимостей вам не избежать синхронизаций с таким подходом. Либо вы просто ни разу не писали сколько-нибудь серьезный одностраничник.

Использовать блокирующийся ajax запрос при этом — злое зло, пользователь вам этого не простит.

Попробуйте это объяснить всем тем сломя-голову бегущим на Node.js, которые кроме обёртки jQuery ничего не пробовали толком. И их большинство, а ведь разработчики Node.js распиарили свой продукт, как снежинку. Какой смысл объяснять, что, например, пишет приложение, а оно бац — скушало поток процессора, сразу паника — как, что, почему? Я же не допускал ошибок! Значит это всё нод, он дерьмо!.

Проблемы с отладкой и обработкой исключения таки остались, тут как ни крути, плюс утечки из-за бездумной передачи анонимных функций в callback. Но чем в остальном nodejs будет отличаться от того же tornado со всеми проблемами однопоточности python — непонятно.

На эту тему уже немало холиваров было.
Из плюсов: удобство, не сложный язык, скорость разработки.

Минусы: все эти плюсы постепенно превращаются в ад пропорционально сложности и масштабности приложения, благодаря простоте языка. Но кроме простоты языка есть ещё фишка — callbacks, которая также совсем перестаёт быть фишкой, когда копаешь глубоко.

В js даже наследования нет нормального

Там много чего нет, но это не отменяет возможность любому специалисту выполнить задачу с необходимым результатом.
Из опыта понял следующее:
Легко и быстро можно написать небольшое приложение. К примеру мне срочно нужно что-то отсортировать или запустить не напрягающий веб-сервер, ну тот-же чат. Т.е. есть небольшие задачи, которые на других языках требуют большей затраты времени и знаний, чем js.

Приложение в масштабе, полноценная система с тысячами, десятками и сотнями тысяч строк кода и большой функциональностью сделать тоже можно, но тут уже не будет так легко, скорей сложнее. В таком случае лучше выбирать более подходящий для таких задач язык.

Т.е. есть небольшие задачи, которые на других языках требуют большей затраты времени и знаний, чем js.

О каких языках и затратах идет речь? Можно пример?

Те же java/php/c#. Во многих случаях только на подготовку уйдёт больше времени. Тут выигрыш (имхо) только по времени.

Ну вот если взять джава, о какой такой подготовке идет речь?

Ну банально сравнить скачивание, установку и настройку среды по времени. Даже если это не будет большой разницей, то написание уже непосредственно самого приложения может оказаться более долгим, чем на node.js

Ну банально сравнить скачивание, установку и настройку среды по времени.

Если я джава программист то у меня среда наверное уже скачана и настроена?

Даже если это не будет большой разницей, то написание уже непосредственно самого приложения может оказаться более долгим, чем на node.js

Тоже высосано из пальца.

Не знаю как в Node.js, но в Java неблокирующие сокеты — это
— либо «сырое» NIO/NIO.2 (с требующими изучения новыми классами и неожиданными ограничениями (скажем, регистрировать новый SelectionKey в Selector должен именно тот поток, который будет вызывать Selector.select()) - если не ошибаюсь) требующими изучения. Еще пример: Netty, для того что бы работать с NIO приходится выяснять версию операционки и виртуальной машины (static.netty.io/...erMetadata.html метод detectConstraintLevelFromSystemProperties()) - Sun JVM, Linux, Windows, Solaris, Apple JVM, AIX, BEA ... ну и камменты типа «IBM JDK 1.6 has different constraint level for different version.» просто убивают.

— либо, из популярных библиотек, Netty — достаточно сложная сходу архитектура приложения. Пример: Echo server из документации (static.netty.io/...ge-summary.html) использует ChannelHandlerContext, ChannelBuffer, SimpleChannelUpstreamHandler, ServerBootstrap, ChannelPipeline, ChannelPipelineFactory, NioServerSocketChannelFactory.

Джава нио для селекторов, не такое уж и сложное. Там статья, аж на две страницы, дает хорошое представление. Да и любой бкодер копипейстом сможет быстренько сокет зделать. Но о том ли речь идет? Любой вебсервлет контейнер всю эту «низкоуровневщену» скрывает далеко.

Если тебе так уж присели неблокирующие сокеты то посмотри уж плей

руби он реилс, груви он греилс ?!

ага, концепцию прототипов не понимаете.

Удачи в програмировании комет сервера на тыщи соеденений на php :P

Ну еще и Websockets хорошая поддержка, да, и джсон гонять туда сюда удобно, а если еще и стоит монга...

НУ как же, ноде.жс это же стильно модно молодежно. А если еще и SaSS и

CoffeeScript/LiveScript/Clojurescript так вообще.

js ничего так — единственный косяк nodejs — «однопроцессорность» , хотя и єто решается, хотя тогда теряется вся прелесть stateful

ok, как нибуть попробую, сделать чат.

для чатов он очень неплох

единственный косяк nodejs — «однопроцессорность»

Это не баг, а фича :)

вся прелесть stateful

стайтфул и прелесть? У меня шота не сходитсо.

Яндекс пишет такое:

Использование одного языка на всех технологических уровнях, начиная c браузера и заканчивая утилитами сборки, сильно упрощает жизнь многим участникам процесса. Разработчики могут конфигурировать (а при желании и дописывать) инструменты для сборки, одинаково легко пишут код для клиента и сервера. Уже не требуется глубокое знание большого количества разных технологий, достаточно хорошо знать базовые: HTML, CSS, JS. Благодаря этому стало проще подключать новых людей в команду: JavaScript знают все фронтенд-разработчики в Яндексе, а серверную специфику можно освоить очень быстро.

habrahabr.ru/...ex/blog/149327

В js даже наследования нет нормального. Какая речь может быть о серверном программировании? Я чего-то не понимаю?

Вы многого не понимаете :)

Если уж вы настолько убоги настолько надо классы, то coffeescript.org

Чем руководствуются заказчики при выборе node.js или подобной технологии?

ИМХО, модой.
Из реальных плюсов.
Если его правильно приготовить, получается очень не требовательный к ресурсам софт с легкой логикой (простенький инет магазин). Или же очень быстрый «риалтайм» сервер (но тут надо совсем минимум логики), некоторые используют как готовый «реактор».

Из более очевидных плюсов, один язык на фронте и на сервере.

настолько надо классы

oop bad way?

Если вы пишете сложное AJAX-приложение вроде Gmail, Node тоже очень хорош. Для современных веб-приложений, делающих большую часть работы в браузере, отлично подходит сервер, который может одновременно обрабатывать тысячи запросов и имеет низкое время отклика. Возможность повторного использования одного и того же кода, например валидации, на сервере и клиенте — тоже плюс

Если его правильно приготовить, получается очень не требовательный к ресурсам софт с легкой логикой (простенький инет магазин). Или же очень быстрый «риалтайм» сервер (но тут надо совсем минимум логики), некоторые используют как готовый «реактор».

Из более очевидных плюсов, один язык на фронте и на сервере.

Erlang сюда подходит хуже?

Если вы пишете сложное AJA...
Цитата не моя (вроде).
Erlang сюда подходит хуже?
Как пишут в инетах ерланг даже лучше подходит, но для начала надо освоить язык, потом техники, потом найти софт...
А с джаваскриптом знаком почти каждый кто работает под веб.
настолько надо классы
oop bad way?
А я про ООП ниче не говорил. В джаваскрипте оно таки прекрасно ... не так ... «божественно» — лучше подходит.

тут

А я про ООП ниче не говорил. В джаваскрипте оно таки прекрасно ... не так ... «божественно» — лучше подходит.

объекты — это функции, объекты — это массивы и наоборот. как-то...

хотя да var x = {}; мне тоже нравится

классы — это функции, классы — это массивы и наоборот. как-то...

Нет не каких классов, ваапшэ. А ООП есть :)

и еще

строки переменными, переменные строками.скрипты компилируются не до исполнения, а в процессе, и не целиком, а только те функции, что были вызваны

С этим можно поспорить) Как минимум — нет инкапсуляции. Имитровать можно, но на уровне языка то — не поддерживается.

Как минимум — нет инкапсуляции.

Рылли? Почитайте больше про ООП и ту же инкапсуляцию (честно уже надоело пересказывать по 100500 раз).

Я знаю как имитировать инкапсуляцию замыканиями. Но это — финт.

Я знаю как имитировать инкапсуляцию замыканиями.

ту же инкапсуляцию (честно уже надоело пересказывать по 100500 раз).

100501:

Инкапсуляция — это в первую очередь «объединение данных и алгоритмов их обработки» (вольная формулировка)

Но это — финт.

Для ограничения доступа — это не финт. Просто другой подход.

правда там есть еще и ограничение видимости.

Для ограничения доступа — это не финт. Просто другой подход.

А я всегда считал инкапсуляцию механизмом ограничения доступа к элементам объекта.

А я всегда считал инкапсуляцию механизмом ограничения доступа к элементам объекта.

Это вторично (или скорее 100500-рично)

UPD. Поищите что пишет сам Алан Кэй и тд. Поймете что глава про ООП из книги по джаве/шарпу это ооочень краткое и частное трактование.

Підписатись на коментарі