Для тех кто учится на чужих ошибках отличный тред на reddit'е где автор делиться опытом применения вайб кодинга на живой системе. В этот тред можно отправлять всех кто думает про вайб кодинг как про "манну небесную" и решение всех проблем. Скорее про создание новых проблем в руках людей не обладающих необходимыми техническими навыками.

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

#ai #coding

Вышла версия 1.4 DuckDB, изменений там довольно немало, я бы обратил внимание на появление режима шифрования базы данных которой охватывает и сам файл базы данных, и всех промежуточных файлов. А также улучшена сортировка, появился коннектор к Teradata, запись в таблицы Apache Iceberg и так далее.

#opensource #datatools

Важный вопрос, как для развития Ruarxive.org, так и для сообщества по цифровой архивации в том как мы могли сообщество развивать и поддерживать? Как можно было бы сделать текущую работы по архивации более полезной, удобной и востребованной? Для чего обязательно проведём опрос тут в телеграм канале, но прежде это хотелось бы обсудить.

У инициатив по архивации, увы, немного ресурсов и удаётся сохранить далеко не всё что хотелось бы

Вот неполный список идей которые "витают в воздухе":
1. Обновить сайт ruarxive.org и выложить туда в более удобном виде все накопленные архивы.
2. Сделать форум для обсуждений который бы дополнял чат @ruarxivechat и дел бы возможность не терять треды обсуждения.
3. Больше интегрироваться с Archive.org и ArchiveTeam и ориентироваться на них в архивных задачах. Например, делать обязательную копию всего в Интернет архив
4. Организовать курсы/семинары по обучению самостоятельной архивации (материалы есть, они даже использовались для курсов в одном из университетов).
5. Регулярно организовывать митапы или ежегодную конференцию по теме архивации цифрового контента
6. Актуализировать гайды по архивации цифрового контента разного типа и подготовить новые
7. Организовать конкурс на создание инструментов архивации типовых сайтов/соц сетей/иных цифровых источников данных, может быть добавить конкурс на создание гайдов и курсов по архивации от сообщества

Возможно какие-то ещё идеи? Предлагаю обсудить их в чате @ruarxivechat и все их выставим на голосование в ближайшее время

#ideas #community

Сюда ещё много чего можно добавить:
❌ вы написали что умеете убирать говно лопатой, а у нас все работают на экскаваторах (недостаточное владение современными инструментами)
❌ вы не умеете убирать говно без роботов, а нам нужен личный опыт (вайб спецы по уборке говна не нужны)
❌ вы умеете бросать говно только налево, а у нас все бросают направо (несоответствие командным практикам)
❌ вы можете убирать говно только с 8 до 16, а надо с 16 до 24 (живёте в другой временной зоне)

Всё так, ИТ-рынок, особенно в части управления проектами, и режим работы "головы откручивать и говно разбрасывать"

#юморпосредам #it

В рубрике как это устроено у них портал открытых данных Ирана data.gov.ir

Включает 11675 наборов данных, от 32 организаций. Внутри построен на CKAN.

Большая часть данных - это статистика, форматы включают Excel, PDF, а также карты, обычно в JPEG'ах.

Лицензии на данные не указывают, структурированного хранилища там тоже нет.

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

#opendata #datasets #iran #ckan

Разные мысли вслух:
1. LLM'ки для кодинга пока плохо справляются с оптимизацией уже оптимизированного кода. Все мои попытки оптимизировать инструменты ориентированные на быстрый разбор данных приводят к тому что ИИ агенты дают множество как бы неплохих оптимизаций, но, ожидаемо, без серьёзного понимания контекста. Например, много лет назад я написал библиотеку для Python qddate которая заточена под быстрый парсинг дат, которая довольно интенсивно мной оптимизировалась под быстрый разбор дат в разных форматах в том числе "грязными хаками" вроде вкодированной идентификации потенциальных шаблонов. Все рекомендации от LLM сводились к введению разных форм кеширования без учёта природы и специфики данных. Итоговой оптимизации парсинга они не дают. Немного лучше становится когда природу данных и инструментов ты понимаешь и ставишь задачу в стиле "Оптимизируй код XXX используя инструменты YYY и/или ZZZ", но в целом проблема не в галлюцинациях, а в непонимании автоматическими инструментами природы задач под которые код должен быть оптимизирован.
2. Программирование тяжело сочетается со всеми прерывающими задачами. Это, конечно, совсем не новость, но сложно сочетать любую разработку и написание текстов и управленческую работу, равно как и работу руководителем проектов. Есть задачи качество которых измеряется в возможности непрерывной работы от 2 до 4 часов подряд. Даже при том что все свои активности связанные с выступлениями, лекциями, совещаниями я в последние годы сократил до минимума, но управление временем становится важнейшей необходимостью.
3. Хороший код != востребованный продукт. Хотя эти явления часто идут вместе, но синонимами не являются. Работая со множеством инструментов по обработке данных вижу как хорошие инструменты часто могут быть заменены эволюционно более сильными инструментами, даже при наличии хорошего кода. Например, DuckDB, по факту, значительно эффективнее большей части утилит работы с CSV файлами, а работа с CSV файлами куда менее эффективна чем работа с файлами в форматах вроде Parquet. Это касается, как минимум, инструментария работы с данными, но ими не ограничивается.

