Архив рубрики: О программировании

Разбираемся с Microsoft Bot Framework

Маленький Бендер

Так как конторский CI/CD висит на мне, то натурально я заинтересован в том, чтобы билд оставался зелёным. Не то, чтобы я тут же бросался к каждому упавшему тесту, но за ненадёжными точно присматриваю.

Когда ветка master держится красной чересчур уж долго, вот какие штуки начинают творится с её упавшими тестами:

  1. Ищем историю падений теста в нашем Google BigQuery (select Name, Result, count(*) from TestResults_...).
  2. Если исторически тест вел себя в большей степени как генератор случайных результатов, и в меньшей степени как тест, создаём для него тикет.
  3. Добавляем тест в игнор и указываем в качестве причины вновь созданный тикет.
  4. Находим, кто же написал это непотребство (git blame) и вешаем кейс на автора.

В общем, очень просто. И ещё очень скучно. Тестов-то у нас много. Я бы автоматизировал это всё, но есть одно небольшое «но» — не всегда можно определить, кто же текущий «владелец» теста. Программисты же увольняются, рефакторят чужое, ну и ломают git’овскую историю по праздникам. Я думал заморочиться и выкатить какое-нибудь machine learning решение для этого, но то попахивает перебором. А вот написать бота выглядит как-то более выполнимо. Он бы мониторил тесты, отслеживал статистику, и когда ему что-то непонятно, вроде на кого повесить кейс, спрашивал бы меня.

Осталось только понять, как этих ботов делают. Читать далее Разбираемся с Microsoft Bot Framework

Взгляд пещерного человека на современный фронт-энд

современный фронт-энд

Возможно, это не совсем очевидно, особенно на фоне того, о чём я тут обычно пишу, но большую часть свой карьеры мой основной фокус был на… фронт-энде. Ага, JavaScript и товарищи. То есть я и другими вещами занимался, но святое дело скриптописания всегда было в центре. Правда, после переезда в Канаду его количество в моей жизни несколько поубавилось. Мне всё ещё перепадают эпизодические скриптовые задачи по веб проекту, который мы начали аж в 2009-м году, но в целом последние 2 года я работаю только с серверами. Читать далее Взгляд пещерного человека на современный фронт-энд

Файрвол веб-приложений

Наша компания немного помешана на интернет безопасности, поэтому, хотя оно и не совсем в сфере моих интересов, раз в пару недель приходится узнавать что-то новое по теме. Иногда случаются приколы, когда «что-то новое» — это идея, которой я пользовался достаточно давно, но теперь вот выяснилось, что у этой штуки есть собственное имя. В последний раз это был файрвол веб-приложений. Читать далее Файрвол веб-приложений

Краткое введение в etcd

etcd лого

Такое чувство, будто в последние месяцы я черезчур уж сильно сосредоточился на дебаггинге и .NET Core, и как-то подзабил на топик, ради которого весь этот блог и затевался — DevOps и распределённые приложения. Ошибку осознал, и сегодня мы посмотрим на что-нибудь более релевантное. Например, etcd.

Во время моего романа с распределёнными приложениями etcd всегда был где-то неподалёку. То он был альтернативой Consul, когда я разбирался с сервис-дискавери и управлением конфигурациями. То etcd всплыл как основное хранилище настроек кластера в Kubernetes. В общем, он везде. Так что я думаю, стоит разобраться, на что же это за зверь такой.

Читать далее Краткое введение в etcd

Вскрываем дамп NodeJS процесса с llnode

Научиться дебаггить дампы .net core процессов на Linux при помощи lldb и SOS плагина оказалось очень приятным опытом. Всё-таки «дамп процесса» звучит как нечто крайне низкоуровневое, а тут можно и на управляемые потоки посмотреть, и в памяти покопаться. В общем, приятное колдунство. И между прочим, lldb плагины были не только для .NET. Я видел ещё и для Python, и для Java.  Интересно, а есть ли что-нибудь похожее для NodeJS и JavaScript? Хе,

Of Course!

То есть «конечно», по-буржуйски. Есть плагин под названием llnode, который как раз с NodeJS и работает. Сегодня я не буду копать в нём слишком уж глубоко, всё-таки со скриптом в последнее время практически не работаю. Но посмотреть, как это вообще делается, интересно. Так что приступим. Читать далее Вскрываем дамп NodeJS процесса с llnode

Тайна «Debug adapter process has terminated unexpectedly»

vs code

Любопытная история приключилась со мной намедни. Моя основная C# IDE на никсовых системах — Visual Studio Code — внезапно приказала долго жить. Не целиком, а самая полезная её часть — дебаггер. Стоило мне поставить брейкпоинт где-нибудь в коде и запустить проект, как редактор останавливал праздник интеллекта с ошибкой «Debug adapter process has terminated unexpectedly»:

Debug adapter process has terminated unexpectedly

