В рамках недавно прошедшей конференции DotNext 2018 состоялся BoF по Domain Driven Design. На нем был затронут вопрос работы с исключениями, который вызвал жаркий спор, но не получил развернутой дискуссии, поскольку не являлся основной темой.

Также, изучая множество ресурсов, начиная от вопросов на stackoverflow и заканчивая платными курсами по архитектуре, можно наблюдать, что в IT-сообществе сложилось неоднозначное отношение к исключениям и к тому, как их использовать.

Наиболее часто упоминается, что с использованием исключений легко построить поток исполнения, имеющий семантику оператора goto, что плохо сказывается на читабельности кода.

Есть разные мнения о том, стоит ли создавать собственные типы исключений или использовать стандартные, поставляемые в .NET.

Кто-то делает валидацию на исключениях, а кто-то повсеместно использует монаду Result. Справедливо, что Result позволяет по сигнатуре метода понять, возможно ли не только успешное выполнение. Но не менее справедливо, что в императивных языках (к которым относится C#) повсеместное использование Result приводит к плохо читаемому коду, засыпанному конструкциями языка настолько, что с трудом можно разглядеть исходный сценарий.

В данной статье я расскажу о практиках, принятых в нашей команде (если кратко — мы используем все подходы и ни один из них не является догмой).

Речь пойдет об enterprise-приложении, построенном на базе ASP.NET MVC+WebAPI. Приложение построено по луковой архитектуре, общается с базой данных и брокером сообщений. Используется структурированное логирование в ELK-стек и настроен мониторинг при помощи Grafana.

Грядущий релиз версии 1.11 языка программирования Go принесет экспериментальную поддержку модулей — новую систему управления зависимостями для Go. (прим.перев.: релиз состоялся)

Недавно я уже писал об этом небольшой пост. С тех пор кое-что слегка поменялось, да и мы стали ближе к релизу, поэтому мне кажется, что настало время для новой статьи — добавим больше практики.

Итак, вот, что мы будем делать: создадим новый пакет и потом сделаем несколько релизов, чтобы посмотреть, как это работает.

Приветствую вас, коллеги!

Около месяца назад я опубликовал здесь статью GUI-фреймворки — на поток, где предлагалась технология создания GUI-фреймворков для разных языков программирования, основанная на подключении (tcp/ip или каком другом) к внешнему процессу, играющему роль своеобразного GUI-сервера. Здесь я хочу представить конкретную реализацию этой идеи — новый GUI-фреймворк для Golang — External.

Зачем вообще потребовалось писать новый GUI для Golang, если в наличии уже имеется немало таких инструментов? В первую очередь, потому, что ни один из них не устраивал меня в полной мере. Нужно было что-то для создания десктопных приложений, кросс-платформенное, чтобы выглядело естественно для каждой платформы. По-возможности, не очень громоздкое, имеющее минимум зависимостей — я привержен минималистическому подходу.

Для тех, кому понравилась моя предыдущая статья, продолжаю делится впечатлениями об инструменте для нагрузочного тестирования Locust.

Постараюсь наглядно показать преимущества написания нагрузочного теста python кодом, в котором можно удобно как подготавливать любые данные для теста, так и обрабатывать результаты.

В начале года мы решили научиться хранить и читать отладочные логи ВКонтакте более эффективно, чем раньше. Отладочные логи — это, к примеру, логи конвертации видео (в основном вывод команды ffmpeg и список шагов по предварительной обработке файлов), которые иногда бывают нам нужны лишь спустя 2-3 месяца после обработки проблемного файла.

На тот момент у нас было 2 способа хранения и обработки логов — наш собственный logs engine и rsyslog, которые мы использовали параллельно. Стали рассматривать другие варианты и поняли, что нам вполне подходит ClickHouse от Яндекса — решили его внедрять.

В этой статье я расскажу о том, как мы начали использовать ClickHouse ВКонтакте, на какие грабли при этом наступили, и что такое KittenHouse и LightHouse. Оба продукта выложены в open-source, ссылки в конце статьи.

Введение

Обычно, при оптимизации программы для многоядерных компьютеров первым шагом является выяснение возможности разделения алгоритма на части, выполняющиеся параллельно. Если для решения задачи необходимо параллельно обрабатывать отдельные элементы из большого набора данных, то первыми кандидатами станут новые возможности параллельности в .NET Framework 4: Parallel.ForEach и Parallel LINQ (PLINQ)

Parallel.ForEach

Класс Parallel содержит метод ForEach, представляющий собой многопоточную версию обычного цикла foreach в C#. Подобно обычному foreach, Parallel.ForEach выполняет итерации над перечислимыми данными (enumerable), но с использованием множества потоков. Одна из более часто используемых перегрузок Parallel.ForEach выглядит следующим образом:

public static ParallelLoopResult ForEach<TSource>(
			 IEnumerable<TSource> source,
			 Action<TSource> body)

Ienumerable указывает на последовательность, по которой нужно выполнить итерации, а Action body задает делегат, вызываемый для каждого элемента. Полный список перегрузок Parallel.ForEach можно найти здесь.

PLINQ

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

Выполнение независимых операций

В последнем посте я рассказывал о Kubernetes, о том, как ThoughtSpot использует его для собственных нужд по поддержке разработки. Сегодня хотелось бы продолжить разговор о короткой, но от того не менее интересной истории отладки, которая произошла совсем недавно. Статья базируется на том, что containerization != virtualization. К тому же наглядно показывается, как контейнеризированные процессы конкурируют за ресурсы даже при оптимальных ограничениях по cgroup и высокой производительности машины.

Создание высокопроизводительного кластера с 12 узлами NanoPi-Fire3 менее чем за £100 (£550, включая двенадцать Fire3)

Мой прошлый кластер на Raspberry Pi 3 в прошлом году немало заинтересовал публику, так что я попробовать сделать аналогичные проекты на других отличных одноплатных компьютерах, которые есть на рынке. FriendlyARM из Китая очень щедро отправила мне 12 своих последних 64-битных ARM плат NanoPi-Fire3, на каждой из которых восьмиядерный ARM A53 SoC, работающий на частоте 1,4 ГГц, с гигабитным Ethernet.

Эта статья полностью посвящена KD-Деревьям: я описываю тонкости построения KD-Деревьев, тонкости реализации функций поиска 'ближнего' в KD-Дереве, а также возможные 'подводные камни', которые возникают в процессе решения тех или иных подзадач алгоритма. Дабы не запутывать читателя терминологией(плоскость, гипер-плоскость и т.п), да и вообще для удобства, полагается что основное действо разворачивается в трехмерном пространстве. Однако же, где нужно я отмечаю, что мы работаем в пространстве другой размерности. По моему мнению статья будет полезна как программистам, так и всем тем, кто заинтересован в изучении алгоритмов: кто-то найдет для себя что-то новое, а кто-то просто повторит материал и возможно, в комментариях дополнит статью. В любом случае, прошу всех под кат.

Раньше я очень любил C#

Это был мой основной язык программирования, и каждый раз, когда я сравнивал его с другими, я радовался тому, что в свое время случайно выбрал именно его. Python и Javascript сразу проигрывают динамической типизацией (если к джаваскрипту понятие типизации вообще имеет смысл применять), Java уступает дженериками, отстутствием ивентов, value-типов, вытекающей из этого карусели с разделением примитивов и объектов на два лагеря и зеркальными классами-обертками вроде Integer, отсутствием пропертей и так далее. Одним словом — C# клевый.

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

А потом я из любопытства попробовал F#.

Всего год назад я сидела на Хабре и читала подобного рода статьи для того, чтобы поддержать свой боевой дух, когда решила покинуть родной Казахстан и найти работу в Европе. Но, к моему сожалению, все статьи начинались примерно одинаково: “Меня зовут username и я программирую с 8 лет”. Я вам поведаю совсем другую историю.

Всем привет!

У нас наконец-то есть контракт на обновление книги Марка Симана "Dependency Injection in .NET" — главное, чтобы он поскорее ее дописал. А еще у нас в редактуре книга уважаемого Динеша Раджпута о паттернах проектирования в Spring 5, где одна из глав также посвящена внедрению зависимостей.

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

Эмоциональная окраска оригинала немного утихомирена, количество восклицательных знаков в переводе сокращено. Приятного чтения!

Года полтора назад встал вопрос совместимости написанного кода с Python3. Поскольку уже стало более менее очевидно, что развивается только Python3 и, рано или поздно, все библиотеки будут портированы под него. И во всех дистрибутивах по умолчанию будет тройка. Но постепенно, по мере изучения, что нового появилось в последних версиях Python мне все больше стал нравится Asyncio и, скорее, даже не Acyncio а написанный для работы с ним aiohttp. И, спустя какое то время, появилась небольшая обертка вокруг aiohttp в стиле like django. Кому интересно что из этого получилось прошу под кат.

Вторая часть

Введение
Краткий обзор других фреймворков на базе aiohttp
1. Структура
2. aiohttp и jinja2
3. aiohttp и роуты
4. Статика и GET, POST параметры, редиректы
5. Websocket
6. asyncio и mongodb, aiohttp, session, middleware
7. aiohttp, supervisor, nginx, gunicorn
8. После установки, о примерах.
9.RoadMap

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

Что касается Python, то в нём есть почти всё.

• Динамический массив — встроенный тип list. Он же поддерживает и стековые операции: .append() и .pop().
• Хэш-таблица — встроенные типы set и dict, а также неизменяемый брат сета frozenset.
• Куча — list со специальными операциями вставки и удаления, реализованными в модуле heapq.
• Двусторонняя очередь — это описанный в модуле collections тип deque.

Но вот самобалансирующегося дерева поиска, как такового, в стандартной библиотеке нет. А жаль!

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

Перевод A Complete Machine Learning Walk-Through in Python: Part Two

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

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

Весь код проекта лежит на GitHub, а здесь находится второй блокнот, относящийся к текущей статье. Можете использовать и модифицировать код по своему усмотрению!

Сэр Тим Бернерс-Ли на Campus Party 2008, фото Jonan Basterra

Сэр Тим Бернерс-Ли, создатель Всемирной паутины и директор консорциума W3C, уверен, что развитие веба достигло критической точки, максимально отклонилось от изначальной концепции. Изначально он задумывался как децентрализованная сеть, где первый браузер одновременно был и редактором документов. Идея состояла в том, что каждый пользователь не только сможет просматривать документы, но и создавать, редактировать их. Веб должен был стать местом совместного творчества и сотрудничества для всего человечества. Но что-то пошло не так.

Есть примеры удачной реализации совместного творчества, как Википедия, децентрализованный хостинг сайтов и пиринговые социальные сети. Это предвестники того, каким может стать веб на основе новой технологии Solid, которую разработал Тим Бернерс-Ли совместно с группой исследователей из Массачусетского технологического института. Это венец десятилетий концептуальной работы, которой занимался Бернерс-Ли.

В свете приближающегося конца мне посоветовали написать несколько слов.

Чтобы понять их — расскажу небольшую историю, о жизни одного человека.

Детство

Воспоминания из раздела "ненависть"

Представьте, что вам сейчас 2.5-4.9 года. Основное время вы проводите в квартире у бабушки с дедушкой (по линии отца; квартира родителей находится в этом же доме, но на другом этаже). Вы любите исследовать все вокруг, и особенно любите изучать работу сложных устройств: электронных приборов (радио, кассетные плееры), механизмов (часы), … Любите чинить их, когда они сломаются, либо чинить их, когда вы сами их сломаете при очередной разборке-сборке. [возможно, этому послужило одно событие в жизни — про него расскажу ниже]. А еще больше любите из нескольких устройств собирать одну вещь, которая вам нужна, либо улучшать одно при помощи разборки на запчасти другого.

И при этом вас "фаршируют" такими книгами как "истории Геракла" и другими детскими/недетскими книгами, которые вы начинаете ненавидеть. Ненавидите из-за того, что вся информация, которая содержится в этих книгах — бесполезна для вас, и при этом вас заставляют "поглощать" ее в большом количестве. Причем других книг в вашем окружении нет, и вы начинаете считать, что все существующие книги наполнены только бесполезной информацией. И когда вы в первый раз в жизни спрашиваете "Что такое библиотека?", и вам отвечают "место, где хранится книги"… (представьте "пожарных" из "451 градус по Фаренгейту")

Положительная сторона

А теперь вопрос: как вам удавалось разбираться в сложных устройствах, чинить их, пересобирать их — без чтения "технической литературы"? Единственное, что вам было доступно — это схемы печатных плат. На "ближайших людей" рассчитывать не приходилось, их специальности: "повар", "модельер" + экономическое образование.

Темы использования Raspberry pi для FPV управления и мониторинг движения в кадре по векторам H.264 не новы. Разработка не претендует на оригинальность, да и времени на нее было потрачено относительно не много (с июля по выходным. иногда.).

Но, возможно, мой опыт (и исходники) окажутся кому ни будь полезными.

Мысль о том, что нужно сделать видео наблюдение в квартире, возникала после того как сосед сказал, что кто-то копался в замке двери.

Первое что было сделано на скорую руку – это установка известной программы motion на Raspberry pi zero c камерой v1.3. В принципе, задачу решает. Если устраивает оповещение через почту и fps=4-5.

Но это показалось не интересным. Под рукой была платформа с колесами и обвязкой от старых экспериментов и аккумуляторы 18650 от старых ноутов.

В результате получилась забавная смесь мобильного видеонаблюдения и детектора движения.
Поскольку у меня есть арендованный VPS, то проблем доступом извне (домашняя сетка за NAT) не было. Время автономной работы около 4-х суток если не злоупотреблять ездой и фарой.

Можно поездить по квартире, удаленно управляя как камерой, так и платформой и оставить в режиме «сторож» (motion detect) в любом нужном месте.

Казусы Российского законодательства связанного с закупками по 44-ФЗ, в которых с недавних пор стало конкретно указано на приоритет Российских товаров (Товаров, работ, услуг-ТРУ), т.е. оборудования и программного обеспечения (если есть аналоги в Реестре Минкомсвязи).

Как законопослушный гражданин РФ, работающий в государственных (муниципальных) организациях, я начал изучать вопрос -как выполнить требования законодательства или их обойти безнаказанно или с минимальными потерями. В процессе проработки вопроса выяснил некоторые моменты и подводные камни данного процесса, с которыми и решил поделиться с сообществом.

Тема видеонаблюдения встала для меня остро с появлением загородного жилья. На просторах интернета можно найти кучу информации по организации видеонаблюдения. К сожалению большинство вариантов сводилось к покупке готовых комплектов из Китая. От знакомых слышал много критики на этот счёт. Как-то даже сам поучаствовал в настройке оборудования, купленного с Aliexpress. Где-то половина заявленных функций работала не так как заявлено, некоторые опции и вовсе не получилось настроить, хотя регистратор был не из дешёвых. И таких отзывов и мнений было много. Также многие критически относятся к тому, что видеозаписи хранятся на китайских облачных сервисах. И тогда появилась мысль — а что если попробовать сделать свой видеорегистратор с минимальным функционалом? А что? На тот момент я начал плотно увлекаться linux, писал приложения с элементарным функционалом на bash, экспериментировал с web… В принципе всё что нужно для решения поставленной задачи. Сказано — сделано.