Утилиты

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

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

Tools learn the tools все написанное субъективно и основано исключительно на личном опыте: помогло мне может быть поможет и вам.

Zsh и oh-my-zsh после всех этих лет в Баше!

Как сейчас помню, мне было 17 лет и я установил линукс. Терминал и Баш. И как-то всегда баш был частью процесса и олицетворял для меня собственно работу в терминале. Спустя 12 лет после окончания PhD я попал в компанию, где был вводный документ и мне впервые в руки попался мак и я решил ему следовать.

И о чудо! Удобный переход по папкам, человеческое автодополнение, индикатор git, темы, плагины, поддержка виртуальной среды для python и тд сижу теперь в терминале и не нарадуюсь!



Ставим zsh, как вы обычно ставите все и переходим к oh-my-zsh (по сути это народная сборка рецептов, которые работают из коробки и добавили поддержку плагинов, тем и тд). Взять можно тут. А также можно поставить тему (ну например). Вот тут неплохое демо возможностей. Взято из вот этой статьи.

Pipelines

Одна из самых прекрасных конструкций терминала это pipeline. Упрощенно говоря, он позволяет соединять выходы одной команды с входами другой, пример простого применения, который буквально взят из одной задачи, которой я занимался два дня назад.

Нужно было смоделировать задачу на одном языке для решения комбинаторных задач, запускалось все из терминала и выдавалось в абсолютно нечитаемом виде из текста, поставив простой значок | соединили входы выходы и сделали поддержку форматирования:

| python.py format.py

Более интересная и каждодневная задача оценить какой-нибудь параметр или характеристику по отгруженным данным, как правило это ряд быстрых проверок, что нужные величины где-то на сервере с данными ведут себя хорошо например мы хотим понять, что у нас с парсером и смотрим сколько во всех json файлах собрано уникальных групп этот параметр должен естественно адекватно расти во времени:

