🔔 Напоминание на завтра (9 фев, день):

Проект CreatorScout / influencer lead gen:

1. Проверить ответ от создателя Datalikers по max_followers фильтру
2. Купить домен (creatorscout.co / leadlikers.com / другой)
3. Задеплоить Umami аналитику на Coolify
4. Создать Stripe payment links ($29/$49/$99)

Полный план: projects/second-brain/ai-docs/2026-02-08 Lead Generation by Region — Product Research.md

Баланс Datalikers: 53 запроса из 100 бесплатных.

📟 Прилетело из @danokhlopkov

Алгоритмы. Представление графов и обход в ширину (BFS)

Новая неделя и новый раздел в изучении алгоритмов. Мы плавно переходим к теме алгоритмов на графах и сегодня поговорим о BFS.

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

    A --- B
    |     |
    C --- D

Здесь буквы A, B, C и D обозначают вершины, а линии между ними — рёбра, то есть связи.

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

# Граф из примера выше
graph = {
    "A": ["B", "C"],      # из A можно попасть в B и C
    "B": ["A", "D"],      # из B можно попасть в A и D
    "C": ["A", "D"],      # из C можно попасть в A и D
    "D": ["B", "C"]       # из D можно попасть в B и C
}

Такой формат хранения делает работу с графом интуитивно понятной и эффективной для многих алгоритмов, одним из которых является обход в ширину. Алгоритм обхода в ширину, или BFS, служит для систематического посещения всех вершин графа, начиная с заданной. Его можно сравнить с волнами, расходящимися от брошенного в воду камня: сначала рассматривается начальная вершина, затем все её непосредственные соседи, потом соседи соседей и так далее, слой за слоем. Это гарантирует, что все вершины на расстоянии одного ребра будут посещены раньше, чем вершины, находящиеся на расстоянии двух рёбер.

Для реализации BFS потребуется несколько инструментов: очередь для хранения вершин, которые ожидают обработки, множество для отметки уже посещённых вершин во избежание циклов и повторного посещения, а также список, фиксирующий порядок обхода. Очередь работает по принципу «первым пришёл — первым вышел», что и обеспечивает поэтапное, послойное исследование графа.

Реализация алгоритма на языке Python выглядит следующим образом:

from collections import deque

def bfs(graph, start_node):
    # 1. Создаём множество для отслеживания посещённых вершин
    visited = set()
    
    # 2. Создаём очередь и добавляем стартовую вершину
    queue = deque([start_node])
    
    # 3. Помечаем стартовую вершину как посещённую
    visited.add(start_node)
    
    # 4. Список для сохранения порядка обхода
    result = []
    
    # 5. Пока в очереди есть вершины
    while queue:
        # Достаём первую вершину из очереди
        node = queue.popleft()
        result.append(node)
        
        # Смотрим на всех соседей этой вершины
        for neighbor in graph.get(node, []):
            # Если соседа ещё не посещали
            if neighbor not in visited:
                # Помечаем как посещённого
                visited.add(neighbor)
                # Добавляем в очередь для будущего посещения
                queue.append(neighbor)
    
    return result

Рассмотрим работу алгоритма на конкретном графе:

graph = {
    "A": ["B", "C"],
    "B": ["A", "D", "E"],
    "C": ["A", "F"],
    "D": ["B"],
    "E": ["B", "F"],
    "F": ["C", "E"]
}

Визуально этот граф можно представить так:

        A
       / \
      B   C
     /|   |
    D E   F
       \ /

Пошаговое выполнение BFS, стартующего от вершины A, будет происходить в таком порядке:

📟 Прилетело из @solidityset

Шаг 0:
Очередь: [A]
Посещённые: {A}
Результат: []

Шаг 1: Обрабатываем A
Очередь: [B, C]
Посещённые: {A, B, C}
Результат: [A]

Шаг 2: Обрабатываем B
Соседи B: A (уже посещён), D, E
Очередь: [C, D, E]
Посещённые: {A, B, C, D, E}
Результат: [A, B]

Шаг 3: Обрабатываем C
Соседи C: A (уже посещён), F
Очередь: [D, E, F]
Посещённые: {A, B, C, D, E, F}
Результат: [A, B, C]

Шаг 4: Обрабатываем D
Соседи D: B (уже посещён)
Очередь: [E, F]
Посещённые: {A, B, C, D, E, F}
Результат: [A, B, C, D]

Шаг 5: Обрабатываем E
Соседи E: B (уже посещён), F (уже посещён)
Очередь: [F]
Посещённые: {A, B, C, D, E, F}
Результат: [A, B, C, D, E]

