Ещё немного рефлексии по поводу навыков Python разработчиков. Я тут регулярно провожу технические собеседования дата инженеров к команду Dateno, в основном это русскоязычные разработчики/инженеры в разных странах и с разными запросами на ЗП.

Поделюсь некоторыми наблюдениями:
1. От многих собеседуемых есть ощущение что они свою ожидаемую ЗП оценивают по средней/верхней планки по рынку и по минимальной сумме при которой им комфортно жить, но никак не по собственным навыкам. С одной стороны это очень понятно, а с другой, в общем-то навыки часто не соответствуют запросу. Это такой естественный конфликт работодатель-работник, но в целом видно что не все могут оценить свою реальную рыночную ценность. Раньше тоже такое бывало, но что-то в этом году я наблюдаю это чаще чем раньше.
2. Мои задачи на технинтервью состоят из проведения ревью кода, либо старого кода одного из проектов, либо небольшого куска искусственно созданного примера кода с заведомыми ошибками. Часто оказывается что собеседуемый прекрасно говорит, идеально рассказывает про свой опыт, но с простым ревью кода не справляется.
3. Самые частые "затыки":
- непонимание приоритетов. Вместо поиска ошибок, которые вполне очевидны, увлечение стилем кода и форматированием. Это реально какое-то массовое явление, многие сбиваются в стилистику кода вместо фокуса на решении проблем.
- незнание асинхронности в Python. Для дата инженерных задач, особенно при работе наиболее популярными инструментами оркестрации конвееров данных хотя бы базовые принципы асинхронности надо если не знать, то уметь понимать.
- невнимательность. В каждом техинтервью есть задача в которой есть вполне понятные вводные на основе которых можно понять где могут быть ошибки и как их можно увидеть. Многие игнорируют существенную часть задачи и бегут смотреть код.
- недостаток архитектурного восприятия. У Python'а есть какое-то количество шаблонных способов решения задач (как и в большинстве языков) и хороших и плохих практик, например, использование глобальных переменных без четкого понимания зачем это делается - всегда плохо. Или же когда функции перегружены большим числом операций и выполняются долго то при выбросе исключения при отсутствии сохранения текущего состояния невозможно продолжить с места сбоя

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

По моему опыту довольно бессмысленно расспрашивать про инструменты, ими несложно овладеть. Неважно есть ли у человека опыт в Polars или DuckDB если он владеет Pandas, к примеру, но problem solving однозначно выходит на первый план для все кто не совсем джуниоры.

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

#thoughts #hiring

В рубрике как это устроено у них портал открытых данных Австралии data.gov.au. Относительно недавно его обновили и обратно мигрировали на CKAN с ранее разработанного австралийцами же дата каталога Magda. Почему мигрировали, кстати, я до сих пор в загадках. Magda интересный проект агрегации данных, но довольно сложный технически, может быть из-за этого.

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

Но всей картины открытых данных в Австралии это не покрывает поскольку де-факто Австралия скорее конфедеративная чем федеративная страна, много данных там на уровне отдельных штатов. И в том же Квинсленде на портале открытых данных www.data.qld.gov.au 188 тысяч наборов данных, а на портале геоданных Квинсленда geoscience.data.qld.gov.au ещё 187 тысяч наборов данных.

Всего в Dateno у нас проиндексировано более 548 тысяч наборов данных в Австралии из местных и международных порталов с данными.

Главная особенность Австралии как и большей части развитых стран - это то что геоданные составляют от 50 до 90% всех публикуемых наборов данных.

И, конечно, необходимо учитывать что его огромный пласт открытых научных данных который в Dateno пока представлен не полностью и если охватить и эти данные то в Австралии число открытых наборов данных легко достигнет 800-900 тысяч наборов данных, если не больше

#opendata #australia #datacatalogs

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

#opensource #ai #privacy #llm #tools #datatools

После экспериментов с простым кодом, я постепенно добрался до тех инструментов которые используются внутри Dateno для сбора данных. Один из них это утилита apibackuper которая помогает вытащить данные публикуемые через API и сохранять их в виде датасета. Фактически это инструмент скрейпинга API через декларативное описание параметров скрейпинга (да, я люблю декларативные описания). У инструмента был ряд недостатков которые я исправлял и думаю что исправил, вот перечень изменений:
- переход от декларативного описания скрейперов с INI (.cfg) файлов на YAML, читать легче, синтаксис приятнее
- валидация YAML описаний через JSON схему
- поддержка ограченичений и таймаутов на число запросов в минуту (Rate Limiting)
- поддержка аутентификации к API
- экспорт данных не только в JSONL, но и в Parquet
- автоопределение формата экспорта данных по расширению файла
- массовое обработка исключений и понятные сообщения об ошибках везде где возможно
- тесты для покрытия большей части кода
- подробная документация
- и всякое по мелочи

