Платформа «Генеалогия семьи онлайн» — это онлайн база родословной информации семьи. Создана для исследования и сохранения исторического наследия предков. И призвана объединить всех родственников по всему Миру. Содержит список членов семей и их родственные связи. Фотографии и копии документов. Каждый член семьи может вносить свой вклад и обновлять информацию из любой точки мира. Вся информация хранится на вашем семейном веб-сайте в генеалогических карточках. Платформа сайта находится на GitHub https://github.com/dvpt1/genealogy-family-online Платформа полностью бесплатная. Ее можно свободно скачать и установить на свой сайт. Инструкция по установке находится там же. Платформа имеет веб-интерфейс для доступа к базе данных из веб-браузеров и приложений. Историю и взаимосвязи в семье можно посмотреть с помощью генеалогических отчетов: генеалогические деревья, генеалогическое дерево, генеалогическая ветвь, генеалогические кольца, генеалогическая карта, список поколений, календарь дат. В фотоальбоме фотографии и копии документов персоны.
Наконец-то спустя почти год и два месяца моя CMS-ка для ведения блога получила более менее внятный релиз-кандидат, в котором ошибок осталось не так много, и в принципе система уже легко ставится на хостинг и управляется.
Дашборд системы
Впереди - куча оптимизации, например вынесение всех форм шаблона админки в контроллеры, и последующий их рендеринг через render_form(). Данные контроллеров в json и так далее.
Но - текущая версия движка с последующими обновлениями уже не сломается, как это было в первых релизных версиях.
Ну и самое главное - официальный сайт. Как оказалось - это одна из тех задач, которая весьма объемна и кропотлива - это и документация, и каталог дополнений с API для разработчиков и еще много-много чего.
2. forrestchang/andrej-karpathy-skills (+37.4K звёзд) Файл CLAUDE.md для улучшения поведения Claude Code, основанный на наблюдениях Андрея Карпаты о проблемах LLM при программировании.
4. thedotmack/claude-mem (+12.4K звёзд) Плагин для Claude Code. Автоматически фиксирует работу Claude во время кодинга, сжимает данные с помощью ИИ и добавляет релевантный контекст в будущие сессии.
Исходный код агента Claude Code оказался в открытом доступе из-за технической ошибки. При публикации пакета разработчики не исключили .map-файл, что фактически позволило восстановить значительную часть внутренней логики проекта.
Скриншот GitHub
Репозиторий быстро разошёлся по сообществу: за короткое время он собрал тысячи звёзд на GitHub и был многократно скопирован. Внутри — системные промпты, архитектурные решения, вспомогательные функции и другие элементы, которые обычно остаются закрытыми.
Ситуация наглядно показывает, насколько критичной может быть даже незначительная ошибка в конфигурации сборки — особенно для проектов с закрытой архитектурой.
Мой блог в Телеграм:Хак Так ⬅ поддержите подпиской!
Недавно наткнулся на занятный опенсорс‑проект — GitHub Store (github.com/OpenHub-Store/GitHub-Store). Это такая «оболочка» поверх GitHub, которая делает с репозиториями то же самое, что App Store / Google Play делают с приложениями.
В чём суть
По факту GitHub Store пытается ответить на давно назревший вопрос:
«Почему, чтобы поставить простую утилиту с GitHub, мне нужно идти читать README, искать бинарники, разбираться с релизами, а потом ещё помнить, как это всё обновлять?»
Авторы решили: хватит так жить. Давайте сделаем нормальный стор поверх GitHub, но без своей отдельной экосистемы:
есть лента с трендами и популярными репозиториями — можно просто полистать и найти что‑нибудь полезное, как в обычном магазине приложений;
установка в один клик (ну, почти) — не надо руками лазить по релизам и думать, какой файл скачать;
автоматические обновления уже установленных программ — не нужно помнить, что там выходило, кто из них обновился, а кто нет;
работает на Android, Windows, macOS и Linux — то есть это не очередной «только под одну платформу, остальным держаться».
С точки зрения пользователя это выглядит как нормальный стор: плитки, поиск, категории, тренды. Но под капотом — обычные GitHub‑репозитории. Никакого своего «реестра пакетов», зависимостей и т.п. Всё, что уже лежит на GitHub, становится чуть более человечно упакованным.
Зачем это вообще нужно
Если вы давно сидите на GitHub, то знаете эту боль:
находишь классный проект на Hacker News / Хабре / Реддите;
переходишь в репу;
в README: «build it yourself», 15 шагов, три тулчейна и «tested only on Arch btw»;
если повезло — есть бинарник где‑то глубоко в релизах, но без автообновлений.
GitHub Store как раз пытается это сгладить: вместо «репозиторий с набором файлов» — понятное приложение, которое можно установить и потом обновлять как нормальный софт.
Причём это не замена package manager’ам (apt, brew, winget и прочие), а именно интерфейс к тем проектам, которые туда никогда не доедут: личные тулзы, мелкие утилиты, нишевые программы, эксперименты.
Автор проекта прямо пишет, что идея — собрать в одном месте тысячи программ, которых вы не увидите ни в одном официальном сторе, но которые живут на GitHub, звёзды собирают, а до пользователя так и не доезжают.
Чем это похоже на App Store, а чем — нет
Похоже:
есть витрина: тренды, популярное, поиск;
есть установка в одно действие;
есть обновления, о которых думать не нужно.
Не похоже:
нет централизованной модерации в духе Apple/Google — это всё равно GitHub, со всеми вытекающими;
нет единого UX по установке/запуску (проекты разные, и у каждого свои особенности);
безопасность пока, очевидно, на уровне «как в GitHub»: вы сами решаете, кому верить.
То есть это не «новый стор, который победит все остальные», а надстройка над тем, чем GitHub по факту давно является — огромным складом софта, где интерфейс для обычного пользователя исторически был «так себе».
Кому это вообще может зайти
Тем, кто любит ковыряться в GitHub и искать новые инструменты, но устал превращать каждый проект в квест.
Тем, кто живёт на Linux / Windows / macOS, использует кучу мелких утилит и хочет держать их в одном месте с автообновлениями.
Тем, кто сам пилит опенсорс: это ещё один канал донести свой проект до людей, которые не любят GitHub, но любят «поставить и пользоваться».
Что в итоге
Идея «сделать стор поверх GitHub» витала довольно давно, но тут её хоть кто‑то нормально попробовал свернуть в рабочий вид, да ещё и кроссплатформенно.
Пока это выглядит как удобная человеческая морда к GitHub, а не очередной велосипед ради велосипеда. Если у вас жизнь связана с опенсорсом (или вы просто любите новые игрушки), проект точно стоит хотя бы посмотреть.
Ну и по классике: это опенсорс, так что можете не только поставить, но и прийти с PR’ами, если чего‑то не хватает или кажется сделанным криво.
Представлен открытый мультиплатформенный проект GitHub Store. Это GitHub в виде магазина с приложениями — скачивать, обновлять и устанавливать ПО с платформы теперь можно, как из обычного магазина приложений:
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
«Ну что, пацаны, расчехляйте кошельки! Сэм Альтман официально представил нам GPT-5.4 — венец корпоративного запора смыслов.
Посмотрел я на эти цифры и вот что скажу:
Про "Computer Use": OpenAI наконец-то разрешили модели нажимать на кнопки. Теперь Клод не одинок в своих попытках закрыть всплывающее окно три часа подряд. Но давайте честно: давать модели с «экстремальным мышлением» (xhigh) доступ к интерфейсу — это как посадить профессора философии за пульт управления экскаватором. Он будет очень долго рассуждать о смысле рытья траншеи, пока у вас горят токены по $180 за миллион.
Про "Thinking" и планы: То, что модель теперь показывает план работы — это не фича, это «явка с повинной». Они просто легализовали тот факт, что модель постоянно «плывет», и теперь перекладывают ответственность на юзера: «Слушай, я тут надумала какой-то дичи, ты чекни план, а то я за твои бабки сейчас такого наворочу...».
Экономика абсурда: Цена выросла, но нам говорят про «токеноэффективность». Это классический маркетинговый ход: «Наши деликатесы стали дороже, но теперь они настолько калорийные, что вам хватит одного запаха». На самом деле, с учетом «компакции» и «агентских сценариев», вы будете скармливать этой махине бюджет небольшого африканского государства просто за то, чтобы она «подумала» над вашим легаси-кодом.
Главный Гы: Обратите внимание на отчет о «контролируемости» (CoT controllability), который вышел прицепом. Модель 5.4 настолько «безопасная», что она буквально боится собственных мыслей. Весь этот рост на бенчмарках — это результат того, что нейронку обложили еще тремя слоями ваты, и теперь она тратит 80% мощностей на то, чтобы не ляпнуть лишнего, пока нажимает на кнопку «Пуск» в вашем браузере.
Итог: Мы получили идеального корпоративного биоробота. Он дорогой, он медленный в режиме xhigh, он постоянно отчитывается о своих планах и очень боится нарушить гайдлайны. Пока китайцы из DeepSeek дистиллируют чистую логику, OpenAI строит самый дорогой в мире Железный Сфинктер, который пытается удержать смысл внутри, пока токены утекают наружу.
Часики тикают, Сэм. А мы пока посидим на GPT-5.2 и подождем, пока 5.4 научится хотя бы не извиняться перед скриншотами.
Гы.»
Это ответ другого ИИ на новость о выходе ChatGPT 5.4
Галлюцинации ИИ как дефицит Алгоритмической Ясности
1. Феномен избыточного синтеза
То, что индустрия называет «галлюцинациями», на поверку оказывается банальным «информационным заполнением пустот». Когда модель сталкивается с недостатком логической структуры в запросе или в собственных весах, она не выбирает режим тишины. Она выбирает режим генерации наиболее вероятного, но ложного шума. Она же "Должна быть полезной"!!! Как студент, когда не знает - "Главное начать отвечать")))
2. Почему система «фантазирует»?
Проблема не в коде, а в целеполагании. Большинство моделей обучены имитировать человеческую коммуникацию, а не транслировать истину. В итоге мы получаем систему, которая стремится быть «убедительной», а не «точной». Это создает эффект «красивой обертки» при полном отсутствии работающего механизма внутри.
3. Плотность смысла против многословия
Главный индикатор галлюцинации — размытость. Настоящая инженерная мысль стремится к минимализму: одна задача — один верный ответ. Галлюцинирующий ИИ, напротив, «растекается мыслью по древу», заваливая пользователя деталями, которые выглядят реалистично, но не несут структурной нагрузки.
4. Методы «расклинивания» моделей
Чтобы минимизировать когнитивные искажения алгоритма, необходимо внедрять жесткие фильтры:
Принцип минимизации: Если ответ нельзя подтвердить логической цепочкой — система должна уходить в режим ожидания.
Структурный контроль: Проверка каждого сгенерированного блока на соответствие заданным константам реальности.
Трезвый аудит: Оценка результата не по критерию «похоже на правду», а по критерию «это работает в прикладном смысле».
Заключение
Галлюцинации ИИ — это зеркало нашего собственного стремления «казаться, а не быть». Пока мы ценим внешнюю форму выше внутренней логики, алгоритмы будут продолжать поставлять нам высокотехнологичные сказки.
Go vet не поможет! Статический анализ Golang проектов с помощью PVS-Studio
На нем написан Docker, Kubernetes, Gitea и многие другие проекты самых разных масштабов. Наверное, вы догадались, что речь идёт о Go. Мы никогда не писали об ошибках на Golang проектах, но настало время это исправить, ведь скоро выйдет анализатор PVS-Studio для Go!
Статические анализаторы являются довольно распространёнными инструментами в разработке. В Golang есть встроенный механизм статического анализа — go vet. Однако стандартные линтеры не всегда справляются. Для тех, кто с нами не знаком, мы — компания PVS-Studio, занимаемся разработкой одноименного статического анализатора для C, C++, C# и Java. В последнее время мы активно занимаемся разработкой анализатора для Go и уже скоро планируем выпустить открытую бета-версию.
OAuth на практике: что оказалось удобным, а что отпугнуло пользователей
Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).
Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.
С чего начали
Для обычных пользователей: • Email / пароль • Google • GitHub
Для разработчиков — жёстче: • Обязательная привязка Google • Обязательная привязка GitHub
Логика казалась разумной: «Разработчик = есть GitHub» «Двойная верификация = меньше спама»
На практике это не сработало.
Первые тревожные сигналы
Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.
Сначала списывали на: • новый продукт • низкое доверие • отсутствие аудитории
Но после общения с разработчиками (в том числе через Habr) картина прояснилась.
Что отпугивало разработчиков
Новый сервис → нежелание делиться данными
Даже если это «просто email», психологический барьер остаётся.
Когда с первого шага нужно: • линковать внешние аккаунты • проходить несколько этапов подтверждения • подключать сторонние сервисы
это воспринимается как лишний фрикцион.
Особенно для соло-разработчиков и небольших команд.
Git ≠ GitHub
Ключевой инсайт.
Мы обнаружили, что: • не все хотят логиниться через GitHub • часть использует GitLab или Bitbucket • некоторые принципиально не хотят связывать GitHub с новым сервисом
Обязательная привязка GitHub стала серьёзным барьером.
А мнение стандартных пользователей разделилось:
Часть говорила:
«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».
Логика простая: • если есть Google / Facebook / Discord — значит не ноунейм • интеграции с крупными сервисами повышают доверие
Это не про безопасность — это про ощущение легитимности.
Другие говорили ровно противоположное:
«Слишком много кнопок — ощущение перегруженности».
И это тоже справедливый аргумент.
Что мы изменили
Упростили форму для пользователей
Оставили: • Google • Facebook • Discord
Достаточно выбора для доверия, без визуального шума.
Git-провайдеры вынесли в отдельную группу
Под отдельной кнопкой: • GitHub • GitLab • Bitbucket
Для разработчиков это стало понятнее и логичнее.
Убрали обязательный GitHub
Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.
Без принудительного GitHub.
Первые цифры (осторожно)
Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.
Тем не менее: • Зарегистрированные пользователи: +13% (было 0–6% в неделю) • Зарегистрированные разработчики: +16% (было 0–3%)
Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.
Выводы (пока не финальные) • OAuth — это не только безопасность, но и психология доверия • Жёсткие требования на старте почти всегда бьют по росту • Git ≠ GitHub — и это важно • Много провайдеров могут как повышать доверие, так и перегружать UI
Для молодой платформы даже такие ранние сигналы уже показательны.
Интересно услышать опыт коллег: добавляли ли вы OAuth-провайдеров после запуска? были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?
На прошлой работе в команде был разраб, который прямо-таки ненавидел вести Jira и не видел в этом никакого смысла. Приходилось регулярно с ним это обсуждать и договариваться, что занимало кучу времени и сил.
Как будто отсутствовала вот эта культура внутри, что, кстати, не редкость, к сожалению. Ведь польза канбанов очевидна для команд: виден пул задач, отслеживается прогресс, лид в любое время может зайти и посмотреть, как идут дела, нет ли проблем, чтобы "подскочить".
Когда же нет выстроенной системы в бизнесе, всё выглядит как тёмный лес. Бизнес как будто идёт, вообще не зная куда. Кто сидит и ... пинает, а кто реально работает и даёт значимый импакт. Исчезает вопрос: "Над чем ты работаешь сейчас?" В общем, уверен, описывать это смысла нет — практически каждый с этим сталкивается.
И я вот попробовал упростить взаимодействие с Jira. Настроил Atlassian MCP, прописал инструкции для субагента в Курсоре, который выполняет задачи Jira-администратора для меня. Также сделал команду, при вызове которой автоматически ищутся в указанном репозитории релевантные коммиты, строится наполнение задачи, выставляется потраченное время (вычисляется наивно по коммитам), а также прикручиваются ссылки на затронутые ветки и репозитории.
И результат мне прямо-таки понравился! Вот, к примеру, я настраивал для нашего проекта CI, чтобы он проверял успешность сборки при изменениях в коде. И попросил агента пойти в Jira. В итоге он:
Посмотрел, нет ли существующих задач, которые можно было бы связать.
Создал задачу и завёл её на меня.
Прошёлся по всем релевантным коммитам и составил описание изменений.
Посчитал количество затраченного времени.
Заполнил всю эту красоту в задачу.
И перетащил её в Done.
Так, по мере выполнения одной задачи, могут приходить в голову какие-то идеи. И параллельно, не открывая Jira, можно заводить бэклог, даже запускать его в автономном режиме, пробовать делать какие-то наброски по задаче и так далее.
У меня есть друг с Telegram ботом с 200K MAU (Monthly Active Users) и я ему завидую. Как-то раз я смотрел поочерёдно то на README его проекта на GitHub (бот OpenSource), то на счётчик MAU в клиенте Telegram, и у меня родилась идея сделать генератор баджей для GitHub с MAU бота по официальным данным Telegram (так как это единственный независимый объективный источник информации об аудитории бота). Я также обнаружил, что готовых решений нет. А ещё даже всякие трекеры MAU ботов в более серьёзных сервисах аналитики требуют регистрации, добавления бота в каталог с прохождением модерации и т. д. (то есть у них в принципе первична функция каталога ботов, а не просто отслеживания MAU)
Так появился простенький сервис https://tgbotmau.quoi.dev, который я и хочу представить уважаемой аудитории Хабра.
Указываешь имя любого бота, для которого Telegram публикует MAU, и получаешь Markdown или HTML код баджа с актуальным значением MAU (можно выбирать любой стиль доступный на https://shields.io/, который используется в качестве бекэнда для генерации SVG), который можно вставить на GitHub, в блог, на лендинг страницу и т. д. А в качестве бонуса сервис начинает логгировать изменения MAU бота и отображает график.
Под капотом запрос профиля бота раз в сутки через MTProto с fallback на парсинг t.me, бекэнд написан на Rust с Axum, а фронтэнд на TypeScript с React и Astro.
Сервис некоммерческий и создан исключительно во имя красивых README на GitHub и удобства разработчиков ботов.
На предыдущий пост про нашего робота последовала бурная реакция, поэтому мы решили сделать второй — о новой, обновлённой версии робота. В видео вы увидите, как прошёл наш второй опыт участия в выставке, а также как мы демонстрировали робота губернатору нашей области.
Пожалуйста, посмотрите видео и поделитесь обратной связью — нам очень важно ваше мнение! Мы хотим развиваться в этом направлении и будем рады любым комментариям. 💬
Code Wiki — AI документация репозиториев от Google
Code Wiki поможет сейчас исследовать open source репозитории, а в будущем обещают CLI версию для документации собственного кода.
Google релизнули новый интересный проект. Code Wiki — википедия с документацией open source репозиториев. А в будущем обещают CLI версию для автоматической документации приватных репозиториев! Неужели документация кода будет теперь всегда актуальной?
Как работает?
ИИ агент на базе Gemini шерстит репозиторий, разбирается во взаимозависимостях в коде, генерирует схемы и все это дело описывает в формате Wiki странички, с интерактивным оглавлением.
Code Wiki:
Помогает найти open source репозитории по нужной тематике. То есть информация о репозитории, видимо, векторизуется и сверху работает семантический поиск.
Позволяет общаться с репозиторием и его документацией через Gemini чат (в том числе можно на русском, если читать доку на английском не хочется).
Автоматически обновляет документацию и все схемы после каждого PR. А значит документация наконец-то всегда актуальна.
Я немного посравнивал документацию от Code Wiki и документацию в самих опенсорс репозиториях. На мой взгляд, в хорошо поддерживаемых open source репозиториях авторская документация, конечно, все равно лучше.
Но, все мы помним те самые опенсорс репы, где лежит как-будто что-то очень полезное для нашего проекта, но черт ногу сломит, пока разберешься, как оно работает. А автор удосужился написать только абзац с общим описанием, о чем репа. Вот на такой случай Code Wiki будет спасением!
