kotiara kotiara

Socket.io ещё не стабилен на высоких нагрузках

Что значит не стабилен? О какой именно не стабильности вы говорите?

node-webkit проще в употреблении, нежели TideSDK, когда речь идёт о создании приложений с графическим интерфейсом на десктопах методами веборазработки

Я думал, что в этом они одинаковые так как используют одни и те же веб-технологии (html, css, js). Или я что-то не понимаю?

Только derby используют socket.io, что совсем меняет картину.

Можете подробней объяснить, что вы хотели сказать?

Сначала можно посмотреть лекции Крокфорда (хотя бы вторую).
Потом можно почитать Eloquent JavaScript (может как базовую книгу кто-то посоветует другую)
Потом пройти туториал Резига
Потом досмотреть все лекции Крокфорда.
А дальше можно пересмотреть все оставшиеся ссылки из статьи (wtfjs, js patterns...)

Так это потому, что Java взяла этот синтаксис из С. А С взял какие-то вещи из Fortran. Посмотрите лекцию Крокфорда, там все подробно рассказано

Вот если бы его можно было использовать для создания сценариев или компилировать в JS…

Выбирайте здесь или здесь (вот эта ссылка есть в посте)

А какой язык вы считаете «удачным»? Просто любопытно

В доме который построил Джек…

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

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

А Джава (если верить русской википедии) — это поселок в Осетии ))

Иностранцы, ее произносят как Джава. Но я думаю, что это дело вкуса. Поэтому исправил на JavaScript.

исправлено

Я о том же хотел сказать, что futures это круто, но как-то синтаксического сахара не хватает…

Я так понял, что это разновидность control flow (futures). Показаыне примеры кода меня как-то не впечатлили. Может я чтол-то не понимаю…

Да, неплохо. Категоризация местами хромает, но лучше чем ничего.

Я хотел список «мейнстримных» пакетов.

Хорошее замечание. Не обратил внимание, что should не поддерживает браузер

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

Следующая тонкость — в моем описании есть небольшая подмена понятий. Группа (которая отражает принадлежность к иерархической структуре в реальном мире) и группа (роль) в системе разделения прав не всегда одно и тоже. Специально оставил, так как сам наступал на эти грабли (думаю, не я один). Нужно разделить понятия группа и роль. Тогда можно будет сделать соотношение между ролями и пользователями многие ко многим.

Гостям вообще разрешить только смотреть

allow('guest', 'read', 'posts[not_only_for_moderators]')

Админам можно все
allow('admin', 'all', 'all')

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

allow('members', 'read', 'posts[not_only_for_moderators,not_fitst_month]') allow('members', [read, 'post'], 'posts[not_only_for_moderators,fitst_month]')

Еще хочется на отдельные темы (!) назначать персональных модераторов.

allow('moderators', 'all', 'posts[where_moderator]') allow('moderators', ['read', 'post'], 'posts[only_for_moderators]')

Все просто если отделить бизнес логику от ACL. Назначение модератора в раздел это бизнес логика. Объясню на примере:
Пользователь является автором поста не потому, что он может редактировать пост, а потому что он написал этот пост и при создании поста система записала в базу текст поста и текущего пользователя как автора.
Эта информация может использоваться для разделения прав, а может и не использоваться. Может использоваться для получения списка всех постов данного пользователя.
Если на ситуацию смотреть под таким ракурсом, то любая задача решается. Была бы соответствующая бизнес логика, а навернуть сверху разделение прав всегда можно.

Вот если модератор — надо в лог записать, что модератор совершил действие.

Тут надо различать два действия: редактирование автором и редактирование модератором.
За ними стоит разная бизнес логика:
— при редактировании автором запись происходит только в таблицу с постами
— при редактировании модератором запись происходит в таблицу с постами и в таблицу с логами (в таблицу, если их потом надо просматривать конечному пользователю)

потому что универсальные, позволяют решить задачу в общем виде

Базовый интерфейс (а именно функция can) тоже может решить задачу в общем виде.

У меня нет опыта использования Yii (поправляйте, если что-то неправильно понял). Вот, что я понял из документации:
— нельзя назначить много ролей юзеру (вместо этого предлагают использовать наследование ролей)
— нет готового решения для задачи с атрибутами ресурсов

Мое решение «на бумаге». Если найдется желающий, то он может реализовать его под интерфейс Zend_Acl

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

Если бы я вдохновлялся вот этой реализацией, я бы получил:
— «непоследовательную» ACL в которой «система вернет вам последний измененный параметр»
— наследование ролей

