Бывшие сотрудники Google опубликовали карту всех внутренних инструментов Google и их open-source аналогов.

15 200 звёзд. 1 100 форков. 99 контрибьюторов.

→ Borg = Kubernetes
→ Spanner = CockroachDB
→ Colossus = HDFS
→ Dremel = DuckDB / Presto
→ Chubby = Zookeeper
→ Stubby = gRPC
→ Zanzibar = SpiceDB
→ Blaze = Bazel
→ MapReduce = Spark

всё, чем инженеры Google пользуются каждый день.
у всего этого есть open-source аналоги.
ничто из этого не требует работы в Google.

https://github.com/jhuangtw/xg2xg

👉 @PythonPortal

🤣🤣🤣

👉 @PythonPortal

ПРО-СОВЕТ

Используешь локальные большие языковые модели? Дай им веб-стек.

Моя конфигурация:

- SearXNG: поиск и отбор источников-кандидатов
- Firecrawl: извлечение и обход по известным адресам
- Camofox: резерв через браузер, когда джаваскрипт или интерактив мешают

Поиск → Извлечение → Взаимодействие

Попроси своего агента настроить это и подключить к локальным моделям

> увидишь, как они резко становятся полезнее

Пожалуйста 🐌

👉 @PythonPortal

Братья! Google обновил Код-Вики.

Google фактически убрал одно из самых неприятных узких мест разработки — чтение чужого кода '

Новый Код-Вики автоматически подключается к любому репозиторию на ГитХабе и превращает его в постоянно актуальную, структурированную и интерактивную вики.

Три ключевые функции:

- автоматически сканирует репозиторий; документация обновляется в реальном времени при любых изменениях кода — больше не нужно переживать за устаревшие описания
- чат на базе Джемини работает по всей вики как по единой базе знаний, отвечает на вопросы и даёт ссылки с переходом прямо на конкретные строки кода
- автоматически строит архитектурные диаграммы, диаграммы классов и последовательностей; одним кликом можно перейти от объяснения к исходному коду

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

Google прямо говорит: «Чтение существующего кода — один из самых дорогих и проблемных этапов разработки».

Теперь этот этап фактически пытаются убрать как класс.

Публичные репозитории доступны для предварительного просмотра: http://codewiki.google

👉 @PythonPortal

Выпустили аналог Claude Code от DeepSeek.
Открытый исходный код, написан на Rust.

✓ использует API-ключ или локальные модели
✓ МСР, навыки, инструменты, память и т.д.

$ npm install -g deepseek-tui

→ https://github.com/Hmbown/DeepSeek-TUI

👉 @PythonPortal

В плейлисте 26 лекций по глубокому обучению
Один из лучших бесплатных материалов в открытом доступе.
Можно пройти путь от базового уровня до уверенного понимания примерно за 5 часов.

👉 @PythonPortal

Python: простые вещи, которые улучшают код

Если писать так:

if type(x) == str:
    print("Это строка")

это может работать, но ломается на наследниках str.

Правильнее использовать isinstance(). Он учитывает наследование и лучше согласуется с полиморфизмом.

if isinstance(x, str):
    print("Это строка")

Такой вариант сработает и для str, и для его подклассов.

Итог: type(x) == str годится только для простых случаев, но хрупкий. isinstance(x, str) — более устойчивый и корректный вариант почти всегда.

👉 @PythonPortal

Наконец-то кто-то пропатчил Chromium на уровне исходников!

Не JS-инъекции, не твики флагов, а полноценная модификация отпечатков прямо в C++ исходниках с последующей сборкой бинарника.

Результат?

Cloudflare Turnstile: всё пройдено
reCAPTCHA v3: score 0.9 (уровень человека)
FingerprintJS / BrowserScan: всё зелёное
Пройдено 30/30 детект-сайтов

Drop-in замена для Playwright / Puppeteer — меняете импорт в 3 строки кода и получаете моментальный unban!

pip install cloakbrowser
или
npm install cloakbrowser

Больше никакого страха перед anti-bot защитой, братья!

👉 @PythonPortal

все записи теперь братья близнецы

👉 @PythonPortal

Напоминание: в Python 3.14 завезли несколько действительно сильных обновлений 🐍

Если ещё не обновлялись, вот что появилось:

- Free-threaded Python теперь официально поддерживается — без GIL;
- deferred evaluation аннотаций — forward references теперь работают нормально из коробки;
- template string literals (t-strings) для более безопасной обработки строк;
- встроенный модуль сжатия Zstandard;
- подсветка синтаксиса прямо в REPL;
- multiple interpreters в стандартной библиотеке.

Кроме этого, tail-call interpreter даёт прирост производительности без изменений в коде:

- примерно 3–5% на Linux;
- около 7–8% на ARM Mac.

👉 @PythonPortal

Это, вероятно, самый честный разбор production-архитектуры AI-систем, который сейчас есть в интернете.

