Как-то выдалась у меня пара выходных, и я набросал GraphQL сервер к нашей Docsvision платформе. Ниже расскажу, как все прошло.
Пользователь
Мониторинг акторов в Akka.Net, но на F#
Для тех кто не знаком с F#, но знаком с C#, рекомендую наисвежайшую статью от Microsoft.
Она поможет Вам испытывать меньше WTF моментов при прочтении, т.к. моя статья не туториал к синтаксису.
Контекст задачи
Есть сервис, написанный на Akka.NET, он вываливает в разные текстовые логи кучу инфы. Отдел эксплуатации грепает эти логи, жарит по ним регекспами, чтобы узнать о кол-ве ошибок (бизнесовых и не очень), о кол-ве входящих в сервис сообщений и кол-ве исходящих. Далее эта информация заливается в ElasticDB, InfluxDB и показывается в Grafana и Kibana в разных срезах и агрегациях.
Звучит сложно, да и парсить текстовые логи сервиса, который генерит несколько десятков ГБ текстового мусора в день — занятие неблагодарное. Поэтому встала задача — сервис должен быть способен поднять ендпоинт, который можно дёрнуть и получить сразу всю инфу о нём.
Решать задачу будем так:
- Напишем доменную модель для метрик
- Замапим доменную модель метрик на реализацию App.Metrics и поднимем апишечку
- Сделаем структурированный доменный логгер, который натянем на внутренний логгер Akka
- Сделаем обёртку для функциональных акторов, которая спрячет работу с метриками и логгером
- Соберём всё вместе и запустим
29 докладов DotNext 2017 Piter: От .NET Standard и контейнеров до безопасности и перфоманса
- Здесь нет безумного зоопарка фреймворков, работу которых надо в обязательном порядке знать на уровне исходников;
- нет 5 GC, каждый из которых обладает своими особенностями;
- качество документации стандартной библиотеки и развитых фреймворков в среднем выше;
- большинство инструментов работают четко и счетчики производительности обычно не врут (это я в основном про .NET Framework говорю, с Core не все так радужно пока);
- сам язык, в конце концов приятен и понятен (хотя под JVM можно пользоваться тем же Kotlin).
Зато есть много чего другого интересного:
- Если вы работаете на низком уровне, модели памяти никуда не деваются;
- Работа над улучшением производительности и оптимизации по памяти по прежнему с нами;
- Сама платформа развивается огромными темпами — надо оставаться в курсе;
- С кроссплатформенностью приходят новые инструменты и новые проблемы.
Поэтому новую программу конференции мы решили строить немного по-другому. Получается, что DotNext 2017 Piter — уже не только хардкор. А если не хардкор, то кто? Подробности смотрите под катом.
Поиск неисправностей с помощью WinDbg, Sos и Sosex
Изображение: Julien Dumont, Flickr
К сожалению, иногда случаются ситуации, когда система перестает работать или начинает безудержно потреблять ресурсы, а логи и системные метрики не могут помочь. Ситуация еще усугубляется тем, что на системе в продакшене нет Visual Studio или какого-либо отладчика, невозможно поотлаживаться удаленно. Чаще всего даже нет возможности получить доступ этой машине. В данном случае единственным решением является анализ дампа памяти процесса. Я хочу описать несколько общих сценариев поиска проблем на таких дампах. Это поиск взаимоблокировок, утечек памяти и высокого потребления процессорных ресурсов.
Реактивные приложения с паттерном RxPM. Прощайте MVP и MVVM
Уже продолжительное время я размышляю над паттерном RxPM и даже успешно применяю его в «продакшене». Я планировал сначала выступить с этой темой на Mobius, но программный комитет отказал, поэтому публикую статью сейчас, чтобы поделиться с Android-сообществом своим видением нового паттерна.
Все знакомы с MVP и MVVM, но мало кто знает, что MVVM является логическим развитием паттерна Presentation Model. Ведь единственное отличие MVVM от PM – это автоматическое связывание данных (databinding).
В этой статье речь пойдет о паттерне Presentation Model с реактивной реализацией биндинга. Некоторые ошибочно называют его RxMVVM, но корректно будет называть его RxPM, потому что это модификация шаблона Presentation Model.
Этот паттерн удобно использовать в проектах с Rx, так как он позволяет сделать приложение по-настоящему реактивным. Кроме того, он не имеет многих проблем других паттернов. На диаграмме ниже представлены различные варианты и классификации шаблонов представления:
Пишем свои монады на Scala на примере CSV-парсера
За последнее время мы очень многое узнали о монадах. Мы уже разобрались что это такое и даже знаем как их можно нарисовать, видели доклады, объясняющие их предназначение. Вот и я решил заскочить в уходящий монадный поезд и написать по этой теме, пока это окончательно не стало мейнстримом. Но я зайду с немного другой стороны: здесь не будет выкладок из теории категорий, не будет вставок на самом-лучшем-языке, и даже не будет scalaz/shapeless и библиотеки parser-combinators. Как известно, лучший способ разобраться как что-то устроено — сделать это самому. Сегодня мы с вами будем писать свою монаду.
Задача
Возьмем для примера банальную задачу: парсинг CSV-файла. Допустим нам требуется распарсить строки файла в case classes, чтобы потом отправить их в базу, сериализовать в json/protobuf и так далее. Забудем про escaping и кавычки, для еще большей простоты, считаем что символ разделителя в полях встречаться не может. Думаю, если кто-то решит затащить это решение в свой проект, докрутить эту фичу будет не трудно.
В ногу со временем: Используем JWT в ASP.NET Core
Полное практическое руководство по Docker: с нуля до кластера на AWS
Содержание
- Вопросы и ответы
- Введение
- 1.0 Играем с Busybox
- 2.0 Веб-приложения и Докер
- 3.0 Многоконтейнерные окружения
- 4.0 Заключение
Вопросы и ответы
Что такое Докер?
Определение Докера в Википедии звучит так:
программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.
Ого! Как много информации.
Azure Service Fabric: вторые шаги
Снова Чарли Чаплин на фабрике в фильме «Новые времена»
Продолжаем разговор про Azure Service Fabric. В предыдущей статье я упомянул о планах написать сначала про stateful сервисы, а затем уже перейти к модели акторов в ASF. Концепция изменилась — подумалось мне, что неплохо бы для примеров использовать если уж не production-решение, то что-то близкое, чтобы была теоретическая польза и практический смысл. Можно объединить все компоненты ASF в одном флаконе — чтобы и корованы набигали, и лунапарк, и Винни-Пух и все-все-все. Вот с такими мыслями я и пошел на кладбище домашних проектов в поисках кандидата на оживление.
Azure Service Fabric: первые шаги
Чарли Чаплин в фильме «Новые времена»
Про Azure Service Fabric уже немало написано статей и даже книг, благо около года продукт находился в состянии preview. Однако 1 апреля 2016 года без всяких шуток Azure Service Fabric наконец достиг состояния General availability, и есть основания полагать, что он задержится здесь всерьез и надолго. А раз так — почему бы не пройтись по нему если не из прикладного, то хотя бы из академического интереса? Тем более что информации по Azure Service Fabric на русском языке явно маловато.
Зачем же вообще потребовался Azure Service Fabric? В мире ПО существует довольно много серверов, привязанных к экосистемам определенного языка или платформы. Исторически так сложилось, что в экосистеме Java таких серверов едва ли не больше всех — Tomcat, JBoss, WebSphere и пр. Увы, платформа .NET таким богатством выбора похвастаться пока не может. На ум приходят разве что IIS, “облачные” сервисы Azure и их “локальный” близнец Windows Azure Pack (не считая хелперов-оберток типа Topshelf). Azure Service Fabric призван расширить этот недлинный список в сторону популярной нынче концепции SOA и остромодной подконцепции микросервисов, упрощая развертывание сервисов и обеспечивая их масштабируемость и отказоустойчивость. И после этого лирического отступления перейдем, наконец, в наступление.
Find.By — finding & verifying locators
Обычно это процесс выглядит так: я пишу xpath выражение в chrome или firepath, потом копирую его и добавляю атрибут к элементу в C# коде. Но локаторы часто нужно исправлять или просто проверить, на какой элемент он указывает. И даже такое просто изменение предиката как [@id='myId'] на [contains(@id = 'Id')] заканчивается падением теста во время выполнения потому, что я написал '=' вместо ',' и поленился проверить изменения. В общем, слишком много действий с копированием, вставкой, переключений между окнами и тому подобного для такой простой задачи. Решил я написать плагин для ReSharper, который бы по Alt+Enter подсвечивал мой элемент в браузере.
Как не наступить на грабли, работая с сериализацией
Несмотря на то, что использовать механизм сериализации при программировании на C# достаточно просто и удобно, есть моменты, которые стоит учитывать. О том, на какие грабли можно наступить, работая с сериализацией, о примерах кода, в котором эти грабли припрятаны, а также о том, как PVS-Studio поможет вам избежать шишек на лбу, и будет эта статья.
Что собой представляют образы Docker none:none?
Предлагаю вашему вниманию перевод статьи What are Docker none:none images? из блога Project Atomic.
Последние несколько дней я потратил на упражнения с образами Docker <none>:<none>
. Чтобы объяснить, что они собой представляют, и что могут натворить, я пишу этот пост, в котором ставлю вопросы:
- Что собой представляют образы Docker
<none>:<none>
? - Что собой представляют обособленные (dangling) образы ?
- Почему я вижу кучу образов
<none>:<none>
, когда делаюdocker images -a
? - В чем разница между
docker images
иdocker images -a
?
Прежде чем я начну отвечать на вопросы, запомните, что есть два вида образов <none>:<none>
: хорошие и плохие.
C# — есть ли что-то лишнее?
Программируя уже более 25 лет, застал достаточно много различных концепций, что-то смог попробовать, еще больше не успел. Сейчас с интересом наблюдаю за языком Go, который можно отнести к продолжателям “линейки языков Вирта” — Algol-Pascal-Modula-Oberon. Одним из замечательных свойств этой цепочки является то, что каждый последующий язык становится проще предыдущего, но не менее мощным и выразительным.
Думаю, что всем понятно, чем хорош простой язык. Но все же приведу эти критерии, поскольку они будут всплывать позже:
- Простой язык быстрее изучается, значит проще получить необходимых разработчиков.
- Поддержка программы на более простом языке обычно проще (да, это интуитивное ощущение, которое нужно бы доказать, но я приму его сейчас за аксиому).
- У более простого языка проще развивать окружающую его инфраструктуру — переносить на разные платформы, создавать различные утилиты, генераторы, парсеры и т.п.
Почему же тогда существуют сложные языки? Все дело в выразительности. Если какая-то конструкция позволяет коротко описать необходимое действие, то это вполне может окупить негативные стороны усложнения языка.
Ценность многошрифтового дизайна
Я заметила, что одна из особенностей моего дизайнерского стиля — это готовность использовать, на первый взгляд, слишком большое количество разных гарнитур шрифтов. Я видела неисчислимое множество статей о сочетаниях и системах использования шрифтов, и почти везде рекомендуется использовать меньше шрифтов в любом дизайне. Я и к своей работе получала такие комментарии – дескать, работы приятные, несмотря на количество используемых шрифтов.
«Очень нравится сайт, потому что он не боится нарушать одно из первых правил шрифта – не использовать слишком много разных гарнитур. Используется четыре шрифта, два из семейства sans-serif и два из serif — Galaxie Copernicus, Interstate, Harriet и Nimbus Sans. Основной момент такого дизайна – последовательность, и сайт Бетани Хек последовательно использует каждый из шрифтов для своей цели.»
— Джеремия Шоаф, Typewolf
Расцениваю это, как вызов. Спасибо, Джеремия!
Хочу поспорить и рассказать о ценности эклектичных систем, и о том, как создать структуру проекта, чтобы эффективно использовать совместно несколько шрифтов.
Так почему же у нас есть правила насчёт количества используемых гарнитур?
Событийная модель на основе async и await
Самым очевидным вариантом использованием этой конструкции является ожидание завершения некой асинхронной операции. Первое, что приходит на ум — это ожидание ввода-вывода. Например, мы послали запрос клиенту и ожидаем ответа, тогда используя await мы сможем продолжить выполнение кода после получения ответа, а сам код при этом будет выглядеть синхронным. Но что если во время ожидания возникнет необходимость прервать выполнение этой операции? Тогда нам придется использовать CancellationToken, причем если таких операций несколько, то токены необходимо будет линковать или использовать один общий токен. При этом причина отмены будет скрыта от кода, использующего этот CancellationToken. Кроме отмены, код должен поддерживать обработку потери соединения, таймаута, возвращаемых ошибок и т.д.
В классическом варианте это выльется в использование CancellationToken для обработки отмены, try catch для обработки разрыва соединения и код анализа возвращенных данных, для оценки результата запроса. Но можно ли уместить всё это в единой парадигме? В этот статье я предлагаю рассмотреть альтернативный подход, основанный на событийной модели с использованием синтаксического сахара async/await.
Как настроить двухфакторную аутентификацию для логина и sudo
Безопасность в моде, как это и должно быть. Мы живем в мире, где данные — невероятно ценная валюта, которую вы всегда рискуете потерять. Поэтому вы должны сделать все, чтобы убедиться, что то, что вы держите на серверах и десктопах — в безопасности. Для этого администраторы и пользователи создают невероятно сложные пароли, используют менеджеры паролей и т.д. Но что, если я вам скажу, что вы можете логиниться на ваши серверы и десктопы Linux за два шага, вместо одного? Вы можете это делать благодаря Google Authenticator. Более того, это невероятно легко настроить.
Я собираюсь провести вас через процесс настройки двухфакторной аутентификации для использования ее на логине и sudo. Я продемонстрирую это на десктопной Ubuntu 16.04, но процесс также работает и для сервера. Чтобы справиться с двухфакторной стороной вещей, я буду использовать Google Authenticator.
Win-Win: Спикеры DotNext на встрече SPB .NET Community и наоборот
Эволюция нейросетей для распознавания изображений в Google: Inception-v3
Продолжаю рассказывать про жизнь Inception architecture — архитеткуры Гугла для convnets.
(первая часть — вот тут)
Итак, проходит год, мужики публикуют успехи развития со времени GoogLeNet.
Вот страшная картинка как выглядит финальная сеть:
Что же за ужас там происходит?
Создание in-memory кэша первого уровня для .NET-клиентов StackExchange.Redis
В этой статье рассказывается о том, как и почему она была создана.
Информация
- В рейтинге
- Не участвует
- Откуда
- Amsterdam, Noord-Holland, Нидерланды
- Дата рождения
- Зарегистрирован
- Активность