Category: наука

Category was added automatically. Read all entries about "наука".

404

ansible/molecule

О, внезапно, мой патч в молекулу приняли в апстрим.

https://github.com/ansible-community/molecule/pull/2962

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

TL;DR; когда молекула собирает инвентори, там есть провижен хосты (которые создаются молекулой) и линкед хосты (которые "даны свыше", например, гипервизоры или внешние сервера). В режиме провиза/дестроя инвентори содержит в себе всё это, а при тесте оно куда-то исчезало (т.к. передавался только файл с провижен хостами). Я поменял на каталог.
404

Molecule

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

404

molecule

Мы всё-таки пытаемся притащить молекулу в продакшен (в смысле, в тесты кода для продакшена). Основная проблема состоит в том, что molecule сконцентрирована на тестах ролей, а нам тесты ролей не особо нужны — стратегически мы отказались от ролей как «reusable code elements». Теоретически, роли могут быть reusable, на практике, роль либо гигантская и неподъёмная, покрывающая 100500 случаев (и тогда она reusable), либо она делает одно дело, одним образом и в рамках многочисленных предположений (и тогда она компактная, быстрая и простая — но применима только в заданном проекте). А вот тесты плейбук и тесты facility (специализированных reusable-плейбук) — это да. Ещё я хочу применить её к реальным тестам сценариев (есть одна сетка, есть две сетки, и т.д.) — т.е. к тестам одной и той же плейбуки в разных окружениях.

Но Молекула активно сопротивляется, и документация у неё написана в интересном стиле — делайте так, не делайте так, делайте так. Что делать я сам разберусь, мне документация к софту нужна, а не ЦУ.

С другой стороны, её техника группировки инвентори (provisioning inventory, вместе с поддержкой ссылок на файлы и т.д.) — это как раз то, что мне очень не хватает в самописных велосипедах.

Вот и страдаем...


404

Редактор

А вот в моей карьере случился провал. Я инвестировал много энтузиазма неофита в Far Editor (включая плагины и т.д.), и при переходе на линуксы я этот вопрос удачно пропустил. Какой-то скилл продраться через vim у меня есть, общий десктопный навык для GUI редакторов есть, но вот инвестированного глубокого знания - нет.

Я чуть-чуть разобрался с атомом (не очень глубоко), но он помер. Так что вопрос с редактором вполне открытый.

Варианты:
Доинвестировать в vim в серьёз (а не в режиме пять фич в год, как учу его я). Плюсы: точно не помрёт. Минусы - текстовый (я в курсе gvim'а, но это ещё более странно, чем vim). Новые редакторы очень удачно дорисовывают важные элементы (всякие синтаксисы/фолдинги и т.д.).

codium (aka vscode). Тот же электрон, что и атом, вид с боку. Пока что я видел - очень многообещающий и эргономичный. Минусы - codium - борьба с MS за отключение трекинга и т.д., т.е. не совсем "оно".

emacs, извините, просто нет. В первую очередь из-за лиспа, во-вторую из-за токсичного комьюнити ("это ошибка со стороны других редакторов использовать шоткаты, которые не совместимы с емаксом").

Что у нас ещё есть? Нужны фолдинг, комфортный сдвиг текста на "следующую позицию", интеграция с гитом, многобуфферность/оконность (в т.ч. для одного и того же файла), интеграция с линтерами.

UPD: Собственно, в районе rls/racer'а и есть список более-менее живых альтернатив:

https://github.com/racer-rust/racer

* Gedit
* Gnome Builder
* Kate
* Kakoune
404

Управление результатами бенчмарков и экспериментов

А вот, вопрос, а есть ли какая-то система для управления результатами тестовых запусков? Мне очень надоело вести лабораторные журналы руками. Сколько не записывай, всё равно неполные данные получаются.

По-идее, не сложная система - eID (experiment ID), с которым ассоциированы любые блобы "до" (описание системы, артефакты, конфиги), результаты (key/value), метрики эксперимента (всякие там latency logs) и блобы "после" (то же описание системы и артефакты).

UI для наблюдения, возможность через API всё это засылать...
404

Теория типов и богословие

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

Ответ на этот вопрос может быть получена за бесконечное время. (divergence type).
404

Принципиальное различие между теоретическим и практическим знанием

Я сейчас играюсь с Rust'ом (выдалось несколько свободных часов), и я их потратил не на заумные трейты, а на самое примитивное — работу с mod/use/lib.rs, В процессе я получил очень мало новых знаний (теоретически я всё это читал), но они получили невероятное подкрепление от практики. (Сам феномен всем понятен — не буду слишком распространяться).

В чём различие между теоретическим и практическим знанием? Допустим, мы имем 100% доверие к источнику знаний, так что мы не можем объявить теорию менее достоверной, чем практика.

У меня есть ощущение, что практика обладает большим разъяснительным потенциалом, потому что практика задаёт новую систему базовых понятий. При чтении любой теории, понятия с сотой страницы строятся на базе понятий с 95-ой страницы, те ссылаются на 50ую страницу и т.д., пока вторая страница не ссылается на первую, а первая страница любой теории обычно либо ссылается на другие теории, либо просто немного разговаривает бытовым языком, аппелируя к бытовому опыту читателя. Т.е. к той самой практике. Соответстственно, знакомство с практикой, это формирование нового бытового опыта. Из которого получается развитие в два направления: анализ (почему так? Как это работает?) и синтез (из фигулины А и фигулины Б очевидно вытекает В. Обобщим В на кучу разных комбинаций двух фигулин...).

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

Collapse )
404

CS для итераторов

Я обнаружил себя в онтологическом болоте.

У меня есть код, который использует (consume) итератор в список, а потом применяет функцию к каждому элементу списка. Я пытался найти метод отложить (make lazy) процесс исчерпания итератор до начала использования значений из списка. У меня не получается, потому что код использует список.

... И моя проблема не тут.

Я не могу найти правильного описания свойств того, что происходит. Какое свойство теряет мой итератор (который создаётся генератором) в момент, когда к нему применяют fold? Что это такое? Что такое laziness с точки зрения теории типов?