9-слойная AI production architecture:

services/ — RAG-пайплайн, семантический кеш, память, query rewriter, роутер. Не один файл. Пять.

agents/ — document grader, decomposer, adaptive router. Самокоррекция заложена в архитектуру.

prompts/ — версионируемые, типизированные, зарегистрированные. Никакого хардкода.

security/ — input, content и output-фильтрация. Три уровня защиты, а не один.

evaluation/ — golden dataset, офлайн-eval, онлайн-мониторинг. Большинство этот слой полностью пропускает и деплоит вслепую.

observability/ — трассировка по каждому этапу, привязка фидбека к трейсам, стоимость каждого запроса.

.claude/ — контекст агента, чтобы AI-кодинг-ассистент понимал кодовую базу до того, как начнёт менять файлы.

👉 @PythonPortal

😢😢😢

👉 @PythonPortal

Промпты для Claude, которые помогают оптимизировать GitHub-профиль.

👉 @PythonPortal

⚠️ Небольшой Python-трюк: как кастомизировать поведение списка

Класс UserList из модуля collections в Python используется для создания пользовательских объектов, работающих как список, но с кастомным поведением. Он выступает базовым классом, от которого можно наследоваться, если нужно реализовать собственные структуры данных со специализированными методами и логикой.

Допустим, вы хотите создать список с кастомным методом append(), разрешив добавлять только чётные числа. Код ниже показывает, как это можно реализовать через UserList.

В этом примере метод append() переопределён так, чтобы разрешать добавление только чётных чисел. Если передать нечётное число, выводится сообщение о том, что нечётные значения запрещены. Метод sort() также переопределён и всегда сортирует список в обратном порядке.

Когда экземпляр obj вызывается с аргументом 3, который является нечётным числом, выводится сообщение "Non-even numbers not allowed", а сам список остаётся без изменений.

👉 @PythonPortal

🤭🤭🤭

👉 @PythonPortal

DeepSeek выпустили фундаментальную переработку архитектуры трансформера.

Она решает проблему «кризиса идентичности», которая ломает очень большие модели ИИ.

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

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

Но есть проблема: при росте глубины и размера моделей такие простые «пропуски» перестают работать.

Информация размывается. Градиенты нестабильны. Математика начинает ломаться.

DeepSeek (включая исследователей, среди которых Вэньфэн Лян) опубликовали работу с введением mHC: манивольд-ограниченные гипер-связи.

Это полная переработка того, как данные проходят внутри модели.

Вместо одного «обходного пути» они расширили его до нескольких параллельных потоков. Эти связи называют гипер-связями.

Но на этом не остановились.

Когда появляется несколько потоков, система обычно уходит в хаос. Модель теряет «отображение идентичности» — перестаёт корректно передавать информацию без искажений.

Ключевой шаг DeepSeek — принудить эти связи жить на заданном математическом многообразии.

Проецируя связи на многогранник Бёркгофа с помощью алгоритма Синхорна–Кноппа, они заставили модель оставаться устойчивой.

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

Результаты:

Стабильность: удалось обучить модель на 27 млрд параметров, которую раньше нельзя было стабилизировать с обычными гипер-связями.

Производительность: значительное улучшение на бенчмарках кодирования, математики и рассуждений (BBH и DROP).

Эффективность: несмотря на усложнение, кастомное ядро добавляет примерно 6,7% накладных расходов на обучение.

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

DeepSeek показали, что реальный прирост даёт исправление «инфраструктуры» внутри модели.

Будущее масштабирования — не только в увеличении числа слоёв.

Оно в более качественных связях между ними.

👉 @PythonPortal

Динамическое программирование — одна из моих любимых тем в компьютерных науках.

А потом приходит осознание, что почти вся инфраструктура систем под капотом опирается на ту же самую идею.

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

И этот уровень абстракции встречается буквально везде.

Например, в базах данных оптимизаторы запросов по стоимости — это по сути огромные движки динамического программирования.

SQL-запрос с большим количеством JOIN между таблицами создаёт колоссальное комбинаторное пространство вариантов выполнения.
Оптимизатору нужно выбрать порядок JOIN, пути доступа, индексы, hash join / merge join / nested loop, predicate pushdown, partition pruning, стратегию параллелизма.

Наивный перебор растёт факториально.

Поэтому оптимизаторы используют динамическое программирование для вычисления:
«какой самый дешёвый способ выполнить подмножество S отношений?»

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

Что-то вроде:

DP[S] = минимальная стоимость плана для JOIN отношений из подмножества S

Дальше переходы выглядят так:
комбинируем оптимальные левый/правый под-планы + оцениваем cardinality + считаем стоимость IO / CPU / сети.

Вся магия в том, что система перестаёт повторно вычислять эквивалентные состояния, но при этом всё ещё приближается к глобальному оптимуму.

