Полезный ежегодный обзор баз данных в тексте Databases in 2025: A Year in Review от Andy Pavlov.
Всем кто работает с данными большого объёма будет полезно, вот ключевые выдержки:
1. Доминирование PostgreSQL продолжается. Многие экспериментируют со многими базами данных, но в продакшен всё равно используется PostgreSQL и совместимые с ним и его протоколом аналоги.
2. MCP для каждой СУБД. Похоже что тренд очевиден, MCP прикручивают к каждой СУБД каждый вендор и в этом нет ничего дурного. Больше универсальных интерфейсов полезных и нужных
3. MongoDB против FerretDB. MongoDB активно давит на FerretDB в том что воспроизведение их API и протокола нарушает их права. Такого в области баз данных ранее не было, самое близкое - это разборки Oracle vs Google из-за Java API. Тогда Oracle не удалось убедить суд в том что их права нарушены
4. Поле битвы форматов файлов. Активно идет появление новых стандартов и форматов дата файлов на замену Parquet. Я также не спроста писал про эту тему так часто, там идет сильная конкуренция и интересные технические решения

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

#data #rdbms #readings

В блоге The Pragmatic Engineer текст созвучный моим мыслям When AI writes almost all code, what happens to software engineering? он частично под пэйволлом, ном открытой части достаточно чтобы понять о чем речь. А речь там ровно о том что я предсказывал - работы для начинающих разработчиков в ИТ будет меньше, а опытные будут цениться больше, возможно даже сильно больше, но общее падение профессиональной экспертизы - это то что нас уже почти неизбежно ждет. Причем перелом произошел в последние полгода с появлением новых LLM моделей которые стали неожиданно хорошо справляться с задачами программирования.

Я добавлю что любые дискуссии по поводу перспектив применения ИИ в разработке будут релевантны только если обсуждающие пробовали последние LLM модели: Gemini 3, GPT-5.2 и Opus 4.5.

#ai #softwareengineering #programming #trends

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

OpenRefine изначально вырос из проекта Google Refine который, в свою очередь, разрабатывался внутри проекта FreeBase который после поглощения Google превратился в Google Knowledge Graph.

OpenRefine позволяет вручную и полувручную, с использованием языка GREL (General Refine Expression Language) или кода на Jython через веб интерфейс чистить табличные наборы данных и сохранять их в CSV и я ряде других форматов. Никакого SQL, сложного кода, зато бесконечный цикл Undo/Redo.

Можно сказать что OpenRefine - это инструмент подготовки данных выросший из экосистемы управления знаниями. Явление он довольно редкое, и сам продукт довольно интересный, но не без ограничений.
Потому что внутри него не СУБД, а граф объектов на Java что резко ограничивало и ограничивает объемы редактируемых датасетов до 100 тысяч записей максимум. Но всё это с удобным UI и возможностью работать чистить данные без глубокого технического погружения в протоколы, SQL запросы и разработку кода.

Какое-то время назад я думал о том не создать ли более эффективную альтернативу OpenRefine. Даже экспериментировал с созданием обвязки с помощью MongoDB mongorefine что было очень прикольным опыт и тренировкой для мозгов, но совершенно точно непригодно для реальной работы потому что MongoDB даёт большую гибкость и очень низкую скорость обработки данных. Это был эксперимент, отложенный для дальнейших размышлений.

Сейчас посмотрев на OpenRefine и его развитие свежим взглядом я могу сказать следующее:
1. Да, с помощью LLM можно очень быстро сделать его аналог, с изначально более-правильной архитектурой на базе Polars + DuckLake или Iceberg, с разделением бэкэнда и фронтэнда/фронтэндов и превратить его в инструмент обогащения данных с помощью LLM и не только.
2. При этом у него очень понятная аудитория, инструмент мог бы быть коммерческим или некоммерческим, важнее что он точно будет востребован

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

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

#opendata #opensource #ideas #dataquality #dataenrichment

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

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

Там много вопросов возникает в связи с тем что ИИ агенты могут автономно делать множественные запросы в разные информационные системы и с юридическим статусом коммуникации с ними.

Но это будущее, возможно неизбежное

#ai #government

Кстати вопрос, кто уже пробовал Sourcecraft и его ИИ ассистента от Яндекса? Оно сравнимо ли с Cursor'ом или аналогичными ИИ инструментами? Стоит ли оно внимания за пределами "нужно на случай если в РФ заблокируют Github и Gitlab" или же всё пока на ранней степени зрелости/полезности/необходимости?

