LINUX.ORG.RU

Релиз Zotonic 0.8.0

 , ,


0

1

Система управления контентом Zotonic обновилась до версии 0.8.0.

Эта версия — последняя мажорная версия перед грядущими изменениями в CSS-фреймворке и административном интерфейсе.

Основные изменения:

  • улучшения в работе менеджера модулей (стабильность при запуске, модули запускаются и останавливаются в правильном порядке и т.п.);
  • страница состояния системы приведена в соответствие с внешним видом основного сайта, требует логина для просмотра и управления;
  • улучшена стабильность соединений с PostgreSQL и улучшена обработка таймаутов при запросах;
  • добавлена поддержка RTL-языков (Иврит, Арабский и т.п.) для модуля mod_translation в админке. Добавлен перевод админки на испанский, ирландский, эстонский и польский;
  • в mod_development добавлена поддержка inotify (только для Линукса). Это позволяет производить компиляцию Erlang'овских файлов, очистку кэша и компиляцию/минимизацию LESS/SCSS/Coffeescript на лету;
  • ветка master теперь использует git-субмодули для основных внешних зависимостей.

Напоминаю, что Zotonic написан на языке Erlang и предназначен для быстрой и удобной разработки. Утверждается, что Zotonic на порядок быстрее PHP-ориентированных фреймворков.

Особенности фреймворка:

  • высокая скорость работы;
  • простой пользовательский интерфейс;
  • система шаблонов, упрощающая разработку;
  • расширяемость;
  • поддержка event-driven модели.

Исходный код проекта доступен на github.

Новость на erlanger.ru.

>>> Документация

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 2)

Не знал о такой. Спасибо. Гляну на досуге, что за зверь.

Bbore
()
Ответ на: комментарий от anonymous

По сравнению с Java конечно медленный

Если только в синтетических однопоточных тестах и без hipe/native-компиляции.

shahid ★★★★★
()

«Как зотоник не пили, всё равно получается бложек» (с) кто-то местный.

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

shahid ★★★★★
()
Ответ на: комментарий от anonymous

фортран решает, однозначно!

ymn ★★★★★
() автор топика
Ответ на: комментарий от shahid

Именно HiPE версия медленнее в два раза примерно.

Причем здесь потоки ??? На LMAX Disruptor придумали - 1 000 000 сообщений обрабатывает на одном сервере. Всё решает архитектура.

anonymous
()
Ответ на: комментарий от anonymous

Причем здесь потоки ???

Да ни причем. Просто когда на яве поднимешь >1000 потоков, то она начнет поглядывать в сторону свопа, а >10000 захлебнется от gc. В отличии от.

На LMAX Disruptor придумали - 1 000 000 сообщений обрабатывает на одном сервере

И что?

shahid ★★★★★
()
Ответ на: комментарий от shahid

И что?

А то, что обрабатывают эти сообщения именно потоки.

Проблема при работе с потоками в Java знаете в чём ? Не в самой Java, а в ОС, которая медленно эти потоки паркует и пробуждает. В Disruptor потоки не паркуются, а спинятся. Т.о. избегая тормозов ОС получается повысить пропускную способность в 5-10 раз.

anonymous
()
Ответ на: комментарий от anonymous

А то есть проблема в недоОС, а jvm на самом деле может работать быстрее компьютера, верно? И монстрик-дисруптор - это не костыль наподобии ринг-буффера для сред, не способных выживать в агрессивной многопоточности, а правильная архитектура? Ок, так и запишем.

1 000 000 сообщений в СЕКУНДУ.

Действительно, на фоне эрланга, который тормозит в 2 раза при включении оптимизатора (!), это прорыв.

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

В эрланге передача данных между потоками всегда идёт через memcpy внутри инстанса beam и через erlang dist между нодами. Передача значения по ссылке идёт только внутри одного потока.

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

shahid ★★★★★
()
Ответ на: комментарий от shahid

да не спорь ты с аноном, очевидно он не шарит.

ymn ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.