cat data/*groups* | jq .group | uniq | wc -l

Мы подробнее поговорим о каждом из них, но общая идея уже понятна:

• cat (сокр. от concatenate) печатает содержимое файлов со словом group в названии из папки data/
• jq выдирает из json поле group
• uniq оставляет только уникальные группы
• wc с ключом -l считает строчки, т.е количество групп

И сейчас мы подробнее посмотрим на wc.

WC маленькая, но гордая утилитка для подсчета строк, слов и тд.

wc умеет быстро считать слова, строчки, буквы, байты и максимальную длину строчки, и все с помощью простых ключей:

• bytes
  

• chars
  

• words
  

• lines
  

• max-line-length
  

Кажется, что это тривиально, но оказывается невероятно часто нужно и удобно.

Повседневное использование, быстро оценим сколько у нас каких данных собрано (тут одна строка одна запись):


Подробнее тут.

Ack/grep

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

Пример: быстренько находим вхождение слова (ключ -w) ga2m (тип модели), без учета регистра (ключ -i) в файлах исходниках питона:

JQ парсим json в командной строке

Документация.

JQ это прямо-таки grep/ack для json (хотя и с оттенком sed и awk о последнем далее) по сути простой парсер json и json line в командной строке, но иногда бывает чрезвычайно удобным как-то пришлось парсить архив wikidata в формате bz2 он весит порядка 100ГБ и где-то 0.5TB uncompressed.

Из него нужно было выдрать соответствие между несколькими полями, что получилось сделать очень просто на машине практически без нагрузки на CPU и память, вот собственно та самая команда, которую я использовал:

bzcat data/latest-all.json.bz2 | jq stream 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2] =="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' | python3 scripts/post_process.py "output.csv"

Это был по сути весь пайплайн, который создавал нужный mapping, как мы видим все работало в режиме потока:

• bzcat читал часть архива и отдавал jq
• jq с ключом stream сразу выдавал результат и передавал его постпроцессору (так же как и с самым первым примером) на питоне
• внутри постпроцессор это простая машина состояний

Итого сложный пайплайн работающий в режиме потока на больших данных (0.5TB), без существенных ресурсов и сделан из простого пайплайна и пары тулзов. Определенно рекомендую глянуть на досуге.

fzf fuzzy finder

Удобнейшая вещь (особенно внутри вима): быстро ищет по файлам, что удобно на большом проекте особенно, когда их у вас несколько. Как правило нужно для быстрого поиска файлов по определенному слову в большом проекте: у меня происходило погружение в новый проект, в который входит несколько крупных репозиториев и в качестве вводного задания мне нужно было добавить одну простую модель в ассортимент доступных в системе и мне нужно было быстро находить свои файлы по ключевому слову ga2m и работать по аналогии с другими блоками кода быстро редактировать то одно, то другое тут fzf очень хорошо приходит на помощь:


Ссылка на репозиторий.

AWK

Название происходит от первых букв создателей Aho, Weinberger и Kernighan: по сути скриптовый язык обработки текстово-табличных данных он приминяет шаблоны трансформации к каждой строке файла

Как правило идеально подходит для быстрых разовых трансформаций, например, у нас были собранный руками датасет в виде tsv, а процессор принимал на вход jsonl причем ожидал доп поле theme, которого не было в исходном файле (нужного для некоторых вещей, которые были не критичны для текущих подсчетов) итого, был написан простой однострочник:

cat groups.tsv | awk '{ printf "{\"group\": \"%s\", \"theme\": \"manual\" }\n", $1  }' > group.jsonl

По сути он брал файлик и каждую строчку заворачивал json с нужными полями.

Ссылка с tutorial.

wget универсальный command line downloader

Регулярно скрипты и пайплайн должны что-то откуда-то подтянуть и качнуть и wget не подводит: умеет докачивать, авторизовываться, proxies, cookies да еще и помимо http(s) умеет в ftp.

Швейцарский нож в скачивании.

HSTR поиск по истории команд, с человеческим лицом

Сommand history: hstr

Регулярно мне приходится искать что-то в истории команд:

• Это уже приходилось делать
• А с каким ключам запускается Х?
• А вот этот кусок можно и переиспользовать

Поэтому мне довольно критично иметь хороший и удобный поиск по истории команд, пока hstr полностью со своей задачей справляется:

Полезное, но не вошедшее

В финале я бы упомянул полезными но тянущими на отдельную статью темы полезно глянуть:

• Связку ssh + tmux + vim (neo, plugins, etc)
• Базовые знания command line git + git hooks
• Data pipeline construction make/just
• Python virtual environments
• Docker

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

1. Website Vulnerability Scanner

Website Vulnerability Scanner это сканер уязвимостей веб-сайтов, разработанный в Pentest-Tools.com. Этому инструменту нужно дать ссылку на сайт, который нужно проверить на уязвимости, после чего будет сформирован отчёт.


Результаты проверки сайта в Website Vulnerability Scanner

2. Nibbler

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


Nibbler даёт высокую оценку сайту dev.to

3. Meta Tags

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


Проверка мета-тегов с помощью Meta Tags

4. Google Lighthouse

Google Lighthouse это опенсорсная автоматизированная система, позволяющая оценивать качество веб-проектов.

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


Анализ сайта в Google Lighthouse

5. Endtest

Endtest (сразу скажу, что я там работаю) это интеллектуальная платформа для автоматизации тестирования, которая позволяет создавать комплексные тесты и выполнять их во всех основных браузерах.

Я автоматизировал Sign In-тест для сайта DEV Community и прогнал этот тест в облачной среде, в браузерах Chrome, Firefox, Edge, Safari и Internet Explorer 11.

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


Результаты тестирования в Chrome


Результаты тестирования в Internet Explorer 11

6. Loom

Loom это бесплатное расширение для Chrome, которое позволяет делать видеозаписи, одновременно захватывая изображение с экрана и с веб-камеры.

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


Chrome-расширение Loom

7. Pexels

Pexels это сайт, на котором можно найти бесплатные фотографии и видеоматериалы для своих проектов. Это один из немногих сайтов, на котором, чтобы скачивать материалы, необязательно даже регистрироваться.

Меня этот сайт всегда выручает в ситуациях, когда мне надо сделать какой-нибудь прототип, а отдел маркетинга ещё не прислал официальные материалы.


Сайт Pexels

8. Figma

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


Figma

9. Funkify

Funkify это расширение для Chrome, которое позволяет разработчику взглянуть на веб с точки зрения людей с ограниченными возможностями. Это помогает разрабатывать сайты, с которыми будет удобно работать всем категориям пользователей.


Funkify

10. PerfectPixel

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


Сравнение страницы и её макета с помощью PerfectPixel

Какие инструменты для веб-разработчиков вы добавили бы в этот список?

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

Почему важно знать и уметь обращаться с языками запросов? По своей сути в Data Science есть несколько важнейших этапов работы и самый первый и важнейший (без него уж точно ничего работать не будет!) это получение или извлечение данных. Чаще всего данные в каком-то виде где-то сидят и их нужно оттуда достать.

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

Всего будет три основных блока типов запросов к данным, которые мы разберем в данной статье:

• Стандартные языки запросов то, что обычно понимают, когда говорят о языке запросов, как, например, реляционная алгебра или SQL.
• Скриптовые языки запросов: например, питоновские штучки pandas, numpy или shell scripting.
• Языки запросов к графам знаний и графовым базам данных.

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

Стандартные языки запросов

Стандартные языки запросов именно в том плане, что обычно мы именно о них и думаем, когда говорим про запросы.

Реляционная алгебра

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

Что такое реляционная алгебра?

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

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

Зачем?

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


Взято из этой статьи. Пример операции: join, который объединяет таблицы.

Материалы для изучения:

Хороший вводный курс от Стэнфорда. Вообще, материалов по реляционной алгебре и теории очень много Сoursera, Udacity. Есть также огромное количество материалов онлайн, в том числе хороших академических курсов. Мой персональный совет: надо понимать реляционную алгебру очень хорошо это основа основ.

SQL

Взято из этой статьи.

SQL это, по сути, имплементация реляционной алгебры с важной оговоркой, SQL декларативен! То есть записывая запрос на языке реляционной алгебры, вы фактически говорите, как нужно считать а вот с SQL вы задаете, что хотите извлечь, а дальше СУБД уже генерирует (эффективное) выражения на языке реляционной алгебры (их эквивалентность известна нам под теоремой Кодда).


Взято из этой статьи.

Зачем?

Реляционные СУБД: Oracle, Postgres, SQL Server, etc по-прежнему фактически повсюду и невероятно велик шанс того, что вам придется с ними взаимодействовать, а это означает, что придется либо читать SQL (что очень вероятно), либо писать на нем (тоже не маловероятно).

Что читать и изучать

По тем же ссылкам выше (про реляционную алгебру), есть невероятное количество материала, например, этот.

Кстати, а что такое NoSQL?

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

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

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

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

{"en_wikipedia_url":"https://en.wikipedia.org/wiki/Johnny_Cash","ru_wikipedia_url":"https://ru.wikipedia.org/wiki/?curid=301643","ru_wiki_pagecount":149616,"entity":[42775,"Джонни Кэш","ru"],"en_wiki_pagecount":2338861}

Подробнее можно прочитать тут про NoSQL.

Что изучать?

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

Скриптовые языки запросов

Сначала, кажется, причем тут вообще Python это язык программирования, а не про запросы вовсе.

• Pandas это прям швейцарский нож Data Science, огромное количество трансформации данных, агрегации и тд происходит в нем.
• Numpy векторные вычисления, матрицы и линейная алгебра там.
• Scipy много математики в пакете этом, особенно статы.
• Jupyter lab много exploratory data analysis хорошо вписывается в ноутбуки полезно уметь.
• Requests работа с сетью.
• Pyspark очень популярны среди инженеров данных, скорее всего, вам придется взаимодействовать с этой либо и спарком, просто в силу их популярности.
• *Selenium очень полезен для сбора данных сайтов и ресурсов, иногда просто по-другому данные никак не получить.

Мой главный совет: учите Python!

Pandas

Возьмем в качестве примера следующий код:

import pandas as pddf = pd.read_csv(data/dataset.csv)# Calculate and rename aggregationsall_together = (df[df[trip_type] == return]\    .groupby(['start_station_name','end_station_name'])\                      .agg({'trip_duration_seconds': [np.size, np.mean, np.min, np.max]})\                           .rename(columns={'size': 'num_trips',            'mean': 'avg_duration_seconds',               'amin': min_duration_seconds',            amax': 'max_duration_seconds'}))

По сути, мы видим, что код вписывается в классический SQL паттерн.

SELECT start_station_name, end_station_name, count(trip_duration_seconds) as size, ..FROM datasetWHERE trip_type = returnGROUPBY start_station_name, end_station_name

Но важная часть этот код является часть скрипта и пайплайна, фактически мы встраиваем запросы в Питоновский пайплайн. В данной ситуации язык запросов к нам приходит из библиотек, таких как Pandas или pySpark.

В целом в pySpark мы видим схожий тип трансформации данных через язык запросов в духе:

df.filter(df.trip_type = return)\  .groupby(day)\  .agg({duration: 'mean'})\  .sort()

Где и что почитать

По самому питону вообще не проблема найти материалы для изучения. В сети огромное количество тьюториалов по pandas, pySpark и курсов по Spark (а также по самому DS). В целом тут материалы великолепно гуглятся и если бы мне нужно было выбрать один пакет, на котором стоит сфокусироваться то это был бы pandas, конечно. По связке DS+Python материалов тоже очень много.

Shell как язык запросов

Немало проектов по обработке и анализу данных, с которыми мне приходилось работать это, по сути, shell скрипты, которые вызывают код на питоне, на java и собственно сами shell команды. Поэтому в целом можно рассматривать пайплайны в баше/zsh/etc, как некоторый высокоуровневый запрос (можно туда, конечно, и циклы запихать, но это нетипично для DS кода на шелл языках), приведем простой пример мне нужно было сделать маппинг QID викидаты и полной ссылки на русскую и английскую вики, для этого я написал простой запрос из команд в баше и для вывода написал простой скприт на питоне, которые я собрал вместе вот так:

pv data/latest-all.json.gz | unpigz -c  | jq --stream $JQ_QUERY | python3 scripts/post_process.py "output.csv"

где

JQ_QUERY = 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2] =="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' 

Это был, по сути, весь пайплайн, который создавал нужный mapping, как мы видим все, работало в режиме потока:

• pv filepath дает прогресс бар на основе размера файла и передает его содержимое дальше
• unpigz -c читал часть архива и отдавал jq
  
• jq с ключом stream сразу выдавал результат и передавал его постпроцессору (так же как и с самым первым примером) на питоне
• внутри постпроцессор это простая машина состояний, которая форматировала вывод

Итого сложный пайплайн работающий в режиме потока на больших данных (0.5TB), без существенных ресурсов и сделан из простого пайплайна и пары тулзов.

Еще один важный совет: умейте хорошо и эффективно работать в терминале и писать на bash/zsh/etc.

Где пригодится? Да почти везде материалов для изучения опять же ОЧЕНЬ много в сети. В частности, вот эта моя предыдущая статья.

R scripting

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

R это среда статистических вычислений и язык статических вычислений и визуализации (согласно этому).


Взято отсюда. Кстати, рекомендую, неплохой материал.

Зачем дата саентисту знать R? По крайней мере, потому что есть огромный пласт людей не из IT, которые занимаются анализом данных на R. Мне встречалось в следующих местах:

• Фармацевтический сектор.
• Биологи.
• Финансовый сектор.
• Люди с чисто математическим образованием, занимающихся статами.
• Специализированные статистические модели и модели машинного обучения (которые часто можно найти только в авторской версии в виде R пакета).

Почему это фактически язык запросов? В том виде, в котором он часто встречается это фактически запрос на создание модели, включая чтение данных и фиксирование параметров запроса (модели), а также визуализация данных в таких пакетах как ggplot2 это тоже форма написания запросов.

Пример запросов для визуализации

ggplot(data = beav,        aes(x = id, y = temp,            group = activ, color = activ)) +  geom_line() +   geom_point() +  scale_color_manual(values = c("red", "blue"))

В целом многие идеи из R перекочевали в пакеты python, такие как pandas, numpy или scipy, как датафреймы и векторизация данных поэтому в целом очень многие вещи в R покажутся вам знакомыми и удобными.

Источников для изучения много, например, этот.

Графы знаний (Knowledge graph)

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

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

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


www.wikidata.org/wiki/Q42

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


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

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

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

SPARQL

Wiki:
SPARQL (рекурсивный акроним от англ. SPARQL Protocol and RDF Query Language) язык запросов к данным, представленным по модели RDF, а также протокол для передачи этих запросов и ответов на них. SPARQL является рекомендацией консорциума W3C и одной из технологий семантической паутины.

А реально это язык запросов к логическим унарным и бинарным предикатам. Вы просто условно указывается, что является фиксированным в логическом выражении, а что нет (очень упрощенно).

Сама база RDF (Resource Description Framework), над которой выполняются SPARQL запросы это тройка object, predicate, subject и запрос выбирает нужные тройки по указанным ограничениям в духе: найти такой X, что p_55(X, q_33) верно где, разумеется, p_55 это какое-то отношение с айди 55, а q_55 это объект с айди 33 (вот и весь сказ, опять же опуская всевозможные детали).

Пример представления данных:


Картинки и пример со странами вот отсюда.

Пример базового запроса



Фактически мы хотим найти значение переменной ?country, такой что для предиката
member_of, верно, что member_of(?country,q458), а q458 это ID европейского союза.

Пример реального запроса SPARQL внутри движка python:



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

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

Логические языки запросов

Подробнее по теме можно прочитать в моей статье тут. А здесь, мы лишь кратко разберем, почему логические языки хорошо подходят для написания запросов. По сути, RDF это просто набор вида логических утверждений вида p(X) и h(X,Y), а логический запрос имеет следующий вид:

output(X) :- country(X), member_of(X,EU).

Тут мы говорим, о создании нового предиката output/1 (/1 значит унарный), при условии, что для X верно, что country(X) т.е., Х это страна и также member_of(X,EU).

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

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

Пример фрагмента кода на логическом языке, обрабатывающем wikidata:

Мы снова в эфире и продолжаем цикл заметок Дата Сайентиста и сегодня представляю мой абсолютно субъективный чек-лист по выбору модели машинного обучения.

Это топ-10 свойств задачи и просто пунктов (без порядка в них), с точки зрения которых я начинаю выбор модели и вообще моделирование задачи по анализу данных.

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

А какая у нас вообще цель? Интерпретируемость и точность спектр

Источник

Пожалуй самый важный вопрос, который стоит перед дата сайентист перед тем, как начать моделирование это:

В чем, собственно, состоит бизнес задача?

Или исследовательская, если речь об академии, etc.

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

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

Но по сути нужно не просто прогнать Catboost / Xgboost / Random Forest и выбрать модельку, а понять, что хочет бизнес, какие у нас есть данные и как это будет применяться.

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

Тип самой задачи

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

• Exploratory analysis чистая аналитика имеющихся данных и тыканье палочкой
  
• Clustering собрать данные в группы по какой-тому общему признаку(ам)
  
• Regression нужно вернуть целочисленный результат или там вероятность события
  
• Classification нужно вернуть одну метку класса
  
• Multi-label нужно вернуть одну или более меток класса для каждой записи
  

Примеры

Данные: имеются два класса и набор записей без меток:


И нужно построить модель, которая разметит эти самые данные:


Или как вариант никаких меток нет и нужно выделить группы:


Как например вот здесь:


Картинки отсюда.

А вот собственно пример иллюстрирует разницу между двумя понятиями: классификация, когда N > 2 классов multi class vs. multi label


Взято отсюда

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

Точность и как она определена

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

Поэтому вопрос об измерении качества работы первичен! Или представьте, что у вас присутствует существенный дисбаланс в данных, класс А = 10%, а class B = 90%, тогда классификатор, который просто возвращает B всегда умеет 90% точность! Скорее всего это не то, чтобы хотели увидеть, обучая модель.

Поэтому критично определить метрику оценки модели включая:

• weight class как в примере выше, вес плохого кредита 5, а хорошего 1
• cost matrix возможно перепутать low и medium risk это не беда, а вот low risk и high risk уже проблема
• Должна ли метрика отражать баланс? как например ROC AUC
• А мы вообще считаем вероятности или прям метки классов?
• А может быть класс вообще один и у нас precision/recall и другие правила игры?

В целом выбор метрики обусловлен задачей и ее формулировкой и именно у тех, кто ставит эту задачу (обычно бизнес-люди) и надо выяснять и уточнять все эти детали, иначе на выходе будет швах.

Model post analysis

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


Однако, что если нам нужно знать направление большие значения признака A увеличивают принадлежность классу Z или наоборот? Назовем их направленные feature importance их можно получить у некоторых моделей, например, линейных (через коэффициенты на нормированных данных)

Для ряда моделей, основанных на деревьях и бустинге например, подходит метод SHapley Additive exPlanations.

SHAP

Это один из методов анализа модели, который позволяет заглянуть под капот модели.


Он позволяет оценить направление эффекта:


Причем для деревьев (и методах на них основанных) он точный. Подробнее об этом тут.

Noise level устойчивость, линейная зависимость, outlier detection и тд

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

Также признаки могут быть коллинеарны и присутствовать бессмысленные признаки разные модели по-разному на это реагируют. Приведем пример на классическом датасете German Credit Data (UCI) и трех простых (относительно) моделях обучения:

• Ridge regression classifier: классическая регрессия с регуляризатором Тихонова
• Decition trees
• CatBoost от Яндекса

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

Еще про DT а если чуть чуть поменять датасет? Feature importance может поменяться, так как decision trees вообще чувствительные методы, даже к перемешиванию данных.

Вывод: иногда проще лучше и эффективнее.

Масштабируемость

Действительно ли вам нужен Spark или нейросети с миллиардами параметров?

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

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

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



И конечно же необходимо учитывать, что если у вас и правда крупные данные, то модель должна быть способной работать на них как обучаться по батчам, либо иметь какие-то механизмы распределенного обучения (и тд). А там же не слишком терять в скорости при увеличении объема данных. Например, мы знаем, что kernel methods требуют квадрата памяти для вычислений в dual space если вы ожидаете увеличение размера данных в 10 раз, то стоит дважды подумать, а умещаетесь ли вы в имеющиеся ресурсы.

Наличие готовых моделей

Еще одна важнейшая деталь это поиск уже натренированных моделей, которые можно до-обучить, идеально подходит, если:

• Данных не очень много, но они очень специфичны для нашей задачи например, медицинские тексты.
• Тема в целом относительно популярна например, выделением тем текста много работ в NLP.
• Ваш подход допускает в принципе до-обучение как например с некоторым типом нейросетей.

Pre-trained модели как GPT-2 и BERT могут существенно упростить решение вашей задачи и если уже натренированные модели существуют крайне рекомендую не проходит мимо и использовать этот шанс.

Feature interactions и линейные модели

Некоторые модели лучше работают, когда между признаками (features) нет сложных взаимодействий например весь класс линейных моделей Generalized Additive Models. Есть расширение этих моделей на случай взаимодействия двух признаков под название GA2M Generalized Additive Models with Pairwise Interactions.

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



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

Package and model support

Многие крутые алгоритмы и модели из статей бывают оформлены в виде модуля или пакета для python, R и тд. Стоит реально дважды подумать, прежде чем использовать и в долгосрочной перспективе полагаться на такое решение (это я говорю, как человек написавший немало статей по ML с таким кодом). Вероятность того, что через год будет нулевая поддержка очень высок, ибо автору скорее всего сейчас необходимо заниматься другими проектами нет времени, и никаких incentives вкладываться в развитие модуля или репозитория.

В этом плане библиотеки а-ля scikit learn хороши именно тем, что у них фактически есть гарантированная группа энтузиастов вокруг и если что-то будет серьезно поломано это рано или поздно пофиксят.

Biases and Fairness

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

Условно, представьте упрощенную модель, которая просто считает цитирования статей и пусть историки друг друга цитируют активно среднее 100 цитат, а математики нет, у них среднее 20 и пишут вообще мало, тогда система распознает всех историков, как хороших ибо цитируемость высокая 100 > 60 (среднее), а математиков, как плохих потому что у них у всех цитируемость куда ниже среднего 20 < 60. Такая система вряд ли может показаться кому-то адекватной.

Классика сейчас предъявить логику принятия решения и тренировки моделей, которые борются с таким предвзятым подходом. Таким образом, для каждого решения у вас есть объяснение (условно) почему оно было принято и как вы собственно приложили усилия к тому, чтобы модель не сделала фигню (ELI5 GDPR).


Подробнее у гугла тут, или вот в статье тут.

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

Если какая-то тема заинтересовала больше остальных пишите в комментарии, будем идти в глубину. (DFS)!

Доброго времени суток, друзья!

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

• MDN Web Docs
• Современный учебник JavaScript Ильи Кантора
• Вы не знаете JS Кайла Симпсона
• JavaScript. Подробное руководство Дэвида Флэнагана
• Learning JavaScript Design Patterns by Addy Osmani

Однако, когда дело касается практических аспектов JavaScript, информацию приходится собирать буквально по крупицам. Собственно, этим я и занимался на протяжении последних 4-5 месяцев.

Предлагаю вашему вниманию Тотальный JavaScript.

Вот что вы найдете в этом репозитории:

• Огромное количество сниппетов (утилит, вспомогательных функций), разделенных по типам данных не могу назвать точного количества (порядка 4000 строк кода без комментариев и пробелов). Следует отметить, что не все функции являются настоящими сниппетами с точки зрения возможности их использования (как есть) в реальных приложениях, некоторые всего лишь эксперименты, демонстирующие те или иные (безграничные?) возможности языка. Коллекция все время пополняется
• 230 практических вопросов приводится пример кода, необходимо выполнить его в уме и решить, что будет выведено в консоль. Конечно, на практике мы редко занимается чем-то подобным, ведь гораздо легче и, главное, быстрее законсолить кусок подозрительного кода. Однако, на мой взгляд, умение решать подобные задачи как нельзя лучше демонстрирует понимание основных принципов и характерных особенностей работы JavaScript. В качестве недостатка этого раздела отмечу почти полное отсутствие вопросов по классам и this. Постараюсь в ближайшем будущем его устранить
• 68 задач разного уровня сложности подборка задач из учебника Ильи Кантора (большинство), немного адаптированных под нужды реальных приложений. Структура раздела, в основном, следует структуре учебника с небольшими лирическими отступлениями
• Паттерны проектирования подробное описание и примеры всех паттернов, которые называет Банда Четырех в своей книге Паттерны объектно-ориентированного программирования, на JavaScript (также в разделе имеются примеры на TypeScript смотрите исходный код). При подготовке данного раздела многое позаимствовано у Refactoring Guru, за что ему (или им) огромное спасибо
• Что за черт, JavaScript? список тонких моментов работы JavaScript. Этот раздел не слишком актуален, учитывая возможности современного JS, однако интересен тем, что позволяет узнать, каким был язык раньше, до того, как завоевал мир веб-разработки. Де факто, он остается прежним, но следование простым правилам (например, использование const или let вместо var или "===" вместо "==") позволяет решить большую часть проблем, с которыми сталкивались разработчики в прошлом

Уверен, что каждый найдет для себя что-нибудь интересное.

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

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

Благодарю за внимание. Всех, кому дым отечества и сладок, и приятен, с наступающим праздником.

Можете ли вы поверить, что с момента моего последнего списка инструментов прошло 6 лет? Инструменты изменились, многие из них доступны онлайн, но, честно говоря, для составления нового списка инструментов требуется ОЧЕНЬ МНОГО РАБОТ. Но я смог, вот список на 2020-2021 годы. Это инструменты в моей папке Utils. Я создал папку d:\dropbox\utils и добавил ее в свой PATH. Таким образом, он будет на всех моих компьютерах, и я могу мгновенно добраться до любого из них.

Это обновленный до версии 2020-21 мой список 2003, 2005, 2006, 2007, 2009, 2011 и 2014 годов, который в настоящее время включает все остальные мои списки. Я занимаюсь этим более 17 лет. Вау. Думаю, стоит тратить на это больше времени.

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

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

Эту статью написал наш коллега Скотт. Вот версия на английском. Ну а сам список под катом.

Утилиты, меняющие жизнь и работу

• Подсистема Windows для Linux. Невозможно переоценить то, как WSL/WSL2 поставил вишенку на вершину Windows 10. Интеграция с Windows просто фантастическая. Это также НАМНОГО быстрее, чем запуск виртуальной машины.
• Терминал Windows. Наконец-то в Windows появился современный терминал. Вы можете запускать такие оболочки, как командная строка, PowerShell и подсистема Windows для Linux (WSL).
• Windows PowerToys они вернулись и должны быть встроены в Windows.
• VS Code Visual Studio Code супер-быстр и является моим редактором кода goto. Я до сих пор иногда использую блокнот и часто использую полную Visual Studio, но VS Code похож на Tesla в мире редакторов кода. Ознакомьтесь с моими любимыми расширениями VS Code ниже.
• ZoomIt Настоящая классика, но также и ответ на вопрос 1, который мне задают. Как вы рисуете на экране, когда показываете свой экран?
• Winget это apt-get для Windows. Подобно choco, который я использовал в прошлом, WinGet будет включен в Windows 10 и будет иметь массу приятных функций.
• QuickLook Бесплатно в Магазине Windows, просто выделите файл в Проводнике и нажмите Пробел, чтобы получить превью.

Крутые утилиты для разработчиков (в большинстве своем .NET, но не только)

• CodeTrack это бесплатный профилировщик производительности и анализатор выполнения .NET. Он работает практически со всеми версиями .NET и даст вам полное представление о том, как работает ваш код!
• LINQPad интерактивно запрашивайте базы данных с помощью LINQ с помощью этого инструмента от Джозефа Альбахари.
• WinMerge WinMerge становится все лучше и лучше. Он сравнивает файлы и папки и помогает вам объединить конфликтующие файлы исходного кода.
• WinDbg низкоуровневый и классический, но также новый и свежий! WinDbg теперь в Магазине Windows со ВСЕМИ НОВМИ ВИЗУАЛАМИ и многим другим!
• Insomnia и Nightingale отличные альтернативы Postman для REST API!
• Обозреватель пакетов NuGet это приложение позволяет просматривать пакеты NuGet из онлайн-канала и просматривать содержимое пакетов.
• WireShark Что происходит в сети? WireShark знает.
• GitHub Desktop Gits, кхм, прочь! Смотрите Git 101 на YouTube.

Полезные утилиты Windows

• Ear Trumpet фантастический продвинутый регулятор громкости для Windows! Если вы когда-нибудь хотели, чтобы громкость в Windows увеличилась до 11, то Ear Trumpet это то приложение.
• Teracopy хотя я чаще всего использую отличные встроенные функции копирования Windows 10, когда я хочу переместить МНОГО файлов как можно быстрее, ничто не сравнится с TeraCopy, приложением, которое делает именно это быстро перемещает файлы. Контроль очереди отличный.
• AutoHotKey это крошечная, удивительно быстрая бесплатная утилита с открытым исходным кодом для Windows. Она позволяет автоматизировать все, от нажатия клавиш до мыши. Программирование для непрограммистов. Это полная система автоматизации для Windows без разочарований из-за VBScript.
• 7-Zip все закончилось, и 7zip выиграл. Время подняться на борт. Формат 7z быстро становится форматом сжатия, который выбирают самые требовательные пользователи. Обычно сжатие на 2-10% лучше, чем у ZIP. Это приложение прекрасно интегрируется в проводник Windows и открывает практически ВСЕ, что вы когда-либо захотите открыть, от TAR до ISO, от RAR до CAB.
• Paint.NET забытая Microsoft программа Paint, написанная на .NET. Это 80% Photoshop, и это бесплатно. Вы можете поддержать автора, получив версию из Магазина Windows, и она будет обновляться автоматически!
• NimbleText регулярные выражения сложны, и я не очень умен. NimbleText позволяет мне делать сумасшедшие вещи с большими объемами текста без особой боли.
• Markdown Monster хотя мне нравится VSCode, Markdown Monster делает одну вещь невероятно хорошо. Markdown.
• Fiddler простой, чистый и мощный прокси отладки для проверки HTTP между здесь и там. Он даже поддерживает изучение SSL-трафика.
• Коллекция утилит NirSoft почти все, что делает NirSoft, заслуживает внимания. Мои любимые MyUninstaller, замена для удаления программ, и WhoIsThisDomain.
• Ditto Clipboard Manager WindowsKey+V великолепен и близок, но Ditto продолжает продвигать управление буфером обмена в Windows.
• TaskbarX он буквально центрирует кнопки панели задач. Я люблю это. Open Source, но также доступно и за 1 доллар в Магазине Windows.
• ShellEx View меню вашего проводника, вызываемое правой кнопкой мыши, загромождено, это поможет вам его не загромождать!
• OneCommander, Midnight Commander и Altap Salamander. Существует множество замечательных переосмыслений проводника Windows. OneCommander и Altap Salamander делают это, а Midnight Commander делает это для командной строки/CLI.
• WinDirStat классический, но необходимый. Что занимает все это место? Спойлер это Call of Duty.
• FileSeek и Everything мгновенный поиск во всем!
• Мне нравится Win+Share+S для скриншотов, но я также рекомендую ShareX, Greenshot и Lightshot.
• Для анимированных гифок попробуйте screen2gif или LICEcap!
• Alt-Tab Terminator переводит ваш Alt-Tab на новый уровень с большим предварительным просмотром и поиском
• PureText PureText вставляет простой текст в чистом виде. Свободный и славный. Спасибо Стив Миллер.
• Я все еще использую FTP, SCP и SFTP, и я использую для этого WinSCP! Это бесплатно или всего 10 долларов, чтобы получить его в Магазине Windows и поддержать автора!
• VLC Player лучший и по-прежнему лучший. Проигрывает все и везде.
• PSReadline в хорошем смысле делает PowerShell более запутанным.
• Yori и все утилиты Малкольма Смита Yori это переосмысление cmd.exe!

Расширения Visual Studio Code

• GitLens великолепен. Просто делает Git и VS радостью и добавляет тысячу крошечных прекрасных функций, которые заставят вас улыбнуться. Вы удивитесь, почему это не встроено.
• Version Lens у вас есть последние версии пакета? Теперь узнать легко.
• CodeSnap скриншоты, специально созданные для того, чтобы делать ваш код красивым.
• Обозреватель тестов .NET Core делает модульное тестирование с .NET на VS Code намного приятнее.
• Arduino для VS Code расширение Arduino упрощает разработку, построение, развертывание и отладку ваших эскизов Arduino в Visual Studio Code! Так мило.
• Coverage Gutters это удивительное расширение показывает, какой код покрывается модульным тестом, а какой нет. Райану нужна помощь, так что узнайте, подходит ли вам этот проект OSS!
• Docker для VS Code обозреватель контейнеров, менеджер и средство развертывания, прямо из VS.
• GitHistory еще одно приятное дополнение для Git, которое показывает ваш журнал Git.
• HexDump мне это нужно больше, чем я хотел бы признать.
• LiveShare прекратите screen-sharing и code и context sharing!
• PowerShell для VS отличная замена PowerShell ISE
• Remote Containers это УДИВИТЕЛЬНОЕ РАСШИРЕНИЕ, которое вы должны попробовать, если у вас есть Docker, но у него ужасное неописательное имя. Но чтобы поверить, это нужно увидеть. Возможно, это Контейнеры разработки Visual Studio, я не уверен. Откройте папку и прикрепите к контейнеру разработки. Никаких установок, просто вы отлаживаете Rust, Go, C#, что угодно, НИЧЕГО не устанавливая. Удивительно.
• Удаленный SSH еще один из семейства расширений VS Remote, он позволяет использовать любой удаленный SSH-сервер в качестве среды разработки.
• Удаленный WSL редактируйте, отлаживайте и создавайте код из Windows используя Linux!
• И, наконец, Yonc, моя текущая тема VS Code. Вдохновлен Бейонсе.

Несколько вещей, которые мне очень нравятся

• RescueTime Вы продуктивны? Вы тратите время на то, что вам нужно? RescueTime отслеживает, что вы делаете, и сообщает вам об этом с помощью фантастических отчетов. Очень хороший материал, если вы пытаетесь использовать GTD и TCB.
• Carnac эта замечательная небольшая утилита с открытым исходным кодом показывает горячие клавиши, которые вы нажимаете, при их нажатии, показывая небольшие оверлеи в углу. Я использую его во время кодирования презентаций.
• DOSBox Когда вы плывете в мире 64-битной супер-Windows-10-Pro, иногда вы забываете, что есть некоторые старые программы, которые вы больше не можете запускать сейчас, когда DOS на самом деле нет. Войдите в DOSBox, эмулятор DOS x86! Уфф, теперь я могу играть в Bard's Tale из 1988 года на Windows 10 в 2021 году! Посетите Gog.com, чтобы найти множество классических произведений на базе DOSBox
• Ах да, и, наконец, Windows Sandbox у вас это уже есть, но вы даже не подозреваете об этом! Вы можете за СЕКУНД запустить копию своей машины с Windows 10 в безопасной песочнице, и когда вы ее закроете, она исчезнет. Пуф. Отлично подходит для тестирования странных инструментов и утилит, которые некоторые рандомы во всяких блогах советуют вам попробовать.

Спасибо за внимание и привет из Сиэтла!

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



Недавно я смотрел два доклада на эту тему: от Юлии Николаевой из iSpring и Антона Губарева из Skyeng. Так как с Антоном мы работаем в одной компании, для своего подкаста я решил поговорить с Юлей.



Ниже текстовая расшифровка основных идей из разговора.

Мы взвесили причины, по которым хотели перейти в микросервисы, и настоящие проблемы, которые мешали нам жить в монолитной архитектуре

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

Это произошло с нашим проектом: он стартовал в 2009-м, но долго не было людей и времени, чтобы бороться с неконтролируемым разрастанием кодовой базы. А к 2018-му стало понятно: пора уже как-то реструктуризировать монолит.

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

Не было как такового нормального CI/CD, не было ни докера, ни кубернетеса вообще ничего такого.

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

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

У нас все усугублялось тем, что кусок легаси написан Symfony 1.4 с использованием Propel 2, который не так просто использовать в парадигме DDD (Domain Driven Design). А нам очень хотелось DDD. Для этого хорошо подходит ORM Doctrine, которую к легаси так просто не прикрутишь.

Мы решили скрестить ужа с ежом и теперь живем с двумя фреймворками.

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

Буквально каждый день, на каждом шагу мы встречали множество вопросов, которые не знали, как решить

Мы, тимлиды, сначала вдвоем, потом втроем разрабатывали функционал в этой новой архитектуре. Было много вопросов. Начиная с того, как организовать папки в проекте: правда, когда сделали и поняли, как и зачем, находили в интернете просто массу источников, в которых все это написано. Наверное, не так искали)

Параллельно часть команды разработчиков ушла в девопсы.

Они занялись переездом в кубернетес, докер и все такое.

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

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

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

На все у нас ушло, наверное, три с половиной месяца.

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

И ура! Мы можем писать фичи в 3-4 потока командой из 12 бэкендеров.


Сергей: В PHP мы не можем дать программисту по рукам и запретить использовать какой-то внутренний класс другого модуля. Это же все держится на устных договоренностях внутри команды. Как это все организовать?

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

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

Мы нашли такую утилиту deptrac статический анализатор кода, который помогает контролировать зависимости.

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

Сергей: А как такую архитектуру мэйнтэйнить?

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

Сергей: БД у нас одна, проект у нас один. Что мне делать, если в моем модуле нужны данные из нескольких других контекстов?

Юлия: Это один из самых сложных вопросов наверное, как в модульной, так и в микросервисной архитектуре. Мы пытались в одном из случаев реализовать объединение данных из разных API: сделали запросы, объединение в памяти, сортировку, фильтрацию. Работало жутко медленно.

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

Сергей: И здесь мы подходим к проблеме с дублированием кода...

Юлия: Дублирование возникает, например, если у нас есть слой, который авторизует операции во всех контекстах и мы его дублируем в каждом контексте. То есть, у нас есть практически одинаковый код, который запрашивает: А есть ли права у пользователей. Но мы считаем, что это достаточно приемлемое дублирование.

Сергей: А что делать, когда одному модулю нужно выполнить действие в другом модуле? Например, при оплате изменить баланс, создать уведомление это все разные контексты. Как в монолите быть с этим?

Юлия: Ты перечислил кейсы, которые хорошо укладываются в событийную модель. У нас много через асинхронные ивенты сделано. Если контекст не должен знать ничего про то, что произойдет в других контекстах, будет событие, которое обработает все заинтересованные в нем лица. Если действие тесно связано с выполняемой операцией и про ее контекст нужно знать, напрямую вызывает метод API.

Все как в микросервисной архитектуре, грубо говоря.

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

Сергей: Но если приложение постоянно усложняется фичами и контекстами, модульный монолит все равно лишь промежуточный шаг к микросервисам?

Юлия: Да, конечно. Если подразумевается, что приложение будет непрерывно расти, если команды будут расти, это естественно. Например, у нас возникла проблема, что автотесты нереально долго выполняются перед релизом, а если что-то отвалится приходится повторно это все запускать.

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

P.S. Больше выпусков подкаста Между скобок с интересными людьми из мира PHP можно найти здесь.

Изображение: Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

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

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

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

• как использовать утилиту checksec для поиска уязвимостей;
• как использовать компилятор gcc для устранения найденных уязвимостей.

Установка checksec

Для Fedora OS и других систем на базе RPM:

$ sudo dnf install checksec

Для систем на базе Debian используйте apt.

Быстрый старт с checksec

Утилита сhecksec состоит из единственного скриптового файла, который, впрочем, довольно большой. Благодаря такой прозрачности вы можете узнать, какие системные команды для поиска уязвимостей в бинарных файлах выполняются под капотом:

$ file /usr/bin/checksec/usr/bin/checksec: Bourne-Again shell script, ASCII text executable, with very long lines$ wc -l /usr/bin/checksec2111 /usr/bin/checksec

Давайте запустим checksec для утилиты просмотра содержимого каталогов (ls):

$ checksec --file=/usr/bin/ls<strong>RELRO      STACK CANARY   NX      PIE       RPATH   RUNPATH   Symbols    FORTIFY Fortified    Fortifiable  FILE</strong>Full RELRO   Canary found   NX enabled  PIE enabled   No RPATH  No RUNPATH  No Symbols    Yes  5    17       /usr/bin/ls

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

Первая строка это шапка таблицы, в которой перечислены различные свойства безопасности RELRO, STACK CANARY, NX и так далее. Вторая строка показывает значения этих свойств для бинарного файла утилиты ls.

Hello, бинарник!

Я скомпилирую бинарный файл из простейшего кода на языке С:

#include <stdio.h>int main(){printf(Hello World\n);return 0;}

Обратите внимание, что пока я не передал компилятору ни одного флага, за исключением -o (он не относится к делу, а просто говорит, куда выводить результат компиляции):

$ gcc hello.c -o hello$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=014b8966ba43e3ae47fab5acae051e208ec9074c, for GNU/Linux 3.2.0, not stripped$ ./helloHello World

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

ls (для него я запускал утилиту выше):$ checksec --file=./hello<strong>RELRO      STACK CANARY   NX      PIE       RPATH   RUNPATH   Symbols     FORTIFY Fortified    Fortifiable   FILE</strong>Partial RELRO  No canary found  NX enabled  No PIE     No RPATH  No RUNPATH  85) Symbols    No  0    0./hello

Checksec позволяет использовать различные форматы вывода, которые вы можете указать с помощью опции --output. Я выберу формат JSON и сделаю вывод более наглядным с помощью утилиты jq:

$ checksec --file=./hello --output=json | jq{./hello: {relro: partial,canary: no,nx: yes,pie: no,rpath: no,runpath: no,symbols: yes,fortify_source: no,fortified: 0,fortify-able: 0}}

Анализ (checksec) и устранение (gcc) уязвимостей

Созданный выше бинарный файл имеет несколько свойств, определяющих, скажем так, степень его уязвимости. Я сравню свойства этого файла со свойствами бинарника ls (тоже указаны выше) и объясню, как это сделать с помощью утилиты checksec.

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

1. Отладочные символы

Начну с простого. Во время компиляции в бинарный файл включаются определённые символы. Эти символы используются при разработке программного обеспечения: они нужны для отладки и исправления ошибок.

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

Сhecksec показывает, что отладочные символы присутствуют в моём бинарнике, но их нет в файле ls.

$ checksec --file=/bin/ls --output=json | jq | grep symbolssymbols: no,$ checksec --file=./hello --output=json | jq | grep symbolssymbols: yes,

То же самое может показать запуск команды file. Символы не удалены (not stripped).

$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=014b8966ba43e3ae47fab5acae051e208ec9074c, for GNU/Linux 3.2.0, <strong>not stripped</strong>

Как работает checksec

Запустим эту команду с опцией --debug:

$ checksec --debug --file=./hello

Так как утилита checksec это один длинный скрипт, то для его изучения можно использовать функции Bash. Выведем команды, которые запускает скрипт для моего файла hello:

$ bash -x /usr/bin/checksec --file=./hello

Особое внимание обратите на echo_message вывод сообщения о том, содержит ли бинарник отладочные символы:

+ readelf -W --symbols ./hello+ grep -q '\.symtab'+ echo_message '\033[31m96) Symbols\t\033[m ' Symbols, ' symbols=yes' 'symbols:yes,'

Утилита checksec использует для чтения двоичного файла команду readelf со специальным флагом --symbols. Она выводит все отладочные символы, которые содержатся в бинарнике.

$ readelf -W --symbols ./hello

Из содержимого раздела .symtab можно узнать количество найденных символов:

$ readelf -W --symbols ./hello | grep -i symtab

Как удалить отладочные символы после компиляции

В этом нам поможет утилита strip.

$ gcc hello.c -o hello$$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=322037496cf6a2029dcdcf68649a4ebc63780138, for GNU/Linux 3.2.0, <strong>not stripped</strong>$$ strip hello$$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=322037496cf6a2029dcdcf68649a4ebc63780138, for GNU/Linux 3.2.0, <strong>stripped</strong>

Как удалить отладочные символы во время компиляции

При компиляции используйте флаг -s:

$ gcc -s hello.c -o hello$$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=247de82a8ad84e7d8f20751ce79ea9e0cf4bd263, for GNU/Linux 3.2.0, <strong>stripped</strong>

Убедиться, что символы удалены, можно и с помощью утилиты checksec:

$ checksec --file=./hello --output=json | jq | grep symbolssymbols: no,

2. Canary

Canary (осведомители) это секретные значения, которые хранятся в стеке между буфером и управляющими данными. Они используются для защиты от атаки переполнения буфера: если эти значения оказываются изменены, то стоит бить тревогу. Когда приложение запускается, для него создаётся свой стек. В данном случае это просто структура данных с операциями push и pop. Злоумышленник может подготовить вредоносные данные и записать их в стек. В этом случае буфер может быть переполнен, а стек повреждён. В дальнейшем это приведёт к сбою работы программы. Анализ значений canary позволяет быстро понять, что произошёл взлом и принять меры.

$ checksec --file=/bin/ls --output=json | jq | grep canarycanary: yes,$$ checksec --file=./hello --output=json | jq | grep canarycanary: no,$Чтобы проверить, включен ли механизм canary, скрипт checksec запускает следующую команду:$ readelf -W -s ./hello | grep -E '__stack_chk_fail|__intel_security_cookie'

Включаем canary

Для этого при компиляции используем флаг -stack-protector-all:

$ gcc -fstack-protector-all hello.c -o hello$ checksec --file=./hello --output=json | jq | grep canarycanary: yes,

Вот теперь сhecksec может с чистой совестью сообщить нам, что механизм canary включён:

$ readelf -W -s ./hello | grep -E '__stack_chk_fail|__intel_security_cookie'2: 0000000000000000   0 FUNC  GLOBAL DEFAULT UND __stack_chk_fail@GLIBC_2.4 (3)83: 0000000000000000   0 FUNC  GLOBAL DEFAULT UND __stack_chk_fail@@GLIBC_2.4$

3. PIE

Включённое свойство PIE позволяет произвольно размещать в памяти исполняемый код независимо от его абсолютного адреса:

PIE (Position Independent Executable) исполняемый позиционно-независимый код. Возможность предсказать, где и какие области памяти находятся в адресном пространстве процесса играет на руку взломщикам. Пользовательские программы загружаются и выполняются с предопределённого адреса виртуальной памяти процесса, если они не скомпилированы с опцией PIE. Использование PIE позволяет операционной системе загружать секции исполняемого кода в произвольные участки памяти, что существенно усложняет взлом.

$ checksec --file=/bin/ls --output=json | jq | grep piepie: yes,$ checksec --file=./hello --output=json | jq | grep piepie: no,

Часто свойство PIE включают только при компиляции библиотек. В выводе ниже hello помечен как LSB executable, а файл стандартной библиотеки libc (.so) как LSB shared object:

$ file hellohello: ELF 64-bit <strong>LSB executable</strong>, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=014b8966ba43e3ae47fab5acae051e208ec9074c, for GNU/Linux 3.2.0, not stripped$ file /lib64/libc-2.32.so/lib64/libc-2.32.so: ELF 64-bit <strong>LSB shared object</strong>, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4a7fb374097fb927fb93d35ef98ba89262d0c4a4, for GNU/Linux 3.2.0, not stripped

Checksec получает эту информацию следующим образом:

$ readelf -W -h ./hello | grep EXECType:               EXEC (Executable file)

Если вы запустите эту же команду для библиотеки, то вместо EXEC увидите DYN:

$ readelf -W -h /lib64/libc-2.32.so | grep DYNType:               DYN (Shared object file)

Включаем PIE

При компиляции программы нужно указать следующие флаги:

$ gcc -pie -fpie hello.c -o hello

Чтобы убедиться, что свойство PIE включено, выполним такую команду:

$ checksec --file=./hello --output=json | jq | grep piepie: yes,$

Теперь у нашего бинарного файла (hello) тип сменится с EXEC на DYN:

$ file hellohello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb039adf2530d97e02f534a94f0f668cd540f940, for GNU/Linux 3.2.0, not stripped$ readelf -W -h ./hello | grep DYNType:               DYN (Shared object file)

4. NX

Средства операционной системы и процессора позволяют гибко настраивать права доступа к страницам виртуальной памяти. Включив свойство NX (No Execute), мы можем запретить воспринимать данные в качестве инструкций процессора. Часто при атаках переполнения буфера злоумышленники помещают код в стек, а затем пытаются его выполнить. Однако, если запретить выполнение кода в этих сегментах памяти, можно предотвратить такие атаки. При обычной компиляции с использованием gcc это свойство включено по умолчанию:

$ checksec --file=/bin/ls --output=json | jq | grep nxnx: yes,$ checksec --file=./hello --output=json | jq | grep nxnx: yes,

Чтобы получить информацию о свойстве NX, checksec вновь использует команду readelf. В данном случае RW означает, что стек доступен для чтения и записи. Но так как в этой комбинации отсутствует символ E, на выполнение кода из этого стека стоит запрет:

$ readelf -W -l ./hello | grep GNU_STACKGNU_STACK   0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10

Отключение NX

Отключать свойство NX не рекомендуется, но сделать это можно так:

$ gcc -z execstack hello.c -o hello$ checksec --file=./hello --output=json | jq | grep nxnx: no,

После компиляции мы увидим, что права доступа к стеку изменились на RWE:

$ readelf -W -l ./hello | grep GNU_STACKGNU_STACK   0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10

5. RELRO

В динамически слинкованных бинарниках для вызова функций из библиотек используется специальная таблица GOT (Global Offset Table). К этой таблице обращаются бинарные файлы формата ELF (Executable Linkable Format). Когда защита RELRO (Relocation Read-Only) включена, таблица GOT становится доступной только для чтения. Это позволяет защититься от некоторых видов атак, изменяющих записи таблицы:

$ checksec --file=/bin/ls --output=json | jq | grep relrorelro: full,$ checksec --file=./hello --output=json | jq | grep relrorelro: partial,

В данном случае включено только одно из свойств RELRO, поэтому checksec выводит значение partial. Для отображения настроек сhecksec использует команду readelf.

$ readelf -W -l ./hello | grep GNU_RELROGNU_RELRO   0x002e10 0x0000000000403e10 0x0000000000403e10 0x0001f0 0x0001f0 R  0x1$ readelf -W -d ./hello | grep BIND_NOW

Включаем полную защиту (FULL RELRO)

Для этого при компиляции нужно использовать соответствующие флаги:

$ gcc -Wl,-z,relro,-z,now hello.c -o hello$ checksec --file=./hello --output=json | jq | grep relrorelro: full,

Всё, теперь наш бинарник получил почётное звание FULL RELRO:

$ readelf -W -l ./hello | grep GNU_RELROGNU_RELRO   0x002dd0 0x0000000000403dd0 0x0000000000403dd0 0x000230 0x000230 R  0x1$ readelf -W -d ./hello | grep BIND_NOW0x0000000000000018 (BIND_NOW) 

Другие возможности checksec

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

Проверка нескольких файлов

Нет необходимости для каждого файла запускать отдельную команду. Можно запустить одну команду сразу для нескольких бинарных файлов:

$ checksec --dir=/usr/bin

Проверка процессов

Утилита checksec также позволяет анализировать безопасность процессов. Следующая команда отображает свойства всех запущенных программ в вашей системе (для этого нужно использовать опцию --proc-all):

$ checksec --proc-all

Вы также можете выбрать для проверки один процесс, указав его имя:

$ checksec --proc=bash

Проверка ядра

Аналогично вы можете анализировать уязвимости в ядре вашей системы.

$ checksec --kernel

Предупреждён значит вооружён

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

---

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

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

Bat это клон команды cat с дополнительной разметкой и подсветкой синтаксиса для большого количества языков программирования, а также интеграцией Git для отображения изменений файлов.

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

Fd это простой, быстрый и удобный инструмент, предназначенный для более простой и быстрой работы по сравнению с командой find.

Procs это современная замена ps, программы командной строки по умолчанию в Unix / Linux для получения информации о процессах. По умолчанию он обеспечивает удобный, понятный для человека (и цветной) формат вывода.

Sd это интуитивно понятный инструмент командной строки для поиска и замены, он является альтернативой sed. sd имеет более простой синтаксис для замены всех вхождений и использует удобный синтаксис регулярных выражений, который вы уже знаете из JavaScript и Python. Sd также в 2-11 раз быстрее, чем sed.

Dust опрятная версия дефолтного du, c удобной записью памяти, цветом и отступами.

Starship очень приятный prompt который легко накатывается поверх zsh, fish, bash и прочего.
Легкая настройка через Toml файл (https://github.com/toml-lang/toml) с кучей уже поддерживаемых форматов и конфигов (https://starship.rs/config/#prompt).

Ripgrep быстрый поиск с возможностью замены по содержимому в файлах, аналог GREP, ASK, написан на RUST, понимает регулярные выражения, игнорирует ресурсы указанные в .gitignore, автоматически пропускает бинарные, скрытые файлы.

Ripgrep-all Инструмент поиска, ориентированный на строки, который позволяет вам искать по регулярному выражению во множестве типов файлов. Ripgrep-all является оберткой над ripgrep и позволяет ему искать в pdf, docx, sqlite, jpg, субтитрах фильмов (mkv, mp4) и т. д.

Grex это инструмент командной строки и библиотека для генерации регулярных выражений из предоставленных пользователем тестовых примеров.

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

Jq это легкий и гибкий JSON-процессор командной строки.

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

HTTPie HTTP клиент для командной строки, с поддержкой json, понятным интерфейсом, подсветкой синтаксиса и прочим.

Rebound это инструмент командной строки, который мгновенно извлекает результаты Stack Overflow при возникновении исключения. Просто используйте команду rebound для запуска вашего исполняемого файла.

HTTP Prompt это интерактивный HTTP-клиент командной строки, созданный на основе prompt_toolkit и HTTPie с более чем 20 темами. Его основные функции включают в себя автоматическое заполнение, подсветку синтаксиса, автоматические куки, Unix-подобные конвейеры, совместимость с HTTpie, http-подсказка, которая сохраняется между сеансами и интеграцию OpenAPI / Swagger.

shell2http Простой веб сервер для удаленного выполнения команд.

reachable инструмент, который поможет вам проверить, работает ли домен или нет.

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

Clog-cli утилита для создания changelogs из истории коммитов Git.

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

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

ngrok Безопасные интроспективные туннели к localhost.

teleconsole поделитесь своим терминалом UNIX.

tmate Мгновенный доступ к терминалу (tmux).

P.S. Пишите утилиты, которые стоит добавить в список.

Shadow запускает реальные приложения, такие как Tor или Bitcoin. Изначально он создавался для экспериментов над Tor, но вырос в крупный проект, который широко используется для исследований в таких местах, как Кембриджский и Колумбийский университеты. В этой статье будут рассмотрены главные особенности проекта, описаны его плюсы и минусы, а также разобран простой пример работы.

Основной задачей проекта является исследование или создание прототипов распределённых или одноранговых систем, включая протоколы многосторонних вычислений. Для этого Shadow связывается с прикладным программным обеспечением и нативно выполняет код приложения во время моделирования, обеспечивая достоверные эксперименты и точные результаты. После чего программа моделирует и запускает распределённые сети на одной машине Linux или настроенном AMI на Amazon EC2. Это упрощает управление экспериментами и сохраняет при этом фокус на результатах.

Фичи

• Создает изолированную среду моделирования, в которой виртуальные хосты могут связываться друг с другом, но не с Интернетом.
  
• Изначально выполняет реальные приложения, такие как Tor и Bitcoin
  
• Обеспечивает эффективные, точные и контролируемые эксперименты
  
• Моделирует топологию сети, задержку и пропускную способность
  
• Работает без рута на одной машине Linux
  
• Имитирует несколько виртуальных хостов в виртуальном времени
  
• Имитирует сеть (стек TCP) и задержки обработки ЦП
  
• Может запускать частные сети Tor с моделями пользователей / трафика на основе Tor metrics
  

Особенности

Shadow моделирует интернет, используя реальные задержки, записанные в результате измерений пинга на PlanetLab. Собранные данные дают распределение попарных задержек между узлами. Затем происходит классификация всех узлов по географическим регионам и объединение распределения узлов между каждой областью. Это приближение формирует модель Интернета и даётся в качестве входных данных. Данная модель основана на конкретных измерениях между конкретными точками в определённое время. Если бы интернет-перегрузка в то время была нехарактерно высокая или низкая, то модель исказит результаты. В частности, эксперименты, которые связаны с задержкой, пропускной способностью или внутренней работой конкретной реализации TCP, могут потребовать более точное моделирование, что достаточно затратно по времени.

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

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

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



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

Пример работы

Процесс установки подробно описан на сайте документации.

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

cd resource/examples/rm -rf shadow.data shadow.logshadow --tcp-windows=1 shadow.config.xml > window1.logmv shadow.data window1.datashadow --tcp-windows=1000 shadow.config.xml > window1000.logmv shadow.data window1000.data

Чтобы распарсить логи выполнения, необходимо выполнить следующие команды:

python ../../src/tools/parse-shadow.py --prefix=window1.results window1.logpython ../../src/tools/parse-shadow.py --prefix=window1000.results window1000.log

Каждый из каталогов window1.results/ и window1000.results/ теперь содержит статистические данные, извлечённые из логов. Теперь можно объединить и визуализировать эти результаты с помощью скрипта plot-shadow.py, который находится по пути ../src/tools/:

python ../../src/tools/plot-shadow.py --prefix "window" --data window1.results/ "1 packet" --data window1000.results/ "1000 packets"

Заключение

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

---

На правах рекламы

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

Подписывайтесь на наш чат в Telegram.

Мы запускаем серию полезных статей, посвященных утилитам nanoCAD. С их помощью процесс подготовки чертежей станет проще и быстрее.
Вы узнаете:
как использовать инструмент Дополнительные средства nanoCAD для экспресс- редактирования;
как быстро заменить слово при помощи команды Найти и заменить;
как соединить разбитые на примитивы dwg-таблицы с помощью команды Распознавание таблиц;
как за один клик экспортировать часть графики в новый файл;
какие существуют способы создания массива объектов.
Следите за каналом. А сегодня мы обсудим Дополнительные средства nanoCAD.


Дополнительные средства nanoCAD это инструменты, подобные самым популярным и востребованным инструментам Express Tools, реализованным в составе зарубежного аналога. Отличительной особенностью этих утилит в nanoCAD является то, что они устанавливаются по умолчанию, тогда как пользователю зарубежного решения приходится контролировать их появление в интерфейсе программы при инсталляции. Набор дополнительных средств включает в себя 10 наиболее часто используемых утилит. Далее мы рассмотрим функционал каждой из них и приведем примеры работы.
В классическом интерфейсе nanoCAD дополнительные средства расположены в меню Редактирование Дополнительные средства (рис. 1). В ленточном они распределены по разным группам в зависимости от объектов, с которыми работает та или иная утилита.

Рис. 1. Расположение дополнительных средств nanoCAD в классическом интерфейсе

Дополнительные средства nanoCAD: функционал и примеры работы

Утилита 1. Преобразование атрибутов блока в текст

Командная строка: РАЗБИТЬАТРБЛОКА (BURST)
Команда позволяет извлечь текстовую информацию из атрибутов блоков при их разбиении. Существенное отличие от похожей команды Разбивка (Explode) состоит в том, что при использовании последней значения атрибутов блока удаляются и остаются только имена. А команда РАЗБИТЬАТРБЛОКА преобразовывает значения атрибутов блока в однострочные или многострочные тексты. Значения поля, вставленного при создания атрибута блока, также перебрасываются в текст. Скрытые атрибуты блоков не преобразовываются.

Порядок выполнения команды:
выберите блок с атрибутами (рис. 2).

Рис. 2. Выбранный блок
Атрибуты, представленные в этом блоке, показаны на рис. 3;

Рис. 3. Атрибуты выбранного блока
запустите команду Преобразовать атрибуты блока в текст.

Рис. 4. Преобразование атрибутов блока в текст
Как видно на рис. 4, атрибуты блока преобразовались в Мтекст и мы можем продолжить редактирование.
Результат работы команды Разбивка с этим же блоком показан на рис. 5.

Рис. 5. Разбивка блока с атрибутами

Утилита 2. Конвертировать текст в Мтекст

Командная строка: ТЕКСТвМТЕКСТ, Т2МТ (TEXT2MTEXT, T2MT)
Команда позволяет преобразовать выбранные однострочные текстовые объекты в многострочный текст. При конвертации однострочные текстовые объекты удаляются из документа и вставляются в один многострочный текстовый объект. При этом в многострочном тексте сохраняются значения высоты, цвета, коэффициента сжатия, угла наклона текстовых объектов.

Порядок выполнения команды:
выберите однострочные тексты (рис. 6);

Рис. 6. Выбранный однострочный текст
вызовите команду Конвертировать текст в Мтекст (рис. 7).

Рис. 7. Однострочный текст, преобразованный в многострочный

Утилита 3. Выравнивание текста

Командная строка: ТЕКСТВР (TJUST)
Команда позволяет изменить точки выравнивания для текстового объекта без перемещения текста.

Порядок выполнения команды:
выберите текстовый объект (рис. 8);

Рис. 8. Выбранный Мтекст
запустите команду Выровнять текст и выберите в командной строке или контекстном меню нужный метод выравнивания (рис. 9).

Рис. 9. Опции выравнивания текста в командной строке
Примеры выравнивания показаны на рис. 10 и 11.

Рис. 10. Пример выравнивания многострочного текста по верхнему краю и центрирования по горизонтали (ВЦ)

Рис. 11. Пример выравнивания многострочного текста по верхнему и правому краям (ВП)

Утилита 4. Изменение регистра текста

Командная строка: ТРЕГИСТР (TCASE)
Команда позволяет редактировать регистр слов, предложений и абзацев выделенного текста.

Порядок выполнения команды:
выделите фрагмент текста (рис. 12);

Рис. 12. Выделенный многострочный текст
запустите команду Изменить регистр текста и установите нужный параметр в окне Регистр текста (рис. 13). Нажмите ОК.

Рис. 13. Диалоговое окно Регистр текста
Результат выполнения команды показан на рис. 14.

Рис. 14. Многострочный текст с установленным регистром

Утилита 5. Растягивание или сжатие текста

Командная строка: ТЕКСТРАСТ (TEXTFIT)
Команда позволяет растягивать или сжимать однострочный текст с возможностью его перемещения.

Порядок выполнения команды:
запустите команду;
выберите текстовый объект. При выборе объекта автоматически схватывается начальная (нижняя левая) точка (рис. 15);

Рис. 15. Выделенный текст
укажите вторую точку на экране. Текст либо автоматически вписывается в указанные границы, либо растягивается (рис. 16).

Рис. 16. Растянутый текст

Утилита 6. Разбивка текста

Командная строка: ТЕКСТРАЗБ (EXPLODETEXT, TXTEXP)
Команда позволяет разбить текстовые объекты на отдельные составляющие (отрезки, полилинии). В процессе ее выполнения можно произвести настройку параметров как для результатов разбивки, так и для исходных объектов. Применение команды к предварительно выбранным текстовым объектам производит разбивку в соответствии с ранее установленными (или действующими по умолчанию) настройками.

Порядок выполнения команды:
выберите текстовый объект (рис. 17);

Рис. 17. Выделенный текст
запустите команду Разбивка текста. В результате вы получите текст в виде отрезков и полилиний (рис. 18).

Рис. 18. Разбитый текст
При запуске команды без выделения текста параметры исходных объектов и элементов разбивки можно настроить в контекстном меню или в командной строке (рис.19).

Рис. 19. Опции команды Разбивка текста

Утилита 7. Разбить геометрию

Командная строка: ГЕОМРАЗБ (EXPLODEGEOMETRY)
Команда Разбить геометрию, в отличие от команды Разбивка (EXPLODE), выполняет разделение сложных объектов на примитивы по всей глубине уровней вложенности. Например, несколько вложений блоков она сразу разобьет на составляющие их отрезки, дуги, полилинии без необходимости многократного вызова команды.

Порядок выполнения команды:
выберите объект (рис. 20);

Рис. 20. Выбранный объект
вызовите команду Разбить геометрию. Объект эллипс будет преобразован в 2D-полилинию (рис. 21).

Рис. 21. 2D-полилиния в форме эллипса

Утилита 8. Упростить сплайн

Командная строка: СПЛАЙНУПР (SIMPLIFYSPLINE)
Команда позволяет оптимизировать сплайн путем управления точностью его аппроксимации и задания максимального количества точек.

Порядок выполнения команды:
выберите сплайн (рис. 22);

Рис. 22. Выбранный сплайн
вызовите команду Упростить сплайн;
в командной строке укажите точность и максимальное количество точек (рис. 23);

Рис. 23. Запросы в командной строке для команды Упростить сплайн
нажмите Enter.
Результат выполнения команды показан на рис. 24.

Рис. 24. Упрощенный сплайн

Утилита 9. Разбивка прокси-объектов

Командная строка: РЗБПРОКСИ (XPROXY)
Команда предназначена для разбивки прокси-объектов, имеющих графическое представление, на обычные объекты. Допускается предварительный выбор объектов.

Порядок выполнения команды:
вызовите команду Разбивка прокси-объектов.
При отсутствии выбранных объектов команда выведет запрос (рис. 25).

Рис. 25. Запрос в командной строке для команды Разбивка прокси-объектов
В ответ можно выбрать объекты или указать опцию. Опция Чертеж предназначена для выбора в чертеже всех прокси-объектов с графикой, включая объекты на других закладках чертежа, выбрать которые другим способом невозможно. После указания этой опции система выполнит разбивку и сообщит о результатах (рис. 28).
На рис. 26 показаны выбранные прокси-объекты.

Рис. 26. Выбранный прокси-объект
После выполнения команды прокси-объект принимает вид, представленный на рис. 27.

Рис. 27. Разбитый прокси-объект

Рис. 28. Сведения о работе команды Разбивка прокси-объектов

Утилита 10. Удаление прокси-объектов

Командная строка: УДЛПРОКСИ (RMPROXY)
Команда предназначена для удаления прокси-объектов. Допускается предварительный выбор объектов.

Порядок выполнения команды:
запустите команду Удаление прокси-объектов;
выберите прокси-объекты.
При отсутствии выбранных объектов команда выведет запрос (рис. 29).

Рис. 29. Запрос в командной строке для команды Удаление прокси-объектов
В ответ можно выбрать объекты или указать нужную опцию.
Опция ? выводит запрос о смене метода выбора объектов (рис. 30).

Рис. 30. Опции метода выбора объектов
Опция Чертеж служит для выбора и удаления в чертеже всех прокси-объектов, включая объекты на других закладках чертежа.
Опция Неграфические прокси предназначена для удаления только прокси-объектов без графики, выбрать которые другим способом невозможно.
При указании нужной опции система выполнит удаление, сообщив о числе найденных и удаленных прокси-объектов (рис. 31).

Рис. 31. Сведения о работе команды Удаление прокси-объектов

Пример выполнения команды показан на рис. 32 и 33.

Рис. 32. До применения утилиты

Рис. 33. После применения утилиты

Заключение

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

Татьяна Васькина,
технический специалист
АО Нанософт
E-mail: vaskina@nanocad.ru

При подготовке задания на проектирование для смежных групп в проектной организации помимо словесной формулировки часто требуется приложить графическое изображение. Прикладывать файл с полным комплектом чертежей во многих случаях нецелесообразно. Разумно будет передать небольшой фрагмент графической информации.
Для подобных задач в nanoCAD Plus с модулем СПДС есть утилита Экспортировать в файл (SPEXPORTTOFILE). Она позволяет сохранить в файл выбранные объекты чертежа и оформить для них формат и основную надпись (штамп).

В ленточном интерфейсе nanoCAD команда Экспортировать в файл располагается на вкладке СПДС, в подвале группы Утилиты (рис. 1).

Рис. 1. Подвал группы Утилиты

Порядок действий при выполнении команды:

1. Вызовите команду Экспортировать в файл.
2. Укажите на чертеже объекты, которые вы хотите оформить в отдельный файл. Подтвердите выбор нажатием клавиши Enter.
3. В открывшемся диалоговом окне Формат установите требуемые параметры и нажмите кнопку ОК.
4. Задайте имя сохраняемого чертежа и нажмите кнопку Сохранить.

Выбранный фрагмент графики будет оформлен отдельным чертежом в отдельном файле.

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

На такой случай предусмотрены две утилиты:
Разбить все объекты (EXPLODEALL);
Разбить примитивы (SPEXPLODEPSEUDO, EXPLODEPSEUDO).
В интерфейсе программы они расположены рядом с командой Экспортировать в файл (см. рис. 1).

Команду Разбить все объекты следует применять обдуманно и иметь на то веские причины. Утилита разбивает объекты СПДС (выноски, таблицы, форматы, элементы оформления, параметрические объекты и т.п.) на примитивы во всем файле без возможности последующего восстановления. Объекты СПДС теряют свою интеллектуальность, многофункциональные ручки и диалоговые окна. Дважды подумайте, прежде чем воспользоваться этой командой (рис. 2, 3).

Рис. 2. Объекты СПДС до применения утилиты Разбить все объекты

Рис. 3. Объекты СПДС после применения утилиты Разбить все объекты

Команда Разбить примитивы разбивает во всем файле примитивы, образующиеся при перекрытии графики nanoCAD объектами СПДС (рис. 4, 5).

Рис. 4. Примитивы чертежа до применения утилиты Разбить примитивы

Рис. 5. Примитивы чертежа после применения утилиты Разбить примитивы

Примечание. Объекты СПДС могут иметь несколько режимов перекрытия примитивов чертежа:
-нет;
-маскированием;
-вырезанием.

Утилита разбивает примитивы чертежа, если режим перекрытия установлен в значение Вырезанием.

Разрушительный эффект обеих утилит весьма велик, поэтому после вызова этих команд программа попросит подтвердить ваши действия в соответствующих диалоговых окнах (рис. 6, 7).

Рис. 6. Подтверждающее диалоговое окно утилиты Разбить все объекты

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

Заключение

Модуль СПДС платформы nanoCAD располагает утилитой Экспортировать в файл, позволяющей быстро извлекать указанную графическую информацию и оформлять ее в отдельные файлы. Прокси-графику, создаваемую модулем СПДС, можно разбить с помощью утилиты Разбить все объекты, а примитивы чертежа, перекрываемые объектами СПДС, утилитой Разбить примитивы.

В течение 30 дней вы можете бесплатно тестировать достойную альтернативу зарубежным САПР. Переходите по ссылке и скачивайте nanoCAD Pro с максимальным количеством модулей и возможностей.

Делитесь своим опытом работы в отечественной САПР, обсуждайте существующий функционал и предлагайте новый на форуме nanoCAD.

Статьи, связанные с этой

• Утилиты nanoCAD СПДС. Найти и заменить текст

• Утилиты nanoCAD СПДС. Создание массива объекта

• Утилиты nanoCAD СПДС. Восстановление таблиц и форматов

• Дополнительные средства nanoCAD

Татьяна Васькина,
технический специалист
АО Нанософт