Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Ещё пойти и в гуглогруппе советую объявить об этой новинке — английскою речью, понятное дело.
Ну я о грядущем релизе напишу, а то пока стесняюсь.
Опубликовал groups.google.com/d/msg/nodejs/mSbwcsiNGng/Df_TldIWriwJ
Посмотрим, как буржуи будут есть тоталитаризм. В версии 0.0.16 уже много нового, но русскоязычная аудитория как-то не особо заинтересовалась, по существу только пару багрепортов.
Посмотрим, как буржуи будут есть тоталитаризм. В версии 0.0.16 уже много нового, но русскоязычная аудитория как-то не особо заинтересовалась, по существу только пару багрепортов.
Подход к делу получился занятный.
Тем не менее, вижу, что всё ещё не стало так просто, как оно было в PHP (где достаточно дать файлу некоторое расширение и обрамлять код специальным образом, а внешние по отношению к коду куски воспринималися просто как HTML).
А было бы неплохо видеть«<?js var fs = require('fs'); var os = require('os'); ?>» и так далее; вот только не знаю, доживу ли до того дня.
Но шаг, по крайней мере, в правильном направлении.
Тем не менее, вижу, что всё ещё не стало так просто, как оно было в PHP (где достаточно дать файлу некоторое расширение и обрамлять код специальным образом, а внешние по отношению к коду куски воспринималися просто как HTML).
А было бы неплохо видеть
Но шаг, по крайней мере, в правильном направлении.
Ну это весьма сомнительный синтаксис, если так сделать, говнокод начнется еще тот, бизнес-логика в шаблонах и поехали. Я не против логики в шаблонах в принципе, просто есть логика отображения, а есть бизнес-логика, и сие есть различные вещи. Идея — взять лучшее отовсюду, ну и это все же экспериментальный код, где можно позволить себе значительно больше.
Я не против логики в шаблонах в принципе, просто есть логика отображения, а есть бизнес-логика, и сие есть различные вещи.Я знаю об этом различии, но не видывал ещё системы, которая могла бы автоматически разделить их. Только воля программиста, ограничивающая его и останавливающая от смешения того и этого, способна невозбранно достичь желаемого.
А значит,
Похоже, логическое разделение кода — это как раз то, чем человек отличен от животного и машины. Если не считать сказок об искусственной интелигенции, то человек — единственная тварь, способная строить абстракции и обреченная все время их рефакторить.
А чем серьезно отличается маршрутизация URL на базе файловой системы от того, размещения php-скриптов по папкам, так это то, что есть одна точка входа, которая предварительно готовит все окружение, как то доступ к базе, предварительную обработку запросов и подгрузку библиотек. В результате, в каждом обработчике мы уже избавлены от необходимости повторять одинаковые предварительные ласки, и приступаем непосредственно к прикладной логике.
А чем серьезно отличается маршрутизация URL на базе файловой системы от того, размещения php-скриптов по папкам, так это то, что есть одна точка входа, которая предварительно готовит все окружение, как то доступ к базе, предварительную обработку запросов и подгрузку библиотек. В результате, в каждом обработчике мы уже избавлены от необходимости повторять одинаковые предварительные ласки, и приступаем непосредственно к прикладной логике.
Весьма амбициозный прототип. А почему в качестве основной поддерживаемой СУБД была выбрана именно MongoDB, а не РСУБД? Будет ли в планах модель для основной функциональности (юзеры, сессии, права доступа)? Планируется ли развитие в сторону полноценной CMS с модульной структурой, или проект не будет выходить за грани фреймворка?
Монго исключительно в качестве примера, доступ к данным — это не основная цель, но другие СУБД будут добавляться. Конечно, тоталитарный стиль не позволит добавить по несколько конкурентных СУБД одного типа, чтобы избавить разработчиков от мук выбора в том случае, если они сами не могут дописать что нужно. Как написано в разделе «Планы на ближайшее время» — простенькая CMS будет и очень скоро. Система юзеров и сессий уже частично выложена, а группы и права уже готовятся к публикации.
Ну как же MEAN stack! Правда теперь уже MIAN.
«MEAN stack» — это (как нетрудно обнаружить вон там) сочетание MongoDB, ExpressJS, AngularJS и Node.
А чем в «теперь ужé MIAN» заменяют ExpressJS?
А чем в «теперь ужé MIAN» заменяют ExpressJS?
Вот не понимаю я этой тяги к повсеместному яваскрипту. В MongoDB нет транзакций, отсюда вытекает либо негибкая схема данных под атомарные файнд-апдейты, либо проблемы гонок при достаточных нагрузках, либо сущий ад с поддержкой двухфазных коммитов вручную. При этом, NodeJS прекрасно дружит с РСУБД, хорошо поддерживает разные коннекшен-пулы и хранимые операторы.
Может Вы хотите сказать, не к повсеместному яваскрипту, а к повсеместному JSON или повсеметсному бессхемному хранению? Кто ж виноват, если народ не видя разницы между RDBMS и NoSQL, не приходя в сознание, хранит все в том, что под рукой? Точно так же, многие используют РСУБД не по назначению, хранят там XML в текстовых полях и потом парсят все это, или хранят таблицы, на 95% заполненные NULL значениями в напрочь вырожденных структурах. Есть данные структурные и типизированные по своей природе, просто декомпозируемые и требующие вычислений «времени выборки», например: финансовые, учетные, транспортные, а есть данные бессхемные, по природе. Нет одной таблетки от всего.
Я говорю именно о JS. Он используется в MongoDB при попытке сделать что-то сложнее выборки, например map-reduce. И много раз слышал девиз «везде JS, это клево».
По поводу проблемы выбора, вы правы. MongoDB — узкоспециализорованная субд для хранения и поиска данных документального типа. От этой ошибки и хочется предостеречь тех, кто еще не наступал на грабли. Простота и лаконичность MongoDB провоцирует выбрать её в качестве основной БД сайта. Мне вот тоже MongoDB вначале показалась идеальной, при её изучении и эксперементировании, до того самого момента, пока не появился сложный проект на ней, c «replica set»-ом на 4 серверах. Его нужно было поддерживать, а в нем начали появляться баги на нагрузках в состоянии «гонок», которые пришлось исправлять руками, симулируя транзакции хранением состояний элементов коллекций (маны по ним). Далее добавились «хотелки» от владельца, что привело к проблемам с модификацией схемы (малейшее поползновение может привести к переписыванию многих частей кода). Делая это, часто в голову приходила мысль «черт, был бы тут postgres — отделался бы одной строчкой».
По поводу проблемы выбора, вы правы. MongoDB — узкоспециализорованная субд для хранения и поиска данных документального типа. От этой ошибки и хочется предостеречь тех, кто еще не наступал на грабли. Простота и лаконичность MongoDB провоцирует выбрать её в качестве основной БД сайта. Мне вот тоже MongoDB вначале показалась идеальной, при её изучении и эксперементировании, до того самого момента, пока не появился сложный проект на ней, c «replica set»-ом на 4 серверах. Его нужно было поддерживать, а в нем начали появляться баги на нагрузках в состоянии «гонок», которые пришлось исправлять руками, симулируя транзакции хранением состояний элементов коллекций (маны по ним). Далее добавились «хотелки» от владельца, что привело к проблемам с модификацией схемы (малейшее поползновение может привести к переписыванию многих частей кода). Делая это, часто в голову приходила мысль «черт, был бы тут postgres — отделался бы одной строчкой».
Ну конечно, любые вычисления внутри update/insert приводят в Монге к вытягиванию данных и обработке их при помощи JS. Это не говоря уже про то, что удаление или изменение связанных ссылками объектов (реализация аналога каскадных операций из RDBMS) становится сущим адом. Простая вещь, умножить поле на 2 по всей коллекции — уже туго. Я это хорошо понимаю, т.к. еще в 1999 году написал СУБД UOD, нечто подобное на Монго, и тогда еще не было ни какого JSON, поэтому у меня был свой формат представления объектов USP и свой двоичный формат для хранения типа BSON. Так вот все это хозяйство использовалось не вместо RDBMS, а вместе с ними, для разных данных разных типов. Конечно, хотелось бы иметь гибридную СУБД, не обертку над двумя и не имитацию одного принципа моделирования данных при помощи другого, а действительно гибридную, совмещающую: таблицы, связи, деревья, бессхемные коллекции, файлы. С реализацией целостности данных в таком хранилище, но на горизонте ничего такого не знаю.
Есть же вполне гибридная ArangoDB с одной стороны и PostgreSQL c индексируемыми json колонками с другой.
А еще есть функциональные индексы в postgres. Инструмент не столь удобный и понятный, как индексы в mongo, но может спасти в некоторых случаях.
Оцените: версия 0.0.3 получила шикарное расширение для шаблонов, позволяющее избежать дополнительных IFов в коде, например: при включении в страницу шаблона с именем «hmenu» происходит такая последовательность поиска:
1. Если нет сессии, то отдается hmenu.template
2. Если есть сессия, и пользователь входит в группу admin, то ищется hmenu.admin.template, если нет такого файла, то берется hmenu.template
3. Если есть анонимная сессия или у пользователя нет группы, то ищется hmenu.everyone.template, если нет такого файла, то берется hmenu.template
4. Если ни один из вариантов выше не позволил найти файл, то смотрим на каталог выше пока не дойдем до корня сайта
Это позволяет без IFов кастомизировать страницу под разные группы пользователей.
1. Если нет сессии, то отдается hmenu.template
2. Если есть сессия, и пользователь входит в группу admin, то ищется hmenu.admin.template, если нет такого файла, то берется hmenu.template
3. Если есть анонимная сессия или у пользователя нет группы, то ищется hmenu.everyone.template, если нет такого файла, то берется hmenu.template
4. Если ни один из вариантов выше не позволил найти файл, то смотрим на каталог выше пока не дойдем до корня сайта
Это позволяет без IFов кастомизировать страницу под разные группы пользователей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прототип тоталитарного фреймворка для node.js