Шаг 6: Обрабатываем F
Соседи F: C (уже посещён), E (уже посещён)
Очередь: []
Посещённые: {A, B, C, D, E, F}
Результат: [A, B, C, D, E, F]

Именно использование очереди, которая следует принципу FIFO, и обеспечивает этот порядок обработки вершин слой за слоем.

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

def bfs_shortest_path(graph, start, end):
    visited = set()
    queue = deque([[start]])  # Храним путь, а не только вершину
    visited.add(start)
    
    while queue:
        path = queue.popleft()
        node = path[-1]  # Последняя вершина в текущем пути
        
        if node == end:
            return path  # Нашли кратчайший путь!
        
        for neighbor in graph.get(node, []):
            if neighbor not in visited:
                visited.add(neighbor)
                new_path = path + [neighbor]
                queue.append(new_path)
    
    return None  # Пути нет

Например, для графа ниже:

graph = {
    "A": ["B", "C"],
    "B": ["A", "D"],
    "C": ["A", "E"],
    "D": ["B", "E"],
    "E": ["C", "D", "F"],
    "F": ["E"]
}

print(bfs_shortest_path(graph, "A", "F"))
# Результат: ['A', 'C', 'E', 'F']

Алгоритм вернёт один из кратчайших путей.

Другим полезным применением BFS является определение расстояния от начальной вершины до всех остальных, то есть их уровня. Для этого в очередь вместе с вершиной помещается и информация о её текущем уровне:

def bfs_levels(graph, start):
    visited = set()
    queue = deque([(start, 0)])  # (вершина, уровень)
    visited.add(start)
    levels = {}
    
    while queue:
        node, level = queue.popleft()
        levels[node] = level
        
        for neighbor in graph.get(node, []):
            if neighbor not in visited:
                visited.add(neighbor)
                queue.append((neighbor, level + 1))
    
    return levels

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

Часто возникает вопрос о различии между BFS и обходом в глубину. Основное отличие заключается в стратегии исследования. BFS исследует граф послойно, используя очередь, и потому находит кратчайший путь. DFS же, используя стек или рекурсию, идёт по одному пути до конца, прежде чем вернуться и исследовать другие ветви. Визуально это можно представить так: для дерева с корнем A, детьми B и C, и внуками D, E у B и F у C, BFS даст порядок A, B, C, D, E, F, а DFS может дать порядок A, B, D, E, C, F.

Сложность алгоритма BFS составляет O(V + E), где V — число вершин, а E — число рёбер, так как каждая вершина и каждое ребро обрабатываются один раз. Пространственная сложность оценивается как O(V), поскольку в худшем случае необходимо хранить все вершины в очереди и множестве посещённых.

📟 Прилетело из @solidityset

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

#algorithm

📟 Прилетело из @solidityset

4К+ без мифов: почему хороший проект не обязан быть хорошей инвестицией

Или как я пересматривал свои рейтинги и увидел расхождение между качеством проекта и ценой токена.

В июне прошлого года я анализировал один из старейших perp dex (децентрализованная биржа деривативов) - dYdX.
По итогам 4К+ он получил 8.4 из 10, если считать общий рейтинг по десятибалльной шкале.

Но важное уточнение: высокая оценка была набрана за счёт других разделов.
По коину у меня стоял рейтинг 3 из 5 - токеномику я считал слабым местом проекта.

А вчера захожу в @price_informerBot и вижу, что $DYDX за месяц упал примерно на 40 процентов и сейчас находится всего на 10 процентов выше исторического минимума.

И именно поэтому я решил написать этот пост - чтобы не было иллюзий при использовании 4К+ аналитики.
Особенно когда смотришь только на итоговый балл.

Да, проект качественный. Это подтверждается тем, что он продолжает развиваться, а TVL (количество средств в протоколе) сохраняется примерно на одном уровне.
И с точки зрения пользователя или трейдера это вполне рабочий продукт.

Но это не значит, что $DYDX - хорошая инвестиция, если вы не сторонник ДАО, который никогда не собирается продавать актив 😊.

Итог:

4К+ может показать, что проект качественный.
Но это не значит, что его токен будет хорошей инвестицией.

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

При этом само приложение вполне можно использовать для торговли. И многие так и делают.

Для себя вы бы выбрали:
пользоваться продуктом без покупки токена, или вообще не заходить в проект?

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Имхо пост

Эволюция работы за компом:
• проект — это его код
• проект — это его спецификация в md файлах
• операционная система — это папка с папками с md файлами
• ???

Я считаю просто необходимым выделять время на изучение новых AI инструментов: не переключаться на чуть более умную LLM, а на новый опыт. У многих он случился после перехода с ChatGPT на Claude Code, у других с Claude Code на Openclawd.

