Более надежный способ — хранение логов локально с ротацией по дням, скажем за последнюю неделю (один из стандартных appender-ов log4j) и ежедневная заливка данных на центральный сервер (log rotation). Если сервер недоступен, ну что же, зальем чуть позже. Логи не пропадут.
Полностью согласен не стоит складывать все яйца в одну корзину. Логи обязательно должны хранится в файловой системе как вы сказали. Центральный сервер в первую очередь нужен для удобства, в 99% случаев он работает и к нему можно подключиться что бы посмотреть логи, но если что-то пошло не так всегда есть локальные логи на сервере.
Что касается SimpleSocketServer: а есть что-нибудь посерьезнее? Скажем, реализация, которая выстраивает логи в правильном хронологическом порядке? Или такие вещи проще решить через консоль при помощи простого sort? :)
В LoggingEvent есть информация о времени возникновения события. Те программы которые я описал сами выстраивают все в верном порядке. На более навороченные реализации сервера не натыкался.
Кстате Alon Zakai (emscripten) в рассылки сообщил, что asm.js бэкенд уже готов и может быть использован повсеместно. Кроме проектов использующих исключения и setjmp/longjmp.
Оригинал
asm.js code generation mode (-s ASM_JS=1) no longer shows the «this is
experimental/not recommended» warning. It's fairly robust at this
point, appears to withstand fuzzing, generates faster code in most
cases even without special JS engine optimizations (but with such
optimizations is significantly faster still), and we've used it on
some large and complex codebases successfully.
It doesn't yet support C++ exceptions or setjmp/longjmp, but aside
from that should be considered ready for general use. It will likely
become the default code generation mode once those limitations are
fixed and we have a minifier for it.
Жду и надеюсь что это решит проблемы производительности emscripten. Однако, боюсь за то что корпорация добра их не поддержит. Сейчас FF серьезно отстает в производительности по сравнению с Chrome на моих проектах. Думаю asm.js подтянит их к результатам Chrome. Есть подозрение что v8 итак достаточно оптимален в этом плане и никакой asm.js ему уже не поможет. Хотя кто знает, если внедрение asm.js в Chrome даст двукратное увеличение производительности, то в TTD уже можно будет аще комфортно играть на больших картах.
Да оно подтормаживает, на среднем железе 20 фпс. На хорошем 40. Постоянно пытаюсь найти как бы ускорить, надежда есть, т. к. сама по себе игра не требовательна к железу.
Радует то что они мержат JRockit, в некоторых аспектах она круче. По памяти точно могу сказать что она расходует ее заметно меньше. Запуск текущей Oracle JVM отъедает порядко 300mb виртуальной памяти минимум, и на сервере с 1ГБ оперативы не удавалось запустить более 3 приложение на java, с JRockit таких ограничений нет практически отжирает ровно столько сколько прописанно в -Xmx.
Проверка существования метода на этапе компиляции. Во многих динамических языках можно вызывать любые сочетания букв как подпрограммы. Соответственно о корректности вызова я узнаю во время исполнения, а не на этапе компиляции. Поэтому простое переименование метода вдет к потенциальной опасности что то поломать (даже если вы исправляете грамматическую ошибку в имени метода).
Аналогично, любая описка ведет к появлению новой сущности в программе, вместо генерации компиляционной ошибки.
С другой стороны, динамические языки мотивируют использовать TDD. Что бы быть уверенным в своем коде его нужно максимально покрыть тестами, что хорошо. Но с другой стороны я часто делаю опечатки в коде, что снижает мою производительность, часто программа запукскается в «холостую» до первой опечатки.
Меня же от написания чего то действительно крупного удерживает во все не анархия и вседозволенность, а банальная не возможность быстрого рефакторинга ввиду отсутствия статической типизации и строгих проверок на этапе компиляции. И тут ruby/python/perl/js выглядят одинаково плохо. Пока я не научился писать код который не нужно проверять. Поэтому для меня динамические языки заняли нишу «быстрого программирования маленьких программ или сайтов».
Выше уже пробегала мысль что это не есть портирование в чистом виде. Скорее это транслирование LLVM байт-кода в JavaScript. По какой причине в оригинальной статье используется термин портирование мне не известно, для себя я счел это не важным. Скорее это вопрос терминологии.
А суть что происходит вы уловили правильно. Это лишь общая схема показывающая как можно выдернуть конкретную функцию из libxml.
Для того что бы получить порт библиотеки нужно написать обертку для вызова каждой конкретной функции из libxml2. Выполнив команду:
Построится файл libxml2.js который будет содержать функции соответствующих статических библиотек, эти функции можно напрямую вызывать из JavaScript кода. Правда делается это не очень красиво, как-то так:
Полностью согласен не стоит складывать все яйца в одну корзину. Логи обязательно должны хранится в файловой системе как вы сказали. Центральный сервер в первую очередь нужен для удобства, в 99% случаев он работает и к нему можно подключиться что бы посмотреть логи, но если что-то пошло не так всегда есть локальные логи на сервере.
В LoggingEvent есть информация о времени возникновения события. Те программы которые я описал сами выстраивают все в верном порядке. На более навороченные реализации сервера не натыкался.
experimental/not recommended» warning. It's fairly robust at this
point, appears to withstand fuzzing, generates faster code in most
cases even without special JS engine optimizations (but with such
optimizations is significantly faster still), and we've used it on
some large and complex codebases successfully.
It doesn't yet support C++ exceptions or setjmp/longjmp, but aside
from that should be considered ready for general use. It will likely
become the default code generation mode once those limitations are
fixed and we have a minifier for it.
Аналогично, любая описка ведет к появлению новой сущности в программе, вместо генерации компиляционной ошибки.
С другой стороны, динамические языки мотивируют использовать TDD. Что бы быть уверенным в своем коде его нужно максимально покрыть тестами, что хорошо. Но с другой стороны я часто делаю опечатки в коде, что снижает мою производительность, часто программа запукскается в «холостую» до первой опечатки.
А суть что происходит вы уловили правильно. Это лишь общая схема показывающая как можно выдернуть конкретную функцию из libxml.
Для того что бы получить порт библиотеки нужно написать обертку для вызова каждой конкретной функции из libxml2. Выполнив команду:
Построится файл libxml2.js который будет содержать функции соответствующих статических библиотек, эти функции можно напрямую вызывать из JavaScript кода. Правда делается это не очень красиво, как-то так:
Пример показывает как обернуть c-функцию, подробнее тут.