Pull to refresh

Comments 27

Тоже используем подобную самописную штуку, хотя у нас она даже больше похоже на отдельно стоящую библиотеку, чем у вас. Вашу внедрять не захочется, потому что слишком много махинаций нужно делать.
И, кстати, есть сервисы готовые по сбору ошибок и логов, в основном платные, конечно.
В нашем случае это часть ядра, что даёт больше возможностей для сбора отладочной информации.
А что происходит с отловленными ошибками дальше? Загорается какая-то лампочка в админке, и какие-то дежурные разбираются в ситуации?
И что будет, если в релизе выкатится фатальная ошибка какой-нибудь жутко популярной ручки, не заддосит ли ваш механизм сбора ошибок?
У нас построена таким образом, что все ошибки хранятся на отдельном сервере, который не жалко положить. А сама система сбора ошибок учитывает что сервер может лежать и просто не пишет в него (потому что если начался ддос ошибками, то значит саму ошибку уже записали). PS: я к либе из данного поста отношения не имею, я про свои решения)
Лампочка в админке. Только без дежурных программистов, поднятых по тревоге.

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

Поддерживаю, вот эта тема гораздо интереснее самого отлова ошибок. Как сделать редукцию и определять однотипные ошибки от разных пользователей? Что бы писать в базу не весь поток а тупо первый десяток инцидентов, а потом лишь собирать статистику если она нужна (число инцидентов, версии пользователей и все такое)

Мне кажется как-то жирно для ошибок, которые могут ни когда не произойти, держать постоянно открытое вебсокет соединение и тянуть не маленькую библиотеку socket.io.
Всё, конечно, зависит от загруженности сервиса. Возникает идея сделать возможным сбор ошибок по запросу (в т.ч. на продакшне).
Скорее всего вебсокеты используется не только для передачи ошибок, но и в основном «цикле» работы приложения.
socket.io используется нами как основной канал для api сервера, т.к. мы пишем RIA Отсюда и выбор.
При желании можно спокойно переписать на динамику.

А для каких конкретно браузеров сейчас есть необходимость в socket.io? Чем плох стандартный WebSocket?

Эммм вы о чем?! А socket.io это что марсианские почтовые голуби? Он его и использует + пердоставляет прозрачный даунгрейд канала в случае если его использование невозможно к примеру браузер не умеет WebSocket
Он его и использует

Я в курсе. Но socket.io, кроме этого, тянет ещё килограмм зависимостей и строит фаллбэки для поддержки того, что давно умерло.


к примеру браузер не умеет WebSocket

Пример браузера приведите, пожалуйста.


Как раз суть в том, что для этого тянуть большой и страшный сокетио уже не надо — всё работает и так, и более стабильно.

caniuse гляньте, Вам лень что ли? Ослы, как обычно. И как обычно — их поддержка обязательна у корпоративных заказчиков.

Мне не лень, я хочу, чтобы вы своими глазами посмотрели и убедились, что там только ие9 из десктопных. Который уже не поддерживается MS, если у вас не Vista. Плюс очень старые мобильные времён iOS 5.

Ага, и не очень старые и гораздо более (чем iOS5) распространенные андройды 4.3 и ниже. Но вообще думается вы правы, привычка она такая.

4.3 это не все андроиды. Это штатный андроид браузер версии 4.3. У всех версий штатного андроид браузера целиком — 9% в русскоязычном сегменте, всё остальное — хром. Причём надо ещё смотреть, какая часть из этого — 4.3, ими вообще скорее как звонилками пользуются.

Если к Вам заказчик придет с XP-ой — Вы его заказ будете выполнять или рассказывать ему что он дебил недальновидный человек и ему как минимум надо поменять безопасника а заодно обновить систему? На паре тысяч компов во всех офисах.

Я откажусь работать. А если у них пни первые и NovellNetware или OS/2 или табуляторы? Мне что работать с ними? Зачем? XP это сим-сим ей уже 15 лет так-то. XP в 2016 — это шиза и для внедрения и разработки нового продукта требуется иметь подходящую инфраструктуру. Это техничесоке требование типа мощности электросети или предельной нагрузки на перекрытия, это же не просто хотелка.

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

Позвольте не согласиться (да я руководитель).
Опыт и практика показывают, что при таком подходе проект заранее провальный — т.к. всем наплевать на проект причем и заказчику и исполнителю (продажникам и руководству как минимум).
Заказчику, потомучто сейчас не 90ые, и если с IT все настолько плохо и нет вариантов изменить ситуацию, то и с другим такаже все печально(а значит будет — постоянное недофинансирование, нарушения договоров, «получилось как всегда», невозможность реализации эффективной работы на имеющемся и прочее, прочее, прочее, и виноват будет всегда исполнитель — тыж программист, профессионал).
Исполнителю, потомучто если ваш руководитель настолько алчный идиот, во-первых потомучто поддержка настолько устаревших систем это ДОРОГО (т.к. требует более редких спецов и гораздо больше человекочасов), а это значит компания меньше заработает, во-вторых он не понимает то что я написал про заказчика а значи сидит не на своем месте.
А когда все наплевать ожидать успешной реализации проекта не стоит + куча дополнительных факторов (трудоемкость, неинтересность, сложность, высокая вероятность аварий, неспособность переварить объемы информации и тп).
В любых дургих конфигурациях такой проект просто не начнется.

