Комментарии 28
Круто! А как stacktrace читаете?
Ребята, вы уж не поймите вопрос неправильно, только в чём у вашего сервиса фишка, за которую хотелось бы платить деньги?
Некоторое время назад у меня возникла потребность логировать клиентские ошибки. Написал обработчик window.onerror, отсылающий информацию об ошибке на сервер, там я её мог хоть грепать, хоть загонять в БД и строить по данным графики. И мне даже в голову не пришло, что на этом можно сделать сервис — решение ведь очевидное.
Я, конечно, потестирую ваш сервис, может действительно эта фишка есть — но при беглом изучении сайта я таковой не обнаружил.
Некоторое время назад у меня возникла потребность логировать клиентские ошибки. Написал обработчик window.onerror, отсылающий информацию об ошибке на сервер, там я её мог хоть грепать, хоть загонять в БД и строить по данным графики. И мне даже в голову не пришло, что на этом можно сделать сервис — решение ведь очевидное.
Я, конечно, потестирую ваш сервис, может действительно эта фишка есть — но при беглом изучении сайта я таковой не обнаружил.
Фишка в группировках ошибок и стектрейсах. Например, одна и та же ошибка в разных версиях браузеров будет на разных языках
Я тоже не до конца понял. Версию браузера можно так-же скинуть в лог.
Потом отгрепать и понять че кого в конкретном браузере. Кроме того как бы не была описана ошибка — суть ее будет понятна — за бэкэндом же не робот сидит.
Ну или я действительно не понимаю…
Потом отгрепать и понять че кого в конкретном браузере. Кроме того как бы не была описана ошибка — суть ее будет понятна — за бэкэндом же не робот сидит.
Ну или я действительно не понимаю…
Группировка — ну не знаю, всё же можно грепом или выборкой из БД это порешать.
Стектрейсы — да, допускаю. Как могу представить, это практически единственный, хоть и не гарантированный, способ восстановить состояние страницы на момент возникновения ошибки.
Но по моему опыту в 95% случаев достаточно знать место ошибки и браузер, а дальше программист может и сам раскрутить что к чему.
А вот если бы было что-то вроде яндексового вебвизора, чтобы сервис показывал воспроизведение всех действий в окружении вплоть до возникновения ошибки (а как бонус, ещё и анализировал бы её причины) — вот на такое бы я купился. В смысле — заплатил бы, тут экономия времени очевидна.
Стектрейсы — да, допускаю. Как могу представить, это практически единственный, хоть и не гарантированный, способ восстановить состояние страницы на момент возникновения ошибки.
Но по моему опыту в 95% случаев достаточно знать место ошибки и браузер, а дальше программист может и сам раскрутить что к чему.
А вот если бы было что-то вроде яндексового вебвизора, чтобы сервис показывал воспроизведение всех действий в окружении вплоть до возникновения ошибки (а как бонус, ещё и анализировал бы её причины) — вот на такое бы я купился. В смысле — заплатил бы, тут экономия времени очевидна.
Фишка сервиса в репортинге, я так думаю, в аналитике и репортинге. Мало скинуть в лог, нужно это все еще сгруппировать и красиво показать.
А я всегда думал что фишка в том, что при падении ошибки в лог ее нужно смоделить и пофиксить и все.
И на красоту представления ошибок мне как-то фиолетово (ИМХО).
Главное — как можно быстрее пофиксить ее, поправить тесты, которые раньше ее не обнаруживали, еще раз их прогнать, проверить и выкатить новую пофиксенную версию в продакшн, чтобы не заставлять ждать конечного пользователя.
И на красоту представления ошибок мне как-то фиолетово (ИМХО).
Главное — как можно быстрее пофиксить ее, поправить тесты, которые раньше ее не обнаруживали, еще раз их прогнать, проверить и выкатить новую пофиксенную версию в продакшн, чтобы не заставлять ждать конечного пользователя.
Я вам еще дам тему для непонимания. Люди еще и для сервер сайда такое используют, splunk например. А вообще, вот это скинуть, грепать, БД, графики это же все равно надо реализовывать, дать для этого инфраструктуру. Часто проще купить.
Ну splunk, по моему опыту, ставится при очень сильной фрагментации (реализаций множество — например под разные системы win/linux/и т.д.) + когда функционал очень сложен, либо же, когда имеются множество систем, объедененных в одно целое.
Он позволяет сократить время на анализ среди кучи реализаций, или кучи систем, генерирующих абсолютно разные логи, каждая в своем формате.
Ошибки там ооочень часто привязаны именно к среде/железу/системе + он эффективен, когда вариантов множество, код сложен и т.д.
Здесь же все работает в рамках браузера — т.е. гораздо более узкая область.
Да, могут быть конечно ошибки связанные с системой (Android / PC / IOS), но это все очень легко детектится да и логика приложений в большинстве случаев достаточно проста, а реализация (JS/HTML/Server-side) обычно одна на все варианты + логи ошибок (как и ошибки) стандартны, хоть и могут отличаться «написанием».
Если в этом случае использовать такой вот «splunk» — это как из гаубицы по воробьям стрелять.
Хотя, быть может есть другой опыт у кого-либо — я не долго этот инструмент использовал.
Он позволяет сократить время на анализ среди кучи реализаций, или кучи систем, генерирующих абсолютно разные логи, каждая в своем формате.
Ошибки там ооочень часто привязаны именно к среде/железу/системе + он эффективен, когда вариантов множество, код сложен и т.д.
Здесь же все работает в рамках браузера — т.е. гораздо более узкая область.
Да, могут быть конечно ошибки связанные с системой (Android / PC / IOS), но это все очень легко детектится да и логика приложений в большинстве случаев достаточно проста, а реализация (JS/HTML/Server-side) обычно одна на все варианты + логи ошибок (как и ошибки) стандартны, хоть и могут отличаться «написанием».
Если в этом случае использовать такой вот «splunk» — это как из гаубицы по воробьям стрелять.
Хотя, быть может есть другой опыт у кого-либо — я не долго этот инструмент использовал.
Домашнему сервису на который ходят только друзья, конечно, нет причин платить за сервис, но он и укладывается в бесплатные лимиты. Если же у вас серьезный веб-сервис с большим количеством пользователей, то и поток ошибок будет большой. И Вы неизбежно столкнетесь с тем что при нескольких десятках тысяч ошибок в день (для этого достаточно сотни тысяч пользователей) список ошибок для вас абсолютно бесполезен без какой-либо агрегации, фильтрации, группировки, сортировки и более умного анализа. Просто лог — бесполезен, в нем слишком много шума, произвольная выборка из базы на реальных данных не спасет, даже если Вы гуру регулярных выражений. Вот именно за это и готовы платить: за возможность анализировать ошибки в реальных системах, где ошибок случается много. И еще немного готовы платить за дополнительный и гибкий интеллект аналитики.
Разумеется, вообще все можно сделать ручками (хотя разработчики тоже люди и грепать удобно далеко не всем, именно поэтому появляются и набирают популярность SaaS). В частности, это я хочу упомянуть когда напишу про разницу менталитетов в России и США. В России не всегда принято считать стоимость времени разработчика. На написание своего движка логов в хоть сколько-нибудь удобном для использования виде (чтобы потом не тратить часы на анализ сырых логов), вы потратите несколько дней (просто записывать логи в базу можно и за час, но в реальной системе этот лог будет абсолютно бесполезен). Несколько дней работы разработчика стоят намного дороже, чем обойдется использование готового инструмента. Тем более, чтобы начать использовать готовое, достаточно подключить, а свою систему надо сначала разработать. На западе это понимают и платят.
Можно и Google Analytics самостоятельно написать, это несложно. А потом хоть графики по этим данным строить, хоть грепать. Одна проблема: это надо делать, а делать стоит времени и денег. И это неудобно, в отличие от прекрасной готовой гугл-аналитики. Скорее всего мы просто недостаточно хорошо объясняем в чем основная ценность нашего сервиса, она вовсе не в том что мы визуализируем лог ошибок.
Разумеется, вообще все можно сделать ручками (хотя разработчики тоже люди и грепать удобно далеко не всем, именно поэтому появляются и набирают популярность SaaS). В частности, это я хочу упомянуть когда напишу про разницу менталитетов в России и США. В России не всегда принято считать стоимость времени разработчика. На написание своего движка логов в хоть сколько-нибудь удобном для использования виде (чтобы потом не тратить часы на анализ сырых логов), вы потратите несколько дней (просто записывать логи в базу можно и за час, но в реальной системе этот лог будет абсолютно бесполезен). Несколько дней работы разработчика стоят намного дороже, чем обойдется использование готового инструмента. Тем более, чтобы начать использовать готовое, достаточно подключить, а свою систему надо сначала разработать. На западе это понимают и платят.
Можно и Google Analytics самостоятельно написать, это несложно. А потом хоть графики по этим данным строить, хоть грепать. Одна проблема: это надо делать, а делать стоит времени и денег. И это неудобно, в отличие от прекрасной готовой гугл-аналитики. Скорее всего мы просто недостаточно хорошо объясняем в чем основная ценность нашего сервиса, она вовсе не в том что мы визуализируем лог ошибок.
И по опыту реально в лог сыпится куча РАЗНЫХ ошибок?
Просто было у нас, что валились десятки тысяч ошибок — виной тому стала библиотека, не подгружавшаяся с зависшего CDN-а.
Выдернуть из лога первую ошибку (потому как, чтобы понять как сыпется, надо начать с первой ошибки, т.к. остальные могут быть уже следствием) для каждого пользователся по таймстампу и уникальному тексту обычным регспом ушло 15 минут и дальше вместо 100000 строк лога у нас было 3 разных текстовых версии одной ошибки. Все.
Я не в коем случае не хочу сказать что сервис плох — хочу понять кто использует и зачем, чтиобы потом это применять в дальнейшем, если будет нужно.
Просто было у нас, что валились десятки тысяч ошибок — виной тому стала библиотека, не подгружавшаяся с зависшего CDN-а.
Выдернуть из лога первую ошибку (потому как, чтобы понять как сыпется, надо начать с первой ошибки, т.к. остальные могут быть уже следствием) для каждого пользователся по таймстампу и уникальному тексту обычным регспом ушло 15 минут и дальше вместо 100000 строк лога у нас было 3 разных текстовых версии одной ошибки. Все.
Я не в коем случае не хочу сказать что сервис плох — хочу понять кто использует и зачем, чтиобы потом это применять в дальнейшем, если будет нужно.
Ок, спасибо за ответ, как я понял — у вас всё-таки имеется аналитика, это интересно. Ещё интереснее будет, если напишете пост с демонстрацией полезности инструмента на примерах, хотя бы подобных реальным. Я вот, как не силюсь, не могу представить какой же должен быть проект, чтобы мне не хватало моего, за пару часов написанного, отладчика. Тем более, что чем больше и серьёзнее проект, тем тщательнее он должен отлаживаться перед запуском.
Я вот также думал про MailChimp (зачем использовать какой-то там платный сервис, когда у нас есть функция mail() и БД)… пока не попробовал его ))
Думаю, тут можно аналогию провести между «сделать что-то непрофильное самому» и «нанять специалиста».
Впрочем, сам я отправляю js-ошибки через window.onerror в гугл.аналитику ;)
Думаю, тут можно аналогию провести между «сделать что-то непрофильное самому» и «нанять специалиста».
Впрочем, сам я отправляю js-ошибки через window.onerror в гугл.аналитику ;)
А как убеждаете доверять вам? Мне кажется это самый интересный момент — не каждый хочет делиться ошибками =)
«Ели маффин мужики..»
Пользовался где-то год назад, отличный проект, спасибо ребята.
Было одно неудобство — отсутствие source maps — ведь код все равно жмется. Сейчас их можно использовать?
Было одно неудобство — отсутствие source maps — ведь код все равно жмется. Сейчас их можно использовать?
Отличный проект, скоро будем внедрять у себя.
+100500, узнал себя в этом абзаце =)
В Менло Парк же беда с тротуарами, периодически они отсутствуют :( и от этого очень неудобно передвигаться пешком.
Приятно было с вами познакомиться на RIW, удачи!
Надо разбираться в размытии акций, конвертируемых займах, настройках nginx, какие бывают конференции по вашей теме, удобстве формы регистрации, сколько денег отправлять в пенсионный фонд и том в какое время лучше публиковать новости. Не просто разбираться, а все это делать. Каждый день: гуглить про акции, вычитывать километровые договоры, писать тексты вакансий, придумывать сценарий видеоролика, подробно прорабатывая каждую сцену, придумывать улучшения очередной версии логотипа, печатать баннер для демо-стенда на мероприятии, самостоятельно создав для него дизайн, выступать с презентациями, созваниваться с банком, ходить на почту отправлять документы, отвечать в твиттере на вопросы про сервис, следить за обновлениями конкурентов, список можно продолжать бесконечно.
+100500, узнал себя в этом абзаце =)
На машине, конечно, тоже экономили, поэтому частенько ходили полчаса до ближайшей станции Caltrain
В Менло Парк же беда с тротуарами, периодически они отсутствуют :( и от этого очень неудобно передвигаться пешком.
Приятно было с вами познакомиться на RIW, удачи!
Супер! Искренне желаю вам успеха! :)
я так и не понял, чем это лучше связки sentry + raven
Как-то поставил себе qbaka, запустил… И волосы на голове зашевелились — столько различных ошибок начало сваливаться.
К сожалению в основном фаерволы резали файлы исполняемые.
К сожалению в основном фаерволы резали файлы исполняемые.
Всегда был интересен один момент. У меня есть стартап, все ок, я хочу в Штаты. Какую визу я могу получить на основе своего стартапа, нужно ли приглашение от акселератора/инкубатора и сколько я там могу находиться?
В штатах прошла сенат инициатива стартап-визы, правда для нее, кажется, нужно получить инвестиции, подробнее не следил. Надо детально читать, ее вроде пока еще не приняли, но должны были скоро принять.
В остальном, есть три основных способа попасть в штаты по делам стартапа.
1. Рабочая виза, как во всех крупных компаниях. Регистрируется компания в США (это делается через интернет за 15 минут). Далее в весной конкурс на квоты — надо успеть в первые день-два в числе других крупных компаний подать заявку на рабочую визу для себя же. Количество таких виз ограничено, разбирают за пару дней, а работать можно начиная с осени. Это H1B, действует долго, стоит дорого (несколько тысяч долларов).
2. Виза для топ-менеджеров компаний, у которых есть юрлицо в США и в другой стране, и эти компании связаны. Нужно минимум год (не уверен, но вроде даже без поездок в штаты) проработать на должности CEO, CTO, итп в компании, которая не в США, но связана с компанией в США (например, дочерняя, можно американской компанией поглотить русскую). Тогда можно делать специальную визу для сотрудников, который отправили управлять представительством в США. Тип визы L1, действует долго, тоже относительно дорого из-за юридической возни.
3. Короткая бизнес-поездка. Которая B1/B2, то есть туристическая + бизнес. Чтобы быть в штатах долго, нужно приглашение от акселератора или любая другая уважительная и убедительная причина именно долгого пребывания, иначе потом могут быть сложности в въездом. С акселератором легко быть, например, 4 месяца из 6. Самому я бы не рекомендовал приезжать дольше, чем на месяц-два, 3 — край. Несмотря на то что могут позволить въезд на 6 месяцев.
В остальном, есть три основных способа попасть в штаты по делам стартапа.
1. Рабочая виза, как во всех крупных компаниях. Регистрируется компания в США (это делается через интернет за 15 минут). Далее в весной конкурс на квоты — надо успеть в первые день-два в числе других крупных компаний подать заявку на рабочую визу для себя же. Количество таких виз ограничено, разбирают за пару дней, а работать можно начиная с осени. Это H1B, действует долго, стоит дорого (несколько тысяч долларов).
2. Виза для топ-менеджеров компаний, у которых есть юрлицо в США и в другой стране, и эти компании связаны. Нужно минимум год (не уверен, но вроде даже без поездок в штаты) проработать на должности CEO, CTO, итп в компании, которая не в США, но связана с компанией в США (например, дочерняя, можно американской компанией поглотить русскую). Тогда можно делать специальную визу для сотрудников, который отправили управлять представительством в США. Тип визы L1, действует долго, тоже относительно дорого из-за юридической возни.
3. Короткая бизнес-поездка. Которая B1/B2, то есть туристическая + бизнес. Чтобы быть в штатах долго, нужно приглашение от акселератора или любая другая уважительная и убедительная причина именно долгого пребывания, иначе потом могут быть сложности в въездом. С акселератором легко быть, например, 4 месяца из 6. Самому я бы не рекомендовал приезжать дольше, чем на месяц-два, 3 — край. Несмотря на то что могут позволить въезд на 6 месяцев.
Надо разбираться в размытии акций, конвертируемых займах, настройках nginx, какие бывают конференции по вашей теме, удобстве формы регистрации, сколько денег отправлять в пенсионный фонд и том в какое время лучше публиковать новости. Не просто разбираться, а все это делать. Каждый день: гуглить про акции, вычитывать километровые договоры, писать тексты вакансий, придумывать сценарий видеоролика, подробно прорабатывая каждую сцену, придумывать улучшения очередной версии логотипа, печатать баннер для демо-стенда на мероприятии, самостоятельно создав для него дизайн, выступать с презентациями, созваниваться с банком, ходить на почту отправлять документы, отвечать в твиттере на вопросы про сервис, следить за обновлениями конкурентов, список можно продолжать бесконечно.
По вашим ощущениям, какая доля из данных мероприятий связана с тем фактом, что вы ищете инвесторов и у вас усложнен маркетинг из-за фокуса на B2B? Если сфокусироваться на B2C и не искать инвестора, будет намного легче?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кубака. Два года из жизни лемура. Год 2012: Погружение