A вот раньше всё работало просто прекрасно. Так как незадолго до проблемы я устанавливал на Убунту сразу несколько новых связанных с дебаггингом утилит (lldbperf и lttng), то естественно подумал, что проблема пришла от них. Но ни их удаление, ни переустановка VS Code целиком не изменили ровным счётом ничего.

В довесок к этому единственная внятная альтернатива VS Code для работы с C# на Linux — JetBrains Rider — тоже косячит. Какие-то проекты она может запустить и дебаггить, какие-то — нет. Те, что мне нужны, например, она даже запустить не может. В общем, не оставалось ничего другого кроме как начать разбираться, кто убил VS Code. Читать далее Тайна «Debug adapter process has terminated unexpectedly»

Отправляем .NET Core метрики в Graphite через StatsD

.NET Core StatsD

Уже прошло больше года с тех пор, как я подключил кусок JavaScript к collectd плагину и начал собирать данные мониторинга с нашей CI, чтобы потом хранить их в Graphite. И знаете что? Оно до сих пор работает. Даже JavaScript’овая часть. Но настали времена, когда мне нужно будет собирать метрики с .NET Core сервисов, и, чувствую, связкой JavaScript + collectd я уже не отделаюсь.

По идее, проблем быть не должно. В Graphite ведь можно отправлять данные хоть по TCP в виде текста, так что сервисы вполне могут заняться этим самостоятельно. Но можно сделать даже ещё проще. Читать далее Отправляем .NET Core метрики в Graphite через StatsD

Тестирование серверов и контейнеров с goss

тестирование серверовНедавно почитывал последний выпуск Technology Radar и нашёл вот какую интересную штуку в разделе новых техник программирования: «разработка контейнеров по TDD». Мдя. Ментально я пока ещё не могу провести соединительную линию между Докером и TDD, но инструменты, которые там упомянуты, оказались достаточно интересными.

Первый — serverspec. С его помощью можно прогонять локальные и удалённые сервера-контейнеры по набору BDD-подобных юнит-тестов. Тулза выглядит вполне зрелой и продуманной, поддерживает не только Linux, и всё было бы хорошо, если бы один огромный косяк (возможно, только для меня): serverspec написан на Ruby, и значит, что он абсолютно не совместим со стеком, в котором я обычно работаю.

Вторая тулза — goss — оставляет впечатление небольшого швейцарского ножика. Вроде и то немного умеет, и это. Обычно я к таким инструментам отношусь настороженно, но… goss какой-то странно прикольный, так что на него хочется посмотреть поближе. Читать далее Тестирование серверов и контейнеров с goss

Профайлинг .NET Core приложения в Linux

flamegraphА тем временем я продолжаю разбираться в том, как дебагить .NET Core приложения в Linux. Теперь я уже более или менее представляю, как анализировать проблемы с памятью, но таких на самом деле у нас не так уж и много. Самая распространённая проблема — загрузка процессора под 100%, и тогда очень, очень хочется понять, чем же это приложение таким занимается.

На Windows я первым делом лезу в логи и трейс-файлы. Когда их не хватает, приходит очередь PerfView, который с огромной частотой сэмплирует приложение, и тогда уже можно посмотреть, сколько потоков сейчас запущено, чем они занимаются, какие самые горячие места, и т. п.

Логи и трейсы, разумеется, существуют и на Linux, но мне было интересно, можно ли на нём профайлить .NET Core примерно так же, как и на Windows. Как оказалось, инструментов почти куча, но применительно к .NET Core основными выглядят три: утилиты perf, lttng  и perfcollect. Вот на них мы сейчас и посмотрим. Читать далее Профайлинг .NET Core приложения в Linux

Дебаггинг памяти .NET Core приложения в Linux

Дебаггинг памяти .NET Core приложения в Linux

Большую часть прошлой недели мне пришлось экспериментировать с виндовым .NET проектом под Linux и в Kubernetes. Это на самом деле не такая уж и дурка, как кажется поначалу. Проект мы заранее перевели на кросс-платформенный .NET Core, я отловил практически все проблемы, которые вплыли в никсе под контейнерами, и по итогу в K8s проект действительно заработал. Почти.

На практике всё равно остались мелкие неприятности. Эпизодически выскакивали всякие StackOverflow (хорошо хоть не segmentation faults), да и мой дебагерский виндовый опыт оказался практически бесполезным на никсах.

Например, практически сразу мы заметили, что, запускаясь под контейнером, проект с ходу отъедал 300 мегабайт физической памяти и около 2-х гигов виртуальной. В виндовом продакшене, конечно, под нагрузкой бывало и на порядки больше, но вот тут, на Linux, в демо-режиме, это много, мало, или вообще как? Как это проверить в принципе? На Винде я бы сделал дамп процесса, запустил Visual Studio или WinDBG и гуглил, что теперь делать дальше. А что тут?

Как выяснилось, гугл под Linux тоже работает, так что через пару часов медитации на монитор я выучил несколько интересных штук, о которых и хотел бы рассказать сегодня. Читать далее Дебаггинг памяти .NET Core приложения в Linux