Ок — давайте понятнее, если перекрытия в здании не расчитано на на новое оборудование то он рухнут. Если подключать станок 380V/50A к сети 220V/20A ничего не заработает. Тут тоже самое, winXP это слишком древняя система. Если у предприятия для нового проекта IT-инфраструктура не годится для реализации проекта ничего хорошего тоже можно не ждать — не взлетит.

Более того если нет возможности изменить ситцуациию или не уволиться, а остаться в таком чудо проекте то есть очень серьезный шанс что обвинят в провале именно вас, и шанс этого и степень порчи репутации на ПОРЯДОК больше чем в ситуации которую описали вы.
Кроме старых браузеров бывают еще прокси…
Но socket.io, кроме этого, тянет ещё килограмм зависимостей и строит фаллбэки для поддержки того, что давно умерло.

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

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

Большой Список Обязательных Зависимостей
accepts@1.1.4
after@0.8.1
arraybuffer.slice@0.0.6
backo2@1.0.2
base64-arraybuffer@0.1.2
base64id@0.1.0
benchmark@1.0.0
better-assert@1.0.2
blob@0.0.4
callsite@1.0.0
component-bind@1.0.0
component-emitter@1.1.2
component-emitter@1.2.0
component-inherit@0.0.3
debug@0.7.4
debug@2.2.0
engine.io-client@1.6.11
engine.io-parser@1.2.4
engine.io@1.6.11
has-binary@0.1.6
has-binary@0.1.7
has-cors@1.1.0
indexof@0.0.1
isarray@0.0.1
json3@3.2.6
json3@3.3.2
mime-db@1.12.0
mime-types@2.0.14
ms@0.7.1
negotiator@0.4.9
object-component@0.0.3
options@0.0.6
parsejson@0.0.1
parseqs@0.0.2
parseuri@0.0.4
socket.io-adapter@0.4.0
socket.io-client@1.4.8
socket.io-parser@2.2.2
socket.io-parser@2.2.6
socket.io@1.4.8
to-array@0.1.4
ultron@1.0.2
utf8@2.1.0
ws@1.0.1
ws@1.1.0
xmlhttprequest-ssl@1.5.1
yeast@0.1.2

Это всё обязательно поставится при установке socket.io текущей версии. Включая две версии ws. Часть из этого любит ломаться при обновлении, потому что привязано к нативным модулям. Причём они это чинят далеко не сразу, и это даже почему-то иногда в issues Node.js приносят:



Часть из этого — из-за старого ws, который они долго обновляли по своей цепочке зависимостей — посмотрите время между фиксом руками и реальным исправлением тикета.


Плюс оно в каки-то версиях при установке тянуло блобы (и в один чудесный момент установка сломалась так как сервер ой), не знаю, как сейчас:



Кроме этого, у сокетио есть некоторые проблемы, которые сказываются в т.ч. на других проектах (например, karma — https://github.com/karma-runner/karma/issues/1788).


А используют сокетио, главным образом, из-за реализованных механизмов комнат, нэмспесов, решенных вопросов с масштабированностью и тому подобному.

Первые два — тривиальны и нет смысл ради этого тащить кило чёртовщины, а про масштабированность можно поподробнее? Что он делает, что невозможно на вебсокетах? Хотелось бы узнать, так как внутри он использует именно вебсокеты.

Что он делает, что невозможно на вебсокетах? Хотелось бы узнать, так как внутри он использует именно вебсокеты.

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

Первые два — тривиальны и нет смысл ради этого тащить кило чёртовщины, а про масштабированность можно поподробнее?

Комнаты тривилальны пока нет необходимости масштабировать, но вряд ли миллион ваших пользователей будут комфортно себя чувствовать на одном ядре, или даже на одном сервере. Когда сообщениями через ваше приложение будут обмениваться пользователи, которых волею судьбы занесло на разные процессы или сервера, то придется решать этот момент. Не сказать, что это сложная задача, иметь готовые решения весьма не плохо.
Для устаревших. Специфика проекта предполагает возможность работы на устаревших браузерах, в т.ч. мобильных(медленно, глючно, но если человек хочет — нам не жалко). И это не говоря о том что socket.io одна из самых популярных библиотек по работе с WebSocket, даже если понижения канала не происходит.
И это не говоря о том что socket.io одна из самых популярных библиотек по работе с WebSocket, даже если понижения канала не происходит.

Ага. глючная и постоянно отваливающаяся при обновлениях.


по работе с WebSocket

Неа. Внутри она всё равно ws использует, по работе с вебсокетами самый популярный — ws. А сокетио предоставляет фаллбэк, который не особо-то и нужен в большинстве случаев, плюс за некоторую цену.


Специфика проекта предполагает возможность работы на устаревших браузерах,

Хорошо, с этим соглашусь, если у вас действительно такие требования — есть смысл. Но ие9 совсем-совсем умер, вообще-то.

Sign up to leave a comment.

Articles