Тимур Шемсединов

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

Ответы:

agentx001:

Сильно много мне не нужно, MVC да рендринг страниц на сервере.

Что такое MVC нет общего мнения, так случается, что каждый поймет это по-разному, потом напишет что-попало, и назовет это MVC. Так вот, Impress это не MVC, если понимать MVC, как отдельное написание контроллеров, моделей и представлений. Не будем обсуждать, что такое MVC, это очень затертый термин, и мы запутаемся в домыслах, которые вокруг него нагромождены. Лучше я скажу, что ждать от фреймворка: Impress, сам по себе, это универсальный контроллер, он как раз написан для того, чтобы не писать контроллеров. В нем есть реализация представления — это рендереры, один из рендереров — это шаблонизатор (с его помощью можно рендерить не только HTML, но и CSV, CSS, TXT и что угодно), но есть еще рендерер для JSON, он совсем простой, можно дописывать другие рендереры, для других форматов данных, если шаблонизация не подходит, например, для бинарных данных. Еще в Impress есть реализация логики приложений — которая разделяется на три части: (а) логику модели данных предметной области, (б) логику представления, т.е. логику рендеринга, (в) логику библиотек общего назначения, не связанных с предметной областью. Логика предметной области — это бизнес-логика приложения, например: алгоритм вычисления маршрута доставки груза, для системы крекинга грузов. Логика рендеринга — это если нужно сформировать данные для рендеринга при помощи императивного кода (т.е. при помощи обычного алгоритмического программирования с условиями, циклами и вызывами), а не только при помощи декларативных шаблонов и декларативных условий в них. Логика библиотек общего назначения — это все универсальные задачи, которые могут быть переиспользованы в других проектах, например, генерация DOCX документа, валидация данных, чтение количества кадров из анимированного GIFа и т.д. Все эти три вида логики (кода), гораздо важнее отделать друг от друга, чем модель от представления. А вот отделать представление от логики представления — это вообще страшная ересь, в которую впадают многие MVC-фреймворки.

agentx001:

Понравился этот новенький impress, но не стремлюсь использовать самопальный продукт, могущий в любой момент свернуться и даже не имеющий документации…

Кроме самописных Вы еще какие знаете? Может есть какие-то автоматически писанные или сгенерированные? Есть статьи, есть примеры, часть API уже документирована, например, вот тут: impress/wiki. Скоро будут скринкасты, я уже об этом говорил. И в Impress очень мало кода, ядро весит 43кб. Код написан аккуратно, его можно прочитать за 5 дней, если читать по 5 страниц на ночь. Примеры готового веб-приложения (админ-панель для БД MySQL и MongoDB) даются вместе с системой и описываются тут: http://habrahabr.ru/post/192302/

rozhik:

По поводу критики impress — я бы таки выбрал другой. Очень странная архитектура, если он выживет — то явно поменяет не только половину апи — но и принципы расположения файлов.

Фреймворк не на пустом месте появился, файловые структуры, как и API, созданы как портированные на ноду, наработки моей команды за последние 15 лет на Delphi, C#, PHP и JavaScript. Структура каталогов и API будут наращиваться, но не переделываться кардинально, я уже нашел для себя золотую середину в архитектуре систем. Вот что будет меняться в ближайшие месяцы — это формат конфига, т.е. Impress же не просто фреймворк, это сервер приложений, и он может сразу обслуживать несколько приложений (на разных доменах). Для этого, конфиг будет разделен на основные настройки и отдельную конфигурацию, для каждого приложения. Но конфиг не вилик, его разнести на несколько файлов — не проблема, при чем, структура конфига не сильно изменится.

Советы:

1. Если у Вас сайт, то рендерите шаблоны на сервере, но если у Вас приложение, то сделайте одну страницу (ну или несколько основных страниц), и на сервере сделайте API на AJAX и JSON. Присылайте данные в клиентское приложение, будь то веб-приложение или мобильное приложение для iOS или Android или оконное приложение, на любом языке. Это гораздо универсальные и удобнее для интеграции и поддержки.