#thoughts

Полезное чтение про данные, технологии и не только с моими комментариями:
- How Tables Grew a Brain: Iceberg, Hudi, Delta, Paimon, DuckLake примерно месячной давности обзор основных продуктов для построения озер данных. Полезно, однако стоит дождаться обновлений по DuckLake и прочитать про них для полноты картины. И тут, конечно, важно вновь вспомнить что озера данных это всё ещё термин имеющий как минимум два значения. Первый - разрозненная комбинация хранилищ данных объединённая общим каталогом метаданных и некоторыми принципами доступа к ним. Второй - это архитектурный подход и хранилище, куда можно загружать разнообразные данные (структурированные, полуструктурированные, неструктурированные) в их исходном виде. Ключевая идея — хранить всё «как есть» и предоставлять единый уровень доступа для анализа, обработки и интеграции. Это кажется очень похожим определениями, но это не совсем так и продуктовая часть подходов к озерам данных сдвинута в сторону "бери в любом формате и загружай в структурированном по правилам".
- The Missing README: A Guide for the New Software Engineer хорошая книжка о том как учиться программной инженерии, почитываю её постепенно в электронном виде. Она, во многом, именно про то как быть профессиональным разработчиком что включает написание тестов, документации, организации процесса разработки, изучение нового, работе в команде, понимание задач и целей программных продуктов и тд. В общем-то похоже на гайд для тимлидов, но начинающим разработчикам полезно читать чтобы понимать куда двигаться чтобы приобретать реальный опыт
- Columnar File Readers in Depth: Structural Encoding погружение в логику работы структурного кодирования в блоге LanceDB. Для тех кто работает с большими массивами и словарями данных о том чем отличается организация данных LanceDB по сравнению с Parquet и другими форматами.
- Is Your Data “AI-Ready”? Why Good Data Isn’t Enough Anymore вполне резонные рассуждения о том что просто "хорошие данные" недостаточны для применения вместе с ИИ. Сталкиваюсь с этим всё больше когда есть базы данных которые могут быть весьма неплохи, но без базы знаний прилинкованных к базам данных и применимость для ИИ задач ограничена.

#readings #ai #data

Рубрика "Циничная перегостехизация"
По данным источников (тм) завтра должна состояться большая стратсессия по Гостеху (но это не точно!).
Сначала эта стратсессия была запланирована на июль 2025, потом плановая дата переехала на август 2025 - но тоже не срослось.
И вот сейчас третья попытка.
В стратсессии будет принимать участие отец Гостеха - Греф Сбер (мамы у Гостеха нет, и это многое объясняет). Предварительная тема выступления Сбера - Гостех 2.0 (что бы это ни значило).
Те, кто еще почему-то следят за историей Гостеха, знают, что то, что сейчас называют Гостехом, это совсем не тот Гостех, который начинался в 2020 году (ахренеть - уже пять лет продолжается это шоу!) - от Сберовской Platform V там почти ничего не осталось.
Но Сбер не теряет надежды заново продать свое детище государству - теперь под вывеской "Гостех 2.0."
Мне еще пару месяцев назад подогнали презентацию Сбера про Гостех 2.0 - и, судя по всему, это внутренняя преза, а не картинки для "Бункера".
Завтра, если стратсессия все-таки состоится, в презе Сбера, наверняка, будет больше всяких лозунгов про пользу Гостеха 2.0 для государства и не будет картинок про экономику проекта в интересах самого Сбера.
Но вы посмотрите на то, что Сбер думает про Гостех внутри себя