Читать про это мало смысла — надо пробовать самому.

Фишка Openclawd в том, что он абстрагирует тебя от менеджмента контекста, запоминания важного, сам пишет себе недостающий код и может проактивно себя вызывать. Это новый опыт. 100% более безопасная и оптимизированная по $$ версия скоро появится в самом Claude Code, а может даже и в macOS. Но уже сегодня можно почувствовать возможности, которые могут натолкнуть на продуктивный полет фантазии.

Имхо в холиваре Codex vs. Claude Code vs. Opencode мало смысла, ведь последние модели от Anthropic или OpenAI уже достаточно умные. Уже роляет ваш скилл генерации контекста и достигания желаемого результата. Да OpenAI завозят супербыстрые LLMки на чипах Cerebras, но рост продуктивности не случится без навыка извлечения пользы из AI.

В интернете уже очень очень много сгенерированного AI слопа: верить наслово никому не стоит. Очень важно выделять время на самостоятельное тыканье. Ссылки на проекты для изучения регулярно постятся в нашем чате при канале))

📟 Прилетело из @danokhlopkov

Как правильно писать скиллы для Claude Code

Спасибо чату за гайд: 7 типичных ошибок, из-за которых скилл не работает:

🔺 Нет триггера - Claude не понимает КОГДА вызывать скилл. Пиши “юзай, когда тебя просят задеплоить”, а не “поможет при деплое”.

🔺 Нет конкретных глаголов действий - “работает с файлами” это вода. Пиши create, generate, convert, analyze.

🔺 Дженерик имена - skill, helper, utils. Лучше: github-pr-reviewer, dev-browser.

🔺 Пустые секции в документации — заголовок без контента жрёт токены впустую. Нет контента - удали секцию.

🔺 Многословные триггеры - "This skill should be used when the user wants to" → просто "Use when …” Каждый лишний токен стоит денег.

🔺 Нет формата вывода - скилл должен знать, что отдавать: json, md, plain text. С примером.

🔺 Противоречия - "always use TypeScript" и "support any language" в одном файле. Тут уж без обид.

Короче: хороший скилл = понятное имя + когда вызывать + что делать + в каком формате отдавать.

Не заполняйте контекст мусором, вам еще свои промпты докидывать.

📟 Прилетело из @danokhlopkov

Пидорасы, отъебитесь от телеги

📟 Прилетело из @n4z4v0d

#freetelegram

📟 Прилетело из @n4z4v0d

gm! Нашёл 23-страничный тред на Gipsy Club русскоязычных трейдеров на покер-форуме про Polymarket. 460 постов за 3 месяца. Там люди с профитом делятся тем, что работает.

Собрал всё в один playbook, потому что обычно такое знание остаётся погребённым в форумных потоках. Читать 460 постов никто не будет.

Что внутри:

– 44 торговых принципа от людей с реальным P&L. Не теория. «Вот конкретная сделка, вот почему зашёл по 5c, вот почему вышел по 47c, вот где просрал из-за жадности».

– Инсайдерские кластеры — кто покупает за часы до публичных новостей. Timeline от полуночи до утра, пока обычные люди спят.

– Структурные арбитражи в правилах маркетов. Типа «China invades Taiwan before GTA VI» когда GTA уже отложена = чистый фриролл.

– Шаблон для авторитарных выборов. Venezuela case: как залокать профит вне зависимости от исхода.

– Антипаттерны с цифрами. $20k потеряно на переносе экспертизы в смежную область. $19.5k упущенного профита из-за «завтра куплю».

– 15 детальных кейсов с входами и выходами — от +$7k на Ukraine ceasefire до +100% за ночь на Venezuela волатильности от риторики Трампа.

– Конкретные трейдеры с кошельками, tier-рейтингами и специализацией.

——

Если торгуешь на Polymarket — прямой edge. Если нет — кейс как собрать разрозненное знание комьюнити в работающую базу.

——

https://www.insuline.club/playbook

📟 Прилетело из @insuline_eth

📟 Прилетело из @dev_in_ruby_colors

Мозг умирает от иишек

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

Сейчас я наверно могу выделить один основной момент, о котором сейчас пишут все - теперь люди это мистеры "код ревью", а это не самая приятная работа

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

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

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

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

📟 Прилетело из @ortomich_main

Сегодня через полчаса думаю поработать в режиме live coding, попишем контракты и тесты не слишком сложные, просто чтобы немного освежить, так что залетайте (дурацкая обложка временная 😂) https://youtube.com/live/I8yS7z_GkFw?feature=share

📟 Прилетело из @dev_in_ruby_colors