#questions

Хороший обзор Eight Software Markets AI That Will Transform Differently того как изменится рынок программного обеспечения в ближайшее время под воздействием развития ИИ инструментов. Из 8 ИТ рынка по настоящему радоваться могут исследователи, для них открывается бесконечный новый мир быстрого создания ПО и кода под свои задачи.

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

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

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

Можно представить, на выбор, укоренившихся вендоров ПО в некоторых отраслях и спокойно имевших свою долю рынка и неспешно на нем живших, а вдруг окажется что то что они делали пару десятилетий можно воспроизвести за 6 месяцев? за 3 месяца?

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

#ai #thoughts #itmarket

В продолжение моих малореалистичных предсказаний вот краткое изложение предсказаний экспертов из Стенфорда.

Они гораздо более скучные реалистичные чем мои

ИИ в 2026: от хайпа к реальной оценке и измерению

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

AGI не появится
Общий искусственный интеллект широкого уровня всё ещё остаётся в будущем, и в ближайшем году его не ожидают.

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

Прозрачность и понимание
В науке и медицине усиливается внимание к объяснимости моделей — не только к результату, но и к тому, *как* система приходит к выводу.

Юридический ИИ — сложнее задач
Системы для юристов пойдут дальше простого чернового текста: научатся сопоставлять документы, синтезировать аргументы и давать оценки с привязкой к метрикам качества.

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

Медицина: постепенный «момент ChatGPT»
Методы самообучения и большие качественные наборы данных позволят медленным до сих пор медицинским ИИ-системам быстрее развиваться — в том числе для диагностики редких заболеваний.

Измерение воздействия на экономику
Вместо деклараций появятся «дашборды» для измерения влияния ИИ на производительность, рабочие места и отходы. Это позволит видеть результаты в реальном времени и корректировать стратегии.
—
По моему уже пришло время предсказаний в стиле Saxo Bank'а в отношении экономики, только вместо экономики предсказывать будущее ИИ (с другой стороны мы разве не подошли вплотную когда ИИ технологии и экономика становятся синонимами?)

#ai #readings

Свежий доклад от Всемирного банка GovTech Maturity Index 2025 : Tracking Public Sector Digital Transformation Worldwide с измерением уровня цифровых технологий в госсекторе.

Некоторые оценки удивляют, например, низкий уровень цифровизации в Польше и высокий уровень в Секторе Газа.

Зато Армения оценена как весьма зрелая страна в этом отношении. Хм

В рейтинге учитывается открытый код и открытые данные и ещё довольно много всего.

Сам рейтинг разделен на 4 суб-рейтинга по зрелости информационных систем, предоставлению услуг, вовлечению граждан и зрелости институтов.

#rankings #readings

Я довольно много писал про разные форматы файлов в дата инженерии и не только, с одной стороны это кажется очень внутренне-технической темой, неочевидной для тех кто не работает с данными постоянно, с другой стороны в обзоре от Andy Pavlov про СУБД за 2025 год активная конкуренция форматов явно упоминается. Потому что (внезапно!) оказалось что то как ты хранишь данные и то как хранят данные кто-то ещё и которые тебе необходимо использовать может быть как очень удобно и практично, так и создавать ничем не обоснованные дополнительные издержки.

Я привожу в пример как часто на порталах открытых данных публикуют CSV или XML файлы внутри ZIP архивов в формате: один файл - один архив. Но данные/файлы внутри ZIP архивов не приспособлены (без шаманства) для потоковой обработки. Их надо вначале распаковать куда-то как временные файлы, а потом уже обрабатывать и временные файлы удалять. Если файлы небольшие то и ладно, а если это десятки и сотни гигабайт и таких задач много, то возникает вопрос: А отчего же так? Это решается распространением датасетов не в виде ZIP архивов, а сжатием из GZip, LZMA, Zstandard, LZ4 и тд., способами и форматами сжатых данных изначально приспособленных под потоковую обработку. Собственно под такие форматы я делал iterabledata, библиотеку для Python. Она про то чтобы условно любой файл с таблицами или объектами можно было бы перебирать как это принято в Python в csv.DictReader. Последовательный перебор с возвращанием каждой записи как словаря (dict).