2. Используйте оперативную память, не лазьте в базу данных постоянно. Нода — это великолепная возможность писать быстрые приложения, и даже не из-за того, что она не блокирующая, за последний год я понял, что правильное использование памяти гораздо более ускоряет, Вам даже не нужно делать операции ввода-вывода в реальном времени, все они могут быть отложенные (ленивые, лэйзи). Вместо этого, разворачивайте данные в память приложения, стройте хеши, объекты, массивы. Не нужно бояться, что нода запущена в несколько процессов, и запросы одного пользователя могут приходить в разные процессы и находить там разные структуры данных. Это можно решить, делая «прилипание» клиентов по IP адресу или по Cookie при помощи балансировщика, к отдельному процессу ноды. В Impress такой балансировщик есть встроенный, можно использовать nginx или сервисы Вашего дата-центра, для больших проектов можно и нужно привлекать аппаратные балансировщики. Между разными процессами так же можно взаимодействовать через ZeroMQ, TCP, HTTP, IPC и еще что-угодно. Таким образом, данные разных процессов, в зависимости от того, что это за данные, могут или дублироваться в памяти (кешироваться, если это общие данные) или быть разделены на «прилепленные» сессии или синхронизироваться между собой через межпроцессовое взаимодействие.

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

Попробуйте сервер приложений Impress — http://habrahabr.ru/post/194250/
Для PHP-разработчиков он будет более понятным, чем другие фреймворки, потому, что делать новые API-обработчики (урлы для AJAX запросов) можно без перезапуска всей системы, просто созданием файла. Решено много вопросов, многопоточный запуск, перезапуск отдельных потоков при вылетании, логирование, обмен данными между потоками, отдача статики, кеширование в памяти как статики, так и кода и данных, которые этот код плодит, кукизы, хорошие драйвера к СУБД, и много другого, в общем, все необходимое для разработки серверов приложений.

У Вас процесс ноды, в котором запущен парсер, будет работать не долго? То есть, запускается только на момент парсинга или имеет в себе какой-то сервер (например, http, tcp, ipc) из которого парсинг вызывается периодически? Для открытия файла какой метод используете? Если делать fs.createReadStream(path, [options]), то там в опциях можно поставить { autoClose: true }

Фреймворк
Посмотрите в сторону Impress, для PHP-шника это будет более естественно. Все урлы мапятся на файловую систему, шаблоны и обработчики переопределяются. Созданием каталогов делается роутинг к страницам и к обработчикам API. Можно менять код обработчиков не перезапуская приложения, просто отредактировав файл на диске. Он подгружается в память и кешируется, то же самое происходит с шаблонами. Все без перезапуска, работает в многопоточном (кластерном) режиме. На нем уже десяток проектов работает под нагрузками. Вот статья на Хабре про Impress (написана в те времена, когда он был еще прототипом): Прототип тоталитарного фреймворка для node.js
require/dic
Модульность в Impress специфиеская, обработчики разбиты на отдельные файла, а вот модели и контроллеры можно писать в виде библиотек вот в таком паттерне, как описан тут: Паттерны JavaScript модулей в Impress для node.js и браузеров
Шаблонизатор
В Impress есть очень простой шаблонизатор, возможно, он не такой функциональный, но он очень производительный, в отличие, например, от EJS, который сделан просто безграмотно, ибо использует синхронное чтение шаблонов с диска. Для ноды синхронные операции вообще выбиваются из концепции и уничтожают все преимущества.

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

Интересная библиотечка, стоит исследовать. К сожалению, я не использую экспресс, и не могу ответить квалифицировано, но подобная проблема возникала у людей github.com/goodeggs/fibrous/issues/10 Очевидно, что экспресс (или его плагины доступа к данным) портят структуры данных, которые создает fibrous, когда привязывается к вызову методов. Методы вешаются в очередь fibrous и когда настает время их исполнять и вернуть управление в нужное место, то оказывается, что данных нет. По хорошему, конечно, fibrous не должен навешивать данные на объекты, которые сам не создает, а должен у себя делать внутренние структуры данных и индексы для вызываемых методов. Ну это нужно изучать и переписывать библиотеку.

Попробуйте этот рецепт: npmjs.org/package/impress
Запускает ноду в кластерном режиме, на все ядра, и умеет сразу целой группой кластерных процессов обрабатывать целую группу доменов. Поддерживается и маршрутизация урлов по каталогам, URL-реврайтинг и проксирование на другой сервер. Следит за конфигурацией на винте, и если в ней появились новые домены, то сразу подгрузит новую и начнет их обрабатывать, без перезагрузки процесса. Но самое удобное, что не нужно перезагружать процесс ноды, когда меняется код программы, т.е. все обработчики для URL-ов лежат в своих папках, можно их на винте менять, а Impress следит за файлами, перечитывает их и кеширует в память. Вот тут подробнее: habrahabr.ru/post/182714/