И это далеко не только про базы данных.

Динамическое программирование тихо лежит в основе:
алгоритмов кратчайших путей, декодирования Витерби, выравнивания последовательностей в биоинформатике, оптимизаций компилятора, edit distance, эвристик TCP congestion control, политик кэширования, планировщиков ресурсов, tiling для GPU-ядра, register allocation, вероятностного вывода, value iteration в reinforcement learning.

Даже современное мышление в распределённых системах часто напоминает динамическое программирование:
минимизация задержек и стоимости через ограниченные переходы состояний.

Больше всего мне нравится, как DP меняет само мышление.

Ты перестаёшь брутфорсить задачу и начинаешь задавать другие вопросы:

— какое состояние действительно важно?
— какой информации достаточно, чтобы восстановить будущее?
— где находятся пересекающиеся вычисления?
— может ли локальная оптимальность собираться в глобальную?
— какие измерения определяют пространство поиска?

Тот самый дофаминовый момент, когда решение оптимизируется с O(nlogn) до O(n) или с O(n²) до O(n), — именно ради этого хочется писать алгоритмы каждый день.

И этот майндсет полезен далеко за пределами алгоритмических собеседований.

Одна из самых элегантных идей в CS:
превращать невозможные пространства поиска в вычислимо решаемые задачи через сжатие состояния и переиспользование оптимальных результатов.

👉 @PythonPortal

👉 @PythonPortal

Кто-то сделал бесплатный PDF-редактор, который делает всё то же, что и Adobe, но занимает всего 20 МБ.

RevPDF работает полностью локально на устройстве. Позволяет редактировать текст и изображения, подписывать документы, редактировать конфиденциальные данные, сжимать файлы, конвертировать в Word — без интернета, без аккаунта и без подписки.

Полностью бесплатно. Полностью офлайн.

👉 @PythonPortal

7 обязательных сложностей алгоритмов (Big-O) для собеседований:

1. 𝐎(1) — 𝐤𝐨𝐧𝐬𝐭𝐚𝐧𝐭𝐧𝐚𝐲𝐚 𝐬𝐥𝐨𝐳𝐡𝐧𝐨𝐬𝐭𝐢

- Время выполнения не зависит от размера входных данных.
- Пример: доступ к элементу массива по индексу.

2. 𝐎(𝐥𝐨𝐠 𝐧) — 𝐥𝐨𝐠𝐚𝐫𝐢𝐟𝐦𝐢𝐜𝐡𝐞𝐬𝐤𝐚𝐲𝐚 𝐬𝐥𝐨𝐳𝐡𝐧𝐨𝐬𝐭𝐢

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

3. 𝐎(𝐧) — 𝐥𝐢𝐧𝐞𝐲𝐧𝐚𝐲𝐚 𝐬𝐥𝐨𝐳𝐡𝐧𝐨𝐬𝐭𝐢

- Время растёт линейно относительно размера входных данных.
- Пример: поиск элемента в массиве перебором.

4. 𝐎(𝐧 𝐥𝐨𝐠 𝐧) — 𝐥𝐢𝐧𝐞𝐲𝐧𝐨-𝐥𝐨𝐠𝐚𝐫𝐢𝐟𝐦𝐢𝐜𝐡𝐞𝐬𝐤𝐚𝐲𝐚 𝐬𝐥𝐨𝐳𝐡𝐧𝐨𝐬𝐭𝐢

- Время растёт чуть быстрее линейного. Обычно включает логарифмическое число операций на каждый элемент.
- Пример: сортировка quick sort или merge sort.

5. 𝐎(𝐧^2) — 𝐤𝐯𝐚𝐝𝐫𝐚𝐭𝐢𝐜𝐡𝐞𝐬𝐤𝐚𝐲𝐚 𝐬𝐥𝐨𝐳𝐡𝐧𝐨𝐬𝐭𝐢

- Время растёт пропорционально квадрату входа.
-Пример: bubble sort, где происходит сравнение и возможный swap каждой пары элементов.

6. 𝐎(2^𝐧) — 𝐞𝐤𝐬𝐩𝐨𝐧𝐞𝐧𝐭𝐬𝐢𝐚𝐥𝐧𝐚𝐲𝐚 𝐬𝐥𝐨𝐳𝐡𝐧𝐨𝐬𝐭𝐢

- Время удваивается с каждым новым элементом входа. Такие алгоритмы быстро становятся непригодными для больших данных.
- Пример: генерация всех подмножеств множества.

7. 𝐎(𝐧!) — 𝐟𝐚𝐤𝐭𝐨𝐫𝐢𝐚𝐥𝐧𝐚𝐲𝐚 𝐬𝐥𝐨𝐳𝐡𝐧𝐨𝐬𝐭𝐢

- Время пропорционально факториалу размера входа.
- Пример: генерация всех перестановок множества.

👉 @PythonPortal