Раз поигрался с DALL-E и смотрел предыдущие текстовые нейронки для Сказки, то надо и OpenAI Chat посмотреть.
Глубоко не копал, так как концептуально возможности и ограничения были понятны уже из экспериментов с DALL-E.
Приведу пример, как одну из следующих версий этой сетки можно будет использовать для Сказки.
Если вам интересны более детальные демонстрации и выводы, смотрите пост про DALL-E для геймдева.
Не о всей конечно, о кусочке.
Забавно, но я за карьеру мало взаимодействовал с контейнерами. Максимум — писал код, который в них работал. Контейнеры либо особо не требовались, либо готовились другими людьми.
В конце прошлого года решил обновить инфраструктуру Сказки, заодно посмотреть чего да как с контейнерами. Взял Docker, как самую популярную штуку.
Этот пост я начал писать как часть рецензии на произведения Сюзанны Кларк, но быстро понял что ухожу в сторону от основной темы. Поэтому в рецензии оставил только то, что напрямую касается мира английской магии, а тему проектирования миров подробнее раскрыл тут.
Изначально эссе было опубликовано на DTF, но я решил вернуть его в блог. Изменений не делал, поэтому подача может немного отличаться от обычной для блога.
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py
. О них и расскажу, для иллюстрации идеи.