Такой возможности нет и не может быть! Это известная задача, для нее изобретены скоростные транспорты типа 0MQ, смотрите в эту сторону zeromq.org/bindings:node-js

Хоть ябольшой приверженец HTML5, но в IE без Canvas или SVG на одном JavaScript, думаю Вы не сделаете то что нужно. jQuery тут вообще ни при чем, это всего лишь сахар, а каких-то кардинально новых возможностей из браузера он не выжимает. Хотя, что понимать под редактором, если же речь идет про подложку картинки с масштабированием и надписью сверху, то это на JS просто. Что значит печать удаленно? Опишите подробнее.

Есть нокийный OVI shop для Maemo, а вот для meego ни какого shop'а я не видел, нужно погуглить. Как-то же приложения там ставятся, должен же быть центр, может тут гляньте — wiki.meego.com/MeeGo_Netbook_FAQ#How_do_I_install_applications

Для описанной ситуации рекомендую брать Oracle как основную СУБД, могут быть, конечно еще дополнительные базы для оперативных данных за день, кеширующее решение какое-то, чтобы часть данных держать в памяти для быстрого доступа. Но если Вы еще не завязаны на технологиях — берите решение Enterprise класса — Oracle. А языки программирования и технологии выбрали уже? Дело в том, что выбор СУБД очень зависит от того ПО, с которым Вы будете интегрировать свое решение, если Вы потом надумаете навесить там Microsoft BizTalk или SAP или 1С где-то, то об этом стоит подумать уже сейчас, при выборе инструментов, чтобы не менять СУБД и не делать потом костыли в виде ночной копии в другую СУБД.

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

Раньше было нельзя отключить цепочки, и это был ад, но перерь можно — gmailblog.blogspot.com/2010/09/turn-off-gmails-conversation-view.html

Гради Буч «Объектно-ориентированный анализ и проектирование»
Там примеры на С++ и ObjectPascal, но труд основопологающий, будет полезно по ООП

Варианты:

1. Сделайте статический класс db в db.php и в нем сделайте все функции «public static function» например: db::connect, db::query, db::freeCursor, db::getLasInserttId и т.д. и тогда вообще не нужно будет указатель на объект БД куда-то передавать в другие модули.

2. Сделайте у себя в проекте FrontController — то есть, единую точку входа, все URL переадресуйте на нее и вместо того, чтобы потом подключать все модули в каждом php файле — подключайте их один раз централизовано из одного файла, а там и с путями проблем не будет.

3. Сделайте в том файле, который устанавливает свзяь в БД переменную $db = db::connect(dbHost,dbName,dbUser,dbPassword); только объявляйте ее не внутри функции, а в теле php кода и потом во всех функциях, где нужно доступаться к пишите global $db; и далее $db->MethodName…

4. Прочтите все же что-то по областям видимости в PHP

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

В подписях к e-mail принято писать не должность, а научное звание, например:
Специалист: Ing. Your Name или Dipl.-Ing. Your Name или Dipl.Ing. Your Name
Доктор наук пишет: Doc. Your Name или Dr. Your Name (это в зависимости от страны)
Кандидат пишет: Your Name Ph.D. или Your Name PhD
Профессор: Prof. Your Name

А почему именно «много-много кода»? Чем меньше кода, тем универсальнее ПО. А чем больше кода, тем функциональнее софт. Нужно искать средний путь, но плодить много-много кода — это однозначно, не хорошая тенденция. Я предпочитаю выносить мысль несколько месяцев, а потом решить несколькими строчками или обозримым куском кода, который при возврате к нему через год, можно будет охватить глазом.

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

Тут уже хорошо ответили, но уточню: разница в зонах видимости/доступности, и это очень зависит от языка. Private — это локальная зона видимости (например, ограниченная юнитом, файлом, модулем, неймспейсом — для разных языков) то есть доступно из кода, составляющего одно логическое целое с этим классом. А Protected — это наоборот, видимость из всех порожденных от него классов, в каких бы файлах, модулях и юнитах они не находились.

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

Паттерн этот называется ООП :) А именно — использование абстрактных классов и наследование. Советую почитать хорошую старую литературу типа Гради Буча.

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

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

возникла мысль написать архитектуру сущностей, как набор примитивных классов-параметров

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

Я лично полюбляю Linksys / Cisco — там целая линейка $50-$100 для дома сейчас и девайсы годные, у меня повсеместно стоят.