Лучше бы вы это здесь не оставляли. Идеи которые предлагает Zend_Acl:
— множественное наследование ролей. Это вообще «сказка» для хранения в базе (если нужно будет перейти от хранения в коде к хранению в базе.
— отсутствие принципов решения конфликтов

IMHO велоустройство через чур complexed.

Да простое же как грабли. Разбито на модули. Даже может работать с флагом admin в таблице user (куда уж проще). Но если изначально использовать заложенные принципы и программные интерфейсы, то легко расширить до решения с редактированием.

Btw, почему мы именуем DSL`ом то, что им не является? :)

Термин DSL я использовал так же как его используют в ruby. Любое множество специфических функций там называют DSL. Например, функции для написания Gemfile.

> на практике полезут вопросы производительности
Все вопросы производительности рассмотрены. Для этого как раз и не делается наследование групп и не даются права напрямую пользователям. Структура получилась «плоская», так что запросы будут простые и красивые и кеширование сделать тоже будет просто.
> и муторность конфигурирования
Не вижу такой проблемы. В коде ничего конфигурировать не надо, потому что CoC. Сбор данных автоматизирован максимально. Можно задавать изначальные значения с помощью DSL (эти файлы будут хранится в системе контроля версий и накатываться автоматически так же как фикстуры на базу).
> Есть еще вопрос аудита — например, хочется знать, юзер редактировал пост потому что ему прав хватило, или потому что он модератор.
Не очень понял проблему. Смотрим на пост и видим кто автор поста.
> А правило например «может редактировать свои посты в течение 30 минут».
can_edit_30(user, resource) return user.id == resource.user_id && (resource.created_at - now()) < 30; end
> Если не различать — логи забьются шлаком.
Поподробней пожалуйста.
> IMHO, оптимальнее всего отталкиваться от реальной задачи, максимально упрощая для нее логику ACL. На «классические» реализации вас ссылки уже дали, тут добавить нечего.
Я как раз все упрощал. А эти реализации все усложняют. Не очень понял почему это «классические», реализации. Я бы назвал классической реализацией, например, права в файловой системе *nix. Именно из этой системы была взята идея о том, что у юзера может быть много ролей (больше ничего подсмотреть не удалось).

> страсть перегорает, в то время как жадность устойчива
Улыбнуло.

• Требования к формальному образованию базовые или отсутствуют
• Хорошая компенсация, даже для посредственных работников
• Миллионы рабочих мест
• Никаких физических усилий
TRUE!

• Никаких рисков здоровью или юридических рисков
Про юридические риски — по разному бывает

FreeArc, кстати, как и 7Zip, бесплатен и у него открытые исходные коды.

Было бы замечательно, если бы эти исходные коды выложили на Github.

fatal можно обработать если set_error_handler выполнился в не в том файле где случается фатал

Цитата с php.net
The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.

Скорее всего дело в этом. Если нет, выложите пример кода.

2Offenso. Достаточно будет, если я напишу это в комментарии?
Код распространяется под «лицензией» AS-IS. Вы можете копировать, модифицировать код без указания автора и без уведомления автора. Можно использовать в коммерческих проектах. Хотя сейчас, мне этот код не кажется идеальным и я бы не использовал его в коммерческих проектах.

Мнения автора могут не совпадать с его точкой зрения (с)

Было бы не плохо завернуть все описные действия как Chef рецепт

Случайно нажал отправить

> P.S. Будем рады если кто-то сможет оптимизировать код для генерации картинок бОльшего разрешения.

Если пиксели с одинаковым цветом идут подряд, то можно не создавать для каждого тег font, а объединять в один тег

> P.S. Будем рады если кто-то сможет оптимизировать код для генерации картинок бОльшего разрешения.

А как насчет компрессии цветов? Вместо #ffffff можно писать #fff; вместо #f00 можно писать red. Код такой компрессии можно подсмотреть в любом css minier'е

В исходном коде только два параметра _ga.trackSocial = function(opt_pageUrl, opt_trackerName), а у вас три. Откуда берется третий?

Opera 11 поддерживает css3 gradient -o-linear-gradient

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

переход явный throw new baseException(); — после этого ничего не выполняется в текущем методе.
Вы же не ожидаете, что что-то выполнится в функции после return;?

Я спросил про бизнес-логику.
1. Cначала оптимизируют ботлнеки.
2. APC
3. Есть еще кучу «микрооптимизаций» которые можно применить прежде чем станет заметна потеря производительности на исключениях

А если view надо отделить от model/control?