где сердечки блин!!!!!!!

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

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

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

Эксперимент: как ИИ фильтрует DAO-пропозалы через ценности пользователя

Последнее время увлёкся вайдкодингом (программированием с помощью ИИ-моделей). И увидел задание в Ambient (о нём писал обзор в прошлом посте). Там требовалось создать скрипт для работы ИИ с ДАО.

В этот момент я вспомнил идею, которую давно хотел реализовать: ИИ анализирует DAO-пропозал (предложение) на основе ценностей пользователя. Что из этого получилось?

Проблема в том, что DAO-пропозалов становится всё больше, а времени и энергии на вдумчивое голосование - всё меньше.

Я реализовал прототип, который:
1. принимает ссылку на DAO-пропозал
2. получает данные через API (Snapshot, Tally) или извлечение данных напрямую со страницы из тега noscript (DAOdao).
3. сопоставляет содержание с набором принципов пользователя (JSON или API запрос)
4. и на выходе даёт отчёт: краткое описание, варианты, риски и рекомендацию по голосованию.

Прототип можно запускать в двух режимах: как простой скрипт с сохранением отчёта в JSON и как API-версию для использования в браузере или других скриптах.

В репозитории на GitHub я оставил 3 реальных примера пропозалов - по одному на каждый DAO-сервис. Их удобно использовать как тестовые кейсы или основу для доработки под свои ценности.
Там же есть инструкции по установке и использованию.

Интересный момент:
уже после этого я наткнулся на X-статью про DAO в 2026 году, где прямо говорилось, что ИИ будет использоваться для снижения усталости от принятия решений - через сопоставление пропозалов с ценностями пользователя.

В итоге получилось почти то, о чём там писали. Оказалось, я случайно попал в тренды будущего 🙂.

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

Это не замена мышления, а способ заранее отсеять пропозалы или варианты голосования, которые не совпадают с вашими принципами.

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

Доверили бы вы ИИ помогать с голосованием, если он не голосует за вас? Буду рад обсудить в комментариях. Свой ответ напишу первым.

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

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

Мне лень изучать алгоритмы Twitter, но хочется и там аккаунт развивать

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

https://x.com/i/status/2019831666353533045

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

🔔 Напоминание на завтра (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