tgindex
Кодовой Барабанщик

Кодовой Барабанщик

Статистика

БлогеРОК программиста-барабанщика 👨‍💻🥁 Telegram: @GranSteL YouTube: https://youtube.com/@granstel ВКВидео: https://vkvideo.ru/@drummer_programmer

Последний пост
14 авг.
Последнее чтение
19:30
Постов за неделю
3
Всего постов
26
Тип
открытый
Язык
русский
Категория
Технологии
В каталоге с
12 авг.
Подписчики
101
0 за 4 дн.
Сутки
0
0,00%
Неделя
 
Месяц
 
Просмотров на пост
56
25 постов
Вовлечённость
55,4%
к подписчикам
Постов в день
0,4
всего 26
Упоминаний
1
каналов
Охват размещения
оценка
1/24сутки в ленте
30
1/48двое суток
34
1/72трое суток
37

Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.

Посты

  • Добавил в #занимательныеистории такой вот сюжет)

  • Способы применения нейронок: тестировщик 😨 Многие вещи в программировании начинаются и заканчиваются с тестов: - Хочешь исправить баг: сперва напиши тесты на ожидаемое поведение - Закончил задачу? Напиши тесты! Написание тестов — довольно рутинная работа. Особенно неприятно, если основной код уже написан, а теперь, оказывается, нужно потратить примерно столько же времени, чтобы убедиться, что он работает (и, зачастую, тесты конечно находят баги, что полезно 🐞) Если не доверяешь нейронке написание основного кода, попробуй отдать ей написание тестов Написание тестов относительно легко формализовать: есть правила, паттерны, структура, ожидаемое поведение. И доверить нейросети такую работу не так страшно. В худшем случае тест будет красным или работать вхолостую Кстати, ещё интересный вариант — попросить нейросеть проверить уже написанные тесты 🔍 🟢Зелёный тест ещё не означает хороший тест 🔴 Можно написать тест с такой запутанной подготовкой, что он фактически проверяет сам себя. Или ничего не проверяет вовсе. Или проверяет не то, что нужно. Или проверяет слишком много и ломается от каждого изменения 💔 Особенно это неприятно со сложными интеграционными тестами: они могут выполняться долго, а пользы при этом не давать почти никакой 0️⃣ Здесь #ИИшница тоже может помочь. Она способна быстро пройтись по коду, проследить взаимосвязи и ветвления, понять, что реально происходит во время теста, и найти несостыковки между тестом и тем, что он якобы должен проверять Ещё более интересный вариант: реальное тестирование функционала Юнит-тесты могут проверить лишь определённую логику в вакууме. Интеграционные тесты могут проверить, как взаимодействую между собой по одному экземпляру сервисов в идеальных условиях Воссоздавать вручную условия для более достоверного тестирования довольно сложно: нужно поднять необходимую инфраструктуру, нужное количество реплик основного и связанных сервисов, наполнить БД данными. Вручную такое будешь делать чуть ли не дольше, чем выполнять само тестирование. Ну и, кстати, воспроизвести сложные тест-кейсы вручную тоже будет довольно сложно и долго В общем, моя рекомендация, конечно же, доверить это всё нейросети 🧠 Всё необходимое можно поднять в контейнерах, что выглядит довольно безопасно для твоего компа, а тест-кейсы нейросеть воспроизведёт через запросы к поднятым сервисам Можно ещё и попросить её придумать какие-нибудь интересные неочевидные случаи для проверки. Ты можешь удивиться, на что способны сервисы в состоянии гонки за БД при обрыве связи с брокером 🇷🇺 Если не хочешь нагружать свой комп, и у тебя есть хороший тестовый стенд, можно попросить нейронку сделать всё на нём. Она будет отправлять запросы с твоего компа, как будто это делаешь ты. Ну и опять же, тестовые стенды не так страшно сломать. В крайнем случае, вы все вместе поймёте, где было слабое место в инфраструктуре🧠 ⚠️Конечно, важно, чтобы на тестовом стенде не оказалось каких-нибудь чересчур чувствительных данных: персданных пользователей, кредов от прод-сервисов, и прочего, что нейронке не стоит читать лишний раз 🔓 В общем, ещё одна вполне практичная сфера применения нейросетей в разработке — это тестирование на всех уровнях: написать тесты, проверить тесты, протестировать изменения⚡️

  • 🚀 Новая серия: от кода до железа Когда в мою жизни пришла #ИИшница, я понял, что с ней можно очень глубоко погрузиться в любую тему: как в устройство баз данных, так и в устройство программ😣 Мне стало интересно разложить прям по байтикам максимально простой однострочный "Hello world!"🖥 Оказалось, что он как торт 🎂 (или как лук🧅, или как огр 🤥), состоит из нескольких слоёв 🔥 Между строкой, которую ты пишешь, и транзистором, который её исполняет, ещё целая стопка: компилятор, рантайм, операционная система, и процессор. Давай вместе пройдём через все эти слои сверху вниз🔽 Начнём с самого начала. Вот файл hello.cs: Console.WriteLine("Hello, World!"); Вот команда запуска: dotnet run hello.cs ⚙️ Что происходит под капотом Код на C# не исполняется напрямую на процессоре. Сначала компилятор (его зовут Roslyn) переводит наш код в промежуточный байт-код — IL (Intermediate Language). Это ещё не инструкции процессора, а переносимый «полуфабрикат». Потом стартует рантайм — CoreCLR, движок .NET. Он берёт IL и уже на лету, прямо во время работы, до-компилирует его в настоящие инструкции процессора. Это называется JIT (Just-In-Time): метод компилируется в момент первого вызова. Важная деталь про масштаб: IL-код нашей строки весит 11 байт, а рантайм, который его исполняет, весит 77 МБ. То есть наш с тобой код — это тонкая надстройка над огромным механизмом, который работает задолго до первой инструкции нашего кода и делает всё необходимое, чтобы мы увидели заветные строки на экране⚙️ Что именно он делает? Создаёт потоки Поток (thread) — это отдельная линия исполнения внутри процесса нашей программу, которую операционная система раскладывает по ядрам процессора. В одном процессе их может быть достаточно много. Сколько? Правильный ответ, конечно, «зависит». При отладке их можно получить целых 7! 7️⃣ И число это не фиксированное, его можно регулировать 🔧 А что ещё? Занимает память 🫡 Физически процесс держит около 24 МБ, но нашей программы там почти нет: больше 20 МБ — это сам рантайм (движок CLR, JIT-компилятор, библиотека базовых типов). Из нашего там два места: 🔲стеки потоков: у каждого из семи потоков свой стек под локальные переменные и кадры вызовов функций. Под него резервируется несколько мегабайт адресов, но физически занято по паре килобайт на поток 🕳 GC-куча (heap): здесь живут объекты, созданные через new. За этим простым словом скрывается целый мир со своими регионами: 👶gen0/👨‍🦱gen1/👴gen2 — здесь хранятся разные поколения «обычных» объектов (размером до 85 000 байт) 🌾 LOH — большие объекты (от 85 000 байт) 📍 POH — закреплённые (pinned) объекты 🧊 FOH — литералы и «вмороженные» объекты И это далеко не всё! 🅰️ Что с этим делать 🟢 Программы работают на целой стопке слоёв: от кода и компилятора до операционной системы и процессора 🟢 За классическим «Hello world» стоит огромный механизм — рантайм, который делает всё необходимое, что наша программа сработала в том окружении, в котором оказалась Если тебе что-то не понятно из вышесказанного👆 — не страшно, мне тоже многое не понятно, так что будем разбираться вместе🫂 Постепенно углубимся в каждую тему и разберёмся, как это всё работает💪 🧑‍💻dp🥁 #dotnet #csharp #инженерныештучки #heavywednesday

  • Готовлю масштабное обновление бэкенда Занимательных историй💡 Одно из достижений: оптимизация потребления памяти📈 🔴 Красный график показывает, как старая версия потребляет память под нагрузкой 18 RPS в течение 10 минут 🟢 Зелёный - новая версия, те же параметры Вывод: в новой версии устранена потенциальная утечка памяти и в целом оптимизировано потребление😎 Историю изменений можешь посмотреть на гитхабе

  • Дала жизнь агента, даст и клиента☯️

  • Способы применения нейронок: хаос-инженер 🤩 Иногда баг возникает в очень специфических условиях: большая конкуренция за ограниченные вычислительные ресурсы, нестабильная сеть, внезапно отвалившийся брокер сообщений, и т. п. Однажды мне надо было починить нестабильный тест в пайплайне сборки, который в разных прогонах мог как пройти, так и упасть, без видимых на то причин. Причиной же было то, что пайпланы выполняются на не самых мощных раннерах, и как раз в условиях конкуренции могли не срабатывать условия для выполнения теста, то есть он был ещё и весьма хрупок. На моём компе этот тест стабильно проходил, поэтому мне нужно был подобрать такие ограничивающие условия, при которых он начнёт падать, чтобы потом убедиться, что внесённое исправление действительно устраняет проблему 🪲 Сложность в том, что зависимость немонотонная: если ресурсов слишком много, все необходимые операции успевают выполниться вовремя. Если чересчур мало, то операции настолько медленны, что тоже, как ни странно, успешно выполняются. Надо было подобрать золотую середину в несколько итераций, что вручную может выполняться довольно долго. Я попросил нейросеть помочь подобрать нужные параметры, и она стала итеративно запускать тест в контейнере с определёнными ограничениями и несколько раз прогонять его в таком окружении. И это сработало: удалось получить воспроизводимое нестабильное поведение и проверить исправление 🎉 С обрывом связи похожая история. #ИИшница может воссоздать условия, в которых имитируется обрыв связи или отключение нужного сервиса. Вручную писать такое - тоже не самая простая задача, на отладку которой могла бы уйти куча времени ⏳ В общем, нейросеть позволяет довольно быстро подготовить эксперимент, запустить его, и получить воспроизводимый сценарий, и это ещё один интересный способ использовать ИИ в разработке: не только проанализировать код, но и испытать его в стрессовых условиях

  • 6 авг.561из yadialogsnews

    Уважаемые разрабочики навыков, спешим поделиться новостью. Навыки перестают быть доступны в чате с Алисой AI и в мобильных приложениях. Алиса постоянно развивается и технически меняется. В рамках этой эволюции мы были вынуждены отключить отображение и запуск развлекательных и познавательных навыков непосредственно в чате с Алисой AI и внутри мобильных приложений. Отметим, что навыки будут доступны пользователям на других платформах, например, на Яндекс Станциях. В чате мы сейчас фокусируемся на тех сценариях, к которым пользователи наиболее часто обращаются. К сожалению, навыки в них не входят. Мы постараемся позже вернуться к вам с небольшим рассказом о планах развития Диалогов.

  • Уходит эпоха😢 Навыки Алисы 🙂 теперь доступны только на Яндекс станциях 🥹 Навыки перестают быть доступны в чате с Алисой AI и в мобильных приложениях. <...> сейчас фокусируемся на тех сценариях, к которым пользователи наиболее часто обращаются. К сожалению, навыки в них не входят В целом, это заметно по снижающемуся траффику к Занимательным историям 💡 В чатах для меня, как разработчика, было хорошо то, что в них отображается реклама, и на монетизации с неё я оплачиваю инфраструктуру для игры. В последнее время доля показов так же снижается, так что бюджет теперь в минусе. Надеюсь, что появится способ компенсировать этот утраченный канал монетизации. Но вообще есть ощущение, что навыки в целом перестают пользоваться спросом, поэтому не сегодня-завтра они в могут перестать работать в Алисе. Думаю, я буду поддерживать игру, пока есть спрос (62 000 пользователей в месяц) и бюджет на инфру, а что будет дальше - увидим😃 Подробности ниже👇

  • Почти всё лето мы с тобой изучали внутрянку БД на примере #postgresql: от индексов мы спустились по Б+-деревьям до work mem и узнали насколько глубока восьмиикилобайтовая страница 📄 Теперь поплывём дальше 🛳 На нашей steam state machine мы пойдём по бурным рабочим потокам (worker thread), воочию увидим их освобождение на асинхронном водопаде, который приведёт нас к бескрайнему озеру памяти 🫡 Там мы увидим, как различные объекты сбились в несколько поколений кучи (heap), сдерживаемой лишь DOTNET_GCHeapHardLimitPercent. Некоторые из них довольно глубоко пустили корни, так что финализировать их приходится в несколько проходов, а некоторые оказались настолько холодными, что образовали свои айсберги Frozen object heap 🧊 В концов концов мы увидим, как, параллельно с другими, наша программа последовательно впадает в океан ЦПУ🤩 и выполняет своё предназначение в этом круговороте исполнения, печатая у тебя на экране заветные слова: Hello, world! По крайней мере таков горизонт нашего планирования, к которому мы стремимся 🌅 Возможно шторма жизни и обратной связи изменят наш с тобой курс, но мы всё равно будем стремиться к общей цели: лучше узнать платформу, на которой работаем 🗼и прочие #инженерныештучки 🧑‍💻dp🥁 Это #heavywednesday, мои чюваки

  • Эскиз картинки к будущему посту в C# Short posts

  • Способы применения нейронок: аналитик кода 🔍 Часто говорят, что нейросети галлюцинируют 🤪 Обычно этим понятием объясняют явление, когда нейронка достраивать картину самостоятельно в условиях неопределённости 🤔 Если же дать нейросети, например, свою кодовую базу, и спросить что-нибудь по ней, вероятность ошибок становится значительно ниже, ведь ИИшнице не надо будет придумывать архитектуру с нуля, а лишь проанализировать то, что уже есть🧠 Особенно это полезно это, когда нужно разобраться в новом большом сервисе, который ты видишь впервые 🆕 Что интересного можно спросить у ИИ про твой код? Отслеживание пути данных 🗺 Например, пока поле из базе данных попадёт на экран пользователя, оно может: 🟢 несколько раз переименоваться 🟢 пройти через DTO и мапперы 🟢 объединиться с другими полями 🟢 вычисляться на основе нескольких значений Вручную восстановить такую цепочку бывает очень утомительно (особенно, когда путь проходит через несколько сервисов в разных репозиториях): нужно открыть десятки файлов, постоянно переключаться между ними и держать всё это в голове🤯 #ИИшница же способна довольно быстро собрать всю цепочку и показать её целиком⚡️ Диагностика сложных багов 🐞 Можно попросить нейросеть: Проанализируй кодовую базу и найди возможные причинно-следственные связи, которые могли привести к <этому багу>. Покажи, на чём основан каждый вывод. Не додумывай, перепроверяй, уточняй Иногда такой подход позволяет заметить зависимости, до которых вручную пришлось бы добираться очень долго ⚠️Важный момент про безопасность ⚠️ Анализировать корпоративный код нейросетью стоит только тогда, когда это разрешено политиками твоей компании Если внутренние правила прямо запрещают передавать код внешним ИИ-сервисам, то делать этого, конечно, не стоит 🚫 Особенно если речь идёт о публичных облачных нейросетях, работающих за пределами корпоративного контура Если же такого запрета нет, то хорошей практикой будет отключить использование ваших диалогов для обучения модели 🧠 У большинства популярных сервисов такая настройка есть. Это не только снижает вероятность использования ваших данных для обучения, но и в целом является хорошей практикой при работе с корпоративной информацией А если в компании запрещено использовать внешние нейросети, то нередко есть альтернатива — внутренний ИИ-ассистент, развернутый внутри корпоративного контура 🏢 В этом случае лучше пользоваться именно им: кодовая база остаётся внутри инфраструктуры компании, а ты при этом всё равно получаешь преимущества анализа кода с помощью ИИ✨

  • Такой вот сюжет не так давно добавил в #занимательныеистории 🖥

  • Картинка дня 🌇 #ИИшница

  • видео или голосовое, без подписи

  • 🩺 Диагностика — как понять, на что ушла оперативка (часть 2, work_mem наносит ответный удар) 👈 Часть инструментов рассмотрели в прошлом посте, а в этом рассмотрим ещё парочку: 🧰 Что лежит в кэше прямо сейчас Расширение pg_buffercache (мы его уже видели в посте про shared_buffers) показывает поимённо, какие страницы заняли кэш Postgres в данный момент. Удобно, когда надо понять, чем именно забиты те самые 128 MB, выданные под shared_buffers 👥 Кто сейчас активен (дикпик 3) Кроме shared_buffers можно проверить и work_mem, чтобы узнать, сколько соединений работает и что они выполняют. Это показывает представление pg_stat_activity: оно построчно показывает каждое соединение, и там видно текущий запрос от клиента (app) и его состояние. Дальше пользуемся арифметикой work_mem × число операций × число активных соединений, чтобы получить объём памяти, занятый данными для операций Чтобы при этом явно понять, какой клиент выполняет запрос, важно передавать его читаемое название через строку подключения или в запросе, тогда его название отобразится в app 🧠 ⚠️ Ловушка при подсчёте памяти процессов Если помнишь, каждое соединение в Postgres обслуживает отдельный процесс. Казалось бы, сложи память всех процессов и получишь общий расход. Но есть подвох: shared_buffers общий, и операционная система засчитывает его в память каждого процесса. Этот объём называют RSS (resident set size — объём оперативки, занятый процессом). Если просто сложить RSS всех бэкендов, общий shared_buffers посчитается много раз, и итог окажется сильно завышенным. Для суммирования правильнее брать PSS (proportional set size): он делит общую память поровну между процессами, которые ею пользуются 🧯 Если work_mem чересчур раздут Если арифметика подтвердит, что в основном память выделена под обработку запросов, рецепт простой: уменьшить work_mem, сократить число соединений, или поставить перед базой пулер соединений. Пулер (например, PgBouncer) — это прослойка, которая держит небольшой набор постоянных соединений к Postgres и раздаёт их клиентам, что позволяет избежать выделение процесса на подключение каждого клиента. А отдельному тяжёлому запросу можно задать work_mem прямо в нём командой SET LOCAL (она меняет параметр в пределах текущей транзакции). 🅰️ Что унести с собой 🟢 Состав кэша показывает pg_buffercache. Кто сейчас активен, видно в pg_stat_activity 🟢 Складывать RSS процессов не стоит: общий shared_buffers задвоится. Для суммы есть PSS 🧑‍💻dp🥁 #бд #postgresql #инженерныештучки #heavywednesday

  • видео или голосовое, без подписи

  • Это мы с #хитпоинт вчера, сейчас дома уже 🤟

  • видео или голосовое, без подписи

  • Мой stuff truck на сегодня: стул, педаль и стойки, и рюкзак с прочими приблудами. Чуть позже сюда добавится барабан и тарелки 🍽 Для сравнения, второе фото: stuff truck 27 марта, с которого начался мой #гастрольный_сезон🤘 Да, разницы особо нет, просто хотел намекнуть на то, что есть такой хэш-тег, который приведёт тебя на мой гастрольный график 📝

  • видео или голосовое, без подписи

Кодовой Барабанщик — tgindex