Я этот инструмент изначально разрабатывал для для архивации данных публикуемых через API, но сейчас он используется в части кода Dateno для выгрузки метаданных из каталогов данных. Может его даже пора уже перенести из ruarxive в dateno на Github'е, ещё не решил.

На скриншоте то как это выглядит на примере реестра лекарственных средств ЕСКЛП

Для сбора данных достаточно выполнить две команды
- apibackuper run
- apibackuper export current.parquet

Первая выгрузит все данные постранично, вторая сохранит выгруженные данные в parquet файл.

#opensource #datatools #data #dataengineering

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

Мне много что есть сказать самому, а заодно я прогнал этот текст через пару ИИ агентов - Perplexity, Manus и Deepseek. ChatGPT разобирать его отказался, а Алиса от Яндекса глубоко анализировать документы не научилась еще.

Результаты анализа Perplexity и Manus'а я прикладываю, а от Deepseek доступно по ссылке.

Что я скажу от себя:
1. Взимание платы за официальную статистику - это существенный барьер в её получении. Выгода гос-ва от запросов будет невелика, а ограничения будут серьезными. Я не знаю кто продумывал эту бизнес модель, но подозреваю что её нет и цель не деньги, а ограничения в распространении.
2. Если для бумажных документов и сложных запросов и необходимости пересылки ещё можно предположить что можно было бы взимать оплату, то для предоставления данных в электронном виде это не оправдано ничем.
3. Сам подход противоречит практикам развитых стран, рекомендациям ОЭСР и тд. Там наоборот идут по пути бесплатности распространения статистической информации
4. Агрессивно взимают плату за любой чих в коммуникации со статслужбами только в наибеднейших странах, в основном, африканских.
5. Собирать и распространять статистику на бумаге в 21 веке это как, даже не могу придумать приличного сравнения, это как самоудовлетворятся предаваться греху на публику или это как выйти куда-нибудь в публичное место и орать изо всех сил: "Смотрите, мы вас ненавидим! Нет, вы смотрите, смотрите же! Реально ненавидим". Потому что любовь к пользователям бумаги не предусматривает, и не должна предусматривать.

#opendata #government #russia #rosstat #statistics #closeddata

Датасет Цифрового архива: контрольные цифры расходов местных бюджетов РСФСР в 1932 году

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

Так, в 1932 году центр предполагал, что суммарные расходы всех регионов на культуру превышают аналогичное значение для народного хозяйства без малого в два раза: 1,8 млрд рублей против 0,9 млрд.

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

#датасет #ЦАГГ #РСФСР #бюджет

В продолжение про постановление российского пр-ва про взимание платы за доступ к статистике и то как оно в мире:
- OECD: Set of good statistical practices свод хороших статистических практик от ОСЭР. Включают рекомендации по бесплатному и свободному распространению статистики. Пункт 9.2: A dissemination policy ensures the free dissemination of official statistics.
- OECD: Open access by default рекомендации ОЭСР по предоставлению доступа к данным в режиме открытости по умолчанию
- OECD Principles and Guidelines for Access to Research Data from Public Funding рекомендации ОЭСР по предоставлению доступа к исследовательским данным (микроданным) с открытостью по умолчанию и взиманию платы только в исключительных случаях и в объеме не более себестоимости

Я специально привожу в пример принципы ОЭСР, есть также и позиции других международных и межгосударственных организаций, практики распространения данных в других странах и многое другое.

Практически все они сводятся к следующим принципа:
1. Статистика по всем вопросам являющихся объектом общественного интереса должна быть открыта и общедоступна
2. За доступ к статистике не должна взиматься плата за исключением очень ограниченного числа случаев запросов на доступ к специализированным данным требующих существенных усилий
3. По умолчанию все данные должны быть свободно доступными в цифровой форме и распространяться в открытую максимально возможными способами распространения

#opendata #statistics #regulation #oecd

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

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

Кроме того хорошо отрабатывают задачи которые:
- находят ошибки в метаданных дата каталогов
- находят и исправляют дубликаты записей
- обогащают карточки каталогов тематиками и тэгами
- исправляют геоклассификацию каталогов
- и многое другое что предполагает массовое исправление и обогащение данных

Лично для меня и Dateno это очень хорошая новость это означает что реестр (dateno.io/registry) можно вести теперь значительно меньшими личными усилиями.

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

P.S. Тут я описываю внутренности происходящего в Dateno, которым я занимаюсь как основным проектом и продуктом. А новости проекта всегда можно читать в LinkedIn

#opendata #datacatalogs #ai #dev #datatools

