скришнот из metal slug 3

2020 год — это определенно год странностей. Мой код тоже часто включает в себя некоторые странные ошибки. И в данном посте я хочу показать вам несколько методов отладки кода на языке julia.

Мы изучаем использование Sentry с React.

Эта статья является частью серии, начинающейся с сообщения об ошибках Sentry на примере: Часть 1.

Sentry — трекинг java exception в Java

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

Sentry — инструмент мониторинга исключений (exception), ошибок в ваших приложениях.

Преимущества использования Sentry:

• не нервничать при размещении приложений на боевом сервере,
• быстро находить причины возникших проблем,
• устранять баги раньше, чем о них вам сообщат тестировщики, коллеги из саппорта, пользователи, ПМ или директор,
• выявлять незаметные остальной команде проблемы, которые портят жизнь пользователям и снижают эффективность вашего продукта,
• бесплатен,
• легко интегрируется в проект,
• ловит ошибки и в браузере пользователя, и на вашем сервере.
• Если в ELK один и тот же exception происходит несколько раз, то они идут как отдельные записи, занимают место на диске и в ОЗУ. Если в Sentry один и тот же exception происходит несколько раз, то поле EVENTS увеличивается, тем самым экономя место на диске и в ОЗУ.
  
  Пример
  
  

Сборка sentry и его зависимостей в rpm. Установка sentry из rpm, базовая настройка.

Описание

Sentry — инструмент мониторинга исключений (exception), ошибок в ваших приложениях.

Преимущества использования Sentry:

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

• когда запись в файл — консоль драматически сказывалось на воспроизодимости бага;
• когда мульти(процессорное/поточное) приложение часто обращается к драйверу и ты не можешь сопоставить временные метки и потоки;
• когда баг воспроизводится на стороне кастомера, сеанс teamviewer бесполезен, да к тому же версия с отладочными символами private;
• когда системное приложение падает до того, как система успеет скинуть логирование на диск;
• или когда макрос для логирования выглядит в лучшем случае как

  #define TraceDbg(format, ...) \
      printf( "(p %d, t %d) - (%s,%d) %s(): " format, GetCurrentProcessId(), GetCurrentThreadId(), __FILE__, __LINE__,__FUNCTION__, __VA_ARGS__ );
  

• когда придумываешь очередной способ вывести на экран ipaddr или UUID

Pyroscope — это мощный инструмент непрерывного профилирования, созданный для мониторинга производительности приложений в реальном времени. В этой статье мы рассмотрим, как быстро развернуть Pyroscope, подключить к нему Node.js приложение и проанализировать поведение кода без использования Grafana Alloy.

Вообще наша компания занимается разработкой смартфонов и софта к ним для слепых и слабовидящих. Но порой возникают ситуации, когда приходится отлаживать не только свои приложения, но и разбираться с чужими. Обычно это происходит в случае, когда приложение глючит или не работает вовсе именно на наших телефонах. Поскольку наша аппаратная платформа не похожа на традиционные Android-смартфоны да и сам код фреймворка доработан рашпилем, мы готовы к подобным сюрпризам. Так случилось и в этот раз. Клиент жаловался, что у него есть проблемы с login-ом в одну из online-библиотек с аудио-книгами через Android-приложение. Поддержка попросила меня разобраться, есть ли в этом наша вина, или же нет.

О процессе отладки я буду рассказывать в хронологической последовательности, как она происходила в жизни, а не с "точки зрения вечности". Надеюсь, это поможет читателю лучше понять историю моих озарений и провалов. Заранее предупрежу, что я пытался двигаться к цели не углубляясь в причины неудачи тех или иных шагов. Если подход "в лоб" в каком либо варианте не срабатывал, я откладывал этот вариант, и переходил к другому. Название каждого раздела соответствует трудности, с которой я столкнулся. Итак, начнем.

Всем привет! Меня зовут Соня Гусева, я фронтенд-разработчик в Яндекс Практикуме (или фронтенд-капибара). Вместе с командой мы развиваем платформу practicum.yandex.ru. Например, сделали поиск по пройденным материалам — тот самый, где «найдётся всё». И тёмную тему — для комфортной учёбы даже ночью.

Практикум появился в 2019 году и с тех пор растёт. В какой-то момент нам стало сложно погружать новичков в проект. Дело в том, что стиль кода всё время развивался, но правила оставались на уровне устных договорённостей. В итоге приходили новые тиммейты, видели легаси и более свежий код — и не понимали, какой написан правильно и почему они разные. Как следствие, код-ревью растягивалось, и тестирование проходило в разы сложнее. Люди чувствовали себя неуютно в таких процессах. 

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

Если вы любите больше смотреть, а не читать, с этой темой я выступила на Frontend meetup, где рассказала подробно о внедрении стиля кода в проекты. 

Загрузка контроллера Teensy, подключенного к компьютеру через СОМ порт при отсутствии других Teensy, не вызывает затруднений. Однако, загрузка одновременно-подключенной группы контроллеров Teensy может оказаться проблематичной [1,2,3,4]. Варианты решения этой проблемы обсуждаются ниже.

Привет! Меня зовут Альберт, я занимаюсь iOS-разработкой в компании SimbirSoft! Хочу поделиться инструментами для дебаггинга iOS-приложений, которые юзаю лично сам. Любой разработчик наверняка знает, что создание высококачественного приложения требует не только написания кода. Одна из важнейших составляющих достижения успеха в этом деле — эффективная отладка. К счастью, существует множество инструментов, которые помогут быстро и эффективно диагностировать, а также устранять проблемы. В этой статье мы подробно рассмотрим нативные и сторонние инструменты, доступные для отладки iOS-приложений, как использовать эти инструменты для диагностики и устранения распространенных проблем. Если интересно, тогда ныряйте под кат.

Привет, Хабр! Меня зовут Алексей Гмитрон, я наставник на курсе «Веб-разработчик» Практикума, а также работаю фулстек-разработчиком. 

Я начал программировать шесть лет назад, и обучение не сразу давалось легко. Одна из главных проблем — не умел выяснять, почему мой код не работает. Это долго тормозило развитие, но когда я начал понимать принцип, как думать при поиске ошибок — процесс сдвинулся с мертвой точки. 

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

Эта статья предназначена для тех, кто только недавно научился писать свои первые программы на JavaScript и испытывает трудности при поиске багов. Статья не столько, не про конкретные инструменты и вкладки в DevTools, сколько про то, о чём думать и куда смотреть при отладке.

Методы отладки

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

Всем, привет!

В статье я хотел бы рассказать об одном из подходов к логированию приложения, который сильно помогал мне и коллегам при отладке, поиске ошибок и анализе проблем производительности. Про необходимость логирования было написано множество хороших статей в том числе и на Хабре, поэтому здесь нет большого смысла повторяться. Я начинал карьеру в IT с Oracle и изучал эту БД по книгам главного эксперта — Тома Кайта. Мне запомнилась его фраза по поводу логирования из книги "Effective Oracle by Design":

Instrumentation is not overhead. Overhead is something you can remove without losing much benefit. Removing (or not having) instrumentation takes away considerable functionality. You wouldn’t need to do this if your systems never break, never need diagnostics, and never suffer from performance issues. If that is true, you don’t need to instrument your system (and send me your email address, because I have a job offer for you).

С работой над Oracle проектами всё и началось.