Но это лишь один уровень оптимизации, далее вопрос в выборочной обработке данных. Почему в какой-то момент так выстрелил довольно старый формат Parquet? Помимо хорошей компресии и возможности быстрого чтения данных он ещё и дает возможность выборочного чтения и фильтрации данных. К примеру, в отношении XML файлов это уже не работает, в отношении JSON, с большими ограничениями (для JSONl да, в остальных случаях нет) и так далее. А ещё есть огромное число форматов имеющих предметное и отраслевое применение где всё что можно - это, либо считывать их в память целиком, или перебирать содержание по каждой записи.

Вот примеры таких форматов: WARC (файлы веб архивов), PCAP (файлы перехвата сетевого трафика), SAS (файлы статпакета SAS), и еще много что: BSON, KML, GML, XLS, ODS и так далее. Реально огромное число форматов не поддаются фильтрации без загрузки в память или не через фильтрацию при тотальном переборе.

Поэтому когда доходит до их обработки, приходится преобразовывать их полностью или частично в parquet. К примеру, для WARC файлов я всегда их преобразую в один или несколько parquet файлов с метаданными, а оригинальные файлы рассматриваю как контейнеры для контента. И это я не сам придумал, а подсмотрел когда-то у Common Crawl, они поступают аналогично поскольку без этой процедуры собирать статистику сложно, надо перелопачивать каждый WARC файл, а это гигабайты-терабайты-петабайты.

Однако и сам формат Parquet'а неидеален и об этом регулярно пишут в разных местах и появляются такие форматы как Lance, Vortex, Nimble, Vortex, FastLanes и другие. Пока они довольно редки в открытом доступе, но постепенно проявляются. Впрочем parquet оказался достаточно эффективным чтобы эта замена длилась ещё какое-то количество леь

А вот чтобы я бы предсказал так то что грядет тренд на parquet'изацию данных, когда просто сильно удобнее распространять их в структурированном подобным образом виде. Возможно через рассмотрения parquet файлов как контейнеры, а возможно как файлы-сателлиты с метаданным к файлам контейнерам. К примеру, можно вполне заменить VCF файлы (генетика) на Parquet или файлы LDIF (директории пользователей LDAP) на Parquet или файлы KML и GML (геоданные) и тд.

#thoughts #data #dataengineering #fileformats

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

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

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

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

И там и там все сохраняется в базы с метаданными оформленным по своим правилам. Тоже пересекающиеся по логике и содержанию.

Удивительное дело, так почему не дознавателей не учат на архивистов, а архивистов на дознавателей? 🙈

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

#thoughts

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

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

А я бы добавил к этому следующее:
1. Планирование через OpenSpec или его аналоги. Очень хорошо структурирует процесс проектирования и коммуникации с ИИ агентом. Для сложного и унаследованного кода - это просто необходимо. В принципе разделять планирование и реализацию, на стадии планирования не меняется код, а результаты - спеки и планы.
2. Cursor и аналогичные инструменты (Antigravity, Copilot и тд.) могут выполнять роль инструментов исследовательской поддержки и аналитики. Например, формируz отчеты по конкурентам, проектируя инструменты бенчмарков с ними, подготовка аналитики по разным функциям, проектирование верхнеуровневой архитектуры и тд.
3. ИИ ассистент - это не только объект проверки (а не кривой ли код он написал?), но и сам является контуром контроля качества. Поэтому на каждой итерации внедрения фич необходим контур создания и проверки тестов, линтинга кода, обновления документации и тд. Это частично решается уже сейчас на стадиях планирования и спеков, но опыт показывает что явное указание этих обязательных проверок дает больше гарантии что код будет не поломан и документация будет актуальной.
4. Инструменты для разработки вполне способны не только писать код, но и писать документы. Подход такой же может быть как к репозиториям кода с использованием спецификаций, планирования и тд. Иначе говоря при проектировании больших ИТ продуктов можно создать отдельный репозиторий с архитектурой продуктов и от него создавать все остальные. Например, если надо условно с нуля сделать продукт у которого есть фронтэнд, бэкэнд, REST API, SDK, интеграционные модули и тд., то вместо того чтобы все засовывать в один репозиторий или сразу разбивать на множество, имеет смысл собрать архитектурный репозиторий с документами.

#ai #coding #thoughts #readings

Кто знает, это правда или фэйк?

Интересный взгляд на ИИ разработку в тексте про Gas town от Steve Egge. Много уникальной терминологии так что сразу ещё один текст Gas town decoded

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

Почитать точно стоит всем кто проектирует ПО

#readings #aiagents