В рубрике как это устроено у них эстонский портал культурного наследия E-Varamu включает 23.8 миллиона описаний архивных объектов из которых 1.94 миллиона доступны онлайн. Включает изображения, документы, карты, тексты, аудио и видеозаписи, и даже наборы данных.

Для сравнения в российском НЭБ доступно 49.8 миллионов описаний из которых 5.3 миллиона доступны онлайн. С одной стороны вдвое больше, с другой стороны в Эстонии проживает 1.3 миллиона человек, а в России 143 миллиона. В России примерно в 100 раз больше людей и можно ожидать примерно в 100 раз больше объектов культурного наследия.

Можно еще к российским культурным объектам добавить данные Госкаталога РФ, это + ~55 миллионов объектов, но даже так разница с эстонским порталом в 4 раза, а не в 100 раз. Есть к чему стремиться, не говоря уже о том что метаданные госкаталога довольно куцые, а, по удивительным причинам каталоги метаданных НЭБ и Госкаталога не объединены.

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

Из минусов - отсутствие публично задокументированного API и наборов данных с метаданными.

#opendata #digitalheritage #culture #culturalheritage #estonia

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

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

И вот когда у меня в голове уже созрела мысль что не попробовать ли сделать поисковик по датасетам, я понял что надо перестать думать об этих данных как о таблицах (сложно перестать, конечно) и начать думать как о реестре. Для меня тогда выбор был в том чтобы:
- перенести этот реестр в СУБД и создать поверх интерфейс для редактирования. Например, загрузить в Postgres и поверх сделать быстро интерфейс с помощью Strapi или Directus'а или других no-code инструментов
- или начать смотреть на этот реестр как на код и поместить все в Github. Не так удобно для работы вручную, но хорошо автоматизируется

В итоге я пошёл вторым путем и разрезал таблицы на индивидуальные карточки дата каталогов сохраненные как YAML файлы согласно предопределенной схеме данных. Например, вот такая карточка. Эти записи можно редактировать вручную, а можно и автоматически. Можно автоматизировать обогащение метаданных, проверку API, доступность сайтов, проверку ошибок и так далее. Чтобы собственно и происходит внутри этого репозитория. От изначальный 2 тысяч каталогов до текущего их числа в более чем 10+ тысяч дата каталогов он вырос за счет автоматизированной загрузки в него большого числа дата каталогов из их агрегаторов.

Теперь я подключил последнюю версию Cursor'а к обновлению этого репозитория и оказывается он очень хорош в массовом обновлении YAML файлов и понимает команды сформулированные в стиле:
- "Проанализируй все записи, найди те у которых веб сайт владельца не указан, найди веб сайт и заполни поля owner.name и owner.link"
- "Проверь все записи относящиеся к Бельгии и проверь доступны ли указанные там сайты"
- "Создай JSON схему для YAML файлов дата каталогов и проверь все их записи на соответствие этой схеме"

и так далее.

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

Итого сейчас в обновленных данных реестра Dateno 10 905 каталогов. Они все пока в репозитории реестра в виде YAML файлов и parquet файла слепка с данными. Это на 794 каталога данных больше чем пока есть в общедоступном реестре (всего 10 111 каталогов).

Были добавлены:
- каталоги данных на базе GBIF IPT
- большие списки каталогов данных во Франции, Испании и Нидерландах
- по мелочи каталоги данных в других странах

А также огромное число исправлений в метаданных всех каталогов.

Фактически ИИ агенты для разработки прекрасно подходят для работы с данными упакованными таким образом. Я начинаю склоняться к мысли что такое обогащение данных работает лучше чем инструменты вроде OpenRefine.

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

#opendata #datacatalogs #dateno #dataengineering #dataanalysis

Regular country open data overview, this time Estonia
—
Open Data in Estonia: A Small Country with a Remarkably Large Data Footprint

Estonia stands out in the open data landscape. Despite its relatively small population, the country hosts an impressive variety of data portals and repositories: open data platforms, official statistics, geodata services, and research data infrastructures. ...

More at LinkedIn https://www.linkedin.com/pulse/open-data-estonia-small-country-remarkably-large-footprint-sdkce/

#opendata #estonia #datacatalogs

Короткий текст The fate of “small” open source где автор рассказывает о будущей печальной судьбе программных библиотек на примере свой библиотеки blob-util и того что ИИ агенты не предлагают использовать её, а автоматически генерируют код.

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

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

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

Похоже на реалистичный сценарий?

#opensource #ai #llm

Рубрика "Циничное интеллектоведение"
В России открыт новый рынок - рынок российского интеллекта.
Источник - альманах "Искусственный интеллект. Индекс 2022 года" (выпуск 12, 2022 год), выпускаемый Центром компетенций НТИ "Искусственный интеллект" при МФТИ