Блог. Склад текстов. И прочее городу и миру...
Рубрикатор
Последние записи
Об инвалидацию кэша
Как известно, в программировании есть только две реально сложные задачи: именование переменных и инвалидация кэша1. С первой мы сделать ничего не можем, со второй, конечно, тоже, но что-то делать приходится…
И вот в процессе большого рефакторинга inat-get я в очередной раз задумался. Суть тут вот в чем: данные, которые требуется получать из API iNaturalist — очень большие (зависит от целей, конечно, но они могут быть очень большими), и логично их закэшировать в локальной базе данных. Естественно, кэшированные данные нужно обновлять.
Есть прекрасный параметр updated_since в запросах к API, т.е. мы храним у себя информацию о сделанных запросах, и когда
нам нужно получить новые данные по тем же условиям, указываем дату/время предыдущего запроса в этом параметре. Но полностью
проблему это не решает: updated_since не отменяет (и не должен отменять) все остальные параметры запроса, т.е. те
наблюдения, которые выпали из запроса, в выборку не попадут. И останутся в локальной БД в старом состоянии.
Ну, то есть, выбрали мы, например, данные по проекту, который фильтрует наблюдения с quality_grade=research, а потом
пришел добрый человек и заметил, что в наблюдении культурное растение. Наблюдение выпадает из проекта, но мы об этом
не можем узнать через обновление…
Какие есть пути решения? Вижу несколько вариантов, ни один из которых меня не устраивает полностью…
-
Автор этой фразы, предположительно, Фил Карлтон (Phil Karlton), ведущий инженер компании Netscape. ↩
Натурадыбр – 2025
Что ж, год подходит к концу, я продолжаю снимать птичек на кормушке, но не думаю, что туда заявится кто-то новый и неожиданный. Так что можно подвести итоги наблюдательского года. Конечно, iNaturalist предлагает свою инфографику, но это все же сухая цифра, хоть и приятно оформленная.
Здесь я попробую изложить итоги года более субъективно и оценочно.
Количественно, как можно видеть, в этом году я снимал меньше, чем в прошлом и позапрошлом. Так получилось, в основном, потому, что в июле, августе и начале сентября я учился на водительские права (сдал), и у меня резко перестало совпадать свободное время с подходящей погодой.
Хотелось бы сказать «зато качественно…», но судя по количеству новых видов (и видов вообще), качество наблюдений осталось примерно таким же. Разве что чисто технически оно выросло, о чем ниже.
Ну и еще про количество, чтобы потом не возвращаться: в мае перешагнул отметку в 5000 наблюдений на iNaturalist, а в сентябре — 6000. Сейчас у меня в профиле показывается 6069 наблюдений всего и 1111 видов. Правда, если брать только наблюдения исследовательского уровня, т.е. подтвержденные, получится 4748 и 836 видов соответственно, так что тысячником называться еще не смею. Ну да ладно, новые виды пока прибавляются, так что пара-тройка лет — и за тысячу перевалю.
Паттерн «Фасад» и гем для DSL
При написании inat-channel я столкнулся вот с какой проблемой: с одной стороны, более-менее сложные
действия должны быть декомпозированы, то есть разбиты на модули и отдельные методы в них; с другой — глубокая декомпозиция заставляет
писать длинные обращения к методам типа INatChannel::Telegram::send_observation, что неудобно, да и не эстетично. По хорошему вообще
нужно верхний уровень методов инклюдить и писать send_observation в основной программе, но если писать все как включаемые методы модулей,
то во-первых, они все из всех модулей попадут в финале в одно пространство имен, а во-вторых, туда же попадут и приватные методы.
Для подобных случаев и предназначен паттерн «Фасад» — мы создаем отдельный программный модуль — в данном случае это модуль же в терминах Ruby — который содержит только нужные извне методы, делегируя их в основной нормально декомпозированный код. И затем его спокойно инклюдим в коде основного скрипта.
Собственно, именно так я и сделал, определив модуль IC и заполняя его методами в тех же файлах, где они определены. Туда же отправились
некоторые методы, не нужные вовне, а используемые слабо логически связанными модулями — здесь речь скорее не о логике и отделении фасада,
а о сокращении (текстовом) кроссмодульных вызовов. Впрочем, по мере разрастания структуры вопрос, что считать внутренним, а что внешним,
становится не очень однозначным.
Подумав немного на эту тему, я решил вынести абстракцию в код и написал is-dsl — гем, упрощающий, а главное — структурирующий делегирование методов и констант фасаду. Подробнее — в README репозитория (есть русская версия), а также в yard-документации. Здесь коротко обозначу основные особенности:
-
Помимо основного модуля фасада формируется теневой модуль — для использования внутри библиотеки. Все, что попадает в основной, попадает и в теневой, обратное неверно. См.
shadow-методы. -
Можно делегировать как статически синглтон-методы классов и модулей, так и лениво методы произвольных синглтон-объектов, где сам объект создается или получается через вызов блока. См.
lazy-методы. Предполагается применение с методом классаinstanceв первую очередь.
Планов менять или добавлять что-то в основную функциональность нет, думаю когда-нибудь сделать плагин для YARD, чтобы делегирование методов правильно автоматически документировалось.
Продолжая повышать энтропию интернетов...
В порядке продолжения повышения энтропии, а также эксперимента ради, я недавно завел еще три канала в телеграм с наблюдениями из iNaturalist:
- Daily Flowers of the World
-
Наблюдения цветов — в запросе указаны
term_idиterm_value_id, чтобы в выборку попадали именно наблюдения с цветами, а не вообще все наблюдения цветковых растений. - Daily Birds of the World
-
Наблюдения птиц. Тут ничего специфического, просто каждый день разные птицы.
- Daily Butterflies of the World
-
Наблюдения бабочек — в запросе опять же указаны
term_idиterm_value_id, чтобы в выборку попадали только взрослые особи, т.е. собственно бабочки, а не гусеницы, куколки или яйца.
Пара апдейтов
inat-channel v0.9.2
Что это такое — см. предыдущий пост.
Помимо исправления мелкого бага (имя lock-файла по умолчанию), изменил немного логику — при запросе свежих наблюдений отсечка происходит не по дате загрузки наблюдения, а по дате его последнего обновления. Это позволяет попадать в выборку наблюдениям, которые долго пролежали без исследовательского статуса. В целом это должно улучшить ситуацию с поступлением наблюдений в «несезон», по крайней мере, я на это надеюсь.
При этом удаление устаревших наблюдений из пула по прежнему контролируется по дате загрузки наблюдения.
jekyll-is-announcer v0.8.3
Опять же, о нем я уже писал. Впрочем, детали и концепция, чую, будут еще меняться и меняться…
А сейчас поменял кнопку перехода в канал на виджет от телеграма с комментариями. Что характерно, когда я делал кнопку, я ведь спрашивал у двух нейросетей, существует ли такой виджет… Но, видимо, как-то неправильно сформулировал и заузил область поиска1. А потом почти случайно сам наткнулся.
Что-то широкий и разнородный плагин получается… Пока не могу сообразить, как его окончательно заархитектурить — кнопки-то можно бы делать к разным сервисам легко, а вот встраиваемые виджеты — уже сложнее. Буду думать дальше. Раскидывать же его на несколько плагинов по отдельным сервисам не хочется, чтобы не плодить массу отдельных вспомогательных JSON-файликов.
Визуальную составляющую пока не дорабатывал — тут тоже надо сначала с общей картиной определиться, потом верстать конкретику.
-
См. раздел об использовании LLM в программировании в соответствующем посте. ↩
iNaturalist + Telegram
Анонс
Написал скрипт для автопостинга выборок из iNaturalist в tg-каналы. Скрипт делает выборку по произвольно сконфигурированным параметрам (которые, разумеется, должны поддерживаться iNaturalist API), затем берет случайное наблюдение, постит его, а остальные складывает в пул, который будет задействован, если свежие кончатся. Это если коротко.
Более подробно, как это все работает, а главное — как настраивается, я описал в README проекта inat-get/inat-channel. В том числе и на русском. Здесь пара моментов:
-
Наблюдения не дублируются.
-
Можно включить режим, когда и таксоны не будут дублироваться, с ограниченным, правда, сроком. Но его можно выставить произвольно большим.
-
Форматирование делается ERB-шаблоном, т.е. максимально гибко.
-
Скрипт прекрасно работает на GitHub Actions, запускаясь по расписанию. Для контроля неповторямости необходимо настроить обратный пуш, чтобы данные, которые хранятся в JSON-файлах, сохранялись в репозитории между сеансами.
-
Используется iNaturalist API v2, которое находится в ранней бете и может поломаться. Однако, на первой версии пришлось бы вытягивать в десятки, если не в сотни раз бо́льшие объемы данных, что малоприемлемо.
Примеры
На реальных примерах работу скрипта можно посмотреть на двух моих каналах:
-
Во-первых, я оживил канал «Природа Урала — наблюдения с iNaturalist». Там, напомню, наблюдения со всего Урала и прилегающих районов — от Оренбуржья до ЯНАО. Ни один регион не входит в выборку целиком, только отдельные районы, относящиеся непосредственно к Уральским горам, или прилегающие. В канале выходит до четырех постов в день по разным группам таксонов.
Все настройки и workflow для Actions доступны в репозитории inat-get/channel-ural.
-
Во-вторых, для проекта «Биоразнообразие районов Свердловской области» тоже завел канал, под немудреным названием «Биоразнообразие Свердловской области в TG». Там один пост в день (да и выборка поменьше).
Все его настройки и workflow также доступны на GitHub — inat-get/channel-sverdlobl.
Подписывайтесь, ставьте лайки, комментируйте… Отелеграмливайте свои проекты. В общем, велкам.
Анонсер — техническая сторона
В посте о подключении телеграм-канала я уже предполагал, что напишу подробнее о технической стороне этого подключения. Вообще-то, я планировал этим заняться попозже, а пока переключиться на «Практическое руководство по darktable»… Но внезапно обнаружил, что толком переключиться не могу, пока не доведу эту задачу с анонсером до какой-то логической точки.
Что ж, причесал Actions, отладил это хозяйство до более-менее стабильного состояния — хоть и далекого от завершения, но уже приемлемого для описания. Принципиальных изменений в ближайших версиях, скорее всего, не будет, а о плановых доделках я здесь еще скажу.
Задача
Собственно, основная задача стояла в следующем:
-
Отправлять анонсы (пока только в телеграм-канал) новых постов;
-
Сохранять ссылки на анонсы и показывать их на страницах, чтобы можно было перейти к обсуждению.
Уже по ходу дела решил добавить в Actions отправку уведомлений себе о выполненных операциях.
Телеграм-канал сайта
Завел себе (точнее, этому сайту) канал в телеге — https://t.me/shikhalev_blog.
-
Во-первых, для анонсов новых постов (даже заморочился и автоматизировал анонсирование на GitHub Actions).
-
Во-вторых, для комментариев, а то, похоже, аккаунт на GitHub мало у кого есть… Хотя, может, просто обсуждать нечего.
-
Ну, и в-третьих, там можно донатить «звездами». Впрочем, тут я иллюзий не питаю.
Кнопка для перехода в канал в постах выглядит корявенько, но я сейчас не хочу заморачиваться с частностями дизайна, поскольку планирую большой рефакторинг в относительно скором времени (весной).
В общем, приглашаю подписываться и обсуждать что-нибудь. Сейчас я закинул туда ссылки на посты этого года и несколько более старых, какие счел нужным. Новые посты буду анонсировать обязательно, может быть, докину и какие-то из старых.
Что касается технической стороны вопроса: плагин для Jekyll можно посмотреть на GitHub —
jekyll-is/jekyll-is-announcer, а его использование —
в каталоге .github/workflows
репозитория сайта. Думаю, еще написать об этом подробнее, но перед этим выделить основные действия из workflow в отдельные
action-репозитории — тогда можно будет поговорить на этом примере и об устройстве GitHub Actions в целом.
Заметки об LLM и нейросетях вообще
За последнее время (особенно последний год) мне довелось довольно активно поработать с большими языковыми моделями (LLM), которые сейчас модно называть искусственным интеллектом. Захотелось кое-что сформулировать и подытожить.
По этому поводу перечитал свои старые посты: «Отставить панику…» и «Паникуем иначе», с удовлетворением убедился, что основной посыл остался верным и на текущий момент, хотя, конечно, за это время многое стало яснее и накопился реальный опыт использования — как у меня лично, так и, не побоюсь этого слова, у человечества в целом.
Кстати, КДПВ сгененирована по тому же промпту, что и в тех старых постах — «deep learned girl in fantasy style». Пожалуй, это будет моя новая традиция для постов на подобные темы. В конце концов, не искусственный же интеллект рисовать — его никто не видел.
В общем, я, пожалуй, сначала пройдусь по своим основным тезисам из старых постов, а затем перейду к новому опыту и мыслям по его поводу. При этом я не собираюсь ограничиваться критическим взглядом, наоборот — основной упор будет на то, как извлечь реальную пользу из применения нейросетей.
Первая глава «Практического руководства...»
Выложил первую главу «Практического руководства по darktable» — «Базовая обработка».
Вместе с «Введением» первая глава должна дать полноценный быстрый старт — основные вещи, которые необходимы, чтобы начать уже делать что-то полезное.
Описаны действия и модули для:
-
Выставления баланса белого;
-
Исправления оптических искажений и шумоподавления;
-
Кадрирования и изменения геометрии;
-
Работы с общим контрастом и экспозицией, вытягивания теней;
-
Подчеркивания деталей посредством локального контраста.
Огроменный вышел справочный раздел, подумываю о том, чтобы вынести переводы справки отдельно от глав все-таки… Но пока не уверен.
По прежнему жду замечаний и вопросов.
Следующая глава будет про организацию изображений — снова представление светового стола, но уже в максимально развернутом виде.
Этим стулом...
Начал писать большое Практическое руководство по darktable. Выложил «Введение», где рассматриваю общий интерфейс и базовое управление снимками.
Это всё пока черновик, который будет правиться и дорабатываться, поэтому замечания и вопросы крайне приветствуются.
Общая идея — соединить изложение в практическом ключе, посредством сквозных примеров и теоретических отступлений, со справочными материалами, прямо соответствующими родной справке darktable.
На данный момент справочная часть — это ИИ-перевод, тогда как практическая — оригинальный текст (писать не-перевод посредством ИИ оказалось практически невозможно, т.е. писать промпт куда сложнее и дольше, чем сам текст… это отдельная интересная тема, надо будет пост написать). По ходу дела буду и справочную часть активно редактировать, чтобы привести язык в порядок и единообразие.
Вообще, конечно, задумка масштабная, писать буду долго, тем более, что не могу этому посвятить все свое время… Но надеюсь где-то за полгода-год закончить. И опять же, рассчитываю на фидбэк по ходу дела, чтобы ничего не забыть и не схалтурить.
Объектив Sigma 60-600mm
Приобрел себе в апреле сабж. Сейчас уже довольно много на него поснимал и можно начинать рефлексировать…
Итак, объектив Sigma AF 60-600mm f/4.5-6.3 DG OS HSM Sports с байонетом Canon EF (напомню, что тушка у меня Canon EOS 77D). Думаю, понятно, что главный критерием покупки было фокусное расстояние на длинном конце — 600mm, что в два раза длиннее моего старого любимого объектива Sigma 18-300mm. Те, кто снимал когда-нибудь птиц в дикой природе, думаю, понимают, какое преимущество это дает.
Это не единственный вариант с таким фокусным на дальнем конце, поэтому стоит, наверное, прояснить выбор.
Альтернативы и выбор
Поскольку менять систему в мои планы не входило (и в ближайшее время не входит), выбор ограничен системой Canon EF. Какие варианты тут доступны?
-
Tamron SP 150-600mm F/5-6.3 Di VC USD G2 (первое поколение можно не рассматривать — во-первых его уже сложно найти в продаже, а во-вторых, по всем отзывам и обзорам, оно сильно хуже G2).
-
Sigma AF 150-600mm F5-6.3 DG OS HSM | Contemporary (а вот версию 150-600mm серии Sports опять же не рассматриваем — она тяжелее и дороже, чем 60-600).
-
Canon EF 600mm f/4L IS III USM — тут достаточно взглянуть на цену, чтобы исключить из рассмотрения…
В общем, реально я рассматривал объективы 150-600mm от Tamron и Sigma1, которые дешевле и, что важно, ощутимо легче2, чем 60-600… Оба варианта неплохи, но дело в том, что я снимаю далеко не только птичек, и такая разница на коротком конце (60mm vs 150mm) для меня существенна — можно снять, например, небольшой кустик целиком, отступив на два-три шага, а не на десять. Ну а менять объектив на ходу (и вообще «в поле») — дело крайне неблагодарное. Финальным аргументом стало то, что у 60-600 на фокусном 200mm МДФ позволяет максимальное увеличение 1:3.3 (у Sigma 150-600mm — 1:4.9, у Tamron 150-600mm — 1:3.9, а у вышеупомянутого 18-300, для сравнения — 1:3). В общем, сабж позволяет снимать достаточно крупно цветы и насекомых, тогда как альтернативы в этом отношении сильно хуже.
Так или иначе, свой выбор я сделал, но хочу отметить, что это именно мой выбор, под мои задачи и привычки. Надеюсь, кстати, на днях записать свои размышления на тему собственно моих прогулок со съемками… Перейдем к впечатлениям от реального использования.
-
Если сравнивать именно объективы 150-600mm, то судя как по характеристикам, так и по отзывам, Tamron предпочтительнее, но тут я ничего от себя сказать не могу — не пробовал. Более того, я вообще не держал в руках никаких объективов Tamron и питаю к ним некоторую настороженность, в отличие от Sigma… ↩
-
Легче — не значит легкие: оба чуть-чуть больше 2 кг, тогда как 60-600 — 2.7 кг. ↩
Показаны 12 записей из 323