Pull to refresh

Comments 36

ну надо тогда смотреть. Делать тестирование и сравнение.
Кстати хотел спросить Вы сами рисовали интерфейс? или использовали какую-то тему?
Уже 8 месяцев тестируется на «Monkey» — проект, куда хуки с ресурсов складываются. И вроде наплывы выдерживал :)

По поводу интерфейсов.
Сам веб для плагина делал дизайнер Тимур Прокопьев (http://pojitonov.blogspot.com/), а для официального сайта заюзал foundation.zurb.com/.
Кассандра вроде нужна, когда информация исчисляется не гигабайтами, а терабайтами.
Кстати я смотрю asset pipeline не используется. Было бы удобнее.
там внутри нет рельсов, там sinatra. это маунтится к рельсам :)
так а смысл если в доке описываются только рельсы.
веб можно запускать без рельсов за надобностью, как rack приложение :)
MongodbLogger is a alternative logger for Rails 3 — как бэ говорит за себя :) Что расчитано на рельсы.
Возможно я неверно понял вопрос про «asset pipeline» :)
ну просто вы его позиционируете как логгер для рельсов и внутрь пихаете просмотрщик на синатре.
Тогда выкусывайте его как сделали в central_logger
Ну логирует он Rails запросы, тоесть функционал для Rails :) А веб так сделан для удобного внедрения в Rails приложение.
хм… для удобного внедрения в Rails приложение используется Sinatra… Оригинально…
А помоему Вы просто видоизменили central_logger, но не смотрели что они веб-клиент просто вынесли как отдельное приложение.
Для начала просто гляньте на их веб, а потом на мой.
Просто видоизменить — это недостаточно. Там многое переписано и написано заново, покрыто тестами, которые тестируют github.com/le0pard/mongodb_logger/blob/master/SUPPORTED_RAILS_VERSIONS данные версии рельсов с логгером. Так что работы проделано достаточно много.

P.S. Для Resque (https://github.com/defunkt/resque) тоже веб написан на Sinatra и маунтится в роутах. И ниче, работает :)
Да только resque был сделан отвязаным от рельсов.
И что-то я не увидел что бы многое было переписано в вашей версии.
Где диф тестов, веб морды и скриншиты вебов для сравнения?
У меня в библиотеке более чем три файла, я не вижу остальные дифы…

Скажем так, кормить троля мне не сильно хочется. Если Вам не нужно — не пользуйтесь. Если нужно, но данное решение не нравися — пишите свое, но то оно и опен сорс. Это решает любые проблемы.
Я не троль. Я хочу сказать о том что не пишите что это ВАША разработка, если вы дописали только тесты, веб морду или что-то еще. Вы вообще не сказали что ВАША разработка базируется на коде другой разработки
Называется: «я открываю для себя Рельсы за пределами блога-за-15-минут». Веб-интрефейсы для сложных сущностей, например, как упомянотый Resque, практика столь же обыденная, как и полезная.
Какая разница на чем он сделан? Тем более его хотя бы сделали :)

Resque вполне спокойно имеет консоль управления на синатре, и никто не жалуется.
А есть возможность добавлять meta информацию, например user_id и тп, как в github.com/customink/central_logger?
Как раз подумывал о централизированном сервере логов, в котором было бы удобно проследить запросы конкретного юзера
Конечно, куда без этого. Он основан на central_logger, тоесть мигрировать можно без проблем.
Забыл сказать что её можно не только добавлять, но и искать через веб, используя дополнительный фильтры.
Попробовал. Неплохо, но есть некоторые замечания

1. В правой панельке метаинформация зашита жестко: например, если я добавляю user_id, то не вижу ее там
2. Тоже самое в «More Info»
3. Если применить фильтр, то в «More info» кнопка «Back» возвращает назад ко нефильтрованному списку

А за труд спасибо.
Можно нажать «Back» в браузере — фильтр сохранится.
С мета информацией спасибо, как раз добавим отображение.
Мета информация добавленна пока в «More Info» в версии 0.2.1
Еще пожелание: отображение содержимого всех записей по фильтру. Т.е. например я отфильтровал по пользователю, заходить в каждую запись — не удобно, было бы гораздо удобней видеть все содержимое всех этих записей сразу
Можно поподробнее в личку? я не все понял.
Я всегда думал, что в монго стоит хранить в основном только очень часто используемые данные, зачем же туда складывать логи, только из-за того что в монго их складывать удобнее? :)
Пункты в статье указаны, почему MongoDB.

«очень часто используемые данные» — я не знаю, что это значит в вашем понимании, но Я кладу очень часто используемые данные в Redis или MemcacheDB, поскольку они точно будут быстрее MongoDB в подобном случае.

P.S. Повторяю линку для Вас: blog.mongodb.org/post/172254834/mongodb-is-fantastic-for-logging?91e05470
Sign up to leave a comment.

Articles