Битборды (Bitboard) — специальные битовые структуры, позволяющие эффективно рассчитывать ходы в настольных играх. На хабре писали про применение битбордов к шахматам и даже к шашкам. Сегодня мы применим технику битбордов к несколько неожиданной, но всем знакомой игре – к тетрису. Результатом наших изысканий будет консольная игра, а также автоматический поиск лучших ходов (при заданной последовательности фигур), скорость которого как раз и обеспечивается эффектиностью битовых манипуляций. Заодно мы поддержим проигрывание найденных ходов в автоматическом режиме, чтобы в полной мере насладиться компьютерным интеллектом. В конце статьи дана ссылка на гитхаб с кодом игры на C#, а также коротенькое видео игры из 114 ходов, найденной компьютером поиском в глубину за пятнадцать минут.

Обычно битборд – это машинное слово, состоящее из нескольких байт, каждый бит которого соответствует одной клетке поля в игре. Так, в шахматах всего 64 клетки, что соответствует 8-байтному слову (ulong в C#), а в шашках – 32 (uint в C#). Любители тетриса наверняка помнят, что размер поля в стандартном тетрисе – 10 на 20 клеток, то есть, 200 бит, что не влезает ни в один числовой тип. Конечно, можно разбить поле на четыре части и использовать четыре восьмибайтных слова, или можно не мелочиться и использовать массив из двадцати двухбайтных слов, по одному слову на каждую линию поля; все реализации тетриса на битбордах, которые я нашел (в количестве одной штуки), так и делают. Но мы пойдем другим путем…

Введение

Практически все, кто имел дело с микросервисами в .NET Core, наверняка знают книгу Кристиана Хорсдала “Микросервисы на платформе .NET”. Здесь прекрасно описаны подходы к построению приложения на основе микросервисов, подробно рассмотрены вопросы мониторинга, журналирования, управления доступом. Единственное, чего не хватает — это инструмента автоматизации взаимодействия между микросервисами.

При обычном подходе при разработке микросервиса параллельно разрабатывается web-клиент для него. И каждый раз, когда меняется web-интерфейс микросервиса, приходится затрачивать дополнительные усилия для соответствующих изменений web-клиента. Идея генерировать пару web-api/web-клиент с использованием OpenApi тоже достаточно трудоемка, хотелось бы чего-то более прозрачного для разработчика.

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

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

Web-клиент для микросервиса должен генерироваться автоматически на основе интерфейса и предоставляться через Dependency Injection.

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

Предисловие

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

Что это

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

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

Среди всего многообразия задач Computer Vision есть одна, которая стоит особняком. К ней обычно стараются лишний раз не притрагиваться. И, если не дай бог работает, — не ворошить.
У неё нет общего решения. Практически для каждого применения существующие алгоритмы надо тюнинговать, переобучать, или судорожно копаться в куче матриц и дебрях логики.

Статья о том как делать трекинг. Где он используется, какие есть разновидности. Как сделать стабильное решение.

Как говорится: «Не было бы счастья, да несчастье помогло.» Внезапно у меня появилось немного свободного времени и я продолжил разработку пиу-пиу.

Среди множества функций, которые предоставляет systemd, есть одна, которую несправедливо забыли. Это функция автомонтирования. При настройке автомонтирования указанный каталог будет подмонтирован только после первого обращения к нему (точнее, прямо во время).

NFS over VPN

Конкретный пример: у меня есть удалённый сервер, на котором есть интересующий меня каталог. Я хочу иметь этот каталог локально на своей машине. Протокол доступа — nfs. Т.к. он не имеет шифрования, то разумным решением выглядит использование vpn-канала до сервера.

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

Как оно устроено

Systemd имеет специальный вид automount-юнитов, которые позволяют автоматически монтировать указанный каталог.

Abstract: как работает open-iscsi (ISCSI initiator в linux), как его настраивать и чуть-чуть про сам протокол ISCSI.

Лирика: В интернете есть множество статей довольно хорошо объясняющих, как настроить ISCSI target, однако, почему-то, практически нет статей про работу с инициатором. Не смотря на то, что target технически сложнее, административной возни с initiator больше — тут больше запутанных концепций и не очень очевидные принципы работы.

ISCSI

Перед тем, как рассказать про ISCSI — несколько слов о разных типах удалённого доступа к информации в современных сетях.

NAS vs SAN

Существует два метода доступа к данным, находящимся на другом компьютере: файловый (когда у удалённого компьютера запрашивают файл, а какими файловыми системами это сделано — никого не волнует), характерные представители NFS, CIFS (SMB); и блочный — когда у удалённого компьютера запрашивают блоки с дискового носителя (аналогично тому, как их читают с жёсткого диска). В этом случае запрашивающая сторона сама себе делает на блочном устройстве файловую систему, а сервер, отдающий блочное устройство, знать не знает про файловые системы на нём. Первый метод называют NAS (network attached storage), а второй — SAN (storage area network). Названия вообще указывают на другие признаки (SAN подразумевает выделенную сеть до хранилищ), но так сложилось, что NAS — это файлы, а SAN — это блочные устройства по сети. И хотя все (?) понимают, что это неправильные названия, чем дальше, тем больше они закрепляются.

Одна из новых возможностей, появившихся в Python 3.7 — классы данных (Data classes). Они призваны автоматизировать генерацию кода классов, которые используются для хранения данных. Не смотря на то, что они используют другие механизмы работы, их можно сравнить с "изменяемыми именованными кортежами со значениями по умолчанию".

• PEP 557 — Data classes
• Официальная документация

Введение

Все приведенные примеры требуют для своей работы Python 3.7 или выше

Большинству python-разработчикам приходится регулярно писать такие классы:

class RegularBook:
    def __init__(self, title, author):
        self.title = title
        self.author = author

Уже на этом примере видна избыточность. Идентификаторы title и author используются несколько раз. Реальный класс же будет ещё содержать переопределенные методы __eq__ и __repr__.

Модуль dataclasses содержит декоратор @dataclass. С его использованием аналогичный код будет выглядеть так:

from dataclasses import dataclass

@dataclass
class Book:
    title: str
    author: str

В качестве первой задачи для машинного обучения возьмем что-то понятное и простое, например, прогноз стоимости жилья. Готовый датасет можно найти на сайте kaggle. На первых шагах обучения не стоит брать датасеты с большим количеством переменных, например, «House Prices: Advanced Regression Techniques» состоит из 80 переменных и advanced regression, остановимся на «House Sales in King County, USA» с 21 параметром. Скачиваем данные и анализируем предоставленное описание. В наличии дата, цена, количество спален, ванных комнат, общая и жилая площадь, этажность, оценка вида, вид на море, оценка общего состояния, грейд (оценка строительства и дизайна), площадь над и под уровнем земли, год постройки, год последнего ремонта, код зоны, координаты (долгота и широта), данные о площади домов 15 соседей.

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

1. Работа с данными.

Сделаем отступление и отдельно отметим важность анализа данных. В настоящий момент все более-менее популярные алгоритмы уже написаны в виде библиотек и непосредственное построение модели сводится к нескольким строкам кода, например, k-ближайших соседей из sklearn в python:

Предлагаем почитать перевод статьи Diego Isco с ресурса dev.to. Она будет полезна начинающим специалистам в области ML.

Изображение с сайта oxygen-icons.org

Задача

Передавать лог-файлы на центральный сервер:

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

Условия: в инфраструктуре используются только Linux-сервера.

pro-cras-ti-na-tion |prəˌkrastəˈnāSHən, prō-|
существительное
задержка или откладывание чего-либо: первый совет — избегайте прокрастинации.

Кто бы мог подумать, что после десятилетий борьбы с прокрастинацией словари будут содержать решение проблемы.

Избегать прокрастинации. Так элегантно в своей простоте…

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

Нет, «избегайте прокрастинации» — хороший совет только для не настоящих прокрастинаторов. Для тех, кто говорит «Я захожу на Facebook несколько раз в день на работе. Я такой прокрастинатор!». Это те люди, которые будут говорить настоящему прокрастинатору «Не откладывай дела на потом и у тебя все будет хорошо».

Дело в том, что ни словари ни не настоящие прокрастинаторы не понимают, что для настоящих прокрастинаторов прокрастинация — не дополнительная опция. Это что-то, что они не знают как не делать.

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

• все системные логи разложенные по индексам в зависимости от их facility(auth,syslog,messages и т.д.);
• логи nginx — access и error;
• логи pm2;
• и др.

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

• Ubuntu 16.04 или debian 8-9;
• vm для развертывания;
• Прямые руки.

Приступим или добро пожаловать под кат

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

Сразу уточняем: это не 15 самых лучших библиотек, а 15 из лучших. Разумеется, есть и другие, не менее замечательные, о которых я не упомянул или не знаю.
И, нет, это не рейтинг — список маркированный, а не нумерованный.

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

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

Привет, Хабр! В преддверии старта курса «C# ASP.NET Core разработчик», подготовили перевод интересного материала о реализации кэша в C#. Приятного прочтения.

---

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

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

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

Хочу в очередной раз рассказать о результатах исследования дизайна сайта, который привлёк моё внимание. В прошлый раз я писал о CSS-механизмах, лежащих в основе нового дизайна Facebook. А теперь мне стало любопытно исследовать CSS-код Twitter. Новый дизайн Twitter появился почти год назад. В CSS-коде Twitter я нашёл много интересного: кое-что кажется мне просто замечательным, а кое-что — странным.

Добрый день. Недавно мне необходимо было разобраться со службой трассировки Windows. Эта служба появилась еще в Windows 2000, однако статей по этой службе в интернете оказалось крайне мало.Так появилась идея написания этой статьи. Итак, начнем!

Сегодня я попытаюсь рассказать про:

1. Теоретические основы службы трассировки Windows
2. Создание своей сессии ETW
3. Использование event tracing API для работы с ETW
4. Использование tracerpt и xperf для работы с ETW

Теоретические основы службы трассировки Windows

Event Tracing for Windows (ETW) — это служба, которая позволяет получать события от одного или нескольких поставщиков событий в режиме реального времени или из файла *.etl за некоторый временной период. Не понятно? Сейчас разберемся!

Для того, чтобы понять принцип работы ETW, необходимо разобраться со структурой этой службы



Архитектура ETW включает в себя 4 элемента

1. поставщики событий (providers)
2. потребители событий (consumers)
3. контроллеры ETW (controllers)
4. сессии ETW (event tracing sessions)

Принцип работы состоит в следующем.

В системе зарегистрировано некоторое число поставщиков событий, т.е. приложений, которые могут делиться своими событиями с сессиями ETW. Так же в этой системе есть некоторое число активных сессий ETW, которые могут потреблять события от одного или нескольких поставщиков и предоставлять их пользователю либо в режиме реального времени, либо записывать все события от поставщиков в файл логирования (*.etl). И управляют всем этим движением контроллеры.

А теперь рассмотрим каждый элемент рассмотренной выше архитектуры подробнее, чтобы окончательно разобраться с принципом работы!

Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

Фабиан Рейнарц (Fabian Reinartz) — разработчик программного обеспечения, фанат Go и любитель решать сложные задачи. Также он мэйнтейнер Prometheus и соучредитель Kubernetes SIG instrumentation. В прошлом он был production-инженером в SoundCloud и возглавлял группу мониторинга в CoreOS. В настоящее время работает в Google.

Бартек Плотка (Bartek Plotka) — инфраструктурный инженер в Improbable. Увлекается новыми технологиями и проблемами распределенных систем. Имеет опыт низкоуровневого программирования в Intel, опыт контрибьютора в Mesos и production-опыт SRE мирового масштаба в Improbable. Занимается улучшением мира микросервисов. Три его любви: Golang, open source и волейбол.

Глядя на наш флагманский продукт SpatialOS, вы можете догадаться, что для Improbable нужна высокодинамичная облачная инфраструктура глобального масштаба с десятками кластеров Kubernetes. Мы были одними из первых, кто начал использовать систему мониторинга Prometheus. Prometheus способен отслеживать миллионы метрик в реальном времени и поставляется с мощным языком запросов, позволяющим извлекать необходимую информацию.

Простота и надежность Prometheus является одним из основных его преимуществ. Однако, пройдя определенный масштаб, мы столкнулись с несколькими недостатками. Для решения этих проблем мы разработали Thanos — проект с открытым исходным кодом, созданный компанией Improbable, для бесшовной трансформации существующих кластеров Prometheus в единую систему мониторинга с неограниченным хранилищем исторических данных. Thanos доступен на Github здесь.

Или старое доброе динамическое программирование без этих ваших нейросетей.

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


Экран игры с сервера проекта Codenjoy