User
На картинке представлен пример обработки одной и той же ошибки. В первом случае ("красный" квадрат) представлен результат стандартной обработки ошибки. Во втором случае ("зеленый" квадрат) представлен результат кодирования ошибок в событийной модели логирования. Помимо информативности текста ошибки для пользователя, мы можем реализовать сбор статистики возникновения ошибки, идентификацию места возникновения ошибки. О том как это можно сделать, постараюсь описать в данной статье.
Вы когда-нибудь задумывались, как вы думаете ? Все мыслительные процессы в нашем мозге можно разделить на блоки, алгоритмы, нейронные сети, но принцип один — есть входные сигналы с сенсоров, есть какая-то схема обработки информации, и наконец, есть выходные нейроны, отвечающие за движение всех мышц и регуляцию организма. Простая схема — вход, функция, выход. Входная информация, это информация из среды. Наше тело так же является средой для информационной функции нашего мозга. Вообще средой можно назвать всё, что даёт информацию мозгу. Мозг получает эту информацию из окружающего нас мира, а так же от сенсоров внутренних органов, а именно об их текущем и прошлом состоянии. Информация поступает постоянным плавным потоком в мозг и хранится в нем какое-то время, что даёт ему возможность взглянуть целиком на график за какой-то последний промежуток времени, а не только исключительно на текущий момент. Что ж, давайте подробно углубимся, куда эта информация поступает и как преобразуется. Я уверен, что эту схему поймёт даже 7 летний ребёнок, и это именно та универсальная формула интеллекта, которой пользуются все высшие организмы на земле.
Когда много-много лет назад писал диссер, я сделаль величайшее супер-пупер-открытие века! Люди, в большинстве, стремятся найти источник здоровья вне себя (т.е. зависимость от внешнего) — витамины или травы, природа или медтехника, более энергичные или веселые собеседники, очищенная или минеральная вода, сахарозаменители или мёд и т.д. Это, конечно, хорошее дело, но это не те дроиды, которых вы ищете! Печаль нам, реабилитологам, что здоровье именно внутри себя почти никто не взращивает. Особенно мало у нас инструментов защиты от чрезмерного эмоционального стресса, депрессии и всяких вирусов со сквозняками. А ведь есть давненько, веков 100—200 примерно, способы увеличения внутренних ресурсов вегетативной и центральной нервной системы до индивидуального максимума. Upgrade организма дающие возможность произвести то бишь психофизическими техниками саморегуляции. Они не обещают бессмертия или ясновидения, но можно почти совсем (максимально) не болеть и быстрее выздоравливать от всяких расстройств. Если только Вы сами не захотите их поиметь вновь.
Уильяма Шекспира знают без малого все. Не только в Британии, но и во всем мире. Это поэт №1 во всем мире.
А кто знает Александра Поупа? Британцы изучают его в университетах, но мы уверены, что среди читателей Хабра с его творчеством знакомы очень немногие. Поуп — это второй по цитируемости поэт в английском языке, автор переводов Гомера и создатель целого ряда идиом, которые сегодня считаются «народными».
А дядька-то на самом деле был очень крут. Поэтому сегодня расскажем именно о нем.
NB: это черновик двух новых глав моей книги, посвященной дизайну API. В тексте встречаются отсылки к предыдущим главам.
В предыдущих разделах мы старались приводить теоретические правила и принципы, и иллюстрировать их на практических примерах. Однако понимание принципов проектирования API, устойчивого к изменениям, как ничто другое требует прежде всего практики. Знание о том, куда стоит «постелить соломку» — оно во многом «сын ошибок трудных». Нельзя предусмотреть всего — но можно выработать необходимый уровень технической интуиции.
Поэтому в этом разделе мы поступим следующим образом: возьмём наше модельное API из предыдущего раздела, и проверим его на устойчивость в каждой возможной точке — проведём некоторый «вариационный анализ» наших интерфейсов. Ещё более конкретно — к каждой сущности мы подойдём с вопросом «что, если?» — что, если нам потребуется предоставить партнерам возможность написать свою независимую реализацию этого фрагмента логики.
Всем привет! За последние пять лет мы достаточно часто сталкивались с запросами на мониторинг Java приложений. Собрав основные моменты по мониторингу Java, мы решили написать данный пост.
Сегодня мы с вами рассмотрим, что такое Full Stack мониторинг и чем он отличается от привычного “уху” понятию мониторинга, нюансы Full Stack мониторинга для Java и сложности мониторинга микросервисных приложений на Java. Расскажем, как мы реализуем Full Stack мониторинг с помощью OpenSource стандартов и платной платформы.
Давайте определимся, что мы называем Full Stack мониторингом?
Full stack мониторинг – это подход в мониторинге производительности приложений, который подразумевает под собой мониторинг всего стека, что включает в себя:
Мониторинг приложений – сбор метрик приложения, сбор трейсов транзакций, обеспечение видимости на уровне кода и т.д.
Мониторинг инфраструктуры – метрики хостов, процессов, контейнеров и т.д.
Мониторинг конечных пользователей – сбор метрик с браузера пользователя, мобильного приложения, синтетические проверки и т.д.
Каждый раз сталкиваясь с различными классификациями баз данных и технологий, связанных с ними, я чувствовал недовольство структурой и подачей этого материала. В результате, я решил выложить свои заметки. Уверен, они могут быть полезны как для опытных специалистов с целью устранения пробелов в знаниях, в качестве отправной точки для изучения материала глубже, так и для подготовки к собеседованиям с обеих сторон.
Информация представлена без деталей намеренно, так как детали легко гуглятся или вычитываются из соответствующих книг.
Замечания и предложения приветствуются.
Предыдущая заметка получилась не такая, как я задумывал. Но вызвала небольшую дискуссию. Может быть и в этот раз получится подискутировать. Или получится не так. В любом случае хотелось бы продолжить воровать тексты у богатых и переводить их бедным, т.е. делиться с общественностью пусть даже иногда для кого-то очевидными вещами. «Поговорим за» динамическую память?
Эта статья о том, как извлечь максимум пользы из статической системы типов при дизайне вашего кода. Статья пытается быть language agnostic (получается не всегда), примеры на Java и взяты из жизни.
В статье показано, как быстро можно создать свой plugin для облегчения работы с Transactional в Spring. Писать будем на Kotlin и Java
Приветствую, это текстовая версия моего доклада на JPoint-2021. Как обычно я сделал упор на случаи из жизни и на повседневные вещи, используемые каждым разработчиком. Под кат приглашаются интересующиеся производительностью и им сочувствующие.
Представьте, что вы читаете текст и наткнулись на новую интересную фразу. Всегда ли вы знаете, как её правильно произнести и использовать в речи? Или, например, вы пишете письмо и не можете решить правильно ли использовали выражение. Эти ситуации типичны для изучающих английский. Что вы обычно предпринимаете? Скорее всего вы открываете гугл и, может быть, даже используете кавычки при поиске. Неплохая стратегия, но есть альтернативы получше. Меня зовут Дарья, я преподаю английский язык в EPAM, и в этой статье я расскажу про эффективные подходы и инструменты для поиска примеров использования лексики.
Функциональное программирование может отпугивать сложностью и непрактичностью: «Я далек от всех этих монад, пишу на обычном C#, в докладе про функциональщину ничего не пойму. А если даже напрягусь и пойму, где мне потом это применять?»
Но когда объясняет Скотт Влашин, все совершенно не так: его доклад о композиции с конференции DotNext 2019 Moscow — пример того, как можно доносить функциональные идеи простыми словами. Он за час перешел от бананов к монадам так, что второе кажется немногим сложнее первого. А в конце объяснил, почему осмыслить композицию полезно даже тем, кто не собирается покидать мир ООП. Примеры кода в докладе как на F#, так и на C#.
Уже завтра начнется новый DotNext, где я помогу Скотту выступить с другим докладом, а пока что публикую перевод его выступления про композицию. Далее повествование будет от лица Скотта.
В первой части вы узнали, что по веским причинам мы были вынуждены выбрать новый технический стек для дальнейшего развития нашего продукта. Пора перейти к самому интересному: что же мы будем использовать вместо Dart?
В 1998, когда Google только появился, его киллер-фичей был патентованный алгоритм PageRank для сортировки результатов поиска по популярности. Описанный стэнфордскими аспирантами Брином и Пейджем в научной статье, он сводится к очень простой идее:
Kodein видит в первый раз, а документация не во всех местах прозрачная и последовательная, поэтому хочу поделиться основными возможностями библиотеки с вами. Некоторые возможности библиотеки будут выпущены, но это в основном advanced часть. Здесь же вы найдете всё, чтобы по ходу чтения статьи нормально стартовать и начать внедрять зависимости с Kodein. Статья базируется на Kodein 5.3.0, так как Kodein 6.0.0 требует Support Library 28 или AndroidX и далеко не скоро все перейдут на них, так как многие сторонние библиотеки ещё не предлагают совместимых версий.